Electronic Bill Presentation is a hot topic in e-commerce right now. Sure, every bank has at least one way to pay on-line, and they generally work well; but getting the bills into the hands of the customer generally requires the use of snail mail. If that bill presentation moves on-line and CPC is not involved, they lose big-time, hence this initiative.
I'm not sure what to think-- it seems like a good idea (on-line presentation from an established name, use of standard protocols (http), access from any 'Net connection) but the implementation sounds like it leaves a lot to be desired. Many of the advantages of Internet e-mail (the mail is pushed to me so I don't have to *login* to a web site to get it, I can mail anyone, etc) are not there. Given the choice of receiving bills via an EPOB or via traditional 'Net e-mail, I think I'd prefer e-mail.
Nonetheless, being Candian, I have the chance to try this out... which I am doing. We'll see...
There are a number of developers sites out there with gripe pages about getting the run-around from Unisys. It sounds like companies that have tried to license LZW have ended up doing the run-around on shifting sand! If Unisys standardized thier terms to the point that they could post them publicly (on a web page) and anyone could read them in plain English, it would help.
It's a Good Thing(tm) that the patent runs out in 3 years if it's going to be managed in this way. In the meantime, I wonder if a benevolent giant (IBM?) might be interested in *buying* the patent and making the technology available under more sane terms. The upside could be a nice PR boost and a general sput in the right direction for the web (not that its growth rate is a problem right now:-).
If you're going to use DHCP, then the Right Thing(tm) is to use DDNS for both forward and reverse mapping.
DHCP provides for automatic, dynamic assignment of IP addresses. As others have pointed out, you don't have to use that feature, and you can centrally assign static IPs based on ethernet hardware (MAC) addresses, but that is a feature provided by BOOTP, the ancestor of DHCP. If you're really using DHCP then you're dynamically assigning IPs.
If you're going to dynamically assign IPs, you should have a mechanism for tracking the name-to-IP mapping. DDNS is that mechanism. Using DHCP without DDNS is Broken and The Wrong Thing.
It is only logical that systems that use DHCP should also support DNS. The fact that many of us (including the distro packagers) are too lazy (self-incrimination, not flaim bait) to set up DDNS does *not* mean that it is a bad idea. The fact that MS is doing The Right Thing (in this rare case) also does not mean that it is a bad idea.
So all Unix sysadmins in mixed shops: if you want to continue to have responsibility for IP assignment and DNS, then hear and heed the warning... get DDNS working with DNS on your machines *now*. When Win2000 is deployed in your company (a year from now?) you'll be ready.
Compaq had said that they would support NT for Alpha64. This sounds like MS is saying, "Oh yeah? Drop Alpha32 and kiss Alpha64 goodbye!".
It's interesting to see this in the light of yesterday's "Interview with Original NT OS/2" developers, which stressed the importance of platform independence and portability. With this announcement (correct me if I'm wrong), MS has finally gone from 4 platforms (PPC/MIPS/Alpha/x86) to 1 (x86).
The business model of most "Free" web space providers is based on publishing derivative works. They take your content, add some ads so to provide some revenue, and then distribute that derivative work. Without permission to distribute and to produce derivatives, the business model doesn't work.
This is good news. sar is a useful utility, and the folks at Starnix are good folks.
But SCO is rewriting history in their press releases. "SAR was developed by SCO..." ? Bzzzt.
sar was a standard utility in Unix SVR4.2 and was included in UnixWare and other SVR4.2 releases before SCO bought UnixWare from Novell, and before Novell bought UnixWare from USL. It may have even existed in SVR3.X
No, using NTP (network time protocol) alone won't work because (1) between the time that the system resumes from sleep and the NTP daemon realizes that something is wrong, the clock will be off; (2) the NTP daemon will try to calculate the clock's drift and calculate a correction factor, and that factor will keep changing as the system sleeps for various lengths of time, "skipping" different-sized chunks each time.
apmd, on the other hand, is wired into the APM system and restores the time from the RTC immediately upon resume. apmd+NTP could work very well together.
I picked up an old Toshiba 2400CS (DSTN colour with onboard SCSI (!), 486 w/ 320 MB/8MB). I was anticipating headaches getting it to run Linux, but I found some Linux-on-Toshiba web pages that had Linux replacements for the Toshiba hotkey utilities, XF86 config files, etc. It's all working wonderfully under RH4.2. The hardest part was making it recognize my IBM "Home & Away" (ethernet + modem) adapter during the install so I could mount the CD over NFS. But the diagnostic messages were clear, and I just changed the signature in one of the PCMCIA config files to match the one my card was reporting (apparently there are slightly different models of the card) and I was off to the races.
With very minor tweaking, I now have APM support (init 0 powers off, the LCD and backlights shut down when not in use), the hard drive spins down/up appropriately, I have visual hotkey feedback, my eraserhead pointer (and external mouse!) work properly, the modem and network connection are working, X works, etc. etc.
Couldn't be happier! Now if I only had a bit more RAM...
I know this sounds ignorant, but what is a journaled file system?
A journalled file system writes all of the proposed changes to control structures (superblock, directories, inodes) into a journalling area before making those writes to the actual filesystem, then removes them from the journal after they have been committed to disk. Thus if the system goes down, you can get the disk into a sane state by replaying/executing the intention journal instead of checking every structure; thus an fsck can take seconds instead of minutes (or hours).
For example, if you're going to unlink the last link to a file (aka delete the file), that involves an update to the directory, inode, and free list. If you're on a non-journalled system and update the directory only, you have a file with no link (see/lost+found); if you update the directory and inode only, you have blocks missing from your free list. Both of these require scanning the whole disk in order to fix; but a journalled system would just update the directory, inode, and free list from the journal and then it would be sane.
Problems with journalled filesystems include conflicts with caching systems (e.g., DPT controllers, RAID subsystems with cache) where the intention journal is not committed to physical disk before the writes to the filesystem commence.
Slashdot Mirror
Electronic Bill Presentation is a hot topic in e-commerce right now. Sure, every bank has at least one way to pay on-line, and they generally work well; but getting the bills into the hands of the customer generally requires the use of snail mail. If that bill presentation moves on-line and CPC is not involved, they lose big-time, hence this initiative.
I'm not sure what to think-- it seems like a good idea (on-line presentation from an established name, use of standard protocols (http), access from any 'Net connection) but the implementation sounds like it leaves a lot to be desired. Many of the advantages of Internet e-mail (the mail is pushed to me so I don't have to *login* to a web site to get it, I can mail anyone, etc) are not there. Given the choice of receiving bills via an EPOB or via traditional 'Net e-mail, I think I'd prefer e-mail.
Nonetheless, being Candian, I have the chance to try this out... which I am doing. We'll see...
There are a number of developers sites out there with gripe pages about getting the run-around from Unisys. It sounds like companies that have tried to license LZW have ended up doing the run-around on shifting sand! If Unisys standardized thier terms to the point that they could post them publicly (on a web page) and anyone could read them in plain English, it would help.
:-).
It's a Good Thing(tm) that the patent runs out in 3 years if it's going to be managed in this way. In the meantime, I wonder if a benevolent giant (IBM?) might be interested in *buying* the patent and making the technology available under more sane terms. The upside could be a nice PR boost and a general sput in the right direction for the web (not that its growth rate is a problem right now
If you're going to use DHCP, then the Right Thing(tm) is to use DDNS for both forward and reverse mapping.
DHCP provides for automatic, dynamic assignment of IP addresses. As others have pointed out, you don't have to use that feature, and you can centrally assign static IPs based on ethernet hardware (MAC) addresses, but that is a feature provided by BOOTP, the ancestor of DHCP. If you're really using DHCP then you're dynamically assigning IPs.
If you're going to dynamically assign IPs, you should have a mechanism for tracking the name-to-IP mapping. DDNS is that mechanism. Using DHCP without DDNS is Broken and The Wrong Thing.
It is only logical that systems that use DHCP should also support DNS. The fact that many of us (including the distro packagers) are too lazy (self-incrimination, not flaim bait) to set up DDNS does *not* mean that it is a bad idea. The fact that MS is doing The Right Thing (in this rare case) also does not mean that it is a bad idea.
So all Unix sysadmins in mixed shops: if you want to continue to have responsibility for IP assignment and DNS, then hear and heed the warning... get DDNS working with DNS on your machines *now*. When Win2000 is deployed in your company (a year from now?) you'll be ready.
Compaq had said that they would support NT for Alpha64. This sounds like MS is saying, "Oh yeah? Drop Alpha32 and kiss Alpha64 goodbye!".
It's interesting to see this in the light of yesterday's "Interview with Original NT OS/2" developers, which stressed the importance of platform independence and portability. With this announcement (correct me if I'm wrong), MS has finally gone from 4 platforms (PPC/MIPS/Alpha/x86) to 1 (x86).
The business model of most "Free" web space providers is based on publishing derivative works. They take your content, add some ads so to provide some revenue, and then distribute that derivative work. Without permission to distribute and to produce derivatives, the business model doesn't work.
This is good news. sar is a useful utility, and the folks at Starnix are good folks.
But SCO is rewriting history in their press releases. "SAR was developed by SCO
sar was a standard utility in Unix SVR4.2 and was included in UnixWare and other SVR4.2 releases before SCO bought UnixWare from Novell, and before Novell bought UnixWare from USL. It may have even existed in SVR3.X
No, using NTP (network time protocol) alone won't work because (1) between the time that the system resumes from sleep and the NTP daemon realizes that something is wrong, the clock will be off; (2) the NTP daemon will try to calculate the clock's drift and calculate a correction factor, and that factor will keep changing as the system sleeps for various lengths of time, "skipping" different-sized chunks each time.
apmd, on the other hand, is wired into the APM system and restores the time from the RTC immediately upon resume. apmd+NTP could work very well together.
I picked up an old Toshiba 2400CS (DSTN colour with onboard SCSI (!), 486 w/ 320 MB/8MB). I was anticipating headaches getting it to run Linux, but I found some Linux-on-Toshiba web pages that had Linux replacements for the Toshiba hotkey utilities, XF86 config files, etc. It's all working wonderfully under RH4.2. The hardest part was making it recognize my IBM "Home & Away" (ethernet + modem) adapter during the install so I could mount the CD over NFS. But the diagnostic messages were clear, and I just changed the signature in one of the PCMCIA config files to match the one my card was reporting (apparently there are slightly different models of the card) and I was off to the races.
With very minor tweaking, I now have APM support (init 0 powers off, the LCD and backlights shut down when not in use), the hard drive spins down/up appropriately, I have visual hotkey feedback, my eraserhead pointer (and external mouse!) work properly, the modem and network connection are working, X works, etc. etc.
Couldn't be happier! Now if I only had a bit more RAM...
A journalled file system writes all of the proposed changes to control structures (superblock, directories, inodes) into a journalling area before making those writes to the actual filesystem, then removes them from the journal after they have been committed to disk. Thus if the system goes down, you can get the disk into a sane state by replaying/executing the intention journal instead of checking every structure; thus an fsck can take seconds instead of minutes (or hours).
For example, if you're going to unlink the last link to a file (aka delete the file), that involves an update to the directory, inode, and free list. If you're on a non-journalled system and update the directory only, you have a file with no link (see /lost+found); if you update the directory and inode only, you have blocks missing from your free list. Both of these require scanning the whole disk in order to fix; but a journalled system would just update the directory, inode, and free list from the journal and then it would be sane.
Problems with journalled filesystems include conflicts with caching systems (e.g., DPT controllers, RAID subsystems with cache) where the intention journal is not committed to physical disk before the writes to the filesystem commence.