I (as an American) don't see the problem with this. If I pay taxes, and they get invested in research, I'd be quite happy if the proceeds of that research get reinvested BACK into research to either augment the amount I pay, or reduce the amount of burden on me as a taxpayer. I don't care if it's not America that is the one profiting -- why should we always feel we should be top dog? If Australia paid for and has the patent rights to it, then good for them - and if they reinvest it into research, then maybe we'll see something else good pop out of the labs down under.
Linux itself (the kernel) has frequently been dragged down routes that it shouldn't have simply to suit the needs of tools that run on top of it. A prime example (that supposedly has been dealt with in 2.6) was the/proc filesystem. It was always an ad-hoc set of entries, with no consistent data presentation format, and occasionally, some truly performance-killing requirements (eg: at one time, one had to close and reopen a file handle to get new data. A rewind() should have been sufficient, but didn't work.). These sorts of subtle things just show that the overall design is erratic, and frequently inconsistent since different developers have a different need or agenda that they are coding for. This is *not* a route towards a rock solid OS. Of course, these issues are being dealt with and fixed, but the fact that they occur in the first place is not a good thing.
Also, take a look at the recent thread on here regarding usability and KDE (and contained in the comments, Gnome). The user interface inconsistencies, flakiness, and generally poor design with respect to users is very sad. From an interface engineering perspective, Linux is near last place out there.
I believe this interface and kernel problem is not due to an inherently bad system (quite the contrary - Linux is great), but too many agendas and people driving one system in too many directions concurrently. Is Linux going to be a good server OS? What sort of server - a database server with one set of requirements, or a file server with a very different set? Or is it supposed to run on a workstation? How about my palm pilot? Or, how about bashing it into a form that can run on my Nintendo DS? All of these are places have a set of people with a different set of goals, and they're all pulling Linux in their respective directions. What is left? Something that is, without better words, somewhere in the centroid of all of their requirements - and far from the ideal point for any of them.
"Only question now is not if but when will Linux become the number one OS on earth?"
This is the attitude that is going to prevent that from ever happening. I wish the movers and shakers in the Linux world would decide to focus on a subset of the OS market, and do it well, instead of trying to do everything and losing focus of good engineering practices...
I have to agree - as a long time Linux user who left the platform for one that actually spends a great deal of effort on usability, I think it's progress to see the Linux GUI being criticized. My personal opinion is that KDE is far more consistent than GNOME -- license issues aside, the KDE environment felt better. Of course, this is simply an opinion.
The unfortunate pattern that seems to pervade the OSS GUI world is that less attention (sometimes none) is paid to giving users a uniform experience across apps, and more attention is given to simply providing cloned functionality of non-OSS programs. It seems to be of little value if I can get an OSS version of a Windows or Mac app, yet find myself in an interface that is subtly (or sometimes, drastically) different than every other application I use.
I will gladly run back to Linux and OSS GUIs when they catch up with the alternatives in terms of the user experience -- functionality is one thing, but usability is another. And it's definitely a key to retention and acceptance. Minimize the learning curve folks!
Of course, there is a definite line between decisions made for engineering reasons (ie, user interface standards and practices) and religious reasons (free vs. not). Opting towards good engineering and design would be a step in the right direction.
I haven't tried it myself, but there are times that it seems a binary compatible UNIX would be nice as an alternative to OSX. Quite often I find myself running plain-old C apps that perform much better and much more consistently if I boot OSX into console mode to disable the GUI infrastructure. It seems a pure darwin compute slave might be slightly more transparent to use than recompiling my code to run on *BSD or an OSX box setup to boot console only.
Of course, this is purely speculation - I haven't tried it myself. Anyoe out there tried this?
"Huh!? Sure it did. You couldn't run 32 bit code on a 286. In practice, by the time 32 bit became effectively mandatory (Win95), the sheer horsepower requirements pushed an upgrade more strongly than word size. It'll likely be the same this time around."
I don't think it's going to be horsepower requirements this time around. The 8086 - 286 - 386 - 486 lineage was many big steps in both clock speed and features. The current 64-bit processors aren't that different from their predecessors in terms of architectural improvements -- sure, a bit more cache, some pipeline changes, and maybe some register tweaks. Nothing like the 386/486 SX vs. DX issue (math coprocessor vs not).
The only big change you'll see now will be addressable memory. Longer word size processors have been around for decades, and for the non-scientific user, they've proven to be pretty useless. And I sure hope apps don't suddenly bloat up such that Linux + Gnome/KDE requires >32-bit address space. (Usually I'd use Windows in this argument, but recently I've discovered that the latest Suse + KDE or Gnome performs slower than the same machine running XP. Sigh...)
Have you considered updating that web page - keep the content you have there now, but possibly tack on some of the feedback from here that shows that yes, a very, very bad implementation of an algorithm will run slowly, regardless of the language. It would be a shame of someone ran across the page seeking a realistic comparison, and didn't look deep enough to realize that this "study" is basically the equivalent of comparing the gas mileage of two makes of automobile without informing the readers that one car had a semi-truck chained to the back of it during the trials.
Slashdot Mirror
GreyCat, MuLinux, Xdenu, 2diskXwin, NucLinux, SmallLinux, LoopLinux, PocketLinux, tomsrtbt, Trinux, CrashRecovery, LIAP, Giotto, Coyote, RIP, Ariane, FDLinux, IBIBLIO, FLI4l, LRP, Floppyfw, FrazierWall, Floppix, Monkey Linux
Is it just me, or do a ton of people out there do things without checking to see if someone else had the same idea 10+ years earlier?
I (as an American) don't see the problem with this. If I pay taxes, and they get invested in research, I'd be quite happy if the proceeds of that research get reinvested BACK into research to either augment the amount I pay, or reduce the amount of burden on me as a taxpayer. I don't care if it's not America that is the one profiting -- why should we always feel we should be top dog? If Australia paid for and has the patent rights to it, then good for them - and if they reinvest it into research, then maybe we'll see something else good pop out of the labs down under.
Linux itself (the kernel) has frequently been dragged down routes that it shouldn't have simply to suit the needs of tools that run on top of it. A prime example (that supposedly has been dealt with in 2.6) was the /proc filesystem. It was always an ad-hoc set of entries, with no consistent data presentation format, and occasionally, some truly performance-killing requirements (eg: at one time, one had to close and reopen a file handle to get new data. A rewind() should have been sufficient, but didn't work.). These sorts of subtle things just show that the overall design is erratic, and frequently inconsistent since different developers have a different need or agenda that they are coding for. This is *not* a route towards a rock solid OS. Of course, these issues are being dealt with and fixed, but the fact that they occur in the first place is not a good thing.
Also, take a look at the recent thread on here regarding usability and KDE (and contained in the comments, Gnome). The user interface inconsistencies, flakiness, and generally poor design with respect to users is very sad. From an interface engineering perspective, Linux is near last place out there.
I believe this interface and kernel problem is not due to an inherently bad system (quite the contrary - Linux is great), but too many agendas and people driving one system in too many directions concurrently. Is Linux going to be a good server OS? What sort of server - a database server with one set of requirements, or a file server with a very different set? Or is it supposed to run on a workstation? How about my palm pilot? Or, how about bashing it into a form that can run on my Nintendo DS? All of these are places have a set of people with a different set of goals, and they're all pulling Linux in their respective directions. What is left? Something that is, without better words, somewhere in the centroid of all of their requirements - and far from the ideal point for any of them.
This is the attitude that is going to prevent that from ever happening. I wish the movers and shakers in the Linux world would decide to focus on a subset of the OS market, and do it well, instead of trying to do everything and losing focus of good engineering practices...
The unfortunate pattern that seems to pervade the OSS GUI world is that less attention (sometimes none) is paid to giving users a uniform experience across apps, and more attention is given to simply providing cloned functionality of non-OSS programs. It seems to be of little value if I can get an OSS version of a Windows or Mac app, yet find myself in an interface that is subtly (or sometimes, drastically) different than every other application I use.
I will gladly run back to Linux and OSS GUIs when they catch up with the alternatives in terms of the user experience -- functionality is one thing, but usability is another. And it's definitely a key to retention and acceptance. Minimize the learning curve folks!
Of course, there is a definite line between decisions made for engineering reasons (ie, user interface standards and practices) and religious reasons (free vs. not). Opting towards good engineering and design would be a step in the right direction.
I haven't tried it myself, but there are times that it seems a binary compatible UNIX would be nice as an alternative to OSX. Quite often I find myself running plain-old C apps that perform much better and much more consistently if I boot OSX into console mode to disable the GUI infrastructure. It seems a pure darwin compute slave might be slightly more transparent to use than recompiling my code to run on *BSD or an OSX box setup to boot console only. Of course, this is purely speculation - I haven't tried it myself. Anyoe out there tried this?
I don't think it's going to be horsepower requirements this time around. The 8086 - 286 - 386 - 486 lineage was many big steps in both clock speed and features. The current 64-bit processors aren't that different from their predecessors in terms of architectural improvements -- sure, a bit more cache, some pipeline changes, and maybe some register tweaks. Nothing like the 386/486 SX vs. DX issue (math coprocessor vs not).
The only big change you'll see now will be addressable memory. Longer word size processors have been around for decades, and for the non-scientific user, they've proven to be pretty useless. And I sure hope apps don't suddenly bloat up such that Linux + Gnome/KDE requires >32-bit address space. (Usually I'd use Windows in this argument, but recently I've discovered that the latest Suse + KDE or Gnome performs slower than the same machine running XP. Sigh...)
Have you considered updating that web page - keep the content you have there now, but possibly tack on some of the feedback from here that shows that yes, a very, very bad implementation of an algorithm will run slowly, regardless of the language. It would be a shame of someone ran across the page seeking a realistic comparison, and didn't look deep enough to realize that this "study" is basically the equivalent of comparing the gas mileage of two makes of automobile without informing the readers that one car had a semi-truck chained to the back of it during the trials.