More to the point -- is "uptime" the opposite of "downtime" or is it "uptime" as in the output of the "uptime" command? With the latter, the 20% difference is at least plausible;
Ah, now we get to the heart of the matter. Obviously Microsoft has managed to pull ahead by padding the output of the uptime command: 20% more characters means 20% more uptime!
Certainly Eiffel was the language that first integrated it in as a serious part of the language. These days though you can get more powerful systems for other languages. Eiffel of pre- and post-conditions, but uses them as runtime checks. Extensions to Java and Ada like JML and SPARK allow for much more expressive statements that pre- and post-conditions alone - for instance JML lets you specify which data fields a given method may access, or write to, or under what conditions an exception may be thrown - and there exist strong static checkers such as ESC/Java2 and the SPARK toolset which let you check for possible errors statically (thus checking all possible cases rather than individual test cases). With JML you can write as much or as little as you wish in the way of annotations describing intent.
By the same token, code checkers can't know what your intentions are for every variable and class relationship. They can tell you if you generate invalid or null variables, or if a function is orphaned, stuff that is strictly boolean. Beyond mistakes like that, you'll have to tell the checker in explicit manners what to look for, negating the benefit of the tool.
If you state your intentions in a language that the code checker understands (preferrably a language designed to be expressive when it comes to making assertions) then the checker can actually determine a great deal about your code. For instance, look at ESC/Java2. By providing annotations to your Java code it allows the checker to find far more errors than the small amount you suggest. Developing using ESC/Java2 instead of a compiler to "check" your code can be very productive (it checks Java syntax and does type checking as well, so if it passes ESC/Java2 it will definitely compile) - Things get flagged as potential errors early on, often forcing you to add extra annotations to clarify your intentions (which is a good thing! it often helps you actually flesh out your ideas of exactly what you intend), and by the time you're done the odds of code working as you intend is far far higher than you would ever expect otherwise.
The fact that the annotation language that ESC/Java2 uses can also be automatically included into your JavaDoc documentation (making method requirements explicit, and making clear what a method guarantees), and can also be used to automatically build a JUnit testing framework for the code - well that's just icing. Take a look - download the Eclipse plugins here and here and try it out. I think you'll be remarkably suprised how powerful the error checking is, and how productive the development cycle can be when using it.
Leibniz really was the first to set off down the road to formal symbolic logic and reasoning as computation. Understanding some of his philosophy from the standpoint of the historical development of formal logic and computation is certainly within the purview of a CS based philosphy course. You could also throw in George Boole and Augustus DeMorgan who took the next important steps to developing, in Boole's words "the laws of thought".
Frege is certainly important in philosophy of mathematics with the first serious attempts to completely rigorously ground mathematics as logic. I'm less clear on exactly how well his work fits in to a CS philosophy course, though certainly he is of importance in the general development of formal logic.
Russell is the founder of type theory, which I'm sure anyone who has done much programming at all has made significant use of. At the time Russell developed it type theory was somewhat of a position he'd been forced into to escape various logical paradoxes in the foundations of mathematics. With the advent of computers however type theory saw a resurgence: types, and type signatures for functions, and a theory of types in general, suddenly seemd quite natural. Indeed type theory has become an important field in CS and programming language research. On that front it would probably be worth including Per Martin Löf and intuitionistic type theory, which is a more modern type theory better suited to the CS perspective than Russell's original work.
Tarski, notoriety of the Banach-Tarski paradox aside, is best known for a lot of remarkable work in logic, including his theorem regarding the indefinability of truth within formal systems, closely related to Gödel's incompleteness theorems. He also developed the bulk of model theory which is now very important in CS fields such as algebraic specification. Certainly including Tarski in a CS course would not go astray.
Did you know that the twin towers were built to withstand a direct impact from a 707?
And they survived impacts from larger planes, then were eventually brought down largely by the fire. But really this just highlights the difference between most engineering and software engineering, and that's assurance. The buildings were designed to be able to withstand impacts from planes, and you can bet that the engineers sat down and did all the lengthy calculations of structure and matrial tolerance to be able to confidently make that assurance.
Yes, nothing is perfect. On the other hand, being able to confidently state under what conditions something will work is a significant advantage over the simple broad statement that nothing is perfect and it probably has bugs somewhere. I would much rather someone tell me that a skyscraper will remain standing under various conditions than be told "well there might be some bugs somewhere, so who knows... if the wind blows from the wrong direction it might fall down. We haven't really checked". It is possible to give the same sort of assurances for software by using similar engineering techniques.
It is NOT inevitable that software will have bugs in it. By your reasoning, it is inevitable that bridges have design defects in them, and that at some point (in their usable specified lifetime), will collapse.
It is somewhat inevitable that software will not be perfect, just as a bridge is unlikely to be perfect. The difference currently, however, is that engineers who build bridges bother to do some analysis and provide assurances with regard to the quality of their work. That is, while the bridge may not be perfect, and likely has flaws, the engineer can say with confidence under what stresses it will stand, under what weather conditions it will survive, etc.
What we lack in the software world is assurances, not a lack of bugs. For some reason because developers can't say "this will work perfectly" they refuse to make any effort at all. The bridge building equivalent would be saying "well inevitably the welders are going to get a seam slightly off, so fuck it, we'll just slap something together any old how". You don't have to be able to say "this software will never crash", but being able to say "under these conditions, this software will never crash" is quite manageable. Of course the trick is managing to write your software well enough that the conditions you can guarantee lack of crashing for a reasonably broad. Of course if you have such a goal in mind, and intend to be able to give such guarantees, then it gets a little easier.
The real key is assurance - being able to state the bounds on when your software is guaranteed to work.
There is no point in donating to this program without donating to a program for putting a full curriculum worth of textbook material into the public domain first.
Luckily that sort of project is already underway. Sure, it is rather incomplete and patchy in its coverage, and the quality can be a little up and down, but there are actually a large number of pretty good quality texts on there for a wide variety of subjects. Wikijunior books, for instance, have material good enough for the kids the laptop project is aimed at.
I see you're not talking about GnuOctave then. Pity, because I was. As was the post I was replying to.
Given that Octave is Matlab workalike that uses Gnuplot for plotting I think we're close enough to talking about the same thing. Besides this whole discussion started with regard to the right tool for the job, the claim originally being that if you need to deal with hundreds of thousands signals analysis data points then Excel is great. It isn't. Matlab is great. The person then complained that Matlab was too expensive. Someone pointed him to Octave. And now you come up with:
And no, not all I need to do is plot. I need a variety of statistical tools as well.
For which, indeed, Octave probably isn't the ideal tool. The better tool for that job is obviously R which can suck in files in just as many formats (or more) than Excel, has far better (and more numerically accurate I might add), and far far more statistics functions, is actually designed from the outset to do high powered statistics on such massive datasets and, what do you know, let's you plot in a dozen different ways with a single command.
If you have a large amount of numerical data (hundreds of thousands of rows worth) then I assure you that Matlab, R, Mathematica, or even Gnuplot will be a the fastest way to "get something up easily and quickly". Just because you've never used them (apparently) and thus don't know how very easy they are to use for anyone who does any sort of numerical work, doesn't make them harder. The fact that they are incredibly powerful and permit far more complex number crunching and data manipulation due to a programmable interface doesn't make them any harder to use either - if all you want to do is plot then gnuplot can do it for you in a single command, no need to load speadsheet programs, import CSV files, and click through various graph making tools.
It is easy to do analysis and plotting of scientific data from databases. All you have to do is actually use the right tool for the job. Do you have gobs of numerical data that you want to crunch, analyse and plot? Then you probably want Matlab or R. Is that data in a database? Then you'll probably be using Matlab's database toolbox or R's database connectivity to import and export data (based on whatever database query you care to use - you can import whole tables easily if you like). Once the data is imported (which is trivial) you have no shortage of tools to process, munge, analyse, and plot to your heart's content.
So those guys in R&D doing basic signal analysis should be demoted because they're using excel to plot some quick-and-dirty graphs using the 1M data points they've collected?
Given that any R&D department that does signals analysis worth its salt will have a copy of Matlab on hand for all their numerical and plotting needs... Yes? There are various tools that are suitable for various jobs. If you are doing number crunching or plotting with datasets of that size then Excel is not the right tool for the job. Try Matlab, Mathematica, R, or similar.
I think most of these examples can be summarised as "Speech that has a strong likelihood to cause significant harm to third parties". Yelling fire in a theatre is a problem because it is reckless and needless endangerment of the fleeing patrons. Slander and Libel are obvious enough. Publising the names and addresses of witnesses, particularly in cases involving organised crime, is clearly endangering the witnesses. Even things like "hate speech" legislation in Europe stems from a similar principle - that a lot of such speech is a quite direct incitement to violence against a minority group. I think there's a pretty clear principle at work here, the question is what the line is with regard to "significant harm" and "likelihood to cause".
Many people put art and culture down to memetic evolution rather than genetics. Presuming you subscribe to memes (and really, the idea isn't that hard to believe, even if the exact details are still hard to properly pin down) then it isn't hard to see how things like art and culture can develop one you have an ability to spread and repliate memes (combined with some basic coupling to genetic selection - again, not hard to achieve). There are plenty of books that would cover this. The Meme Machine by Susan Blackmore comes to mind off the top of my head.
Could Sun be using this to eventually get to the desktop, or at the very least, allowing companies to run a complete linux system. Solaris server, Ubuntu clients for the employees?
In some ways RedHat/Fedora might be a better fit for this with Stateless Linux which would fit nicely into that sort of model.
This might make a big splash here, but in the real world, nobody will truly care.
The point being that you could say exactly the same thing about Apple proudly declaring that they were going open source and providing source code for Darwin. A few people care, most don't, and apparently it doesn't really matter at all.
Apple claiming to support open source: This might make a big splash here, but in the real world, nobody will truly care.
Sun would not be happy with a java.org fork that everyone and their dog adopted and left Sun to be just another contributor instead of running the show.
I never claimed they would be happy with that. All I'm claiming is that if they don't want that to happen all they have to do is not mismanage Java, and not provide any reasons for such a fork to get any traction.
Suggesting that Microsoft wouldn't bundle a look-a-like product in their monopoly OS and then do exactly what the parent post suggests (start making small changes) makes you sound naïve. For God sakes man, they did already try it once!
Yes, they tried, they failed, they moved on. At this point there's little reason in trying to poison the Java JVM well because their investment is in.NET. Throwing on a JVM, even a poisoned on, only dilutes their push now. Besides, Sun can still bar Microsoft from calling it Java, or claiming it to be Java compatible, at which stage what's the point for Microsoft to even bother? Back when Java mattered Microsoft was more than willing to fuck things up, but they're now making quite respectable headway with.NET and simply don't care anymore.
You throw out a couple of scare scenarios here with either Microsoft or IBM making a mess of Java, but as far as I can tell they are just that, wild scare scenarios that simply aren't viable if Sun is at all on the ball. For starters Sun can keep the Java trademark and simply bar Microsoft and IBM from advertising whatever they care to sell as "Java". From there it is a question of exactly how either Microsoft or IBM is going to get their new language and VM (whatever they decide to call it - maybe microsoft will call it C# and.NET; no, wait, they already did that) to be dominant, or at least bootstrap it into being a competing standard. Microsoft can do that, as you point out, by leveraging their monopoly. The thing is they've already done that: C# and.NET. They can do that quite successfully whether Sun opens sources Java or not. So for Microsoft the argument is rather moot. What about IBM? They don't have a monopoly to leverage so they'd have to resort to the nasty tactic of making a better language and VM with better libraries to manage to get it to take off. But wait, they can only do that if Sun drop the ball in exactly the manner I described and let Java stagnate and become unresponsive to change. So we're back where we started. Sun open sourcing Java really isn't going to make a lot of difference unless Sun drops the ball themselves - which is exactly what I originally said.
Which interestingly enough took place between proprietary systems, not open ones. In that sense the UNIX wars are more akin to the battle between Java and C# and.NET (which could, indeed, be seen as damaging to the VM market). That is to say, regardless of what Sun does with Java they are already facing the same sorts of problems.
But they DO care about IBM or Microsoft creating a VM that advertises compatbility, but actually pulls the bait-and-switch routine. Remember, Microsoft already tried to pull that routine with the NON-OSS version of Java.
Sure, but they will still own and control the Java trademark and they can simply bar such bait-and-switch advertising. Microsoft can fork Java all they want, they just can't call it Java, nor Java comnpatible. Besides MS is unlikely to do any such thing now since their efforts are heavily sunk into C# and.NET.
Unfortunately, one of OSI's core requirements is forking. So Java will never be able to make the pundits happy.
Sure they can - there are other ways to pevent forking than in the license. Look at most of the major OSS projects around and you'll see that there is very little in the way of forking - sure minor forks exist but they quickly die. Sun doesn't care about some minor fork of Java that 20 people use that eventually dies, they are worried about a significant competing standard that honestly splits developers between two different platforms. How often has that happened with big OSS projects? Hardly ever. The question is not so much "what can be done to prevent forking" but "what happens that causes a successful fork". The major examples of significant splits in the OSS world would be Emacs/XEmacs, gcc/ecgs, and XFree86/Xorg. In each of those cases the reason for both the fork, and the success of the fork, comes down to the original project stagnating and being unresponsive to change. Avoid that and you tend to avoid significant forks.
Sounds fine to me. A while ago I bought a Dell laptop. It had the obvious downside of being a Dell, but one strong point was the display: 15" widescreen that can do 1920x1200. The result is a display that's incredibly crisp and clear, and I certainly don't regret the purchase from that point - the display has very much been worth it.
What I don't understand is why it works. Why do children fixate on McDonalds so much? What is the secret sause here? And it's not just McDonalds. Apparently, brand loyalty can be instilled before the third year.
For starters you've got the fact that a lot of the brands that go after kids have (you'll note) simple clear logo designs that tend to be in very crisp vibrant colours. If you're looking for something to imprint on a small mind then simple clear lines and bright colours are the way to go.
In practice the real key is repetition. Small children (and even adults really) are remarkable mimicry machines. Find something short and attention grabbing and repeat ad nauseum and kids will pick it up. I imagine if you stuck a parrot in front of a TV 6 hours a day it would learn to say McDonalds pretty well too.
My wife uses Linux and she has never opened a console. I occasionally open it, but that's because I like to do "advanced" stuff. If I really wanted to, I could live without ever opening the console.
And alternatively, with Linux, you could live without ever opening a GUI. Hell I have a friend who, out of curiousity, decided to spend a week using nothing but Emacs just to see if it was possible. In the end he found it really was quite manageable - the only thing he really missed was a good webbrowser (W3 isn't that great).
Slashdot Mirror
Ah, now we get to the heart of the matter. Obviously Microsoft has managed to pull ahead by padding the output of the uptime command: 20% more characters means 20% more uptime!
Certainly Eiffel was the language that first integrated it in as a serious part of the language. These days though you can get more powerful systems for other languages. Eiffel of pre- and post-conditions, but uses them as runtime checks. Extensions to Java and Ada like JML and SPARK allow for much more expressive statements that pre- and post-conditions alone - for instance JML lets you specify which data fields a given method may access, or write to, or under what conditions an exception may be thrown - and there exist strong static checkers such as ESC/Java2 and the SPARK toolset which let you check for possible errors statically (thus checking all possible cases rather than individual test cases). With JML you can write as much or as little as you wish in the way of annotations describing intent.
Jedidiah.
By the same token, code checkers can't know what your intentions are for every variable and class relationship. They can tell you if you generate invalid or null variables, or if a function is orphaned, stuff that is strictly boolean. Beyond mistakes like that, you'll have to tell the checker in explicit manners what to look for, negating the benefit of the tool.
If you state your intentions in a language that the code checker understands (preferrably a language designed to be expressive when it comes to making assertions) then the checker can actually determine a great deal about your code. For instance, look at ESC/Java2. By providing annotations to your Java code it allows the checker to find far more errors than the small amount you suggest. Developing using ESC/Java2 instead of a compiler to "check" your code can be very productive (it checks Java syntax and does type checking as well, so if it passes ESC/Java2 it will definitely compile) - Things get flagged as potential errors early on, often forcing you to add extra annotations to clarify your intentions (which is a good thing! it often helps you actually flesh out your ideas of exactly what you intend), and by the time you're done the odds of code working as you intend is far far higher than you would ever expect otherwise.
The fact that the annotation language that ESC/Java2 uses can also be automatically included into your JavaDoc documentation (making method requirements explicit, and making clear what a method guarantees), and can also be used to automatically build a JUnit testing framework for the code - well that's just icing. Take a look - download the Eclipse plugins here and here and try it out. I think you'll be remarkably suprised how powerful the error checking is, and how productive the development cycle can be when using it.
Jedidiah.
Leibniz really was the first to set off down the road to formal symbolic logic and reasoning as computation. Understanding some of his philosophy from the standpoint of the historical development of formal logic and computation is certainly within the purview of a CS based philosphy course. You could also throw in George Boole and Augustus DeMorgan who took the next important steps to developing, in Boole's words "the laws of thought".
Frege is certainly important in philosophy of mathematics with the first serious attempts to completely rigorously ground mathematics as logic. I'm less clear on exactly how well his work fits in to a CS philosophy course, though certainly he is of importance in the general development of formal logic.
Russell is the founder of type theory, which I'm sure anyone who has done much programming at all has made significant use of. At the time Russell developed it type theory was somewhat of a position he'd been forced into to escape various logical paradoxes in the foundations of mathematics. With the advent of computers however type theory saw a resurgence: types, and type signatures for functions, and a theory of types in general, suddenly seemd quite natural. Indeed type theory has become an important field in CS and programming language research. On that front it would probably be worth including Per Martin Löf and intuitionistic type theory, which is a more modern type theory better suited to the CS perspective than Russell's original work.
Tarski, notoriety of the Banach-Tarski paradox aside, is best known for a lot of remarkable work in logic, including his theorem regarding the indefinability of truth within formal systems, closely related to Gödel's incompleteness theorems. He also developed the bulk of model theory which is now very important in CS fields such as algebraic specification. Certainly including Tarski in a CS course would not go astray.
Did you know that the twin towers were built to withstand a direct impact from a 707?
And they survived impacts from larger planes, then were eventually brought down largely by the fire. But really this just highlights the difference between most engineering and software engineering, and that's assurance. The buildings were designed to be able to withstand impacts from planes, and you can bet that the engineers sat down and did all the lengthy calculations of structure and matrial tolerance to be able to confidently make that assurance.
Yes, nothing is perfect. On the other hand, being able to confidently state under what conditions something will work is a significant advantage over the simple broad statement that nothing is perfect and it probably has bugs somewhere. I would much rather someone tell me that a skyscraper will remain standing under various conditions than be told "well there might be some bugs somewhere, so who knows... if the wind blows from the wrong direction it might fall down. We haven't really checked". It is possible to give the same sort of assurances for software by using similar engineering techniques.
Jedidiah.
It is NOT inevitable that software will have bugs in it. By your reasoning, it is inevitable that bridges have design defects in them, and that at some point (in their usable specified lifetime), will collapse.
It is somewhat inevitable that software will not be perfect, just as a bridge is unlikely to be perfect. The difference currently, however, is that engineers who build bridges bother to do some analysis and provide assurances with regard to the quality of their work. That is, while the bridge may not be perfect, and likely has flaws, the engineer can say with confidence under what stresses it will stand, under what weather conditions it will survive, etc.
What we lack in the software world is assurances, not a lack of bugs. For some reason because developers can't say "this will work perfectly" they refuse to make any effort at all. The bridge building equivalent would be saying "well inevitably the welders are going to get a seam slightly off, so fuck it, we'll just slap something together any old how". You don't have to be able to say "this software will never crash", but being able to say "under these conditions, this software will never crash" is quite manageable. Of course the trick is managing to write your software well enough that the conditions you can guarantee lack of crashing for a reasonably broad. Of course if you have such a goal in mind, and intend to be able to give such guarantees, then it gets a little easier.
The real key is assurance - being able to state the bounds on when your software is guaranteed to work.
Jedidiah.
There is no point in donating to this program without donating to a program for putting a full curriculum worth of textbook material into the public domain first.
Luckily that sort of project is already underway. Sure, it is rather incomplete and patchy in its coverage, and the quality can be a little up and down, but there are actually a large number of pretty good quality texts on there for a wide variety of subjects. Wikijunior books, for instance, have material good enough for the kids the laptop project is aimed at.
Jedidiah.
I see you're not talking about GnuOctave then. Pity, because I was. As was the post I was replying to.
Given that Octave is Matlab workalike that uses Gnuplot for plotting I think we're close enough to talking about the same thing. Besides this whole discussion started with regard to the right tool for the job, the claim originally being that if you need to deal with hundreds of thousands signals analysis data points then Excel is great. It isn't. Matlab is great. The person then complained that Matlab was too expensive. Someone pointed him to Octave. And now you come up with:
And no, not all I need to do is plot. I need a variety of statistical tools as well.
For which, indeed, Octave probably isn't the ideal tool. The better tool for that job is obviously R which can suck in files in just as many formats (or more) than Excel, has far better (and more numerically accurate I might add), and far far more statistics functions, is actually designed from the outset to do high powered statistics on such massive datasets and, what do you know, let's you plot in a dozen different ways with a single command.
Jedidiah.
If you have a large amount of numerical data (hundreds of thousands of rows worth) then I assure you that Matlab, R, Mathematica, or even Gnuplot will be a the fastest way to "get something up easily and quickly". Just because you've never used them (apparently) and thus don't know how very easy they are to use for anyone who does any sort of numerical work, doesn't make them harder. The fact that they are incredibly powerful and permit far more complex number crunching and data manipulation due to a programmable interface doesn't make them any harder to use either - if all you want to do is plot then gnuplot can do it for you in a single command, no need to load speadsheet programs, import CSV files, and click through various graph making tools.
Jedidiah.
And I take it R is too expensive as well?
Jedidiah.
It is easy to do analysis and plotting of scientific data from databases. All you have to do is actually use the right tool for the job. Do you have gobs of numerical data that you want to crunch, analyse and plot? Then you probably want Matlab or R. Is that data in a database? Then you'll probably be using Matlab's database toolbox or R's database connectivity to import and export data (based on whatever database query you care to use - you can import whole tables easily if you like). Once the data is imported (which is trivial) you have no shortage of tools to process, munge, analyse, and plot to your heart's content.
Jedidiah.
So those guys in R&D doing basic signal analysis should be demoted because they're using excel to plot some quick-and-dirty graphs using the 1M data points they've collected?
Given that any R&D department that does signals analysis worth its salt will have a copy of Matlab on hand for all their numerical and plotting needs... Yes? There are various tools that are suitable for various jobs. If you are doing number crunching or plotting with datasets of that size then Excel is not the right tool for the job. Try Matlab, Mathematica, R, or similar.
Jedidiah.
I think most of these examples can be summarised as "Speech that has a strong likelihood to cause significant harm to third parties". Yelling fire in a theatre is a problem because it is reckless and needless endangerment of the fleeing patrons. Slander and Libel are obvious enough. Publising the names and addresses of witnesses, particularly in cases involving organised crime, is clearly endangering the witnesses. Even things like "hate speech" legislation in Europe stems from a similar principle - that a lot of such speech is a quite direct incitement to violence against a minority group. I think there's a pretty clear principle at work here, the question is what the line is with regard to "significant harm" and "likelihood to cause".
Jedidiah.
Many people put art and culture down to memetic evolution rather than genetics. Presuming you subscribe to memes (and really, the idea isn't that hard to believe, even if the exact details are still hard to properly pin down) then it isn't hard to see how things like art and culture can develop one you have an ability to spread and repliate memes (combined with some basic coupling to genetic selection - again, not hard to achieve). There are plenty of books that would cover this. The Meme Machine by Susan Blackmore comes to mind off the top of my head.
Jedidiah.
Could Sun be using this to eventually get to the desktop, or at the very least, allowing companies to run a complete linux system. Solaris server, Ubuntu clients for the employees?
In some ways RedHat/Fedora might be a better fit for this with Stateless Linux which would fit nicely into that sort of model.
Jedidiah.
This might make a big splash here, but in the real world, nobody will truly care.
The point being that you could say exactly the same thing about Apple proudly declaring that they were going open source and providing source code for Darwin. A few people care, most don't, and apparently it doesn't really matter at all.
Apple claiming to support open source: This might make a big splash here, but in the real world, nobody will truly care.
Jedidiah.
Sun would not be happy with a java.org fork that everyone and their dog adopted and left Sun to be just another contributor instead of running the show.
I never claimed they would be happy with that. All I'm claiming is that if they don't want that to happen all they have to do is not mismanage Java, and not provide any reasons for such a fork to get any traction.
Jedidiah.
Suggesting that Microsoft wouldn't bundle a look-a-like product in their monopoly OS and then do exactly what the parent post suggests (start making small changes) makes you sound naïve. For God sakes man, they did already try it once!
.NET. Throwing on a JVM, even a poisoned on, only dilutes their push now. Besides, Sun can still bar Microsoft from calling it Java, or claiming it to be Java compatible, at which stage what's the point for Microsoft to even bother? Back when Java mattered Microsoft was more than willing to fuck things up, but they're now making quite respectable headway with .NET and simply don't care anymore.
Yes, they tried, they failed, they moved on. At this point there's little reason in trying to poison the Java JVM well because their investment is in
Jedidiah.
You throw out a couple of scare scenarios here with either Microsoft or IBM making a mess of Java, but as far as I can tell they are just that, wild scare scenarios that simply aren't viable if Sun is at all on the ball. For starters Sun can keep the Java trademark and simply bar Microsoft and IBM from advertising whatever they care to sell as "Java". From there it is a question of exactly how either Microsoft or IBM is going to get their new language and VM (whatever they decide to call it - maybe microsoft will call it C# and .NET; no, wait, they already did that) to be dominant, or at least bootstrap it into being a competing standard. Microsoft can do that, as you point out, by leveraging their monopoly. The thing is they've already done that: C# and .NET. They can do that quite successfully whether Sun opens sources Java or not. So for Microsoft the argument is rather moot. What about IBM? They don't have a monopoly to leverage so they'd have to resort to the nasty tactic of making a better language and VM with better libraries to manage to get it to take off. But wait, they can only do that if Sun drop the ball in exactly the manner I described and let Java stagnate and become unresponsive to change. So we're back where we started. Sun open sourcing Java really isn't going to make a lot of difference unless Sun drops the ball themselves - which is exactly what I originally said.
Jedidiah.
Which interestingly enough took place between proprietary systems, not open ones. In that sense the UNIX wars are more akin to the battle between Java and C# and .NET (which could, indeed, be seen as damaging to the VM market). That is to say, regardless of what Sun does with Java they are already facing the same sorts of problems.
Jedidiah.
But they DO care about IBM or Microsoft creating a VM that advertises compatbility, but actually pulls the bait-and-switch routine. Remember, Microsoft already tried to pull that routine with the NON-OSS version of Java.
.NET.
Sure, but they will still own and control the Java trademark and they can simply bar such bait-and-switch advertising. Microsoft can fork Java all they want, they just can't call it Java, nor Java comnpatible. Besides MS is unlikely to do any such thing now since their efforts are heavily sunk into C# and
Jedidiah.
Unfortunately, one of OSI's core requirements is forking. So Java will never be able to make the pundits happy.
Sure they can - there are other ways to pevent forking than in the license. Look at most of the major OSS projects around and you'll see that there is very little in the way of forking - sure minor forks exist but they quickly die. Sun doesn't care about some minor fork of Java that 20 people use that eventually dies, they are worried about a significant competing standard that honestly splits developers between two different platforms. How often has that happened with big OSS projects? Hardly ever. The question is not so much "what can be done to prevent forking" but "what happens that causes a successful fork". The major examples of significant splits in the OSS world would be Emacs/XEmacs, gcc/ecgs, and XFree86/Xorg. In each of those cases the reason for both the fork, and the success of the fork, comes down to the original project stagnating and being unresponsive to change. Avoid that and you tend to avoid significant forks.
Jedidiah.
Sounds fine to me. A while ago I bought a Dell laptop. It had the obvious downside of being a Dell, but one strong point was the display: 15" widescreen that can do 1920x1200. The result is a display that's incredibly crisp and clear, and I certainly don't regret the purchase from that point - the display has very much been worth it.
Jedidiah.
What I don't understand is why it works. Why do children fixate on McDonalds so much? What is the secret sause here? And it's not just McDonalds. Apparently, brand loyalty can be instilled before the third year.
For starters you've got the fact that a lot of the brands that go after kids have (you'll note) simple clear logo designs that tend to be in very crisp vibrant colours. If you're looking for something to imprint on a small mind then simple clear lines and bright colours are the way to go.
In practice the real key is repetition. Small children (and even adults really) are remarkable mimicry machines. Find something short and attention grabbing and repeat ad nauseum and kids will pick it up. I imagine if you stuck a parrot in front of a TV 6 hours a day it would learn to say McDonalds pretty well too.
Jedidiah.
My wife uses Linux and she has never opened a console. I occasionally open it, but that's because I like to do "advanced" stuff. If I really wanted to, I could live without ever opening the console.
And alternatively, with Linux, you could live without ever opening a GUI. Hell I have a friend who, out of curiousity, decided to spend a week using nothing but Emacs just to see if it was possible. In the end he found it really was quite manageable - the only thing he really missed was a good webbrowser (W3 isn't that great).
Jedidiah.