Any company that makes a profit is necessarily NOT paying its employees for all the fruits of their labors. If it *was* paying them
the real value for all the fruits of all their labors, the company would at best be breaking even, not making profit.
This argument depends on the premise that whoever owns the company does not work for the profit they make. I guess it's a semantic definition - is owning a company considered "labor"?
Break it down into cases of whether the owner works for the company or merely invested in it. In the latter case, an investor certainly has to work to keep track of and manage his investments, and according to the capitalist system it is fair game that he be compensated for this effort. The "laborers" are giving him part of the fruits of their labor while he in return gives them a place to earn money.
But in the former case - business run by its owner(s) - said owners are providing tangible value, so are being paid the fruits of their labors. Look up the term "opportunity cost" if this is unclear.
Interestingly, these points seem to fly perpetually over the heads of most union workers I've talked to. Union people, for whatever reason, seem to believe companies are always hugely profitable and that said profits can either be (a) returned to workers in the form of wages and benefits or (b) given to the fat cats at the top... but never (c) reinvested in the company for strategic reasons or (d) low or in the red to begin with. Oh, and apparently none of them have retirement plans, because otherwise they too would be the hated fat cats making undeserved interest off the backs of workers whose companies they invest in.
I hate to type people in stereo like that, but I meet enough blue collar union dudes who seem to think that way that I really wonder.
I don't see anything inappropriate. In fact, I credit Google for being above
some of the slimy companies on the web and staying above the board with its business practices.
Wow, that has got to be in the ranking (sorry) for Understatement of the Year. Above some of the slimy companies on the web? (:
The real question is: why did the MPEG group choose a technology that was patented, or at least had a patent pending?
It's called a submarine patent. Thomson / Fraunhofer filed patents, but - oops - forgot to tell the MPEG group until well after MPEG-1 had become a standard. In fact, the patent didn't really come to light until MP3 audio had become a de facto standard well outside the realm of video files.
Basically, someone forgot to do a patent search before ratifying a standard. And the standards body didn't have a clause to the effect that "any patents held by any member company which covers the standard in question must be freely licensed to everyone in perpetuity".
Let that be a lesson..
But, existing decoders shouldn't have to pay for licences, don't they?
Wherever did you get that idea? They're still allegedly infringing the patent. Fraunhofer can still sue the authors / vendors if they don't pay whatever royalties are demanded. Then, as the courts sort it out, it's anyone's game.
If someone can change a licence, also other persons can change a licence. That means that next year ogg could be asking fees also.
Is there any guarantee that this wouldn't happen ?
Perhaps the fact that Ogg Vorbis is not covered by any patents, so there is nothing to license?
Yes, this has been independently verified - Xiphophorus almost certainly does not have a "submarine patent" hidden away somewhere until such time as Ogg Vorbis takes over the world.
The worst Xiph could do to you is to relicense their codec - that is, deny you the use of new versions of their reference implementation. But the spec is freely available, so you would still have two choices: use a version of the Xiph codec not yet covered by objectionable license terms, or write your own compatible codec.
With MP3 you don't have either of those options - patents don't cover the exact code used, but the algorithm. That means that if the patent is written right, it may be impossible to write an MP3 decoder that doesn't infringe it. (If the patent is written properly. I know there has been an assumption in the MP3 community that while encoding is covered by the Fraunhofer patents, decoding isn't. I have no idea if this is the truth, or mere hopeful / wishful thinking. Fraunhofer, of course, says it covers both - but then, they would.)
Summary: don't worry, all your oggs are still belong to you.
I can't see this being anything but bad for the end users. As much as everyone loves to bash MS, the Office package has served me very well for a very long time, since I switched from WordStar way back when.
Somehow you forgot to mention exactly how familiar you are with WordPerfect. Are you in a position to say that users will find it hard to use, buggy, incompatible, or in any other way unsuitable? Or are you just shooting from the hip, as a Word user who has never actually tried WordPerfect?
Personally I love WP - which is not something I say about most proprietary software. It is so much better suited to serious document publishing than MS Word, it's not even funny. But then, I'm almost as biased as you are, since although I have access to Word, I hardly ever use it. (I don't have to, you see, with WP around.)
So, hypothetically, I could use an ATA133 drive on an older
ATA100 controller that's been firmware upgraded to support LBA48?
In general, no firmware upgrade is needed. The controller doesn't care about block addressing, it just shuttles packets back and forth between the OS and the drive. LBA48 has been reported to fail on a few chipsets, but in general it should work for even a 1995-class IDE interface. You do need your OS drivers to support LBA48 - and if old chipsets don't come with the requisite new drivers for your OS, I guess you could say the old chipsets "don't support" LBA48.
(forgive my ignorence, but what was the previous standard?
LBA32?)
Well, LBA32 is what the BIOS interface is called - I think the ATA standard was just called "the ATA standard". (: It boasts 28-bit addressing, which is 256 million blocks. Multiply by 1/2 kB per block and you get 128 GB - which explains why 160 GB disks require LBA48 but 120 GB disks don't.
I have never understood this obsession people have with NextStep (WindowMaker, GNUStep, Afterstep etc).
It's just another side of the coin where all non-NeXT-esque window managers and GUI toolkits look like either (a) Motif, (b) Windows 95 or (c) TWM/Athena. (Oh, and Open Look, but talk about ugly.)
Then there are the polymorphic scripted window managers and themeable / skinnable GUI components which give you a choice between NeXT, Motif, Windows 95 and TWM/Athena.
I think it's objective-c. Who writes apps in objective-c anymore?
NeXTstep was Objective C - not sure if GNUstep is as well. In any case, what is wrong with Objective C? In the last 8 years since I first heard of it, I've never actually learned ObjC, but I've also never heard anyone say anything bad about it. Quite the contrary: people who use it seem to love it. They say it gives you an object-oriented abstraction as a conceptually lightweight extension to C, as opposed to the syntax city which is C++.
Seriously - would anyone who does know Objective C care to comment? Is it a decent language? What does it bring to the table over C or C++?
Actually, ATA133 excists because there's a fault in the IDE address scheme, and an ATA133 drive of any capacity larger
You are referring to LBA48, a standard which addresses (sorry) the block number limit. While most drives which support UDMA mode 6 (ATA133) also support LBA48 and vice versa, the two work at different levels.
The ATA133 cable speed is a physical thing, and depends on the drive and the interface. LBA48, on the other hand, is controller-agnostic - it operates above that level. To run a drive in "large disk" mode, what you need is (a) drive firmware that accepts LBA48 commands and (b) an OS that issues them. The controller in between the two doesn't actually matter.
(Actually that's not quite true. Turns out there are a few older coughVIAcough controller chips that seem not to like LBA48. But most IDE chipsets are fine with it, even those that came out long before LBA48 was invented.)
larger then 132GB
(I believe that's the limit... it might be 125)
It's all about terminology. Specifically you get 2^37 bits of address space. Why 37? ATA specifies a 28-bit block number, where blocks are 512 bytes (2^9). So 28+9 bits. Now 2^30 is 1 GB, so 2^37 is 128 GB, or 137438953472 bytes. However, drive vendors prefer the metric system, not because they're scientists but because their drives sound bigger that way. So they define 1 GB as 10^9 instead of 2^30. By that definition the 137438953472 is 137.4 GB.
cannot be used in an older system, as the ATA subsystem will try to address the wrong part of the disk, leading to corruption.
Replace "older system" with "older OS / older IDE driver".
In any case I doubt you have anything to worry about. It's not like your serial ATA card will either be old hardware or be using an old driver. I seriously doubt anyone would ship something in Q3 2002 which doesn't work with LBA48.
I was gonna say "The OS likely already does this, under the label of 'elevator seeking' or something like that." But then I
realized: who knows more about the drive: the guy who wrote the OS, or the guy who wrote the drive firmware?
Exactly. OSes definitely use elevator algorithms, but such tactics are only of limited effectiveness. Consider hardware RAID controllers - the sector layout on each physical disk will have only passing resemblance to the logical block numbers.
At the low end, OS people used to use elaborate hand-tuned timings that took into account how fast the drive spun, so you could read/write the sector directly under the drive head if possible. The old Unix filesystem actually has drive timings in its superblock! But nowadays, even such things as the actual disk geometry (sectors per track, tracks per spindle, number of spindles) are not exposed outside the drive firmware. Yes, the drive reports these numbers - but they're invented for backward compatibility. (LBA48 finally gets rid of geometry-based I/O - everything is in blocks now. Whew!)
Even things that should be obvious aren't. For example, if you have to write a sector 30 sectors behind the current write, should you back up and do it? Some drives are optimised to seek faster forwards than backwards (that's what benchmarks benchmark, y'know), so "30 sectors back" might take longer than "60 sectors forward".
I leave you with a quote by the venerable Larry McVoy, from the <linux-kernel> list a couple years back: "Screwing around with the elevator is in general a waste of time, but it is a rite of passage for all I/O people."
now if only we could build an anonymous-friendly slashdot, that doesn't place posts at 0.
Great idea! How about if we had a slashdot that let anyone in the world register for a free account without giving away any personal information except an email address, and the email address would never be shown publicly, and you could even change it to an invalid address if you didn't mind giving up certain features?
Now some people don't need 4 devices, I admit but some people do actually use more, my housemate uses 3 cdroms and 3 hard disks, a
total of 6 devices, so 3 standard 40pin cables.
With serial ATA he will need a board which has 6 ports OR he will need a board with 4 and a dual port card (hello a nice $$$ making
scheme for promise etc)
So which brand of motherboard is he using currently, with the 3 built-in IDE channels? Or is he using gasp an add-in card?
Yes, I'm sure you can buy motherboards with more than two ATA channels. Likewise you will probably be able to buy SATA motherboards with more than 4 ports. Joe Consumer won't need these motherboards, though.
Then the power plugs look just plain messy, how exactly do we feed these hard disks 3.3, 5 and 12 volts if the p/supply only offers
12 and 5 as per normal on your floppy and hdd power cables, do we plug in our power supply into a "serial ATA power device" mounted
inside the case with cables running off that??? Does this theoretical device then split the power in to say 4/6/8 seperate cables
(what if we only need 2??? etc)
Yeah, that's a good point. With this talk of using the extra pins on the power plug as some sort of hot-swap enabling technology (I'm still not sure how that's supposed to make the difference), it sounds like the power plug is somehow wired to the ATA controller. That would be messy indeed.
does anyone know if those little parallel/serial ATA
adaptors work with ATA133 devices, or are they only for ATA100 and older standards?
For better or worse, ATA is intended to be fully backwards and forwards compatible. If you have an ATA133 card and a CD-ROM that needs to be run in a crufty old PIO mode, it should work. Ditto if you have an old ISA IDE interface that doesn't even support multiword DMA, and the latest / greatest drive. The devices find a common ground. SCSI has the same property.
So I wouldn't worry about compatibility. Even if the serial/parallel adaptor uses ATA66 or ATA100, your drive should do the same and you'll never know the difference (since even today's hard drives can't really go that fast anyway).
The disk was unplugged, the plugged back in. OBSD said it was reinitializing the controller. Poof! back to normal. Still, this
probably would not be a good general practice to follow.
Several years ago on the linux-kernel list, someone posted to say "I accidenally pulled my drive cable out and plugged it back in, it worked fine, Linux r0000lz, thanks" and several people piped up to say "DON'T EVER DO THIS, you're likely to fry your hardware!"
So "probably would not be a good general practice to follow" is right.
SCSI has the ability to disconnect devices, meaning that you can send drive0 a read request & disconnect from the bus
Isn't that tagged command queueing (TCQ), or am I confused? If so, recent ATA standards support TCQ as well, though according to the Linux IDE people, the TCQ support in most IDE drive firmware is either missing or buggy.
As I said in a previous post, now that serial ATA has TCQ as a bullet-point feature, maybe the drive vendors will actually implement it properly.
ATA-133 really isn't about the speed either - its about how much storage can be addressed.
Nah, you're confusing ATA-133 with LBA48. LBA48 is the "big drive" spec, and it works fine with any cable speed - and almost any IDE controller (certain old coughVIAcough chipsets have trouble with it, but theoretically it's controller-agnostic - it's all about communication between the OS and the drive).
It just so happens that drives that support LBA48 also usually support UDMA mode 6 aka ATA133, mainly because it wasn't needed with earlier, smaller, drives.
Be nice when the
2 device on a channel is killed off.
Who cares? Why not just design an ATA chipset that can do, say, 8 channels instead of the traditional 2? With a 7-pin cable, you should have plenty of real estate on the mobo or add-in card to plug in lots of cables. (Unlike ATA "classic" or SCSI.)
Tagged Command Queueing is something the SCSI standard has had for years, and the ATA standard only got recently. Basically, it allows you to have more than one active command on a single bus. With non-TCQ, you have to tell the drive "read this set of blocks", then nothing can happen on that bus until the drive answers "here are your blocks" or "read failure" or whatever. So if you have two drives on one cable, that other drive is just sittin' there. This is the main reason they say not to put two high-bandwidth devices (read: hard drives) on a single ATA cable.
With TCQ, you say "read this set of blocks, tag #64397", and then you can keep using the bus for other stuff until the drive responds "tag #64397: here are your blocks". The number of tags you can have active at once is known as the queue depth; some SCSI cards can go up to about 255.
Note that this isn't just useful if you have multiple devices. On a single drive, you can have several outstanding read or write requests, and the drive electronics can reorder them arbitrarily so as to take care of things in an optimal order. Remember, the biggest factor in drive speed is seek latency - that is, repositioning the read/write heads. If the drive is given several I/O requests to fulfill in any order, it may be able to optimise the seek times considerably.
Here's hoping that, with TCQ getting attention being a bullet point for Serial ATA (not that it's new - as I said, recent versions of the regular ATA standard have it too), the drive vendors will actually take the time to implement it properly. TCQ support for most existing ATA drives is either missing or buggy. My theory is that the Windows ATA drivers don't use TCQ so the manufacturers don't care. (That seems to be how hardware vendors think.)
This is going to be great for NAS applications and managing racks of drives.
Nah. NAS can solve the same problems without it:
cable length: NAS boxes are custom-built, they could do four-inch cables if necessary
hot-swap: many ATA controllers support powering down the bus to swap a device
cooling: again, the boxes are custom-built - they can figure out where to put the fans to avoid the cables
speed: between one-drive-per-cable and RAID5, there is no need for that 150MB/s (not that the desktop needs it at this point either...)
Serial ATA is a much more exciting for classic "in-box" file servers, and desktop machines.
Re:Why go from 32 to 64? Why not jump to 128?
on
PowerPC Goes 64 bit
·
· Score: 2, Insightful
But if your saying that us humans just simply can't conceive and design a 128bit processor...
They can, they can. There are plenty of good reasons not to:
Memory bandwidth. This is probably the biggie. If you have 128 bits for every memory address, that's 128 bits for every pointer in your C program, 128 bits for every instruction that loads from an absolute memory location (ok so such an instruction probably doesn't exist, but that doesn't make the problem go away). Memory bandwidth already cannot keep up with CPU speeds - that's why we have such huge caches nowadays, and caches are expensive.
Real estate. Moore's Law was originally formulated in relation to transistor size / density. The more transistors you can cram into a given amount of silicon, the faster and cheaper you get. Likewise, the fewer transistors you need, the better. Expanding all your registers, all your speculative registers, all your ALUs, all your address xlation units, all your caching logic, all your pipelines, to accommodate 128-bit words is far from free.
Disk storage. A 64-bit memory or disk address is on the order of 16,000,000,000,000,000,000 bytes of addressibility. (And that's assuming you can't multiply by about 4 more orders of magnitude to address blocks rather than bytes.) That will be vast overkill for years to come, which is why the new ATA standard (IDE disks) specifies a 48-bit rather than 64-bit block number. (The original 28-bit ATA lasted for what, 15-20 years?)
In short, provide even one application domain where having 128 bits of addressable memory, or a convenient 128-bit word size, would come even close to offsetting the inherent architectural costs compared to a 32- or 64-bit design. I can't think of one.
NO, IPv6 isn't a valid answer! (: Word size hasn't been a significant obstacle for current implementations.
Is this IBM just coming out with their own 64-bit PPC core?
IBM has been making 64-bit POWER3 chips for years - nothing new on that front. I guess the news is that they're now adding AltiVec or something very like it - AltiVec (unlike 64-bit mode) is not specified in the original early-90s PowerPC spec, Motorola invented it later.
Slashdot Mirror
This argument depends on the premise that whoever owns the company does not work for the profit they make. I guess it's a semantic definition - is owning a company considered "labor"?
Break it down into cases of whether the owner works for the company or merely invested in it. In the latter case, an investor certainly has to work to keep track of and manage his investments, and according to the capitalist system it is fair game that he be compensated for this effort. The "laborers" are giving him part of the fruits of their labor while he in return gives them a place to earn money.
But in the former case - business run by its owner(s) - said owners are providing tangible value, so are being paid the fruits of their labors. Look up the term "opportunity cost" if this is unclear.
Interestingly, these points seem to fly perpetually over the heads of most union workers I've talked to. Union people, for whatever reason, seem to believe companies are always hugely profitable and that said profits can either be (a) returned to workers in the form of wages and benefits or (b) given to the fat cats at the top ... but never (c) reinvested in the company for strategic reasons or (d) low or in the red to begin with. Oh, and apparently none of them have retirement plans, because otherwise they too would be the hated fat cats making undeserved interest off the backs of workers whose companies they invest in.
I hate to type people in stereo like that, but I meet enough blue collar union dudes who seem to think that way that I really wonder.
Wow, that has got to be in the ranking (sorry) for Understatement of the Year. Above some of the slimy companies on the web? (:
*boggle* You've figured out a way to unite the OSI model with the Real World at least well enough to run Mozilla over it? Color me impressed..
It's called a submarine patent. Thomson / Fraunhofer filed patents, but - oops - forgot to tell the MPEG group until well after MPEG-1 had become a standard. In fact, the patent didn't really come to light until MP3 audio had become a de facto standard well outside the realm of video files.
Basically, someone forgot to do a patent search before ratifying a standard. And the standards body didn't have a clause to the effect that "any patents held by any member company which covers the standard in question must be freely licensed to everyone in perpetuity". Let that be a lesson..
Wherever did you get that idea? They're still allegedly infringing the patent. Fraunhofer can still sue the authors / vendors if they don't pay whatever royalties are demanded. Then, as the courts sort it out, it's anyone's game.
Perhaps the fact that Ogg Vorbis is not covered by any patents, so there is nothing to license?
Yes, this has been independently verified - Xiphophorus almost certainly does not have a "submarine patent" hidden away somewhere until such time as Ogg Vorbis takes over the world.
The worst Xiph could do to you is to relicense their codec - that is, deny you the use of new versions of their reference implementation. But the spec is freely available, so you would still have two choices: use a version of the Xiph codec not yet covered by objectionable license terms, or write your own compatible codec.
With MP3 you don't have either of those options - patents don't cover the exact code used, but the algorithm. That means that if the patent is written right, it may be impossible to write an MP3 decoder that doesn't infringe it. (If the patent is written properly. I know there has been an assumption in the MP3 community that while encoding is covered by the Fraunhofer patents, decoding isn't. I have no idea if this is the truth, or mere hopeful / wishful thinking. Fraunhofer, of course, says it covers both - but then, they would.)
Summary: don't worry, all your oggs are still belong to you.
Somehow you forgot to mention exactly how familiar you are with WordPerfect. Are you in a position to say that users will find it hard to use, buggy, incompatible, or in any other way unsuitable? Or are you just shooting from the hip, as a Word user who has never actually tried WordPerfect?
Personally I love WP - which is not something I say about most proprietary software. It is so much better suited to serious document publishing than MS Word, it's not even funny. But then, I'm almost as biased as you are, since although I have access to Word, I hardly ever use it. (I don't have to, you see, with WP around.)
I thought it was "The determined programmer can write a FORTRAN program in any language." Or something.
In general, no firmware upgrade is needed. The controller doesn't care about block addressing, it just shuttles packets back and forth between the OS and the drive. LBA48 has been reported to fail on a few chipsets, but in general it should work for even a 1995-class IDE interface. You do need your OS drivers to support LBA48 - and if old chipsets don't come with the requisite new drivers for your OS, I guess you could say the old chipsets "don't support" LBA48.
Well, LBA32 is what the BIOS interface is called - I think the ATA standard was just called "the ATA standard". (: It boasts 28-bit addressing, which is 256 million blocks. Multiply by 1/2 kB per block and you get 128 GB - which explains why 160 GB disks require LBA48 but 120 GB disks don't.
It's just another side of the coin where all non-NeXT-esque window managers and GUI toolkits look like either (a) Motif, (b) Windows 95 or (c) TWM/Athena. (Oh, and Open Look, but talk about ugly.)
Then there are the polymorphic scripted window managers and themeable / skinnable GUI components which give you a choice between NeXT, Motif, Windows 95 and TWM/Athena.
(:
NeXTstep was Objective C - not sure if GNUstep is as well. In any case, what is wrong with Objective C? In the last 8 years since I first heard of it, I've never actually learned ObjC, but I've also never heard anyone say anything bad about it. Quite the contrary: people who use it seem to love it. They say it gives you an object-oriented abstraction as a conceptually lightweight extension to C, as opposed to the syntax city which is C++.
Seriously - would anyone who does know Objective C care to comment? Is it a decent language? What does it bring to the table over C or C++?
You are referring to LBA48, a standard which addresses (sorry) the block number limit. While most drives which support UDMA mode 6 (ATA133) also support LBA48 and vice versa, the two work at different levels.
The ATA133 cable speed is a physical thing, and depends on the drive and the interface. LBA48, on the other hand, is controller-agnostic - it operates above that level. To run a drive in "large disk" mode, what you need is (a) drive firmware that accepts LBA48 commands and (b) an OS that issues them. The controller in between the two doesn't actually matter.
(Actually that's not quite true. Turns out there are a few older coughVIAcough controller chips that seem not to like LBA48. But most IDE chipsets are fine with it, even those that came out long before LBA48 was invented.)
It's all about terminology. Specifically you get 2^37 bits of address space. Why 37? ATA specifies a 28-bit block number, where blocks are 512 bytes (2^9). So 28+9 bits. Now 2^30 is 1 GB, so 2^37 is 128 GB, or 137438953472 bytes. However, drive vendors prefer the metric system, not because they're scientists but because their drives sound bigger that way. So they define 1 GB as 10^9 instead of 2^30. By that definition the 137438953472 is 137.4 GB.
Replace "older system" with "older OS / older IDE driver".
In any case I doubt you have anything to worry about. It's not like your serial ATA card will either be old hardware or be using an old driver. I seriously doubt anyone would ship something in Q3 2002 which doesn't work with LBA48.
Exactly. OSes definitely use elevator algorithms, but such tactics are only of limited effectiveness. Consider hardware RAID controllers - the sector layout on each physical disk will have only passing resemblance to the logical block numbers.
At the low end, OS people used to use elaborate hand-tuned timings that took into account how fast the drive spun, so you could read/write the sector directly under the drive head if possible. The old Unix filesystem actually has drive timings in its superblock! But nowadays, even such things as the actual disk geometry (sectors per track, tracks per spindle, number of spindles) are not exposed outside the drive firmware. Yes, the drive reports these numbers - but they're invented for backward compatibility. (LBA48 finally gets rid of geometry-based I/O - everything is in blocks now. Whew!)
Even things that should be obvious aren't. For example, if you have to write a sector 30 sectors behind the current write, should you back up and do it? Some drives are optimised to seek faster forwards than backwards (that's what benchmarks benchmark, y'know), so "30 sectors back" might take longer than "60 sectors forward".
I leave you with a quote by the venerable Larry McVoy, from the <linux-kernel> list a couple years back: "Screwing around with the elevator is in general a waste of time, but it is a rite of passage for all I/O people."
Great idea! How about if we had a slashdot that let anyone in the world register for a free account without giving away any personal information except an email address, and the email address would never be shown publicly, and you could even change it to an invalid address if you didn't mind giving up certain features?
Oh, wait...
So which brand of motherboard is he using currently, with the 3 built-in IDE channels? Or is he using gasp an add-in card?
Yes, I'm sure you can buy motherboards with more than two ATA channels. Likewise you will probably be able to buy SATA motherboards with more than 4 ports. Joe Consumer won't need these motherboards, though.
Yeah, that's a good point. With this talk of using the extra pins on the power plug as some sort of hot-swap enabling technology (I'm still not sure how that's supposed to make the difference), it sounds like the power plug is somehow wired to the ATA controller. That would be messy indeed.
For better or worse, ATA is intended to be fully backwards and forwards compatible. If you have an ATA133 card and a CD-ROM that needs to be run in a crufty old PIO mode, it should work. Ditto if you have an old ISA IDE interface that doesn't even support multiword DMA, and the latest / greatest drive. The devices find a common ground. SCSI has the same property.
So I wouldn't worry about compatibility. Even if the serial/parallel adaptor uses ATA66 or ATA100, your drive should do the same and you'll never know the difference (since even today's hard drives can't really go that fast anyway).
Several years ago on the linux-kernel list, someone posted to say "I accidenally pulled my drive cable out and plugged it back in, it worked fine, Linux r0000lz, thanks" and several people piped up to say "DON'T EVER DO THIS, you're likely to fry your hardware!"
So "probably would not be a good general practice to follow" is right.
Isn't that tagged command queueing (TCQ), or am I confused? If so, recent ATA standards support TCQ as well, though according to the Linux IDE people, the TCQ support in most IDE drive firmware is either missing or buggy.
As I said in a previous post, now that serial ATA has TCQ as a bullet-point feature, maybe the drive vendors will actually implement it properly.
Nah, you're confusing ATA-133 with LBA48. LBA48 is the "big drive" spec, and it works fine with any cable speed - and almost any IDE controller (certain old coughVIAcough chipsets have trouble with it, but theoretically it's controller-agnostic - it's all about communication between the OS and the drive).
It just so happens that drives that support LBA48 also usually support UDMA mode 6 aka ATA133, mainly because it wasn't needed with earlier, smaller, drives.
Who cares? Why not just design an ATA chipset that can do, say, 8 channels instead of the traditional 2? With a 7-pin cable, you should have plenty of real estate on the mobo or add-in card to plug in lots of cables. (Unlike ATA "classic" or SCSI.)
Tagged Command Queueing is something the SCSI standard has had for years, and the ATA standard only got recently. Basically, it allows you to have more than one active command on a single bus. With non-TCQ, you have to tell the drive "read this set of blocks", then nothing can happen on that bus until the drive answers "here are your blocks" or "read failure" or whatever. So if you have two drives on one cable, that other drive is just sittin' there. This is the main reason they say not to put two high-bandwidth devices (read: hard drives) on a single ATA cable.
With TCQ, you say "read this set of blocks, tag #64397", and then you can keep using the bus for other stuff until the drive responds "tag #64397: here are your blocks". The number of tags you can have active at once is known as the queue depth; some SCSI cards can go up to about 255.
Note that this isn't just useful if you have multiple devices. On a single drive, you can have several outstanding read or write requests, and the drive electronics can reorder them arbitrarily so as to take care of things in an optimal order. Remember, the biggest factor in drive speed is seek latency - that is, repositioning the read/write heads. If the drive is given several I/O requests to fulfill in any order, it may be able to optimise the seek times considerably.
Here's hoping that, with TCQ getting attention being a bullet point for Serial ATA (not that it's new - as I said, recent versions of the regular ATA standard have it too), the drive vendors will actually take the time to implement it properly. TCQ support for most existing ATA drives is either missing or buggy. My theory is that the Windows ATA drivers don't use TCQ so the manufacturers don't care. (That seems to be how hardware vendors think.)
Nah. NAS can solve the same problems without it:
Serial ATA is a much more exciting for classic "in-box" file servers, and desktop machines.
They can, they can. There are plenty of good reasons not to:
In short, provide even one application domain where having 128 bits of addressable memory, or a convenient 128-bit word size, would come even close to offsetting the inherent architectural costs compared to a 32- or 64-bit design. I can't think of one.
NO, IPv6 isn't a valid answer! (: Word size hasn't been a significant obstacle for current implementations.
Guys, guys! Enough! It's just a label. If it's backward-compatible with the PowerPC spec, it's a PowerPC. You're starting to sound like me:
Me: What kind of CPU is in there?
Other: 450 MHz.
Me: Yeah but what chip?
Other: A Pentium.
Me: Where did you find a Pentium running at 450 MHz?
*sigh*
IBM has been making 64-bit POWER3 chips for years - nothing new on that front. I guess the news is that they're now adding AltiVec or something very like it - AltiVec (unlike 64-bit mode) is not specified in the original early-90s PowerPC spec, Motorola invented it later.