Evince seems to do a splendid job of rendering (and printing) PDFs that don't have forms in them. Does anyone know if the forms extension is part of the ISO standard, or is it a proprietary Adobe thing? Because if it is a proprietary extension, it hardly seems fair to blame Linux for not handling it properly, nor for Adobe's inability to make a product that doesn't suck.
Earlier this month while doing my US Federal taxes, I ended up installing the Windows version of Acrobat Reader 8 under Wine just to fill in the IRS PDF-based tax forms. None of the other readers I tried were both A) capable of handling the IRS forms correctly; and B) stable enough on Ubuntu 8.10 to actually use. Other readers I tried included Evince, another Open Source one (I forget which), and several versions of Acrobat Reader for Linux (both from the Ubuntu restricted repo and direct from Adobe).
The Windows version under Wine was an iffy proposition at best, but I was able to get it working eventually. The installers for 7.x and 9.x bombed outright; 8.x installed, but wouldn't let you click past the EULA! Once past the EULA issue (regedit to the rescue!), 8.x on Wine worked OK. Workable, but far from an ideal solution...
Scrubbing and chipkill shouldn't cost any extra to implement (beyond the cost of using ECC memory modules in the first place) if you're using an AMD Athlon64/Opteron/Phenom processor. The memory controller is on the CPU, and already supports these features.
Years ago I had a conversation about parity and ECC memory with an employee of Gateway. The gist of Gateway's position was "Why should we bother checking for memory errors when Windows is going to crash twice a day anyway?" (This was back in the Win95 days IIRC.)
Unfortunately, many desktop motherboards won't use ECC even if you install appropriate memory modules. Check the BIOS section of the motherboard manual to see if there is an option to enable it. Memtest86/Memtest86+ will tell you whether ECC is enabled; I've encountered at least one motherboard that had a BIOS setting for ECC that did absolutely nothing (even when set to 'enabled', ECC was not being used).
I always run Memtest86 (or Memtest86+) for at least a couple of full passes (preferably overnight) whenever I build a new system or upgrade RAM. It gives you a pretty good "zeroth order" indication of whether your motherboard and RAM are stable. I don't even bother trying to install an OS until I can get Memtest86 to run clean. As others have already noted, if it reports errors, you can be pretty certain that you have a problem; if it runs clean overnight the RAM is probably OK, but there is still a slight chance that there may be some issues.
Regarding ECC, I think it is a travesty that most consumer desktop motherboards do not even have the option of enabling it in the BIOS. When I put together PCs, I try to use motherboards which I know support ECC, and pay the extra few dollars for ECC memory modules. I've found that Asus desktop motherboards often do support ECC (unlike most of the other brands).
The biggest hurdles are probably the shelf life of the hard drive and any electrolytic capacitors in the system. The spindle motor lubricant will dry out, as will the electrolyte in the capacitors. I seriously doubt that it will still be bootable 50 years from now.
Sadly, I don't think there is a good answer here.
VMs or emulators are potentially a partial answer, but you're still counting on a compatible VM player being available decades from now. And I don't think this is really what you had in mind regardless; it seems like you were wanting to preserve the actual hardware.
This argument only holds water if the drives are all put in service at the same time, and experience the same usage patterns.
A better argument for not buying them all at once is that the price for a given capacity of drive will tend to come down over time, so you're probably going to be paying more if you buy them all at once, versus only buying them as they are needed.
If you'd read the linked discussion at TR and the KB article at Seagate, you'd know that the problem is not limited to just the 1.5TB drives. A large number of models (of varying capacities) from both Seagate and Maxtor are potentially affected.
...but it pisses my wife off because I'm always late for dinner. On the whole, I'd say it's a (slight) plus because I spend a couple of hours a month less on commuting, which saves time, gas, and money.
Yes, I've occasionally been called in on the "off" Friday, but it has not happened often enough to really piss me off (yet).
The comical aspect is our time reporting system. Since we do a lot of government contract work, we have to keep detailed time records. Furthermore, the time reporting system they've set up requires that we report at least 40 hours per *week* (including holiday/sick/vacation time). The way they've dealt with this is by decreeing that the end of the work week occurs at noon on Friday; so Friday afternoon of the "on" week has to be reported in the following week's time record. Explaining this to new employees is fun!:D
VirtualBox really does seem to be on a fast track lately. I've mostly switched over to it (from VMware), for anything that doesn't require SMP. Stable support for 2-4 cores would be the killer feature which could convince me to ditch VMware for good.
Ahh, the old 680x0 based Sun workstations... fun times. I remember back in the late '80s when I figured out how to get direct access to the frame buffer via remote (rsh) shell session. Had a blast flipping the screen image on co-workers' workstations upside-down (one guy actually started whacking the monitor to try and get it to flip back), making the screens snow for the holidays, etc...:D
It has been nearly a month since the original breach was noticed. That's an awful long time for people to be left hanging, wondering whether their systems are running potentially compromised packages.
...that at the company where I work (privately held defense contractor), it is on the order of 20:1 or higher, but I really do not know for certain. I work at a small satellite R&D office; our situation is rather different than that of the company as a whole since we are entirely focused on R&D, whereas the home office has a significant manufacturing aspect as well.
We have no full-time IT staff in our office, but several of us deal with IT issues as a sideline (it probably represents about 10% of what I do in a typical work week, and a similar percentage of overall staff hours in our office). The home office is totally Windows-centric, whereas we (in our office) are running a mix of Windows and Linux infrastructure, with Linux playing an increasingly prominent role.
I imagine they weighed the disruption of forcing everyone to update their keys against the odds of some sysadmin getting tricked into installing one of the bad packages. I haven't heard anything yet about sightings of the bogus packages "in the wild", but I think we need to assume that it is a possibility.
On the other hand, I would think that with a package as critical as OpenSSH, sysadmins would be careful to only install it from official repositories (which, according to the announcement from Redhat, have not been compromised).
Both the Fedora and Redhat announcements actually say the opposite -- i.e., that none of the official repositories were compromised. The issue is that there may now be packages circulating in the wild which are not legitimate, but appear to be signed with the official Fedora/Redhat keys.
If I'm reading things right, it would take the equivalent of a phishing attack against a server admin (i.e. convince them to install a trojaned package which appears to be legit) to compromise a sever running either of these distros. The official repositories are still secure, and if you only install from the official repositories, you will not be affected.
The people I currently work for deal with large (10s of GBs) financial databases. They used to ship the database out (to their clients) on a stack of CDs, until the database got too large for that to be practical. Now they just ship the database on a Firewire hard drive. After the client has loaded the data into their database server, they ship the hard drive back.
Hey, someone else who actually knows what Lambics are... and likes them!:D
I haven't gotten brave enough to try brewing my own Lambics yet, but I'll get around to it eventually. My goal is to attempt brewing every style of beer (well, at least all the ones recognized by the BJCP, plus a few other oddball ones like Sahti) at least once!
Well... SCHECK pins don't actually have anything to do with MP operation per se; they are related to ECC support. Not sure why they left them out of the XP data sheet... it's all rather bizarre if you ask me.
Well... the SCHECK pins are documented in the data sheet for the AMD 761 (uniprocessor northbridge) chip, and the data sheet for the older (T-Bird) non-MP Athlons. Seems rather inconsistent...
But the MPX chipset uses point-to-point links between the northbridge and each CPU, not a shared bus. Seems to me the timings should be no more critical than on a standard uniprocessor XP system, since the interface is the same.
Can you cite any references regarding your claim of cache coherency problems? Seems to me that cache coherency issues would result in more than just slowdowns -- I'd expect it to cause outright crashes. Given that many people (myself included) have used modded XPs in SMP systems successfully, this smells like unfounded speculation/FUD to me.
Slashdot Mirror
Evince seems to do a splendid job of rendering (and printing) PDFs that don't have forms in them. Does anyone know if the forms extension is part of the ISO standard, or is it a proprietary Adobe thing? Because if it is a proprietary extension, it hardly seems fair to blame Linux for not handling it properly, nor for Adobe's inability to make a product that doesn't suck.
Earlier this month while doing my US Federal taxes, I ended up installing the Windows version of Acrobat Reader 8 under Wine just to fill in the IRS PDF-based tax forms. None of the other readers I tried were both A) capable of handling the IRS forms correctly; and B) stable enough on Ubuntu 8.10 to actually use. Other readers I tried included Evince, another Open Source one (I forget which), and several versions of Acrobat Reader for Linux (both from the Ubuntu restricted repo and direct from Adobe).
The Windows version under Wine was an iffy proposition at best, but I was able to get it working eventually. The installers for 7.x and 9.x bombed outright; 8.x installed, but wouldn't let you click past the EULA! Once past the EULA issue (regedit to the rescue!), 8.x on Wine worked OK. Workable, but far from an ideal solution...
No argument here. But then, you could've probably guessed that from my nick. :D
(FWIW I've been coding for ~30 years, and brewing my own beer for about 15!)
Scrubbing and chipkill shouldn't cost any extra to implement (beyond the cost of using ECC memory modules in the first place) if you're using an AMD Athlon64/Opteron/Phenom processor. The memory controller is on the CPU, and already supports these features.
Years ago I had a conversation about parity and ECC memory with an employee of Gateway. The gist of Gateway's position was "Why should we bother checking for memory errors when Windows is going to crash twice a day anyway?" (This was back in the Win95 days IIRC.)
Unfortunately, many desktop motherboards won't use ECC even if you install appropriate memory modules. Check the BIOS section of the motherboard manual to see if there is an option to enable it. Memtest86/Memtest86+ will tell you whether ECC is enabled; I've encountered at least one motherboard that had a BIOS setting for ECC that did absolutely nothing (even when set to 'enabled', ECC was not being used).
I always run Memtest86 (or Memtest86+) for at least a couple of full passes (preferably overnight) whenever I build a new system or upgrade RAM. It gives you a pretty good "zeroth order" indication of whether your motherboard and RAM are stable. I don't even bother trying to install an OS until I can get Memtest86 to run clean. As others have already noted, if it reports errors, you can be pretty certain that you have a problem; if it runs clean overnight the RAM is probably OK, but there is still a slight chance that there may be some issues.
Regarding ECC, I think it is a travesty that most consumer desktop motherboards do not even have the option of enabling it in the BIOS. When I put together PCs, I try to use motherboards which I know support ECC, and pay the extra few dollars for ECC memory modules. I've found that Asus desktop motherboards often do support ECC (unlike most of the other brands).
Yeah, but I think his intent was to preserve the *actual* system, not just an emulation of it.
The biggest hurdles are probably the shelf life of the hard drive and any electrolytic capacitors in the system. The spindle motor lubricant will dry out, as will the electrolyte in the capacitors. I seriously doubt that it will still be bootable 50 years from now. Sadly, I don't think there is a good answer here. VMs or emulators are potentially a partial answer, but you're still counting on a compatible VM player being available decades from now. And I don't think this is really what you had in mind regardless; it seems like you were wanting to preserve the actual hardware.
This argument only holds water if the drives are all put in service at the same time, and experience the same usage patterns.
A better argument for not buying them all at once is that the price for a given capacity of drive will tend to come down over time, so you're probably going to be paying more if you buy them all at once, versus only buying them as they are needed.
That works both ways. By buying in bulk, maybe you'll get a truckload of drives that are all trouble-free! :D
If you'd read the linked discussion at TR and the KB article at Seagate, you'd know that the problem is not limited to just the 1.5TB drives. A large number of models (of varying capacities) from both Seagate and Maxtor are potentially affected.
...but it pisses my wife off because I'm always late for dinner. On the whole, I'd say it's a (slight) plus because I spend a couple of hours a month less on commuting, which saves time, gas, and money.
:D
Yes, I've occasionally been called in on the "off" Friday, but it has not happened often enough to really piss me off (yet).
The comical aspect is our time reporting system. Since we do a lot of government contract work, we have to keep detailed time records. Furthermore, the time reporting system they've set up requires that we report at least 40 hours per *week* (including holiday/sick/vacation time). The way they've dealt with this is by decreeing that the end of the work week occurs at noon on Friday; so Friday afternoon of the "on" week has to be reported in the following week's time record. Explaining this to new employees is fun!
VirtualBox really does seem to be on a fast track lately. I've mostly switched over to it (from VMware), for anything that doesn't require SMP. Stable support for 2-4 cores would be the killer feature which could convince me to ditch VMware for good.
Ahh, the old 680x0 based Sun workstations... fun times. I remember back in the late '80s when I figured out how to get direct access to the frame buffer via remote (rsh) shell session. Had a blast flipping the screen image on co-workers' workstations upside-down (one guy actually started whacking the monitor to try and get it to flip back), making the screens snow for the holidays, etc... :D
It has been nearly a month since the original breach was noticed. That's an awful long time for people to be left hanging, wondering whether their systems are running potentially compromised packages.
Nitpick: Actually, the 5.25" disks came a little later than that. Floppy disks in 1970 were 8".
We have no full-time IT staff in our office, but several of us deal with IT issues as a sideline (it probably represents about 10% of what I do in a typical work week, and a similar percentage of overall staff hours in our office). The home office is totally Windows-centric, whereas we (in our office) are running a mix of Windows and Linux infrastructure, with Linux playing an increasingly prominent role.
I imagine they weighed the disruption of forcing everyone to update their keys against the odds of some sysadmin getting tricked into installing one of the bad packages. I haven't heard anything yet about sightings of the bogus packages "in the wild", but I think we need to assume that it is a possibility. On the other hand, I would think that with a package as critical as OpenSSH, sysadmins would be careful to only install it from official repositories (which, according to the announcement from Redhat, have not been compromised).
Both the Fedora and Redhat announcements actually say the opposite -- i.e., that none of the official repositories were compromised. The issue is that there may now be packages circulating in the wild which are not legitimate, but appear to be signed with the official Fedora/Redhat keys. If I'm reading things right, it would take the equivalent of a phishing attack against a server admin (i.e. convince them to install a trojaned package which appears to be legit) to compromise a sever running either of these distros. The official repositories are still secure, and if you only install from the official repositories, you will not be affected.
The people I currently work for deal with large (10s of GBs) financial databases. They used to ship the database out (to their clients) on a stack of CDs, until the database got too large for that to be practical. Now they just ship the database on a Firewire hard drive. After the client has loaded the data into their database server, they ship the hard drive back.
I haven't gotten brave enough to try brewing my own Lambics yet, but I'll get around to it eventually. My goal is to attempt brewing every style of beer (well, at least all the ones recognized by the BJCP, plus a few other oddball ones like Sahti) at least once!
Well... SCHECK pins don't actually have anything to do with MP operation per se; they are related to ECC support. Not sure why they left them out of the XP data sheet... it's all rather bizarre if you ask me.
Well... the SCHECK pins are documented in the data sheet for the AMD 761 (uniprocessor northbridge) chip, and the data sheet for the older (T-Bird) non-MP Athlons. Seems rather inconsistent...
Can you cite any references regarding your claim of cache coherency problems? Seems to me that cache coherency issues would result in more than just slowdowns -- I'd expect it to cause outright crashes. Given that many people (myself included) have used modded XPs in SMP systems successfully, this smells like unfounded speculation/FUD to me.