I do not know, if you have read the official standard, but neither "sun.*", "com.apple.*" nor "com.microsoft.*" are part of it.
See, and like Java, Linux, too, has parts that are standardized and parts that are not standardized. So, your whining about the existence of unportable parts of Linux distributions is unwarranted. In fact, the parts of Linux distributions that need to be standardized are standardized because those are the parts that people standardize! Java is in far worse shape because it fails to standardize things people would like standardized, and it standardizes things that Sun thinks are useful to standardize (often just for their own benefit).
I just wanted to say, that neither approach actually solves the problem, that there is the requirement to some kind of leadership. In Linux development, this post is currently filled in more or less good way by Linus Torvalds
Yes, and why do you think Linux has a good leader? It's because Linux can get forked: if Linus stops doing a good job, someone else takes over. But nobody can take over from Sun because Java is proprietary; and that's no accident: Sun wants to remain in the driver seat, no matter how poor a job they may be doing.
I know of no way to solve the bikeshed problem. I only said, that -- unfortunately -- it is also not solved by a bazaar like approach
There is no problem--that kind of debate is a normal and healthy part of design--it just needs to happen at the right level. With open source, it is happening at the right level. With the JCP, it is happening at the wrong level.
I think they won't be able to compete with an FPGA-based design: ultimately, those chips are too much work to program and they don't use their transistors all that efficiently when you already know you are mostly going to be doing stuff with numbers.
If, instead, they can come up with a high performance vector or SIMD machine which also has graphics output at a decent price, then they might really have something that people would snap up, not only for doing killer 3D graphics on, but also for doing more general computation.
No, but you do need a license to have a copy of the copyrighted work in your posession. And that license can regulate your use. It can't regulate your use completely (you can make backup copies, you can sell your license), but it can regulate many aspects of your use.
If you don't believe me, try buying a 1 CPU license from Microsoft, running it on an 8 CPU system, and taunting their lawyers with it.
I didn't make that copy therefore anything agreed to in order to poduce that copy is between the rights holder and the person making the copy, NOT me
But you made a purchase contract with someone who copied the item under license. No matter what you do, you have no way of obtaining a copy of the software legally without agreeing to its license.
I don't understand your mental block. Microsoft, Sun, IBM, etc. have been regulating your use of your software for decades using licenses and copyright.
Most Linux-only users use NFS, which does not have these security holes.
Are you kidding? From a security point of view, past versions of NFS have been an absolute disaster, far worse than SMB. You can run NFS only if you have complete trust in your network infrastructure and every single machine on it. Sun's engineers must have been on drugs when designing it.
NFSv4 may fix some of those problems, but it hasn't been widely deployed yet, and it is far more complex than it has a right to be given its limited functionality. All network file systems for Linux currently have major problems of one kind or another (they are one of incompatible, immature, insecure, etc.).
Any 'copying' necessary to actually use the work in a normal fashion should be seen in the same light as the 'imaged copy' on your retina of the book, the analogy is strongest in reference to ram storage of the pieces of code and data in use as they are temporary as is the image on your retina from said book.
The "copy" in question isn't the copying into RAM when you use the software, it's the copying that took place when you obtained your copy of the software. It's at that point that you agree to abide by the use restrictions in the future when you actually use the software.
That can be a bit reaching.
It can be. And the law limits how far such licenses can reach in various ways. But that doesn't change the principle.
Also, use of a program (that is, merely executing the program) is not a power regulated by US copyright law
No, but in order to use the program, you have had to copy it. And in order to copy it, you have had to agree to its license. And licenses can impose all sorts of binding conditions on you. Therefore, a license on a copyrighted piece of software can regulate its use, although the GPL chooses not to.
What about the Guy Who Wants to Make a Few Bucks Writing Useful Software So He Can Pay His Rent? He wants to create and share, but would like to earn a living wage doing it
What does that have to do with the GPL? Lots of people (myself included) have gotten paid (and paid very well) to develop GPL'ed software.
Of all these standards as you cite them, only Gnome has actually originiated from the community or a bazaar-like design approach.
At issue is not where the standard originated, but Schwartz's bogus claims that OSS can't implement and maintain practical, de-facto standards. In reality, all the OSS I mentioned gives me more compatibility between a wider range of platforms than Java ever has. OSS evolves at just the speed and offers just the level of compatibility users need because it gives users a real choice. With Java, Sun makes the decisions, and they are wrong.
There is a number huge of systems out there, were the community approach has utterly failed. There is the Linux DDI, there is the ever-changing glibc and there are things like/proc, that I do not really want to loose a word about.
Well, then Java obviously isn't cross-platform either: just look at sun.* and com.apple.*! What frightening inconsistency between different platforms and implementations!
But very often, that does not work. When there is no one to step up and make a design decision or when the one is simply ignored or flamed to death by the people involved, things go wrong. And that's a problem, open source does not solve, but rather possibly increase, since everybody regardless of qualification will try to put down his fingerprint.
You're just making the same tired, old argument that it takes a big, centrally managed process to set good standards. The market's experience with IBM's and Microsoft's hegemony disproved that conclusively, and Sun is doing an even worse job. Event if I wanted to attach myself to a corporate standards setter, it would be to Microsoft, not to a loser like Sun.
Parkinson's bikeshed story was true in 1950 and it is still true today; neither the system in which it surfaces nor the people have changed.
You don't understand the bikeshed story if you think the solution to the problem it describes (which is a real problem) is to institute heavy-handed top-down decision making.
The original UNIX file system was an arbitrary directed graph (similar to databases for knowledge representation), not hierarchical. Pick and MUMPS were database-based OSes developed in the 1960's. AS/400 came out in the 1980's and was database-based. Going back at least as far as the 1960's, people also experimented in various ways with more complex file systems: metadata, versioning, notification, etc., and many mainframe OSes also effectively made every file a database. All of these have disappeared, except for niche applications. In practice, after half a century of experimentation and evolution, flat files in a directory hierarchy, together with user-mode database implementations, have turned out to be the best engineering compromise. They suck, but they suck less than all known alternatives.
Sun uses the second with the Java programming language specification. That may cause a major uproar, everytime it is discussed
The "uproar" is about Sun's misrepresentation of Java as an "open" system (viz Schwartz's latest drivel). If Sun stood by their convictions and just told everybody consistently that Java was proprietary and not open, people wouldn't give it a second though. But if Sun hadn't misrepresented Java as "open", people would have just seen a poorly executed proprietary platform and it wouldn't be used very much today.
Since the first way seems not to work well within most parts of the open source community
It works very well: most major open source OS'es implement POSIX and other common standards and systems like Perl, Python, Tcl, and Gnome run on dozens of different platforms. The APIs and functionality of those systems has been exceptionally stable. Sun Java is pitiful in comparison.
For example Apple's JVM has extensions, but they don't get sued b/c they also implement the entire J2SE specification.
Actually, Apple probably doesn't get sued because they licensed their implementation from Sun and because it would be unwise for Sun to sue a licensee.
(Based on my experience with Apple Java, I find it difficult to believe that it really passes all the test cases.)
There is a point to maintaining pruity in your programming language. For example, we have an application at work that some knuckleheads in New York wrote against Microsoft Java about 2 years ago. Now the thing doesn't work with Sun Java, doesn't work with IBM Java and it doesn't even work with the new Microsoft Java. I'm forced to uninstall java on every machine in my location and install a 2 yr old M$ build.
If those people hadn't had Microsoft Java, they would have used some other Microsoft language and you would be even worse off. Something written in MS Java is still a lot easier to port than something in VB or VC++.
Sun's claims that they are "ensuring compatibility" are just a smokescreen; they really just don't want to give up ownership of the platform because they apparently hope that that kind of ownership of an entire software platform gives them some kind of escape hatch once their other businesses fail.
I encourage you to find out what bullshit these claims from Schwartz are by going to the JCP home page and having a look at what you actually get. JCP specification downloads require you to agree to a license that starts out with:
SUN IS WILLING TO LICENSE THIS SPECIFICATION TO YOU ONLY UPON THE CONDITION THAT YOU ACCEPT ALL OF THE TERMS CONTAINED IN THIS LICENSE AGREEMENT ("AGREEMENT").
What you see is that Sun owns the specifications. Sun also has a lifetime membership in the JCP, and they effectively decide at their discretion whether your implementation conforms or not. Java/JCP isn't a bazaar, it's the Catholic Church, with Sun being the infallible Pope and making all the final decisions and a bunch of cardinals that provide volunteer labor as part of the JCP (you can figure out for yourself what position they want you to assume).
As for Schwartz's comments about Linux, Linus gets to run the show because he delivers results, not because he has any special status. That's what makes Linux a "bazaar"--it can be forked and it has been forked. On the other hand, Sun gets to run the show with Java only because they have kept Java proprietary; they know full well that as soon as they free Java and make their implementation open source, they'll lose control because they have been doing such a poor job.
Schwartz seems to live by the credo of another well-known propagandist, that if you repeat a lie often enough, people will believe it, no matter how preposterous it may be. He sees his empire crumbling and in poverty, pines for its past glories, and wants to make a last ditch effort to take over the world. Let's not let it come to that. The best defense against Sun's propaganda and campaign of misinformation is to read and think for yourself: read their licenses and think about them and their consequences carefully. What Schwartz says doesn't matter; what matters is their licenses and intellectual property.
But don't you think it's telling that all those PDAs used DBs for data, rather than files?
Yes: it's telling you that they were RAM-based devices with limited memory.
Files and filesystems are primitive hierarchical databases, exclusive subsets (acyclic graphs, trees) with symlink hacks to wriggle in the straitjacket. And their metadata is structured upfront by the filesystem designers, and typically becomes obsolete, therefore retrofitted, very quickly. Instead, we should learn from 30 years of accumulated experience about structure,
You got it backwards. File systems started out much more like databases. They turned into what they are today because it's the best known compromise from the user's point of view. If they are going to change, it's more in the direction of ReiserFS and Plan9. And one important purpose of file systems is to organize general purpose databases, like for PDA apps.
Palm's response to defects in their DB implementation should be to fix it, make it better, rather than give up and crawl back to an even more braindead DB, the filesystem.
Palm's "DB implementation" doesn't "have defects", it is a defect--as is Palm's file system implementation (I'm not talking about FAT, I'm talking about the directory listing you get in Launcher > Delete).
Which consumer-grade OS used only DB storage before PalmOS?
The Newton, original Sharp and Casio organizers, several versions of Psion, and PARCTAB handhelds, to name just a few. (And, in contrast to its predecessors, the poor storage system Palm actually has hardly deserves the name "database".)
And why do handhelds need files, instead of just datasets? Why does *anyone* need files, except perhaps in the presentation layer, where they can be simulated (and always have been simulated)?
Because files represent units of data and metadata that people commonly work with: documents, images, etc.
The problem is that even IF you by from a OSS friendly hardware vendor its still a PITA to get a driver running if it happens to be developed outside the Linux kernel.
I feel your pain and I agree: it would be nice to have a more stable binary interface for the purpose of distributing open source drivers more easily. However, the parent post was complaining that he wanted a more stable driver interface for the purpose of running proprietary drivers, and that's a short-sighted attitude.
I can't speak for Linus at all, but my impression is simply that the risk of more proprietary binary-only drivers together with the extra work involved in maintaining a stable interface outweigh the advantages in the kernel developer's minds. I'm not sure I agree with that myself, but what I do agree with is to tell developers of binary-only drivers to go take a hike.
ohh i see, so the drivers API are changed not to improve them but for the only purpose of make the using of binary drivers impossible !!
No. Driver APIs are changed as needed. The kernel developers just don't bother to accomodate binary-only drivers.
ohh i see, those unspecified "many" have to be right right ?
Ultimately, it's the people who are writing the code. If you don't like it, you can fork the kernel and develop it yourself. But they seem to be doing something right.
Mod me flamebait if you will, there's always a first, but I honestly think that it is exactly this hobbystic, unprofessional, and not-caring way of thinking that hinders the widespread adoption of linux.
Linux runs on far more hardware platforms than Windows or OS X. The current situation vis-a-vis PC hardware is not ideal, but it's the PC hardware vendors that need to change if they want to sell their hardware for Linux.
As for "professionalism", Linus/x has made a choice on licenses and its success is self-evident. His choice is no less professional than Microsoft or Apple's choice on licenses. If you don't like it, buy something else.
Why move from the major innovation of *all database storage*
It wasn't an innovation (lots of systems had used that kind of storage before)
Palm's implementation of the concept was poor
Whether you like it or not, handhelds need to be able to deal with files
Palm needed files. The real question is why they didn't put the Palm application environment on top of a nice Linux kernel and ReiserFS, instead of hacking in FAT.
Increasing abstraction is necessarily the way of things.
Better languages give you increasing abstraction, which is a good thing. But tools don't really give you increasing abstraction, they just try to hide complexity.
The next wave is the ides that make the repetitive coding unnecessary.
That has also been the previous wave and the wave before that. In all those waves, people tried to get by with tools, but eventually they realized, they had to move to new languages. It's going to be the same this time around.
People will develop software like that right after we get world peace, have completely switched to renewable energy, and everybody exercises for 1h and flosses and brushes three times a day.
Re:I'd Like to Run Linux -- Just No Time
on
Linux Kernel to Fork?
·
· Score: 2, Informative
I imagine a future where I can download a copy of Linux and it would install on my system without any configuration and every option would be through an option menu, like our Slashdot prefs. If this could be a reality today, I would drop XP in a heartbeat.
Install SuSE, RedHat, or Ubuntu: they are easier to install than Windows XP and come with tons of applications. They even come with excellent printed documentation in case you do need to look something up.
Even easier, buy a PC with Linux pre-installed: you just plug it in and it works.
A driver compiled for 2.6.1 should work, in its binary form, on 2.6.2, 2.6.3, and 2.6.99. If Linus wants to change the API, he should wait until 2.7/2.8 to do so.
That's deliberate...
In fact, I recently had to ditch Linux for a project which required four different third-party add-ons, because I couldn't find a Linux distribution common to those supported by all four. We had to buy a Sun machine and use Solaris, because Sun has the common sense to keep a consistent driver API across each major version.
... and that's the reason why. If it were easy to use binary drivers, more and more drivers would become binary. For making Linux distributions easier to manage, it would be nice if binary drivers were easier to manage and distribute for Linux. But the fact that that would make distribution of binary-only drivers easier is considered a disadvantage by many.
Overall, please either by from open source friendly hardware vendors, or pay the price for a proprietary operating system. You have chosen the second option, so deal with it.
Slashdot Mirror
Sounds like the same technique should work with solar energy, both the heating and the electrolysis.
I do not know, if you have read the official standard, but neither "sun.*", "com.apple.*" nor "com.microsoft.*" are part of it.
See, and like Java, Linux, too, has parts that are standardized and parts that are not standardized. So, your whining about the existence of unportable parts of Linux distributions is unwarranted. In fact, the parts of Linux distributions that need to be standardized are standardized because those are the parts that people standardize! Java is in far worse shape because it fails to standardize things people would like standardized, and it standardizes things that Sun thinks are useful to standardize (often just for their own benefit).
I just wanted to say, that neither approach actually solves the problem, that there is the requirement to some kind of leadership. In Linux development, this post is currently filled in more or less good way by Linus Torvalds
Yes, and why do you think Linux has a good leader? It's because Linux can get forked: if Linus stops doing a good job, someone else takes over. But nobody can take over from Sun because Java is proprietary; and that's no accident: Sun wants to remain in the driver seat, no matter how poor a job they may be doing.
I know of no way to solve the bikeshed problem. I only said, that -- unfortunately -- it is also not solved by a bazaar like approach
There is no problem--that kind of debate is a normal and healthy part of design--it just needs to happen at the right level. With open source, it is happening at the right level. With the JCP, it is happening at the wrong level.
I think they won't be able to compete with an FPGA-based design: ultimately, those chips are too much work to program and they don't use their transistors all that efficiently when you already know you are mostly going to be doing stuff with numbers.
If, instead, they can come up with a high performance vector or SIMD machine which also has graphics output at a decent price, then they might really have something that people would snap up, not only for doing killer 3D graphics on, but also for doing more general computation.
No, but you do need a license to have a copy of the copyrighted work in your posession. And that license can regulate your use. It can't regulate your use completely (you can make backup copies, you can sell your license), but it can regulate many aspects of your use.
If you don't believe me, try buying a 1 CPU license from Microsoft, running it on an 8 CPU system, and taunting their lawyers with it.
I didn't make that copy therefore anything agreed to in order to poduce that copy is between the rights holder and the person making the copy, NOT me
But you made a purchase contract with someone who copied the item under license. No matter what you do, you have no way of obtaining a copy of the software legally without agreeing to its license.
I don't understand your mental block. Microsoft, Sun, IBM, etc. have been regulating your use of your software for decades using licenses and copyright.
Most Linux-only users use NFS, which does not have these security holes.
Are you kidding? From a security point of view, past versions of NFS have been an absolute disaster, far worse than SMB. You can run NFS only if you have complete trust in your network infrastructure and every single machine on it. Sun's engineers must have been on drugs when designing it.
NFSv4 may fix some of those problems, but it hasn't been widely deployed yet, and it is far more complex than it has a right to be given its limited functionality. All network file systems for Linux currently have major problems of one kind or another (they are one of incompatible, immature, insecure, etc.).
Any 'copying' necessary to actually use the work in a normal fashion should be seen in the same light as the 'imaged copy' on your retina of the book, the analogy is strongest in reference to ram storage of the pieces of code and data in use as they are temporary as is the image on your retina from said book.
The "copy" in question isn't the copying into RAM when you use the software, it's the copying that took place when you obtained your copy of the software. It's at that point that you agree to abide by the use restrictions in the future when you actually use the software.
That can be a bit reaching.
It can be. And the law limits how far such licenses can reach in various ways. But that doesn't change the principle.
Also, use of a program (that is, merely executing the program) is not a power regulated by US copyright law
No, but in order to use the program, you have had to copy it. And in order to copy it, you have had to agree to its license. And licenses can impose all sorts of binding conditions on you. Therefore, a license on a copyrighted piece of software can regulate its use, although the GPL chooses not to.
What about the Guy Who Wants to Make a Few Bucks Writing Useful Software So He Can Pay His Rent? He wants to create and share, but would like to earn a living wage doing it
What does that have to do with the GPL? Lots of people (myself included) have gotten paid (and paid very well) to develop GPL'ed software.
Of all these standards as you cite them, only Gnome has actually originiated from the community or a bazaar-like design approach.
/proc, that I do not really want to loose a word about.
At issue is not where the standard originated, but Schwartz's bogus claims that OSS can't implement and maintain practical, de-facto standards. In reality, all the OSS I mentioned gives me more compatibility between a wider range of platforms than Java ever has. OSS evolves at just the speed and offers just the level of compatibility users need because it gives users a real choice. With Java, Sun makes the decisions, and they are wrong.
There is a number huge of systems out there, were the community approach has utterly failed. There is the Linux DDI, there is the ever-changing glibc and there are things like
Well, then Java obviously isn't cross-platform either: just look at sun.* and com.apple.*! What frightening inconsistency between different platforms and implementations!
But very often, that does not work. When there is no one to step up and make a design decision or when the one is simply ignored or flamed to death by the people involved, things go wrong. And that's a problem, open source does not solve, but rather possibly increase, since everybody regardless of qualification will try to put down his fingerprint.
You're just making the same tired, old argument that it takes a big, centrally managed process to set good standards. The market's experience with IBM's and Microsoft's hegemony disproved that conclusively, and Sun is doing an even worse job. Event if I wanted to attach myself to a corporate standards setter, it would be to Microsoft, not to a loser like Sun.
Parkinson's bikeshed story was true in 1950 and it is still true today; neither the system in which it surfaces nor the people have changed.
You don't understand the bikeshed story if you think the solution to the problem it describes (which is a real problem) is to institute heavy-handed top-down decision making.
The original UNIX file system was an arbitrary directed graph (similar to databases for knowledge representation), not hierarchical. Pick and MUMPS were database-based OSes developed in the 1960's. AS/400 came out in the 1980's and was database-based. Going back at least as far as the 1960's, people also experimented in various ways with more complex file systems: metadata, versioning, notification, etc., and many mainframe OSes also effectively made every file a database. All of these have disappeared, except for niche applications. In practice, after half a century of experimentation and evolution, flat files in a directory hierarchy, together with user-mode database implementations, have turned out to be the best engineering compromise. They suck, but they suck less than all known alternatives.
Sun uses the second with the Java programming language specification. That may cause a major uproar, everytime it is discussed
The "uproar" is about Sun's misrepresentation of Java as an "open" system (viz Schwartz's latest drivel). If Sun stood by their convictions and just told everybody consistently that Java was proprietary and not open, people wouldn't give it a second though. But if Sun hadn't misrepresented Java as "open", people would have just seen a poorly executed proprietary platform and it wouldn't be used very much today.
Since the first way seems not to work well within most parts of the open source community
It works very well: most major open source OS'es implement POSIX and other common standards and systems like Perl, Python, Tcl, and Gnome run on dozens of different platforms. The APIs and functionality of those systems has been exceptionally stable. Sun Java is pitiful in comparison.
For example Apple's JVM has extensions, but they don't get sued b/c they also implement the entire J2SE specification.
Actually, Apple probably doesn't get sued because they licensed their implementation from Sun and because it would be unwise for Sun to sue a licensee.
(Based on my experience with Apple Java, I find it difficult to believe that it really passes all the test cases.)
There is a point to maintaining pruity in your programming language. For example, we have an application at work that some knuckleheads in New York wrote against Microsoft Java about 2 years ago. Now the thing doesn't work with Sun Java, doesn't work with IBM Java and it doesn't even work with the new Microsoft Java. I'm forced to uninstall java on every machine in my location and install a 2 yr old M$ build.
If those people hadn't had Microsoft Java, they would have used some other Microsoft language and you would be even worse off. Something written in MS Java is still a lot easier to port than something in VB or VC++.
Sun's claims that they are "ensuring compatibility" are just a smokescreen; they really just don't want to give up ownership of the platform because they apparently hope that that kind of ownership of an entire software platform gives them some kind of escape hatch once their other businesses fail.
What you see is that Sun owns the specifications. Sun also has a lifetime membership in the JCP, and they effectively decide at their discretion whether your implementation conforms or not. Java/JCP isn't a bazaar, it's the Catholic Church, with Sun being the infallible Pope and making all the final decisions and a bunch of cardinals that provide volunteer labor as part of the JCP (you can figure out for yourself what position they want you to assume).
As for Schwartz's comments about Linux, Linus gets to run the show because he delivers results, not because he has any special status. That's what makes Linux a "bazaar"--it can be forked and it has been forked. On the other hand, Sun gets to run the show with Java only because they have kept Java proprietary; they know full well that as soon as they free Java and make their implementation open source, they'll lose control because they have been doing such a poor job.
Schwartz seems to live by the credo of another well-known propagandist, that if you repeat a lie often enough, people will believe it, no matter how preposterous it may be. He sees his empire crumbling and in poverty, pines for its past glories, and wants to make a last ditch effort to take over the world. Let's not let it come to that. The best defense against Sun's propaganda and campaign of misinformation is to read and think for yourself: read their licenses and think about them and their consequences carefully. What Schwartz says doesn't matter; what matters is their licenses and intellectual property.
But don't you think it's telling that all those PDAs used DBs for data, rather than files?
Yes: it's telling you that they were RAM-based devices with limited memory.
Files and filesystems are primitive hierarchical databases, exclusive subsets (acyclic graphs, trees) with symlink hacks to wriggle in the straitjacket. And their metadata is structured upfront by the filesystem designers, and typically becomes obsolete, therefore retrofitted, very quickly. Instead, we should learn from 30 years of accumulated experience about structure,
You got it backwards. File systems started out much more like databases. They turned into what they are today because it's the best known compromise from the user's point of view. If they are going to change, it's more in the direction of ReiserFS and Plan9. And one important purpose of file systems is to organize general purpose databases, like for PDA apps.
Palm's response to defects in their DB implementation should be to fix it, make it better, rather than give up and crawl back to an even more braindead DB, the filesystem.
Palm's "DB implementation" doesn't "have defects", it is a defect--as is Palm's file system implementation (I'm not talking about FAT, I'm talking about the directory listing you get in Launcher > Delete).
Which consumer-grade OS used only DB storage before PalmOS?
The Newton, original Sharp and Casio organizers, several versions of Psion, and PARCTAB handhelds, to name just a few. (And, in contrast to its predecessors, the poor storage system Palm actually has hardly deserves the name "database".)
And why do handhelds need files, instead of just datasets? Why does *anyone* need files, except perhaps in the presentation layer, where they can be simulated (and always have been simulated)?
Because files represent units of data and metadata that people commonly work with: documents, images, etc.
The problem is that even IF you by from a OSS friendly hardware vendor its still a PITA to get a driver running if it happens to be developed outside the Linux kernel.
I feel your pain and I agree: it would be nice to have a more stable binary interface for the purpose of distributing open source drivers more easily. However, the parent post was complaining that he wanted a more stable driver interface for the purpose of running proprietary drivers, and that's a short-sighted attitude.
I can't speak for Linus at all, but my impression is simply that the risk of more proprietary binary-only drivers together with the extra work involved in maintaining a stable interface outweigh the advantages in the kernel developer's minds. I'm not sure I agree with that myself, but what I do agree with is to tell developers of binary-only drivers to go take a hike.
ohh i see, so the drivers API are changed not to improve them but for the only purpose of make the using of binary drivers impossible !!
No. Driver APIs are changed as needed. The kernel developers just don't bother to accomodate binary-only drivers.
ohh i see, those unspecified "many" have to be right right ?
Ultimately, it's the people who are writing the code. If you don't like it, you can fork the kernel and develop it yourself. But they seem to be doing something right.
Mod me flamebait if you will, there's always a first, but I honestly think that it is exactly this hobbystic, unprofessional, and not-caring way of thinking that hinders the widespread adoption of linux.
Linux runs on far more hardware platforms than Windows or OS X. The current situation vis-a-vis PC hardware is not ideal, but it's the PC hardware vendors that need to change if they want to sell their hardware for Linux.
As for "professionalism", Linus/x has made a choice on licenses and its success is self-evident. His choice is no less professional than Microsoft or Apple's choice on licenses. If you don't like it, buy something else.
Palm needed files. The real question is why they didn't put the Palm application environment on top of a nice Linux kernel and ReiserFS, instead of hacking in FAT.
Your "radical innovation" has been around for several decades; it's only that the industry mainstream is finally catching on.
(Calling MFC a "real UI advance" is a howler.)
Increasing abstraction is necessarily the way of things.
Better languages give you increasing abstraction, which is a good thing. But tools don't really give you increasing abstraction, they just try to hide complexity.
The next wave is the ides that make the repetitive coding unnecessary.
That has also been the previous wave and the wave before that. In all those waves, people tried to get by with tools, but eventually they realized, they had to move to new languages. It's going to be the same this time around.
People will develop software like that right after we get world peace, have completely switched to renewable energy, and everybody exercises for 1h and flosses and brushes three times a day.
I imagine a future where I can download a copy of Linux and it would install on my system without any configuration and every option would be through an option menu, like our Slashdot prefs. If this could be a reality today, I would drop XP in a heartbeat.
Install SuSE, RedHat, or Ubuntu: they are easier to install than Windows XP and come with tons of applications. They even come with excellent printed documentation in case you do need to look something up.
Even easier, buy a PC with Linux pre-installed: you just plug it in and it works.
A driver compiled for 2.6.1 should work, in its binary form, on 2.6.2, 2.6.3, and 2.6.99. If Linus wants to change the API, he should wait until 2.7/2.8 to do so.
... and that's the reason why. If it were easy to use binary drivers, more and more drivers would become binary. For making Linux distributions easier to manage, it would be nice if binary drivers were easier to manage and distribute for Linux. But the fact that that would make distribution of binary-only drivers easier is considered a disadvantage by many.
That's deliberate...
In fact, I recently had to ditch Linux for a project which required four different third-party add-ons, because I couldn't find a Linux distribution common to those supported by all four. We had to buy a Sun machine and use Solaris, because Sun has the common sense to keep a consistent driver API across each major version.
Overall, please either by from open source friendly hardware vendors, or pay the price for a proprietary operating system. You have chosen the second option, so deal with it.