If you never need to make any calls outside of Qt, then yes, you're fine. As soon as you need to interact with another library or make a syscall that Qt doesn't wrap, though, you aren't going to be using QString.
You could go toe-to-toe to RMS. Reminds me when a Crystal Space developer asked him a straightforward question. He was trying to strictly comply with the GPL, and instead Stallman sent back a string of about ten letters bitching about how the CS guy was misusing "Open Source" and "Free" and kept ignoring the question.'
For what it's worth, gcj actually is not as awesome as you would expect just because it's a native code compiler. IBM's JDK/JVM produces code significantly faster under Linux, even without native code compilation, for example. It's the fastest zero-cost way to run Java on Linux.
Kaffe, despite being free, has really, really, *really* atrocious performance from both a memory and CPU standpoint.
Sun's Java implementation is okay, but not as peppy as IBM's implementation.
As a hosting provider, how far should I go to protect the rights of my clients while upholding the law, and still verify every claim that comes in?"
You know, if you're looking for crucial legal advice, I really don't think you should be relying on Slashdot. "But, *your Honor*, 'autopr0n' on Slashdot *said* that it would be okay!"
We already know that most Slashdotters would *like* you to do nothing, for example, so your chance of getting a legally useful opinion is about zip.
The C++ string class also lets you interface with C strings with minimal effort. The c_str() method will return the string's content as a char * (though you must be careful if the string contains NUL characters, of course).
I didn't think string could contain NUL characters, actually.
No, I realize that you can *convert* between them, but that's a long shot from doing a g_strdup_printf(), which is really what I'm interested in. I have a couple of posts in this thread giving examples.
You ought to benchmark before claiming that C++'s ostrstream is slower than glib or other ways of writing formatted output.
Oh, it probably isn't at writing, but it's heavier weight. In the example I was using, you'd be creating the thing, slapping together two or three strings and an int, c_str()ing the results, and destroying the thing immediately. It doesn't make a whole lot of sense.
So I'd imagine that formatted output with ostrstream is pretty respectable.
[shrug] The STL has a lot of stuff that has good performance, but it tends to be heavyweight. It's not that the printing itself is inefficient, it's the creation and deletion of a string and stream buffer objects just to combine two C strings. At the very least, you're doing an extra copy of the strings, and I suspect there's more internal state involved. So if I'm dumping tons of stuff to an ostrstream, yeah, I expect it's fine. If I'm just creating it to do a simple string operation and then immediately destroying it, the constant time costs start to count.
In any case, a possible increase in speed for formatting some data into a string is not a good enough reason to stop using the standard 'string' type and reinvent the wheel with glib.
In the case of KDE it is different because they already have their own not-invented-here-ism (inherited from Qt) using QString instead of the standard std::string. Nonetheless two different string classes are not as bad as three.
My point is partly that string isn't used, though. In KDE/Qt, they're already using QString/QCString. Interfacing with C APIs happens, like it or not, because Qt doesn't wrap every library and the kernel -- sometimes you just need to make syscalls or other library calls, and those don't use QString. Plus, QString doesn't seem to do the string operations I was talking about.
The STL string, if anything, would the be odd man out that isn't already used. You're going to see char *s in your apps and you're going to see QStrings, but you may well not have an STL string.
The point about the APIs not making much sense still stands, though. There's no particularly clean way to use Qt in GNOME without major restructuring. If Qt broke off a library that contained some basic functionality that didn't depend on using Qt data structures throughout (which is what glib is, at least as far as I use it), I could see it as more reasonable.
glib isn't part of the gtk framework, though it contains handy code. gtk and Qt are both part of app frameworks, and combining the two wouldn't work that well.
I could see it being doable if Qt were to break out a "foundational" library, much like the gtk guys did with glib, though.
However, almost 95% of what Glib does is already handled by Qt (and in some places, in a more natural manner, such as QObject vs. GObject)
Huh. I haven't even seen GObject -- I've only used glib 1, not glib 2. I guess I should see what's up. Some of the things are the same. I'm pretty sure that both have some sort of API for creating timers, for example.
Qt provides the same easy ways to use C strings as glib does.
No, I don't think it's quite as nice -- if you'll take a look at some of my other posts in this thread, you'll see me talkign about them.
GNOME would probably never want to depend on Qt (it's GPL'd, not LGPL'd)
I always wondered about that. How do the KDE and TrollTech people get along when it comes to licenses? kdelibs is LGPL and is definitely dynamically linked to qt, which is GPL.
depending qt on gnome would do the same thing.
I think that would be worse. Glib is a very small, basic set of utility code that gdk/gtk use. You'd have to combine all three of them to have something equivalent to Qt, so GNOME depending on Qt would be a much larger set of dependencies. KDE can comfortably use lots of glib code without having to adopt a new object model, but GNOME doing the same with Qt would not hold true. Plus you'd be introducing a C++ requirement into GNOME, plus there's the license issue, yadda, yadda, yadda.
Minimal effort to interface with APIs that use C strings. A good way to slap formatted output into a buffer (I remember some way to do this with the STL -- you use an ostrstream, IIRC -- but it's significantly more overhead, both in cycles and typing).
I really don't use most of glib, but I do like what I do use.
Also, Qt/KDE seem to use QString rather than string, so the onus is really on QString rather than string, which (AFAI can tell) doesn't have a particularly nice way of doing this.
Rich, what would be your approach if you had, say, three C strings returned by various UNIX library functions and an integer, and you wanted to do a formatted print to another C string to pass to something like chown()?
You can pull something like this off (with a bit extra code) using the STL, but I don't see a nice way to do it with QCString. I suppose I could be missing something. I'd use this if I had glib handy:
There's probably a way to pull it off, but glib is particularly useful when working with C strings, which just happens because of all the libraries and system calls that are C.
And no one (that I can see) is advocating replacing Qt with glib -- just using it as another handy utility. I don't see gtk or gdk becoming used in KDE, but glib seems quite useful. It fits well with C++ -- I was recently writing a (non gdk/gtk) piece of software and used it for a number of string operations that I needed done.
It is just to radical to say that KDE should now start over and start using all C based infrastructure just so that KDE and GNOME can share stuff.
No one has said that. KDE does have C underpinnings already -- lots of it *is* a set of C++ wrappers around C APIs on various platforms. The API it exposes to user apps is C++. None of that would change if glib was used, even throughout the entire thing.
No compelling reason exists to remove Qt from KDE.
Right. And it's not going to happen, and no one suggested it.
The only reason I mentioned that I'd like to see it happen is completely unrelated to what we're talking about -- that Qt causes KDE licensing problems. Qt is GPL, KDE is LGPL. I'm not entirely sure how they managed to work that out. More significantly, I'm not a tremendous fan of TrollTech, or of any one company having control over a fundamental library (like what was proposed as a standard UNIX widget set). No one company controls KDE, no one company controls GNOME, and no one company controls GTK -- but one does Qt. So it's mostly political irritation for me. But my mentioning that has nothing to do with what's being proposed, just to be entirely clear.
Hey like i've said earlier I don't really mind using glib if a good technical reason exists not to use the Qt equivalent.
Sure, but there isn't really a good Qt equivalent. Glib's functionality is really orthogonal to Qt. You can't replace Qt with glib. Maybe glib + gdk + gtk + Inti.
If I'm calling chmod(), I have to pass it a C string. If I want to compose said string from other strings, I *could* convert everything to QStrings, create the desired string, and then convert back to a C string, but the class really doesn't provide a great way to do the equivalent of auto-output-sizing sprintf() to create the filename string, which glib can do.
The KDE people aren't going to replace Qt with glib -- it wouldn't make much sense for them to do so, nor does glib do the same things.
Again, no problem, but to me the exclusion of Qt/C++ from this shared tech is a non starter.
That I really don't agree with. The important thing to share is protocols and conventions, not so much code, which is what they seem to be really interested in. If code is to be shared (and keep in mind, this is code *internal* to KDE, which can be wrapped so that the user only sees a C++ interface), it's only reasonable to use C for cross-environment code. C++ is a superset of C, so the only set of code that is accessable to both is C.
This is nothing new -- much of KDE and Qt *are* C++ wrappings for various C APIs on different platforms. For KDE/Qt, this is precisely what they've been doing for years.
Qt cannot legally be linked as a library to gtk/glib/gnome, because Qt is GPL and the other three are LGPL. Qt *can* happily make use of the other three, however.
From a legal and a technical standpoint, moving Qt between the two environments makes very little sense.
The two have quite different object models. Glib is a general utility library, below either object model, so it can be useful to each. Qt doesn't have a general utility library that it uses, and the Qt API is as difficult to use from gdk/gtk as the gdk/gtk object model would be from Qt. glib, however, can be very useful.
This isn't an attempt to "stab at" KDE. It's not affecting user APIs at all -- it's just being useful to KDE apps.
Well, this isn't about moving everything to use glib instead of the Qt-based equivalent data types at all (which is what several of the developers on kde-core-devel seemed to think) but simply about moving the copy of glib out of arts and into kdesupport.
I know (manyoso seems to also be confused here), but if it's external, then it's more widely available if I want to use an app that uses it. glib feels kind of like "stuff that should have been in the standard library but shouldn't", and tends to help programmers avoid stupid string mistakes. I really like having it available (I've used it on plenty of non-gtk stuff).
When you have zero need to ever touch a C api (i.e. almost all UNIX APIs) from your C++ program, then you have no use for glib. In the meantime, it's a tremendous timesaver. Again, it's a tiny general utility library, mostly useful for working with C strings. It tends to improve security immensely, since it discourages using things like statically sized strings.
Using it wouldn't cause Qt to be "replaced" in any way. It just helps Qt programmers whenever they're using something (SDL, OSS, the Unix system calls) that uses C strings. Glib is really nice -- stuff that (IMHO) probably should have been part of the standard library.
Inti, a C++ framework, is actually a pretty major project.
Recently, we've been discussing the incorporation of Glib into KDE on the core development list.
Have you used glib? It's a really, really good library, but it's also very lightweight. It's a tremendously useful utility library. It would add very little by way of dependencies to either project -- it's nothing like requiring libgdk or libgtk or any of the gnome libraries. Using Qt or C++ in GNOME would significantly increase gnome's requirements.
But please, let's not rearchitect KDE and strip it of Qt.
Actually, I'd really like to see that.:-) However, that's really not related. Look at what glib does. It's quite simple, not at all like tossing GTK in. And you certainly don't strip KDE of Qt. I've written C++ code that uses glib before. It's just really helpful code, particularly if you call any code that uses C strings (which, even if you happen to be using Qt, you may well have to do).
It's there so that any random "bit rot" (single-bit errors) is caught and corrected before it causes damage.
That can't be right, though. The system *bus* doesn't have ECC, and by virtue of its far greater area, would be much more vulnerable to errors induced by interference than the RAM.
i can gurantee you that you will find some net access, if anything esle, you can always hit up down town cyber cafe'
Either cyber cafes or (simpler) a modem both came to mind. This seems far easier. If I needed 'Net access, I'd probably have a laptop, slap a modem and get an account with a national ISP, and be happy as a clam. This guy isn't going to be downloading movies onto his laptop during the road trip (I would imagine), so I can't see any reason this wouldn't work. There are phones *everywhere* in the US.
Okay. SCSI lets you do command queuing and reordering. Serial ATA will have this too. Theoretically, if you have a bunch of things doing sequential accesses at once, this can help. SCSI can have outstanding requests to multiple devices on a bus at once, and ATA cannot. This is a pretty big deal for environments where you can have heavy disk load, since if you have two drives on an ATA bus, one can get starved if the other is doing lots of work. I'm not sure if Serial ATA addresses this. For Average Joe's desktop, it's not a big deal because he's usually only doing one thing at once -- loading a game up, or copying a file.
SCSI is generally used to allow price discrimination by vendors. SCSI drives have a reputation for being more reliable, and much more expensive.
SCSI supports many more devices on a bus. This is a big deal to me -- it's a royal pain to buy another controller to add another device or two.
It's unlikely that the two will be merged any time soon, because there's tremendous financial incentive to prevent "enterprise-class" drives from becoming commoditized. SCSI is one of the industry's last useful tools to avoid this.
If you're getting a desktop, use ATA, almost certainly. If you're getting a server with a lot of drives, it may be worth your while to get SCSI, for the abovementioned benefits.
If I had some extra money and just wanted some extra reliability, I'd probably have a mirrored RAID pair of IDE drives, if I were building a desktop without a ton of drives.
What I don't get is there already is a serial SCSI, it is called Fibre Channel. Right now it is clocked at 4 Gbits/sec. and there is no reason it can't go faster.
Fiber optic hardware is more expensive. What I'd like to know is why *Firewire* doesn't serve the purpose.
Moving to 3Gbits is evolutionary, not a huge jump.
I'm wondering what's going on here too -- WTF happened to Firewire? I remember thinking that everyone would be using it as a universal high bandwidth data bus, and for some reason it doesn't seem to be happening.
Slashdot Mirror
If you never need to make any calls outside of Qt, then yes, you're fine. As soon as you need to interact with another library or make a syscall that Qt doesn't wrap, though, you aren't going to be using QString.
You could go toe-to-toe to RMS. Reminds me when a Crystal Space developer asked him a straightforward question. He was trying to strictly comply with the GPL, and instead Stallman sent back a string of about ten letters bitching about how the CS guy was misusing "Open Source" and "Free" and kept ignoring the question.'
For what it's worth, gcj actually is not as awesome as you would expect just because it's a native code compiler. IBM's JDK/JVM produces code significantly faster under Linux, even without native code compilation, for example. It's the fastest zero-cost way to run Java on Linux.
Kaffe, despite being free, has really, really, *really* atrocious performance from both a memory and CPU standpoint.
Sun's Java implementation is okay, but not as peppy as IBM's implementation.
As a hosting provider, how far should I go to protect the rights of my clients while upholding the law, and still verify every claim that comes in?"
You know, if you're looking for crucial legal advice, I really don't think you should be relying on Slashdot. "But, *your Honor*, 'autopr0n' on Slashdot *said* that it would be okay!"
We already know that most Slashdotters would *like* you to do nothing, for example, so your chance of getting a legally useful opinion is about zip.
Yeah, you're right. We dwell on the negative too much around here, and there were some good anecdotes that came up. Thanks!
Of course, there's the question of how much it would cost to be dragging SCO/Caldera's remains around, which might well exceed $32.9 million.
The C++ string class also lets you interface with C strings with minimal effort. The c_str() method will return the string's content as a char * (though you must be careful if the string contains NUL characters, of course).
I didn't think string could contain NUL characters, actually.
No, I realize that you can *convert* between them, but that's a long shot from doing a g_strdup_printf(), which is really what I'm interested in. I have a couple of posts in this thread giving examples.
You ought to benchmark before claiming that C++'s ostrstream is slower than glib or other ways of writing formatted output.
Oh, it probably isn't at writing, but it's heavier weight. In the example I was using, you'd be creating the thing, slapping together two or three strings and an int, c_str()ing the results, and destroying the thing immediately. It doesn't make a whole lot of sense.
So I'd imagine that formatted output with ostrstream is pretty respectable.
[shrug] The STL has a lot of stuff that has good performance, but it tends to be heavyweight. It's not that the printing itself is inefficient, it's the creation and deletion of a string and stream buffer objects just to combine two C strings. At the very least, you're doing an extra copy of the strings, and I suspect there's more internal state involved. So if I'm dumping tons of stuff to an ostrstream, yeah, I expect it's fine. If I'm just creating it to do a simple string operation and then immediately destroying it, the constant time costs start to count.
In any case, a possible increase in speed for formatting some data into a string is not a good enough reason to stop using the standard 'string' type and reinvent the wheel with glib.
In the case of KDE it is different because they already have their own not-invented-here-ism (inherited from Qt) using QString instead of the standard std::string. Nonetheless two different string classes are not as bad as three.
My point is partly that string isn't used, though. In KDE/Qt, they're already using QString/QCString. Interfacing with C APIs happens, like it or not, because Qt doesn't wrap every library and the kernel -- sometimes you just need to make syscalls or other library calls, and those don't use QString. Plus, QString doesn't seem to do the string operations I was talking about.
The STL string, if anything, would the be odd man out that isn't already used. You're going to see char *s in your apps and you're going to see QStrings, but you may well not have an STL string.
so? libfam is already C++,
Huh, you're right. Didn't even know that.
The point about the APIs not making much sense still stands, though. There's no particularly clean way to use Qt in GNOME without major restructuring. If Qt broke off a library that contained some basic functionality that didn't depend on using Qt data structures throughout (which is what glib is, at least as far as I use it), I could see it as more reasonable.
glib isn't part of the gtk framework, though it contains handy code. gtk and Qt are both part of app frameworks, and combining the two wouldn't work that well.
I could see it being doable if Qt were to break out a "foundational" library, much like the gtk guys did with glib, though.
Yes, both can concatenate strings into a new (dynamically sized and allocated) string, but g_strdup_printf() doesn't seem to have an equivalent.
However, almost 95% of what Glib does is already handled by Qt (and in some places, in a more natural manner, such as QObject vs. GObject)
Huh. I haven't even seen GObject -- I've only used glib 1, not glib 2. I guess I should see what's up. Some of the things are the same. I'm pretty sure that both have some sort of API for creating timers, for example.
Qt provides the same easy ways to use C strings as glib does.
No, I don't think it's quite as nice -- if you'll take a look at some of my other posts in this thread, you'll see me talkign about them.
GNOME would probably never want to depend on Qt (it's GPL'd, not LGPL'd)
I always wondered about that. How do the KDE and TrollTech people get along when it comes to licenses? kdelibs is LGPL and is definitely dynamically linked to qt, which is GPL.
depending qt on gnome would do the same thing.
I think that would be worse. Glib is a very small, basic set of utility code that gdk/gtk use. You'd have to combine all three of them to have something equivalent to Qt, so GNOME depending on Qt would be a much larger set of dependencies. KDE can comfortably use lots of glib code without having to adopt a new object model, but GNOME doing the same with Qt would not hold true. Plus you'd be introducing a C++ requirement into GNOME, plus there's the license issue, yadda, yadda, yadda.
Minimal effort to interface with APIs that use C strings. A good way to slap formatted output into a buffer (I remember some way to do this with the STL -- you use an ostrstream, IIRC -- but it's significantly more overhead, both in cycles and typing).
I really don't use most of glib, but I do like what I do use.
Also, Qt/KDE seem to use QString rather than string, so the onus is really on QString rather than string, which (AFAI can tell) doesn't have a particularly nice way of doing this.
Rich, what would be your approach if you had, say, three C strings returned by various UNIX library functions and an integer, and you wanted to do a formatted print to another C string to pass to something like chown()?
You can pull something like this off (with a bit extra code) using the STL, but I don't see a nice way to do it with QCString. I suppose I could be missing something. I'd use this if I had glib handy:
char * new_str = g_strdup_vprintf("%s/%s,%s(%d)", foo, bar, baz, number);
chown(new_str, own, group);
g_free(new_str);
There's probably a way to pull it off, but glib is particularly useful when working with C strings, which just happens because of all the libraries and system calls that are C.
And no one (that I can see) is advocating replacing Qt with glib -- just using it as another handy utility. I don't see gtk or gdk becoming used in KDE, but glib seems quite useful. It fits well with C++ -- I was recently writing a (non gdk/gtk) piece of software and used it for a number of string operations that I needed done.
It is just to radical to say that KDE should now start over and start using all C based infrastructure just so that KDE and GNOME can share stuff.
No one has said that. KDE does have C underpinnings already -- lots of it *is* a set of C++ wrappers around C APIs on various platforms. The API it exposes to user apps is C++. None of that would change if glib was used, even throughout the entire thing.
No compelling reason exists to remove Qt from KDE.
Right. And it's not going to happen, and no one suggested it.
The only reason I mentioned that I'd like to see it happen is completely unrelated to what we're talking about -- that Qt causes KDE licensing problems. Qt is GPL, KDE is LGPL. I'm not entirely sure how they managed to work that out. More significantly, I'm not a tremendous fan of TrollTech, or of any one company having control over a fundamental library (like what was proposed as a standard UNIX widget set). No one company controls KDE, no one company controls GNOME, and no one company controls GTK -- but one does Qt. So it's mostly political irritation for me. But my mentioning that has nothing to do with what's being proposed, just to be entirely clear.
Hey like i've said earlier I don't really mind using glib if a good technical reason exists not to use the Qt equivalent.
Sure, but there isn't really a good Qt equivalent. Glib's functionality is really orthogonal to Qt. You can't replace Qt with glib. Maybe glib + gdk + gtk + Inti.
If I'm calling chmod(), I have to pass it a C string. If I want to compose said string from other strings, I *could* convert everything to QStrings, create the desired string, and then convert back to a C string, but the class really doesn't provide a great way to do the equivalent of auto-output-sizing sprintf() to create the filename string, which glib can do.
The KDE people aren't going to replace Qt with glib -- it wouldn't make much sense for them to do so, nor does glib do the same things.
Again, no problem, but to me the exclusion of Qt/C++ from this shared tech is a non starter.
That I really don't agree with. The important thing to share is protocols and conventions, not so much code, which is what they seem to be really interested in. If code is to be shared (and keep in mind, this is code *internal* to KDE, which can be wrapped so that the user only sees a C++ interface), it's only reasonable to use C for cross-environment code. C++ is a superset of C, so the only set of code that is accessable to both is C.
This is nothing new -- much of KDE and Qt *are* C++ wrappings for various C APIs on different platforms. For KDE/Qt, this is precisely what they've been doing for years.
Qt cannot legally be linked as a library to gtk/glib/gnome, because Qt is GPL and the other three are LGPL. Qt *can* happily make use of the other three, however.
From a legal and a technical standpoint, moving Qt between the two environments makes very little sense.
The two have quite different object models. Glib is a general utility library, below either object model, so it can be useful to each. Qt doesn't have a general utility library that it uses, and the Qt API is as difficult to use from gdk/gtk as the gdk/gtk object model would be from Qt. glib, however, can be very useful.
This isn't an attempt to "stab at" KDE. It's not affecting user APIs at all -- it's just being useful to KDE apps.
Well, this isn't about moving everything to use glib instead of the Qt-based equivalent data types at all (which is what several of the developers on kde-core-devel seemed to think) but simply about moving the copy of glib out of arts and into kdesupport.
I know (manyoso seems to also be confused here), but if it's external, then it's more widely available if I want to use an app that uses it. glib feels kind of like "stuff that should have been in the standard library but shouldn't", and tends to help programmers avoid stupid string mistakes. I really like having it available (I've used it on plenty of non-gtk stuff).
When you have zero need to ever touch a C api (i.e. almost all UNIX APIs) from your C++ program, then you have no use for glib. In the meantime, it's a tremendous timesaver. Again, it's a tiny general utility library, mostly useful for working with C strings. It tends to improve security immensely, since it discourages using things like statically sized strings.
Using it wouldn't cause Qt to be "replaced" in any way. It just helps Qt programmers whenever they're using something (SDL, OSS, the Unix system calls) that uses C strings. Glib is really nice -- stuff that (IMHO) probably should have been part of the standard library.
Inti, a C++ framework, is actually a pretty major project.
:-) However, that's really not related. Look at what glib does. It's quite simple, not at all like tossing GTK in. And you certainly don't strip KDE of Qt. I've written C++ code that uses glib before. It's just really helpful code, particularly if you call any code that uses C strings (which, even if you happen to be using Qt, you may well have to do).
Recently, we've been discussing the incorporation of Glib into KDE on the core development list.
Have you used glib? It's a really, really good library, but it's also very lightweight. It's a tremendously useful utility library. It would add very little by way of dependencies to either project -- it's nothing like requiring libgdk or libgtk or any of the gnome libraries. Using Qt or C++ in GNOME would significantly increase gnome's requirements.
But please, let's not rearchitect KDE and strip it of Qt.
Actually, I'd really like to see that.
glib is great -- I'd love to see it universally available. If both KDE and GNOME used it as a standard base library...
hdparm -d1 -u1 [hd devicename] doesn't help?
This newfangled Linux thing seems a bit risky. Minix is definitely the way to go.
It's there so that any random "bit rot" (single-bit errors) is caught and corrected before it causes damage.
That can't be right, though. The system *bus* doesn't have ECC, and by virtue of its far greater area, would be much more vulnerable to errors induced by interference than the RAM.
Actually, you are assuming that that is the speed per wire which isn't right.
No -- I meant the whole bus.
320Mbps = 320 / 16 = 20Mbytes/s
It's not 320Mbps. It's 320MBps, which is for the whole bus.
i can gurantee you that you will find some net access, if anything esle, you can always hit up down town cyber cafe'
Either cyber cafes or (simpler) a modem both came to mind. This seems far easier. If I needed 'Net access, I'd probably have a laptop, slap a modem and get an account with a national ISP, and be happy as a clam. This guy isn't going to be downloading movies onto his laptop during the road trip (I would imagine), so I can't see any reason this wouldn't work. There are phones *everywhere* in the US.
Okay. SCSI lets you do command queuing and reordering. Serial ATA will have this too. Theoretically, if you have a bunch of things doing sequential accesses at once, this can help. SCSI can have outstanding requests to multiple devices on a bus at once, and ATA cannot. This is a pretty big deal for environments where you can have heavy disk load, since if you have two drives on an ATA bus, one can get starved if the other is doing lots of work. I'm not sure if Serial ATA addresses this. For Average Joe's desktop, it's not a big deal because he's usually only doing one thing at once -- loading a game up, or copying a file.
SCSI is generally used to allow price discrimination by vendors. SCSI drives have a reputation for being more reliable, and much more expensive.
SCSI supports many more devices on a bus. This is a big deal to me -- it's a royal pain to buy another controller to add another device or two.
It's unlikely that the two will be merged any time soon, because there's tremendous financial incentive to prevent "enterprise-class" drives from becoming commoditized. SCSI is one of the industry's last useful tools to avoid this.
If you're getting a desktop, use ATA, almost certainly. If you're getting a server with a lot of drives, it may be worth your while to get SCSI, for the abovementioned benefits.
If I had some extra money and just wanted some extra reliability, I'd probably have a mirrored RAID pair of IDE drives, if I were building a desktop without a ton of drives.
What I don't get is there already is a serial SCSI, it is called Fibre Channel. Right now it is clocked at 4 Gbits/sec. and there is no reason it can't go faster.
Fiber optic hardware is more expensive. What I'd like to know is why *Firewire* doesn't serve the purpose.
Those numbers *sounded* completely wrong.
Existing SCSI is 320Mbps*8bits/byte = 2.5Gbps.
Moving to 3Gbits is evolutionary, not a huge jump.
I'm wondering what's going on here too -- WTF happened to Firewire? I remember thinking that everyone would be using it as a universal high bandwidth data bus, and for some reason it doesn't seem to be happening.