``3. They're stuck in a mindset where file formats are secret and proprietary. Solution: use a nonproprietary file format.''
Honestly, I feel this is the point that the vast majority of people are missing. Most people don't even know there _are_ proprietary and open formats. And yet, this is so vitally important for future proofing...
Ah, I should have clarified. The original quote ("...doomed to repeat it") isn't due to jonadab. But the part that says that those who do study history are forced to watch in agony is his.
``I am criticizing my university and the Mathworks company, for creating an environment where only people who are involved in computing can access Matlab outside of our computer labs. My point is that, because of the terms of Mathworks' site license, the software must be on a specific number of university owned systems, and that while there is nothing stopping Apple or Microsoft users from accessing that software, the majority are not knowledgeable enough to do that.''
Is the university to be faulted for computer users who prefer not learning how to use X11 over getting access to Matlab from outside the compter labs?
Note that, although I'd say it's a fair guess that almost any work you'll download is copyrighted, that doesn't mean you aren't allowed to download it. Think open source software, for example.
``I get the same reaction when I bang on people's door and try to tell them the good news about Jesus Christ. I wonder if it might possibly be related to my behaviour, rather than the relative merits of my beliefs and theirs?''
Thanks for pointing out that I have gone a bit further over the edge than I wanted to. My post was meant to be a friendly suggestion to try Ruby, because I think the person I replied to might like it, based on what he wrote.
``Seriously, the #1 problem with Ruby right now is the way Ruby advocacy has literally turned into a kind of religious evangelism. Ruby fans claim that their new favourite programming language will change your life. Even you talk of "falling in love" -- more extreme cases talk of having their eyes suddenly opened to huge new worlds of possibility.''
Frankly, depending on what languages you already know, I think this might not be over the top at all.
``I understand this because I've been there and done it (evangelised the One True Language, that is; it wasn't Ruby for me, but I felt the same way about it). You get over it with time, and come to recognise that no language is so good that it matters whether other people use it too or not, and start choosing your languages more pragmatically instead of believing that code blocks are so cool that they make Ruby absolutely the ideal language to write this microcontroller in.''
Oh, I'm all for the right tool for the job. And Ruby definitely isn't fit for all jobs. In fact, I do think I mentioned that in my original post.
The sentiment I get from that last paragraph of yours, though, is the suggestion that all the features that I (or someone else) like in Ruby don't matter too much. Some sort of "who cares if you have code blocks, just shut up and get the job done". And that's something I vehemently disagree with. What makes programming languages great is not the amount of things that are built in, the amount of library code shipped with them, or even the amount of library code available for them. What makes programming languages great is the productivity you get when developing _new_ things. I find that, here, it matters a lot how well you can abstract from things. Basically, you adapt the programming language to the problem you're solving. In Ruby, this is very easy. In many languages, it isn't. This makes all the difference in the world. Oh, and of course, Ruby isn't the only language like this. But if I start about Lisp, people fall over me, too.
At first, I was going to ignore your comment as completely idiotic, but looking at some of your other posts I found a few good ones, so I feel you deserve a good answer.
``the way they always trot out the same "with-foo" example. Yeah, it's a minor syntactic improvement over try/finally, but can't you think of something else?''
First of all: obviously I not only can, but _did_ think of something else; it's right in the very same post.
Secondly, I don't agree that with-open-file is just "a minor syntactic improvement over try/finally". It opens the file _and_ makes sure the file is closed no matter what. It does the right thing in case an exception occurs, but, more importantly, you can't forget to write code to close the file...because you don't have to write anything more.
Thirdly, I'd like to turn the "can't you think of something else?" around and turn it into an argument in favor of macros, instead of a baseless ad hominem. The beauty with macros is that they give you a very powerful abstraction mechanism. So that when you _do_ think of something else, you can implement that. Show me how to do the first example from my earlier post without macros. I can give you more examples of cases where macros are or would have been very helpful, but I'm not going to spend the time unless I am convinced you are actually interseted in learning, rather than bashing macro advocates for no reason I can fathom.
You might have a look at Ruby sometime. It has pretty good language design (inspired by Lisp and Smalltalk), many practicalities copied from Perl, it has plenty of libraries available for it (though not nearly as many as Perl), which are easy to manage with Ruby Gems, and it's easy to interface to C code.
I find that Ruby is the language that nobody wants to look at, because it's just like the language they're currently happy with (usually Python, often also Perl). It was the same for me for many years (and, at the time, English documentation was somewhat lacking). But when I did check out Ruby, I quickly fell in love with it. I'm a programming language freak, so chances are that whatever language you use now is one I've used as well. It would go too far to say that Ruby beats them all...but on many tasks, it does.
Will the Tk widgets now integrate with the rest of the desktop, in terms of using the same theme settings that other programs use?
I like how Tk has been used as a GUI toolkit by many programming lanugages, and I think that says something good about its design and implementation, but the ugly, unthemeable, and out-of-place looking widgets have always been a thorn in my eye.
Especially because it _did_ work sort of right on proprietary OSes as far as I know.
``POSIX file capabilities, which have recently become available in the Linux kernel; they are expected in the mainline kernel by 2.6.24.''
Recently become available? Haven't POSIX capabilities been in Linux for some time? I seem to recall reading about them in the documentation for some 2.4 kernel, and there is a Gentoo page about them from some time in 2005. Am I missing something?
My feelings about Flash are kind of mixed. On one hand, it's proprietary technology. Specifications have, at some point, been published, but I don't think they are current, and there certainly isn't a full-featured implementation from anyone other than Adobe. This is bad.
On the other hand, looking at what Flash does, and at other technologies that do these things, it seems to me that Flash is clearly technologically superior. I don't know how large the browser plugin is these days, but the one that used to come with Opera used to be very small, and yet provide features that web masters are trying to kludge together with AJAX and whatnot, and for which the W3C has come up with the gargantuan SVG, which has even more elephantine implementations. Flash is the clear winner here.
And then, of course, there is the misuse of Flash for things where Plain Old HTML would be much better. But then again, if Flash were a widely-implemented open standard (rather than a widely-implemented proprietary technology which yet leaves some users in the cold), perhaps such use wouldn't be _mis_use.
So, all in all, I think that Flash would be _great_ if it weren't proprietary...but the fact that it _is_ proprietary is a real obstacle.
``The LISP guy has a point, though that syntax is even uglier.''
That's an old argument, but for the sake of people who haven't heard it before, I will enter the debate again.
Lisp syntax is actually very beautiful for describing tree structures. And tree structures are very useful. For example, web pages have tree structures. And many types of relational data. And with the addition of references, trees can be used to describe graphs, and thus, all data and all relations. Oh! And lest I forget, computer programs!
Now, why would you want to describe your program like a tree? Why would you want _everything_ to start with an open paren, then have a bunch of child nodes (which could be simple words or numbers, or could also start with an open paren, etc.), and finish with a closing paren? What is the advantage of this over having a bunch of curly braces, commas, semicolons, and infix operators thrown in for variety?
Well, the advantage of Lisp syntax is that it is extremely regular. And this is good for analysis and transformations. And _that_ is what Lisp is all about.
In most languages, you write your program in some complex surface syntax, which is then run through a complicated parser. The parser converts it into a tree (hey...wasn't there something about trees before?), and the compiler then performs all kinds of transformations on that tree. Transformations that are relatively easy to describe on trees, but not so much on the surface syntax of the programming language - that's why you generate the parse tree. Of course, this all happens behind the scenes. But not so in Lisp. In Lisp, your program already _is_ a tree the way you wrote it down. A convenient format for performing (and understanding!) transformations to be performed on the source code. And this is something Lisp programmers do all the time, and something that is rarely seen outside Lisp.
I believe this is largely due to the difficulty of describing and understanding program transformations in other languages. Lisp has a very simple macro system; a macro takes a tree you wrote, and runs some Lisp code, and eventually returns a new tree. And then it is as if you had written that new tree instead of the old one. So, where in Java you will see code like...
x.setFoo(y.getFoo()); x.setBar(y.getBar()); x.setBaz(y.getBaz());...in Lisp you will see something like...
(copy-fields x y foo bar baz)...which will be transformed into the code that actually does the copying. And where in Java you will see...
FileInputStream stream = new FileInputStream("filename"); try {// Do something with stream } finally {// Make sure stream is closed, even if an exception was thrown
stream.close(); }...in Lisp you will see...
(with-open-file (stream "filename")
; Do something with stream
)...which is a macro that expands into the appropriate code.
As it happens, the macro in the second example happens to be part of Common Lisp's standard library and the one in the first example doesn't. Of course, it can easily be written. What the macros have in common, however, is that they allow you to do the same things that the Java snippets do, but with less code, less repetition, and fewer weird characters. I don't know how you can not find that beautiful.
``Ironically, the lack of pointers, something that computer scientists think is terrible, is actually one of its strengths.''
Err...well, maybe. I don't know the opinion of _all_ computer scientists, but I am one, and I think pointers are terrible. I mean, on a low level, you need them, but you really shouldn't be writing application code on such a low level. In a well-designed language, the only power pointers would add that you don't get without them is the power to access memory in ways you shouldn't be accessing it. Besides crashing your program and introducing security holes, this also makes optimization more difficult.
The thing with C is that the language, that is, the type system and the abstractions it offers, is so weak that you _need_ pointers to get all but the most trivial algorithms to work at all. But C is actually one of the few languages still in common use that exposes pointers, and is actually rarely used in computer science these days. For implementation work, yes, but rarely for actually communicating concepts, as far as I know.
All in all, I think you will find that the idea that "computer scientists find the lack of pointers terrible" is just plain wrong.
``Python is not universal, 95% of the world's computers (that is to say, the ones running the most popular desktop OS) still do not ship with a Python interpreter, and many engineers are using Windows systems with Matlab and neither Python nor PERL environments.''
That's a weird line of reasoning. Python is "not universal" because "95% of the worlds [desktop] computers... do not ship with a Python interpreter. And this is somehow an argument for using Matlab syntax...even though _100%_ of desktop computers don't ship with a Matlab interpreter!
I do agree with your assessment that Matlab compatibility has its merits; I just wanted to point out that your reasoning is... funny.
``But this project kind of supports the idea that open source can't really innovate, only follow (sometimes far) behind what proprietary companies invent.''
I don't know how _one_ open source project copying a proprietary project is supposed to support the idea that open source as a whole can't really innovate. Reasoning that way is completely bogus.
``It would have been really interesting to see what some of the open source folks could do if their goal was to surpass MATLAB instead of be an almost-free version that's almost as good as something that people almost like to use.''
I agree with you, and a lot of open source development does exactly that. Or implements things that there is no proprietary software for. But Octave, like a lot of other GNU software, has a different goal, apparently: allowing users to take their MATLAB code and run it using only Free software. That's a worthwhile goal, too. Although it's not something I'm personally interested in - and, apparently, not something many people are interested in at all, or progress would be quicker (either in Octave or in a sister project fueled by developers who resent Octave's slow progress).
I echo that sentiment. I remember being amazed at how smoothly X ran on a 486 with _16_ instead of 8 megs of RAM. It made me think that the 66 MHz DX2 was ridiculous, seeing as the 25 MHz SX ran faster thanks to having more memory.
When I went to college, I got a brand new PC with a whopping _64_ megabytes of RAM. I could compile and run the just released KDE 2! And oh, it was fast!
Now I hear my colleagues complain that they have only 1 gig of RAM...
What are we doing to our computers that memory (and CPU speed...) increases by a factor 100...and it's still too little, too slow?!
The aforementioned 486 ran a web browser (was it called Baron?) that was written in Python. Not a speed demon by any stretch of the imagination, but it worked fine. Try running Firefox on that machine... Granted, games worked like crap under Linux on that machine...for that, there was DOS. Ah well. Same old, same old. Only now most computers have fans...
``Stop with the kludges and force the developers along.''
The transition is relatively easy to make if almost all software is open source, and/or you mostly have backward compatibility. Microsoft are in a situation where they have neither...a lot of things (especially drivers) will simply break. And well...a smooth upgrade path has been one of the reasons for people to stick with Microsoft, despite the abuse...
Slashdot Mirror
``3. They're stuck in a mindset where file formats are secret and proprietary. Solution: use a nonproprietary file format.''
Honestly, I feel this is the point that the vast majority of people are missing. Most people don't even know there _are_ proprietary and open formats. And yet, this is so vitally important for future proofing...
``If they want to permanently archive digital media, why not just keep the DVD glass masters around?''
What, to have a collection of seemingly meaningless bits, and garbled by DRM, too? That's not very future proof...
``Funny how I've found drives made almost a decade ago working just fine now... ''
As if a decade is a long time.
Especially compared to how long copyright lasts nowadays.
Ah, I should have clarified. The original quote ("...doomed to repeat it") isn't due to jonadab. But the part that says that those who do study history are forced to watch in agony is his.
``I am criticizing my university and the Mathworks company, for creating an environment where only people who are involved in computing can access Matlab outside of our computer labs. My point is that, because of the terms of Mathworks' site license, the software must be on a specific number of university owned systems, and that while there is nothing stopping Apple or Microsoft users from accessing that software, the majority are not knowledgeable enough to do that.''
Is the university to be faulted for computer users who prefer not learning how to use X11 over getting access to Matlab from outside the compter labs?
As jonadab once put it:
:-)
> Those who do not study history are doomed to repeat it
Yes, and those who do study history are doomed to watch in frustration
as it is unwittingly repeated by those who do not
Note that, although I'd say it's a fair guess that almost any work you'll download is copyrighted, that doesn't mean you aren't allowed to download it. Think open source software, for example.
Proofreading? On Slashdot? You must be new here!
``I get the same reaction when I bang on people's door and try to tell them the good news about Jesus Christ. I wonder if it might possibly be related to my behaviour, rather than the relative merits of my beliefs and theirs?''
Thanks for pointing out that I have gone a bit further over the edge than I wanted to. My post was meant to be a friendly suggestion to try Ruby, because I think the person I replied to might like it, based on what he wrote.
``Seriously, the #1 problem with Ruby right now is the way Ruby advocacy has literally turned into a kind of religious evangelism. Ruby fans claim that their new favourite programming language will change your life. Even you talk of "falling in love" -- more extreme cases talk of having their eyes suddenly opened to huge new worlds of possibility.''
Frankly, depending on what languages you already know, I think this might not be over the top at all.
``I understand this because I've been there and done it (evangelised the One True Language, that is; it wasn't Ruby for me, but I felt the same way about it). You get over it with time, and come to recognise that no language is so good that it matters whether other people use it too or not, and start choosing your languages more pragmatically instead of believing that code blocks are so cool that they make Ruby absolutely the ideal language to write this microcontroller in.''
Oh, I'm all for the right tool for the job. And Ruby definitely isn't fit for all jobs. In fact, I do think I mentioned that in my original post.
The sentiment I get from that last paragraph of yours, though, is the suggestion that all the features that I (or someone else) like in Ruby don't matter too much. Some sort of "who cares if you have code blocks, just shut up and get the job done". And that's something I vehemently disagree with. What makes programming languages great is not the amount of things that are built in, the amount of library code shipped with them, or even the amount of library code available for them. What makes programming languages great is the productivity you get when developing _new_ things. I find that, here, it matters a lot how well you can abstract from things. Basically, you adapt the programming language to the problem you're solving. In Ruby, this is very easy. In many languages, it isn't. This makes all the difference in the world. Oh, and of course, Ruby isn't the only language like this. But if I start about Lisp, people fall over me, too.
At first, I was going to ignore your comment as completely idiotic, but looking at some of your other posts I found a few good ones, so I feel you deserve a good answer.
``the way they always trot out the same "with-foo" example. Yeah, it's a minor syntactic improvement over try/finally, but can't you think of something else?''
First of all: obviously I not only can, but _did_ think of something else; it's right in the very same post.
Secondly, I don't agree that with-open-file is just "a minor syntactic improvement over try/finally". It opens the file _and_ makes sure the file is closed no matter what. It does the right thing in case an exception occurs, but, more importantly, you can't forget to write code to close the file...because you don't have to write anything more.
Thirdly, I'd like to turn the "can't you think of something else?" around and turn it into an argument in favor of macros, instead of a baseless ad hominem. The beauty with macros is that they give you a very powerful abstraction mechanism. So that when you _do_ think of something else, you can implement that. Show me how to do the first example from my earlier post without macros. I can give you more examples of cases where macros are or would have been very helpful, but I'm not going to spend the time unless I am convinced you are actually interseted in learning, rather than bashing macro advocates for no reason I can fathom.
You might have a look at Ruby sometime. It has pretty good language design (inspired by Lisp and Smalltalk), many practicalities copied from Perl, it has plenty of libraries available for it (though not nearly as many as Perl), which are easy to manage with Ruby Gems, and it's easy to interface to C code.
I find that Ruby is the language that nobody wants to look at, because it's just like the language they're currently happy with (usually Python, often also Perl). It was the same for me for many years (and, at the time, English documentation was somewhat lacking). But when I did check out Ruby, I quickly fell in love with it. I'm a programming language freak, so chances are that whatever language you use now is one I've used as well. It would go too far to say that Ruby beats them all...but on many tasks, it does.
I am only interested in one thing:
Will the Tk widgets now integrate with the rest of the desktop, in terms of using the same theme settings that other programs use?
I like how Tk has been used as a GUI toolkit by many programming lanugages, and I think that says something good about its design and implementation, but the ugly, unthemeable, and out-of-place looking widgets have always been a thorn in my eye.
Especially because it _did_ work sort of right on proprietary OSes as far as I know.
Ah, I see now that I _was_ missing something.
What is new is not that Linux has POSIX capabilities.
What is new is that you can store a description of the capabilities an executable is to receive _on the executable_.
I just looked at the capability.h on my system, and it has
#define _LINUX_CAPABILITY_VERSION 0x19980330
This suggests to me that Linux has had capabilities since 1998 at least...
Quoth the summary:
``POSIX file capabilities, which have recently become available in the Linux kernel; they are expected in the mainline kernel by 2.6.24.''
Recently become available? Haven't POSIX capabilities been in Linux for some time? I seem to recall reading about them in the documentation for some 2.4 kernel, and there is a Gentoo page about them from some time in 2005. Am I missing something?
How do POSIX capabilities compare to systrace?
My feelings about Flash are kind of mixed. On one hand, it's proprietary technology. Specifications have, at some point, been published, but I don't think they are current, and there certainly isn't a full-featured implementation from anyone other than Adobe. This is bad.
On the other hand, looking at what Flash does, and at other technologies that do these things, it seems to me that Flash is clearly technologically superior. I don't know how large the browser plugin is these days, but the one that used to come with Opera used to be very small, and yet provide features that web masters are trying to kludge together with AJAX and whatnot, and for which the W3C has come up with the gargantuan SVG, which has even more elephantine implementations. Flash is the clear winner here.
And then, of course, there is the misuse of Flash for things where Plain Old HTML would be much better. But then again, if Flash were a widely-implemented open standard (rather than a widely-implemented proprietary technology which yet leaves some users in the cold), perhaps such use wouldn't be _mis_use.
So, all in all, I think that Flash would be _great_ if it weren't proprietary...but the fact that it _is_ proprietary is a real obstacle.
``The LISP guy has a point, though that syntax is even uglier.''
...in Lisp you will see something like...
...which will be transformed into the code that actually does the copying. And where in Java you will see...
// Do something with stream // Make sure stream is closed, even if an exception was thrown ...in Lisp you will see...
...which is a macro that expands into the appropriate code.
That's an old argument, but for the sake of people who haven't heard it before, I will enter the debate again.
Lisp syntax is actually very beautiful for describing tree structures. And tree structures are very useful. For example, web pages have tree structures. And many types of relational data. And with the addition of references, trees can be used to describe graphs, and thus, all data and all relations. Oh! And lest I forget, computer programs!
Now, why would you want to describe your program like a tree? Why would you want _everything_ to start with an open paren, then have a bunch of child nodes (which could be simple words or numbers, or could also start with an open paren, etc.), and finish with a closing paren? What is the advantage of this over having a bunch of curly braces, commas, semicolons, and infix operators thrown in for variety?
Well, the advantage of Lisp syntax is that it is extremely regular. And this is good for analysis and transformations. And _that_ is what Lisp is all about.
In most languages, you write your program in some complex surface syntax, which is then run through a complicated parser. The parser converts it into a tree (hey...wasn't there something about trees before?), and the compiler then performs all kinds of transformations on that tree. Transformations that are relatively easy to describe on trees, but not so much on the surface syntax of the programming language - that's why you generate the parse tree. Of course, this all happens behind the scenes. But not so in Lisp. In Lisp, your program already _is_ a tree the way you wrote it down. A convenient format for performing (and understanding!) transformations to be performed on the source code. And this is something Lisp programmers do all the time, and something that is rarely seen outside Lisp.
I believe this is largely due to the difficulty of describing and understanding program transformations in other languages. Lisp has a very simple macro system; a macro takes a tree you wrote, and runs some Lisp code, and eventually returns a new tree. And then it is as if you had written that new tree instead of the old one. So, where in Java you will see code like...
x.setFoo(y.getFoo());
x.setBar(y.getBar());
x.setBaz(y.getBaz());
(copy-fields x y foo bar baz)
FileInputStream stream = new FileInputStream("filename");
try {
} finally {
stream.close();
}
(with-open-file (stream "filename")
; Do something with stream
)
As it happens, the macro in the second example happens to be part of Common Lisp's standard library and the one in the first example doesn't. Of course, it can easily be written. What the macros have in common, however, is that they allow you to do the same things that the Java snippets do, but with less code, less repetition, and fewer weird characters. I don't know how you can not find that beautiful.
``Ironically, the lack of pointers, something that computer scientists think is terrible, is actually one of its strengths.''
Err...well, maybe. I don't know the opinion of _all_ computer scientists, but I am one, and I think pointers are terrible. I mean, on a low level, you need them, but you really shouldn't be writing application code on such a low level. In a well-designed language, the only power pointers would add that you don't get without them is the power to access memory in ways you shouldn't be accessing it. Besides crashing your program and introducing security holes, this also makes optimization more difficult.
The thing with C is that the language, that is, the type system and the abstractions it offers, is so weak that you _need_ pointers to get all but the most trivial algorithms to work at all. But C is actually one of the few languages still in common use that exposes pointers, and is actually rarely used in computer science these days. For implementation work, yes, but rarely for actually communicating concepts, as far as I know.
All in all, I think you will find that the idea that "computer scientists find the lack of pointers terrible" is just plain wrong.
``Python is not universal, 95% of the world's computers (that is to say, the ones running the most popular desktop OS) still do not ship with a Python interpreter, and many engineers are using Windows systems with Matlab and neither Python nor PERL environments.''
... do not ship with a Python interpreter. And this is somehow an argument for using Matlab syntax...even though _100%_ of desktop computers don't ship with a Matlab interpreter!
... funny.
That's a weird line of reasoning. Python is "not universal" because "95% of the worlds [desktop] computers
I do agree with your assessment that Matlab compatibility has its merits; I just wanted to point out that your reasoning is
``But this project kind of supports the idea that open source can't really innovate, only follow (sometimes far) behind what proprietary companies invent.''
I don't know how _one_ open source project copying a proprietary project is supposed to support the idea that open source as a whole can't really innovate. Reasoning that way is completely bogus.
``It would have been really interesting to see what some of the open source folks could do if their goal was to surpass MATLAB instead of be an almost-free version that's almost as good as something that people almost like to use.''
I agree with you, and a lot of open source development does exactly that. Or implements things that there is no proprietary software for. But Octave, like a lot of other GNU software, has a different goal, apparently: allowing users to take their MATLAB code and run it using only Free software. That's a worthwhile goal, too. Although it's not something I'm personally interested in - and, apparently, not something many people are interested in at all, or progress would be quicker (either in Octave or in a sister project fueled by developers who resent Octave's slow progress).
``I'm not sure who's worse, the employers or the gov't.''
The gov't, of course. The employers at least pay you money. The gov't _takes_ your money, and then uses it against you!
I echo that sentiment. I remember being amazed at how smoothly X ran on a 486 with _16_ instead of 8 megs of RAM. It made me think that the 66 MHz DX2 was ridiculous, seeing as the 25 MHz SX ran faster thanks to having more memory.
When I went to college, I got a brand new PC with a whopping _64_ megabytes of RAM. I could compile and run the just released KDE 2! And oh, it was fast!
Now I hear my colleagues complain that they have only 1 gig of RAM...
What are we doing to our computers that memory (and CPU speed...) increases by a factor 100...and it's still too little, too slow?!
The aforementioned 486 ran a web browser (was it called Baron?) that was written in Python. Not a speed demon by any stretch of the imagination, but it worked fine. Try running Firefox on that machine... Granted, games worked like crap under Linux on that machine...for that, there was DOS. Ah well. Same old, same old. Only now most computers have fans...
That said, I have a hard time seeing what could use more than 2GB of RAM on a laptop..
Java apps. Microsoft apps. Games. Bloatware in general.
``Stop with the kludges and force the developers along.''
The transition is relatively easy to make if almost all software is open source, and/or you mostly have backward compatibility. Microsoft are in a situation where they have neither...a lot of things (especially drivers) will simply break. And well...a smooth upgrade path has been one of the reasons for people to stick with Microsoft, despite the abuse...