Important features for good Gbit performance in PC-like systems:
PCI-X: a full-width (64 bit), full-speed (133MHz, quad-clocked) PCI-X bus gives 1064Mbyte/s peak bandwidth, shared between all devices on that PCI-X segment
Multiple PCI-X segments: this is already happening on some high-end boards (e.g. the Newisys board used in Sun's quad-Opteron v40z).
It's a shame, then, that nVidia seem to have decided that geforce2go-based notebooks running kernels newer than 2.6.10 or newer are not worth maintaining their drivers for.
Rely on binary drivers, and sooner or later you get screwed.
My outlook on ID cards is very different to a normal persons - pretty much any person who has had contact with the military has a different outlook on them. I have no qualms about registering for an ID card, after all I need to register to vote, register to drive, register to own property, register to travel outside the country, register to have a bank account.
Actually, you don't need to do any of those things, so if you felt strongly enough, you could choose not to interact with those organisations and not need to register anything.
However, we are all compelled to interact with the state, so if the government's ID card/database proposals become law, every (legal) citizen will be compelled to register and carry ID. In effect, it becomes a license to live, in the same way that you need a dog license. Excuse me, but I don't live by permission of the state.
All of those things bring the burden of proof of identity on you, and a government backed proof would make all of these things easier.
Well, until there's a cockup, or you're the victim of identity theft (see Brazil!) and no-one will believe that you're not the terrorist, paedophile, tax-evading, kitten-boiling Richard Price because officially, the card and database are "100% foolproof".
I'd rather be blown up by a suicide terrorist than see you unsafely convicted (and that's assuming ID cards would even do anything to prevent the former anyway).
What if I don't want the latest & greatest files in the respository?
Why would you want to run anything other than the latest and greatest security-fixed, stable and tested packages? Bearing in mind that if you're using dependent FOSS packages, they'll probably be rebuilt and repackages fairly quickly after any updates (if necessary). That only really leaves the case where you're running some closed application; if you are, you'll probably be running RHEL or similar, and RH will be communicating with the ISV. If the ISV can't get a new package built and validated in time for the official updates, that's probably a sign you don't want to be doing business with that particular ISV. If they do, but the updates break the application, similarly. Besides, you're testing on non-production machines before pushing updates to the production machines, right?
Can I check all packages against a particular OS level? On Solaris, I can say "Check that I have all packages released in Solaris x.y.z patch 5, which was released on June 2, 2005"? Can I do that with Yum?
Conceivably, though, there's no reason why RH, or anyone else for that matter, couldn't put together a series of snapshot repositories. Then you could do that with yum.
That would be a very odd thing to do in FOSS-world, though.
With Linux it's the opposite. You need to check the version of each individual package. You have an md5 string to compare against the.deb,.rpm or.tar.gz file, but how can you verify all components in the system?
rpm --verify -a
and to check you've got all the current updates:
yum check-update
This is on FC3, but both yum and rpm have been around for quite some time.
Dvorak's argument seems to boil down to people being able to dual-boot MacOS with Windows on their Macs in future. I don't see that as a significant factor, and certainly not on the enterprise server or desktop (which never dual boot, with the possible exception of sales engineers' laptops and the like). I don't see that Apple merely changing CPU makes the Mac any more or less easy for developers to target. It's not like there's much assembly code being written any more.
That said, the Mac is acting - and will continue to act - as a retarding factor to Linux desktop adoption. Essentially, if you don't like tweaking, MacOS X is "desktop Linux" available today, and with Microsoft Office, QuickTime and all the rest. In this respect, RH got it right by shifting focus from the hobbyist/home user desktop. Me, I enjoy the tweaking, and consider it a fair price to pay to avoid being locked into anyone's proprietary software, whether Microsoft or Apple. Each to their own though; I gather some people actually use computers to do their real job, strange as that might seem!
Of course, as MacOS X is more-or-less a UNIX, it can be argued that any retardation it causes Linux is balanced by the invigorating effect it gives to UNIX-like OSs like Linux.
But until it comes bundled, then game developers won't develop games for [keyboard/mouse]
Not necessarily. If it was important enough to the console manufacturer, they could specify that the only guaranteed way for games to read input events was through the official functions of the official libraries. These could handle alternative controllers transparently (e.g. by allowing the user to assign events before the game loads). The developer would then have to actively put in work so as not to support alternatives (some will probably be stupid enough to do so, I guess, though).
What's silly is the assertion that it is possible to "punish" a company. All it does is raise the costs, and therefore the price of the end products.
Charging manufacturers a 'recycling tax' at the point of sale or manufacture isn't about punishing them, it's about forcing them to internalise the externalities they would otherwise leave to society to pay for. It's a counterpoint to a belief that profits should be privatised whilst costs are socialised wherever possible.
charging a $6 to $10 disposal fee on every computer and television purchased. Maine puts the onus on manufacturers, demanding they pay the full cost of recycling
which they swiftly pass onto consumers. Net result: consumers always pay for recycling (which incidentally sounds rather normal).
But it can mean that manufacturers then take steps to make their products more easily recyclable (since if they are obliged to do it, they might as well make it easy for themselves).
Just tatoo a big "T" on everyone's forehead. Makes the screening even easier, and just about as effective.
No, no, no. If you invert the result, it'll actually be about 99.99% accurate. What you really need to do is tattoo 'T' on 50% of the world population's forehead. Then you end up with something as effective as ID cards.
...I'm looking at, so far, are Patchlink and Managesoft. Maybe even Symantec's ON iPatch, if they can be bothered to get back to me (I think they've renamed their product too, but they haven't bothered to tell me that either).
My current employer is a UK university with Windows PCs numbering in the thousands.
S.M.A.R.T. isn't really analogous; you need to poll a drive's S.M.A.R.T. characteristics periodically, and run periodic tests (which can impair performance whilst they're running). It also doesn't give you 'I've remapped block X' messages, merely 'I've remapped another block'. Besides, what you'd be after would be 'I thought you should know - I had a few problems reading block X just now'.
That said, someone who's familiar with the ATA command set (which is pretty similar to SCSI's command set anyway) might well be able to point to a command that enables the same level of notification as SCSI provides.
After a single sector read error you need to resync the disks, risking that another sector is not readable on the remaining disk, while it would have been valid on the disk that is now the target of the copy.
Excellent reasoning! I've now become convinced that Linux's RAID-1 should work as you wrote in his post. Unfortunately, I'm in pretty much the same boat as you with respect to getting it fixed.:-(
I think the poster was actually referring to enterprise SATA drives, like WD's raptor drives.
WD are pretty much unique in that they don't make SCSI drives, therefore there are no SCSI drives that use exactly the 'same physical hardware' as those ESATA Raptors.
That said, what Seagate do differently between their Personal (i.e. [S]ATA) and Enterprise Storage (SCSI and ESATA) may well be different for other manufacturers, of course.
SCSI drives usually make use of the latest technology. ATA uses whatever older technology has been cost-engineered to a suitable price-point
SCSI drives usually are a couple of years behind in drive capacity relative to ATA drives. This seems to contradict the above.
Good point. I was referring to 1.4.2/1.4.3 from the Seagate paper. Perhaps it would be more accurate to say that SCSI gets mechanical technology improvements first (hence faster rotational speeds and seek times) whereas ATA gets new recording technologies first...
Your other reply was informative, too. I think I agree with you on how Linux RAID-1 should work.
Part of me wonders if this explains the anecdotal stories that SCSI disks are more reliable than their cheaper ATA counterparts - even when they use the same physical hardware. Perhaps (and this is blind speculation) the drives with fewer errors get sold to the customers willing to pay more.
Sort of. According to this paper from Seagate, the main differences between SCSI and ATA are:
SCSI drives are individually tested, rather than tested in batch
SCSI drives typically have a 5 year warranty, rather than 1 year for ATA (note that Seagate's ATA drives also have 5 years, and WD's Special Edition -JB ATA drives have 3 years).
SCSI drives usually have higher rotational speeds (i.e. 10K or 15K RPM vs. 7200RPM)
SCSI drives usually make use of the latest technology. ATA uses whatever older technology has been cost-engineered to a suitable price-point
The physical and programming interface
I also suspect that SCSI drives have a larger number of reserved blocks for remapping, and that they remap blocks on read operations when the ECC indicate that a block has crossed some threshold of near-unreadability. This would account for a) SCSI drives' lower capacities and b) a report I had from a SCSI-using friend running BSD who reports that a 'remapping' message turned up in his syslog without needing any special action to invoke.
By contrast, in my experience, ATA drives only remap failed blocks on write operations. Lots of people think that when a drive returns a read error on a file, it's only fit for the bin, but I've forced the remapping to take place by writing to the affected blocks (either by zeroing the entire partition or drive using dd or badblocks -w, or by removing the affected file then creating a large file that fills all unallocated space in a partition, then removing it to reclaim the space).
This indicates that/dev/hde is far from exhausting its supply of reserved blocks (the first 100) and never has been (the second 100, which is 'worst'). When it crosses the threshold (36) (or the threshold of any of the other 'Pre-fail' attributes for that matter), failure is imminent.
Does RedHat purposely make Fedora incompatible with RHEL to protect their "semi-proprietary" RHEL product line? Or are they incompatible just because Fedura version N will become RHEL version N+1?
The latter, pretty much; RHEL3 was RH9-ish, RHEL4 is FC3-ish.
Obviously, though, RH benefit from there being such a clear differentiator.
Slashdot Mirror
PCI-X: a full-width (64 bit), full-speed (133MHz, quad-clocked) PCI-X bus gives 1064Mbyte/s peak bandwidth, shared between all devices on that PCI-X segment
Multiple PCI-X segments: this is already happening on some high-end boards (e.g. the Newisys board used in Sun's quad-Opteron v40z).
Network drivers which support NAPI (e.g. Intel's PRO/1000 NICs) are much more likely to achieve Gbit speeds in practice
Rely on binary drivers, and sooner or later you get screwed.
Actually, you don't need to do any of those things, so if you felt strongly enough, you could choose not to interact with those organisations and not need to register anything.
However, we are all compelled to interact with the state, so if the government's ID card/database proposals become law, every (legal) citizen will be compelled to register and carry ID. In effect, it becomes a license to live, in the same way that you need a dog license. Excuse me, but I don't live by permission of the state.
All of those things bring the burden of proof of identity on you, and a government backed proof would make all of these things easier.
Well, until there's a cockup, or you're the victim of identity theft (see Brazil!) and no-one will believe that you're not the terrorist, paedophile, tax-evading, kitten-boiling Richard Price because officially, the card and database are "100% foolproof".
I'd rather be blown up by a suicide terrorist than see you unsafely convicted (and that's assuming ID cards would even do anything to prevent the former anyway).
jwz is responsible for many significant *NIX applications.
Why would you want to run anything other than the latest and greatest security-fixed, stable and tested packages? Bearing in mind that if you're using dependent FOSS packages, they'll probably be rebuilt and repackages fairly quickly after any updates (if necessary). That only really leaves the case where you're running some closed application; if you are, you'll probably be running RHEL or similar, and RH will be communicating with the ISV. If the ISV can't get a new package built and validated in time for the official updates, that's probably a sign you don't want to be doing business with that particular ISV. If they do, but the updates break the application, similarly. Besides, you're testing on non-production machines before pushing updates to the production machines, right?
Can I check all packages against a particular OS level? On Solaris, I can say "Check that I have all packages released in Solaris x.y.z patch 5, which was released on June 2, 2005"? Can I do that with Yum?
Conceivably, though, there's no reason why RH, or anyone else for that matter, couldn't put together a series of snapshot repositories. Then you could do that with yum.
That would be a very odd thing to do in FOSS-world, though.
and to check you've got all the current updates:
This is on FC3, but both yum and rpm have been around for quite some time.
And anyway, Intel have announced that EM64T-enabled (i.e. 64 bit instruction set) Celeron Ds are on the way.
Google can give you a start. I'm pretty sure there have been image- or avi/wmv-borne exploits too.
That said, the Mac is acting - and will continue to act - as a retarding factor to Linux desktop adoption. Essentially, if you don't like tweaking, MacOS X is "desktop Linux" available today, and with Microsoft Office, QuickTime and all the rest. In this respect, RH got it right by shifting focus from the hobbyist/home user desktop. Me, I enjoy the tweaking, and consider it a fair price to pay to avoid being locked into anyone's proprietary software, whether Microsoft or Apple. Each to their own though; I gather some people actually use computers to do their real job, strange as that might seem!
Of course, as MacOS X is more-or-less a UNIX, it can be argued that any retardation it causes Linux is balanced by the invigorating effect it gives to UNIX-like OSs like Linux.
Not necessarily. If it was important enough to the console manufacturer, they could specify that the only guaranteed way for games to read input events was through the official functions of the official libraries. These could handle alternative controllers transparently (e.g. by allowing the user to assign events before the game loads). The developer would then have to actively put in work so as not to support alternatives (some will probably be stupid enough to do so, I guess, though).
The only game I know of that used it was X-Com.
There were lots more, though it wasn't as widely supported as the standard pad, for obvious reasons.
Charging manufacturers a 'recycling tax' at the point of sale or manufacture isn't about punishing them, it's about forcing them to internalise the externalities they would otherwise leave to society to pay for. It's a counterpoint to a belief that profits should be privatised whilst costs are socialised wherever possible.
which they swiftly pass onto consumers. Net result: consumers always pay for recycling (which incidentally sounds rather normal).
But it can mean that manufacturers then take steps to make their products more easily recyclable (since if they are obliged to do it, they might as well make it easy for themselves).
He died nearly 13 years ago.
No, no, no. If you invert the result, it'll actually be about 99.99% accurate. What you really need to do is tattoo 'T' on 50% of the world population's forehead. Then you end up with something as effective as ID cards.
My current employer is a UK university with Windows PCs numbering in the thousands.
That said, someone who's familiar with the ATA command set (which is pretty similar to SCSI's command set anyway) might well be able to point to a command that enables the same level of notification as SCSI provides.
Excellent reasoning! I've now become convinced that Linux's RAID-1 should work as you wrote in his post. Unfortunately, I'm in pretty much the same boat as you with respect to getting it fixed. :-(
That's my interpretation, too, FWIW.
WD are pretty much unique in that they don't make SCSI drives, therefore there are no SCSI drives that use exactly the 'same physical hardware' as those ESATA Raptors.
That said, what Seagate do differently between their Personal (i.e. [S]ATA) and Enterprise Storage (SCSI and ESATA) may well be different for other manufacturers, of course.
SCSI drives usually are a couple of years behind in drive capacity relative to ATA drives. This seems to contradict the above.
Good point. I was referring to 1.4.2/1.4.3 from the Seagate paper. Perhaps it would be more accurate to say that SCSI gets mechanical technology improvements first (hence faster rotational speeds and seek times) whereas ATA gets new recording technologies first...
Your other reply was informative, too. I think I agree with you on how Linux RAID-1 should work.
Sort of. According to this paper from Seagate, the main differences between SCSI and ATA are:
SCSI drives are individually tested, rather than tested in batch
SCSI drives typically have a 5 year warranty, rather than 1 year for ATA (note that Seagate's ATA drives also have 5 years, and WD's Special Edition -JB ATA drives have 3 years).
SCSI drives usually have higher rotational speeds (i.e. 10K or 15K RPM vs. 7200RPM)
SCSI drives usually make use of the latest technology. ATA uses whatever older technology has been cost-engineered to a suitable price-point
The physical and programming interface
I also suspect that SCSI drives have a larger number of reserved blocks for remapping, and that they remap blocks on read operations when the ECC indicate that a block has crossed some threshold of near-unreadability. This would account for a) SCSI drives' lower capacities and b) a report I had from a SCSI-using friend running BSD who reports that a 'remapping' message turned up in his syslog without needing any special action to invoke.
By contrast, in my experience, ATA drives only remap failed blocks on write operations. Lots of people think that when a drive returns a read error on a file, it's only fit for the bin, but I've forced the remapping to take place by writing to the affected blocks (either by zeroing the entire partition or drive using dd or badblocks -w, or by removing the affected file then creating a large file that fills all unallocated space in a partition, then removing it to reclaim the space).
No, asylum workers can't work (legally, at least, which would imply they're earning sub-minimum wage rates if they are working illegally).
What you're seeing is probably students from the recently-acceded EU states, such as Poland. You're as free to work in Poland, if you wish.
The latter, pretty much; RHEL3 was RH9-ish, RHEL4 is FC3-ish.
Obviously, though, RH benefit from there being such a clear differentiator.