If you like them, more power to ya. I think they look cheesy. I prefer "cool" logos over "funny and irreverent" (Linus quote from boot magazine) logos, but that's just me... and four fifths of the adult population...
I know. That's my point. If the LSB isn't doing its job making an effective standard, then guys like Volkerding will be there to provide a better alternative.
This is so freaking cool! This is just the type of thing that Linux needs to become better than Windows in every possible way. EVAS is
A) Fast. We (I anyway) all love speed, don't we?
B) Has anti-aliased text! I haven't gotten Render to work yet (as I don't have a Matrox card) but I *DO* have an NVIDIA card, and from my POV, going through OpenGL is a much better way to integrate Render's features without yet another driver API.
C) Alpha blending? Compositing functions? Am I dreaming? I hope not!
I think that if the XFree guys keep hacking away at X (another couple of releases with jump as a big as 4.0, and X might get halfway to mediocre) and NVIDIA keeps churning out new Detonator releases, and the LibArt guys find a way to integrate with EVAS (yea, I know it's asking a lot, but everything is there, and it is wholly in the realm of possibility) then Quartz may not be the sexiest windowing environment around anymore. If EVAS takes off, I might even load Linux back on my system, and that is quite high praise indeed.
PS> I know I'm dilusional and self-important, live with it;)
Dude. 600/1200dpi? Magazines publish at 2400+ DPI. At that resoultion, a page-size graphic consumes over 2 gig of memory. Without the big-memory patches, Linux won't even handle that much. And I don't even want to think of trying to do a poster-sized logo in GIMP. Use REAL tools, it will make your life easier...
This sort of thing dose happen and makes perfictly good managment sence. An employee using a compeating product is both an endorcment of the product and an emberrisment to the employer.
>>>>>>>>>>>>>
Except, not really. Nobody even knows what the people behind the scenes use. A lot of people at the MS campus use *NIX. MS really doesn't care as long as they get a good product.
This is much worse when you have Linux advocates making logos using Windows
>>>>>>>>>>>>>>
Who cares? Isn't Linux about using the best product for the job? I don't know when Linux became a religion, but last thing I heard, people used it because it was better/freer/cheaper, not because it was anything not Windows.
Linux has very good graphics software and unless people are willing to spring for $2,000 profesional rendering pacages you are not likely to get much better results on other platforms.
>>>>>>>>
Except not really. For anything 3D, Linux is out until Maya gets ported. (Yea right, Blender, don't make me laugh.) Then there is the GIMP==Photoshop arguement. Ha ha, funny. Also, anybody who is in the graphics arts business already has Photoshop, so its not a new investment. Of course, the logo is going to end up being some amaturish spiral, so its not like what tool is used matters anyway.
PS> Yes, that's the whole problem with Linux. Crappy logos. For example...
A) The X logo. Black and what? How '80's of them. Oh wait...
B) The Redhat logo. Two tone? No style whatsoever.
C) The Debian logo. A spiral? How damn creative.
D) The Mandrake logos: Good grief, if I see any more purple cartoon penguins, I'll scream.
E) The freaking penguin: I'm sorry, but compared to the BSD Daemon, Sting (an unofficail BeOS mascot), or even the flying Windows, Tux just look uncool. Needs to lose some weight too.
Oh, god forbid that some Linux distros actually become COMPATIBLE and CONSISTANT. We UNIX grognards could never stand *anything* that was CONSISTANT. God help us, what are we going to do? People actually want to make MONEY of a good OS. How can we stop these capitalist bastards?
Good grief, quit complaining. If Linux get unified that would be a *good* thing, both for companies, and users. Not many people give a flying f*ck about tailoring their distro to their exact wants. Most people just want to use something that works well, without fussing with it. For these people, and LSB standard is a good thing. And for those people who couldn't stand a standard, well, Linux is free for a reason. The Debians and Slackwares of the world will always be around to annoy monolithic, all consuming companies like RedHat. Ideally, the LSB would write a strong standard, distros (but not all of them!) would follow it, and the free nature of Linux could be harnessed to keep the standard from becoming crappy.
Doh. I forgot that moderators never read at -1. I don't mind the mod-point (cuz it *was* offtopic) I just hope nobody thinks that I am inviting racist trolls to post on/. more often. I was replying to a troll that had set himself up too well to resist.
PS> Yea, you can mod this one too. Why doesn't/. offer post editing?
A) Has a better media API.
B) Is much, much faster.
C) Has a better filesystem.
D) has a level of integration between apps that OS-X can just dream of now.
True, I am sitting here drooling at Quartz, ObjC, and XML, but all the other stuff that OS-X will force me to live with (aging version of FreeBSD, antiquated Mach microkernel, slightly long in the tooth filesystem, etc) makes OS-X more of a "great try, needs work" rather than a "good god, I'm ditching Be."
It's exactly like NeXT... without the great windowing server, without the cool UI gadgets, and without the style and polish.
Seriously, though, saying that putting GNUStep onto Linux somehow makes it approach NeXT is pushing it. X doesn't compare to anything NeXT OS 5.0 (OS-X;) or even Next 4.0 has. DPS isn't yet ready on Linux. And Linux lacks the coherence exhibited by every non-*NIX OS out there.
I almost died laughing when I saw your list. I had thought people had gotten beyond the GIMP==Photoshop dillusional stage. Gimp comes nowhere near Photoshop. End of story. Do a big project on both and see which one you end up liking at the end of the day. OpenOffice not only has fewer features than MS Office, but they actually made it slower and harder to use. Now that takes some serious skill!
I haven't used Jazzware, but most likely it is inferior to Cakewalk. (How do I know? Jazzware doesn't cost as much;)
As for 3D Studio being equal to blender, don't make me laugh. Not only does 3D Studio's workflow and interface whip blender to shreds, but it has features Blender hasn't dreamed of.
PS: SAW and ACID are multi-track audio editors. Trust me, you won't find an equivilant for those on Linux either. Linux might have some good apps, but in terms of "best of breed" apps (regardless of cost, of course) the party's on Windows.
I guess we just have different priorities then. On my home machine, I would much rather have performance than data integrity (up to a point of course;) Of course, I have scripts sync my data directories to my trusty FreeBSD server, so a data loss wouldn't hit me as hard. Of course, I wouldn't run a green filesystem on by BSD server, so I guess I can see where you're coming from. I still think you should invest in a good tape drive and live on the edge a little;)
The only reason for using Windows is playing (3D) games
>>>>>>>>>>
What planet *are* you living on? I suppose all the Photoshop, SAW, Cakewalk, ACID, 3D Studio, Office, etc, all have their own fully functional, OSS counterparts. In terms of apps, Linux only competes in the server market and light-weight home user market.
implementation I like; a thin layer ontop of proven code
>>>>>>>>>>
Yuck. To some extent that's fine, but eventually, you get a bunch of layers that really needn't be there, and a core layer that is rapidly decaying. The whole idea of "layers of software" make me retch. I'm a more horizontal person myself. Anyway, ext2 is nothing special. It's stable, and it's reasonably fast, but the design has been done (better) before in fs's like FFS. (Before anybody says ext2 is faster, mount it sync and see what happens.) ReiserFS has shown that it is quite stable, and very fast. In other words, better than ext2, and better than ext3 ever can be. I think that its here at the right time, and its done well enough to switch to it. At some point, it just makes sense to throw away the old code (but not the old ideas) and implement the thing better. ReiserFS is that better implementation, so stop bitching and do some debugging...
As for data loss, journelling FSs give no protection against that, they just provide fs consistancy. Anything JFS does is its own feature.
In addition to the stuff the other guy mentioned, journeling filesystems also seem to be able to handle changes like unlinking files much more quickly than ext or FFS. After doing a full build, deleting the XFree86 source tree takes several minutes on ext2, but is more or less instantaneous on ReiserFS.
It's not the same thing. Clumping all employee data together makes sense (since they all work at the same company) Different applications are totally unrelated, and their configurations should be kept seperate, but accessible from the same place. For instance, that's how the internet works. All the webpages aren't put on a central server. Instead, they're spread out and a common broker (DNS) allows you to access them from a central point. Stupid analogies aside, the fact remains that the only reason RPM and Windows keep a central registry of data is because that's the easy thing to do. Getting rid of that central registry, however, complicates things for the package manager designer (unless you've got great OS support, the reason I don't use a central DB is because the API's in BeOS make this method simpler for me;) but frees the user from having to worry about database consistancy, or having to worry about what "going behind the tool's back" will do to their system. Think, for example, why you can't just delete a directory to uninstall an application. Apps litter your registry (Windows) or your home or/etc directory (UNIX) or you/config/settings directory (BeOS) with configuration data. Instead, if all configuration data was kept local the app, but the system provided a central access point for that data, you could just delete a directory and be done with it. Yet, you'd have the central access through the tools. Decide that you want to change the name of the app directory? In Windows, you have to reinstall, in Linux you have to reinstall, with a decentralized system, you just change the name.
John Carmack's reference system is a PIII because either
A) The PIII is faster at Quake than an Athlon
B) The PIII is more common than an Athlon
C) The PIII has better Visual C++ support
D) The PIII has multiprocessor capability (Quake III is SMP)
Take your pick. I have not heard a single comment from Carmack that he uses a PIII because of compatibility issues. And even if he does, it means jack-shit because he is probably just phobic from the whole K6 dabacle, (chips which actually *did* have compatibility problems!) If you are saying that programmers avoid AMD like the plague, I'd request that you get your head out of your ass and show me exactly where it says that!
You're delusional, aren't you?
>>>>>>>
Good drugs.
Databases are evil? Care to cite a few reasons, or is it just that you don't understand them?
>>>>>>>>>
Right. I'm stupid. That is why I disagree with you. Grow up, jackass. I say databases are stupid when they are not used properly. Just as keeping a central database of all configuration data (the Windows registry) is stupid, keeping a central database of all files (locate) is stupid, and keeping a central database of all packages (RPM) is stupid. Package info should not be stored in one big database, but spread throughout a hierarchy and contained within the packages that they refer to. For example, I'm writing a package manager for BeOS. It has no central database. Instead, all dependency and package info is stored within the attributes of the folder where the package was installed. For example, if I install app.pkg to/boot/apps/app, then all the dependency info, version info, the description, update information, author, etc, is stored within the attributes of the/boot/apps/app folder. The folder is given a special key attribute, and every time I need to locate a dependency, I just search for that key and get the correct folder. The only centralized info is a cache of common searches. This is better than a centralized database for several reasons:
A) No single point of failiure, and the importance of keeping the database's state correct dissapears.
B) Packages can be moved, removed, renamed, etc, without having to update a central database, or having to go through tools like RPM.
C) The user has total control over where packages are installed, and how dependencies are satisfied.
D) The user has access to this data through any tool that deals with the (system standard) attribute system. This is unlike RPM, where only software coded for the RPM database is useful in accessing its data.
While this would be harder to implement in Linux (which doesn't allow filesystem attributes) it wouldn't be terribly hard to emulate.
You really are delusional. What control does an RPM take away from the user?
>>>>>>>>>>
You don't get to decide which dependencies are filled, the package maintainers do. You don't get to decide where stuff is installed (not without breaking things anyway) the package maintainers do. You don't get to decide how your system configuration is updated, the package maintainers do.
You do realize you can still
build RPMs from source, right?
>>>>>>>>
That doesn't solve any of the problems I just mentioned.
Let me suggest a course in reading comprehension.
>>>>>>>>>>
Let me suggest a course in common courtesy.
Go back and read what I wrote again. I pointed out one
package from slackerware 7.2 that is old, but harkened to the days when half of the packages were 3 or 4
versions old.
>>>>>>>>>>>
When I say that the Debian distro is out of date, people tell me to go use -unstable. If you're telling me that Slackware is out of date, then I'm assuming you're talking about 7.x, because the previous versions are too different to warrent any consideration.
Intel must be paying you good money. They should have to, to get you to spout bullshit like that...
laggy API that only performs decently on $75,000 Sparc servers
>>>>>>>>>>
Umm, API's are only laggy if they're inherently badly designed (like X:) Otherwise, their speed depends only on implementation. So if you are remarking that Solaris's API is laggy, then you've just discounted every *NIX out there. On the other hand, if you are saying that Solaris itself is laggy, then remember that a lot of these servers will use Linux.
92.815% x86 compatible CPU = disaster!!!
>>>>>>>>>>>>>>>
Yes, the Athlon is totally x86 uncompatible. Absolute and utter bullshit. I have yet to hear of an incompatibility problem with the Athlon CPU. Aside from the lack os SSE, the Athlon is 100% compatible. Maybe you'd care to point at some stories that show otherwise? Even rare x86 instructions like sysenter/sysexit are supported in the same way as on a P6. What *are* you talking about?
Sorry. I missed the announcement of Sony's Linux-based IA. Since Sony is using this very dead OS in its eVilla IA I'm sure it has one based on the very not-dead LinuxOS, right?
Slashdot Mirror
If you like them, more power to ya. I think they look cheesy. I prefer "cool" logos over "funny and irreverent" (Linus quote from boot magazine) logos, but that's just me... and four fifths of the adult population...
True, however I was giving measurements according to what guidelines some mag posted about what resolution to send art at.
I know. That's my point. If the LSB isn't doing its job making an effective standard, then guys like Volkerding will be there to provide a better alternative.
This is so freaking cool! This is just the type of thing that Linux needs to become better than Windows in every possible way. EVAS is A) Fast. We (I anyway) all love speed, don't we? B) Has anti-aliased text! I haven't gotten Render to work yet (as I don't have a Matrox card) but I *DO* have an NVIDIA card, and from my POV, going through OpenGL is a much better way to integrate Render's features without yet another driver API. C) Alpha blending? Compositing functions? Am I dreaming? I hope not! I think that if the XFree guys keep hacking away at X (another couple of releases with jump as a big as 4.0, and X might get halfway to mediocre) and NVIDIA keeps churning out new Detonator releases, and the LibArt guys find a way to integrate with EVAS (yea, I know it's asking a lot, but everything is there, and it is wholly in the realm of possibility) then Quartz may not be the sexiest windowing environment around anymore. If EVAS takes off, I might even load Linux back on my system, and that is quite high praise indeed. PS> I know I'm dilusional and self-important, live with it ;)
I think he was trying to be funny. And if he wasn't, and actually *likes* Mandrake's logos, then somebody call a medic...
Dude. 600/1200dpi? Magazines publish at 2400+ DPI. At that resoultion, a page-size graphic consumes over 2 gig of memory. Without the big-memory patches, Linux won't even handle that much. And I don't even want to think of trying to do a poster-sized logo in GIMP. Use REAL tools, it will make your life easier...
It's like microsoft using Apache/PHP/MySQL on their servers.
>>>>>>>>>>>
Or like using BSD to run Hotmail?
This sort of thing dose happen and makes perfictly good managment sence. An employee using a compeating product is both an endorcment of the product and an emberrisment to the employer.
>>>>>>>>>>>>>
Except, not really. Nobody even knows what the people behind the scenes use. A lot of people at the MS campus use *NIX. MS really doesn't care as long as they get a good product.
This is much worse when you have Linux advocates making logos using Windows
>>>>>>>>>>>>>>
Who cares? Isn't Linux about using the best product for the job? I don't know when Linux became a religion, but last thing I heard, people used it because it was better/freer/cheaper, not because it was anything not Windows.
Linux has very good graphics software and unless people are willing to spring for $2,000 profesional rendering pacages you are not likely to get much better results on other platforms.
>>>>>>>>
Except not really. For anything 3D, Linux is out until Maya gets ported. (Yea right, Blender, don't make me laugh.) Then there is the GIMP==Photoshop arguement. Ha ha, funny. Also, anybody who is in the graphics arts business already has Photoshop, so its not a new investment. Of course, the logo is going to end up being some amaturish spiral, so its not like what tool is used matters anyway.
PS> Yes, that's the whole problem with Linux. Crappy logos. For example...
A) The X logo. Black and what? How '80's of them. Oh wait...
B) The Redhat logo. Two tone? No style whatsoever.
C) The Debian logo. A spiral? How damn creative.
D) The Mandrake logos: Good grief, if I see any more purple cartoon penguins, I'll scream.
E) The freaking penguin: I'm sorry, but compared to the BSD Daemon, Sting (an unofficail BeOS mascot), or even the flying Windows, Tux just look uncool. Needs to lose some weight too.
Oh, god forbid that some Linux distros actually become COMPATIBLE and CONSISTANT. We UNIX grognards could never stand *anything* that was CONSISTANT. God help us, what are we going to do? People actually want to make MONEY of a good OS. How can we stop these capitalist bastards?
Good grief, quit complaining. If Linux get unified that would be a *good* thing, both for companies, and users. Not many people give a flying f*ck about tailoring their distro to their exact wants. Most people just want to use something that works well, without fussing with it. For these people, and LSB standard is a good thing. And for those people who couldn't stand a standard, well, Linux is free for a reason. The Debians and Slackwares of the world will always be around to annoy monolithic, all consuming companies like RedHat. Ideally, the LSB would write a strong standard, distros (but not all of them!) would follow it, and the free nature of Linux could be harnessed to keep the standard from becoming crappy.
Doh. I forgot that moderators never read at -1. I don't mind the mod-point (cuz it *was* offtopic) I just hope nobody thinks that I am inviting racist trolls to post on /. more often. I was replying to a troll that had set himself up too well to resist.
/. offer post editing?
PS> Yea, you can mod this one too. Why doesn't
While BeOS might not be as pretty, it
A) Has a better media API.
B) Is much, much faster.
C) Has a better filesystem.
D) has a level of integration between apps that OS-X can just dream of now.
True, I am sitting here drooling at Quartz, ObjC, and XML, but all the other stuff that OS-X will force me to live with (aging version of FreeBSD, antiquated Mach microkernel, slightly long in the tooth filesystem, etc) makes OS-X more of a "great try, needs work" rather than a "good god, I'm ditching Be."
It's exactly like NeXT... without the great windowing server, without the cool UI gadgets, and without the style and polish.
;) or even Next 4.0 has. DPS isn't yet ready on Linux. And Linux lacks the coherence exhibited by every non-*NIX OS out there.
Seriously, though, saying that putting GNUStep onto Linux somehow makes it approach NeXT is pushing it. X doesn't compare to anything NeXT OS 5.0 (OS-X
I almost died laughing when I saw your list. I had thought people had gotten beyond the GIMP==Photoshop dillusional stage. Gimp comes nowhere near Photoshop. End of story. Do a big project on both and see which one you end up liking at the end of the day. OpenOffice not only has fewer features than MS Office, but they actually made it slower and harder to use. Now that takes some serious skill! ;)
I haven't used Jazzware, but most likely it is inferior to Cakewalk. (How do I know? Jazzware doesn't cost as much
As for 3D Studio being equal to blender, don't make me laugh. Not only does 3D Studio's workflow and interface whip blender to shreds, but it has features Blender hasn't dreamed of.
PS: SAW and ACID are multi-track audio editors. Trust me, you won't find an equivilant for those on Linux either. Linux might have some good apps, but in terms of "best of breed" apps (regardless of cost, of course) the party's on Windows.
I guess we just have different priorities then. On my home machine, I would much rather have performance than data integrity (up to a point of course ;) Of course, I have scripts sync my data directories to my trusty FreeBSD server, so a data loss wouldn't hit me as hard. Of course, I wouldn't run a green filesystem on by BSD server, so I guess I can see where you're coming from. I still think you should invest in a good tape drive and live on the edge a little ;)
The only reason for using Windows is playing (3D) games
>>>>>>>>>>
What planet *are* you living on? I suppose all the Photoshop, SAW, Cakewalk, ACID, 3D Studio, Office, etc, all have their own fully functional, OSS counterparts. In terms of apps, Linux only competes in the server market and light-weight home user market.
implementation I like; a thin layer ontop of proven code
>>>>>>>>>>
Yuck. To some extent that's fine, but eventually, you get a bunch of layers that really needn't be there, and a core layer that is rapidly decaying. The whole idea of "layers of software" make me retch. I'm a more horizontal person myself. Anyway, ext2 is nothing special. It's stable, and it's reasonably fast, but the design has been done (better) before in fs's like FFS. (Before anybody says ext2 is faster, mount it sync and see what happens.) ReiserFS has shown that it is quite stable, and very fast. In other words, better than ext2, and better than ext3 ever can be. I think that its here at the right time, and its done well enough to switch to it. At some point, it just makes sense to throw away the old code (but not the old ideas) and implement the thing better. ReiserFS is that better implementation, so stop bitching and do some debugging...
As for data loss, journelling FSs give no protection against that, they just provide fs consistancy. Anything JFS does is its own feature.
In addition to the stuff the other guy mentioned, journeling filesystems also seem to be able to handle changes like unlinking files much more quickly than ext or FFS. After doing a full build, deleting the XFree86 source tree takes several minutes on ext2, but is more or less instantaneous on ReiserFS.
I stand corrected, defeated, and humiliated ;) The point still stands that requiring a user-level program to ferret out library names is stupid.
It's not the same thing. Clumping all employee data together makes sense (since they all work at the same company) Different applications are totally unrelated, and their configurations should be kept seperate, but accessible from the same place. For instance, that's how the internet works. All the webpages aren't put on a central server. Instead, they're spread out and a common broker (DNS) allows you to access them from a central point. Stupid analogies aside, the fact remains that the only reason RPM and Windows keep a central registry of data is because that's the easy thing to do. Getting rid of that central registry, however, complicates things for the package manager designer (unless you've got great OS support, the reason I don't use a central DB is because the API's in BeOS make this method simpler for me ;) but frees the user from having to worry about database consistancy, or having to worry about what "going behind the tool's back" will do to their system. Think, for example, why you can't just delete a directory to uninstall an application. Apps litter your registry (Windows) or your home or /etc directory (UNIX) or you /config/settings directory (BeOS) with configuration data. Instead, if all configuration data was kept local the app, but the system provided a central access point for that data, you could just delete a directory and be done with it. Yet, you'd have the central access through the tools. Decide that you want to change the name of the app directory? In Windows, you have to reinstall, in Linux you have to reinstall, with a decentralized system, you just change the name.
Actually, the think the actual loading (at least on most *NIXs, I don't know about Linux) is done by ld.so.
John Carmack's reference system is a PIII because either
A) The PIII is faster at Quake than an Athlon
B) The PIII is more common than an Athlon
C) The PIII has better Visual C++ support
D) The PIII has multiprocessor capability (Quake III is SMP)
Take your pick. I have not heard a single comment from Carmack that he uses a PIII because of compatibility issues. And even if he does, it means jack-shit because he is probably just phobic from the whole K6 dabacle, (chips which actually *did* have compatibility problems!) If you are saying that programmers avoid AMD like the plague, I'd request that you get your head out of your ass and show me exactly where it says that!
I don't know about you, but I read the book first. It was a weird purple and blue book, but it *was* Star Trek Generations.
You're delusional, aren't you?
/boot/apps/app, then all the dependency info, version info, the description, update information, author, etc, is stored within the attributes of the /boot/apps/app folder. The folder is given a special key attribute, and every time I need to locate a dependency, I just search for that key and get the correct folder. The only centralized info is a cache of common searches. This is better than a centralized database for several reasons:
>>>>>>>
Good drugs.
Databases are evil? Care to cite a few reasons, or is it just that you don't understand them?
>>>>>>>>>
Right. I'm stupid. That is why I disagree with you. Grow up, jackass. I say databases are stupid when they are not used properly. Just as keeping a central database of all configuration data (the Windows registry) is stupid, keeping a central database of all files (locate) is stupid, and keeping a central database of all packages (RPM) is stupid. Package info should not be stored in one big database, but spread throughout a hierarchy and contained within the packages that they refer to. For example, I'm writing a package manager for BeOS. It has no central database. Instead, all dependency and package info is stored within the attributes of the folder where the package was installed. For example, if I install app.pkg to
A) No single point of failiure, and the importance of keeping the database's state correct dissapears.
B) Packages can be moved, removed, renamed, etc, without having to update a central database, or having to go through tools like RPM.
C) The user has total control over where packages are installed, and how dependencies are satisfied.
D) The user has access to this data through any tool that deals with the (system standard) attribute system. This is unlike RPM, where only software coded for the RPM database is useful in accessing its data.
While this would be harder to implement in Linux (which doesn't allow filesystem attributes) it wouldn't be terribly hard to emulate.
You really are delusional. What control does an RPM take away from the user?
>>>>>>>>>>
You don't get to decide which dependencies are filled, the package maintainers do. You don't get to decide where stuff is installed (not without breaking things anyway) the package maintainers do. You don't get to decide how your system configuration is updated, the package maintainers do.
You do realize you can still
build RPMs from source, right?
>>>>>>>>
That doesn't solve any of the problems I just mentioned.
Let me suggest a course in reading comprehension.
>>>>>>>>>>
Let me suggest a course in common courtesy.
Go back and read what I wrote again. I pointed out one
package from slackerware 7.2 that is old, but harkened to the days when half of the packages were 3 or 4
versions old.
>>>>>>>>>>>
When I say that the Debian distro is out of date, people tell me to go use -unstable. If you're telling me that Slackware is out of date, then I'm assuming you're talking about 7.x, because the previous versions are too different to warrent any consideration.
Intel must be paying you good money. They should have to, to get you to spout bullshit like that...
:) Otherwise, their speed depends only on implementation. So if you are remarking that Solaris's API is laggy, then you've just discounted every *NIX out there. On the other hand, if you are saying that Solaris itself is laggy, then remember that a lot of these servers will use Linux.
laggy API that only performs decently on $75,000 Sparc servers
>>>>>>>>>>
Umm, API's are only laggy if they're inherently badly designed (like X
92.815% x86 compatible CPU = disaster!!!
>>>>>>>>>>>>>>>
Yes, the Athlon is totally x86 uncompatible. Absolute and utter bullshit. I have yet to hear of an incompatibility problem with the Athlon CPU. Aside from the lack os SSE, the Athlon is 100% compatible. Maybe you'd care to point at some stories that show otherwise? Even rare x86 instructions like sysenter/sysexit are supported in the same way as on a P6. What *are* you talking about?
Sorry. I missed the announcement of Sony's Linux-based IA. Since Sony is using this very dead OS in its eVilla IA I'm sure it has one based on the very not-dead LinuxOS, right?