So? Everybody has to pay taxes. A $471m deal is still a $471m deal.
And, in actual fact, Microsoft has been more successful than other companies in avoiding paying taxes, which is really pretty obscene for a company with one of the highest profit margins among the Fortune 500.
As I sit here, developing a program for our company using VS.NET and linked to a backend SQL Server database, I would have to disagree.
If Microsoft weren't selling VS.NET or SQL Server, would you be cleaning toilets instead? I don't think so. You would be programming in some other language for some other database server, say, Java and Oracle, or Python and PostgreSQL.
Furthermore, none of the $471m go to pay for your job, they exclusively go to Microsoft.
In other words, as a customer I get far more software value for my $1m given to Microsoft than I would get giving it to any other company. That presents me with greater opportunities to customize the software for my specific business needs.
No, Microsoft just overcharges you, and they can do that because they have a near monopoly position in many areas. They can also do it because people like you prefer wasting their employer's money on overpriced software instead of improving their skills to the point where they can do more with less.
Let's say every MS employee now gets a $30k bonus. Each one goes out and buys a new car... now you have job creation at car dealerships and manufacturing plants.
MS employees are fairly well-off. If you give an extra $30k bonus to someone who is well-off, they won't spend it. (The last $30k windfall I got just disappeared into my savings account.)
[Microsoft has a lot of its jobs overseas, so much of Microsoft's already measly job creation doesn't even take place in the US.] That's ok, the US military has a lot of its jobs overseas as well.
The US military overseas mostly consists of US citizens and US tax payers, so the US military workforce abroad is not comparable to Microsoft's workforce abroad.
In any case, personally I'm all for the US tax payer supporting the Indian and Chinese IT industry; God knows, the US has drained away enough talents from those countries. However, I suspect US tax payer support for foreign countries was not what people had in mind when they were arguing that this purchase was good because the $471m would "create jobs".
Actually, you're wrong. Think about all the support people who will be needed for all those machines. There's going to be a lot of IT people needed in the Army now to install and support all those systems. Either military personnel or outside contractors.
Whether you run Linux or Windows, you are going to need IT people to install and support those machines.
And to the degree that Windows is harder to maintain and support than Linux (which it probably is), the additional jobs it might create relative to Linux are unproductive: they cost money, but they don't produce any extra value or output. If you have the money to employ people in unproductive jobs, you might as well spend that money on having them do something productively.
And, of course, the $471m that you would save on licensing costs when going with Linux over Windows would be a nice chunk of money for tax breaks or other programs to help the economy.
But while it's a very good server OS it probably wouldn't meet the Army's needs very well on the desktop.
I disagree. The only reason many other organizations are still using Microsoft software is for compatibility with outside entities. But the Army is large and powerful enough that they can pick their desktop software. Something like OpenOffice running on Gnome or KDE is the ideal environment for them: robust, easy to use, powerful, and cheap.
The money won't be used to create jobs at Microsoft directly but it sure will create a lot of them indirectly.
No, the $471m will not create lots of outside jobs, the $471m will go to Microsoft investors. The outside jobs needed to install and maintain Windows will cost the tax payer additional hundreds of millions of dollars a year.
I like to see Microsoft get punished for their monopolistic behavior, but forcing them to distribute Java would set a bad precedent in my opinion. Courts should not force one company to act as the distributor for another company. They have a wide variety of other remedies at their disposal: fines, corporate breakups, restrictions on contractual agreements and pricing structure, jail time for executives, etc. Besides, Microsoft could have easily sabotaged this kind of distribution anyway and placed the blame on Sun ("it's not our fault that Sun's distribution isn't keeping up with Windows DLLs").
If decisions like this were allowed to stand, judges might start messing around with Linux distributions as well, and that would definitely not be good.
I RTFA and I saw NO reference to anyone paying twice. The article does not state this deal is for the OS and office, so you, Michael, should not assume anyone is paying twice.
Can you come up with a reasonable collection of Microsoft software that costs $950 per machine (on average)? I can't.
"Paying twice" seems like a pretty reasonable guess to me. That is, incidentally, also the situation in which many corporate customers are. Basically, the license you pay for with the machine doesn't quite cover enough.
Of course, the Army may be able to negotiate with some big PC vendor not to include an OEM license, but that usually doesn't help either because the vendors usually also pay Microsoft for all shipping units, one way or another.
If you are concerned with job creation, Microsoft is the wrong company to give money to. First of all, Microsoft needs much fewer employees than other industries to generate each $1m in revenue. In addition, since these are probably sales of existing software, there will be almost no job creation from those sales at all. Furthermore, Microsoft has a lot of its jobs overseas, so much of Microsoft's already measly job creation doesn't even take place in the US.
Open source is driven by market forces. If Gentoo makes sense, people will continue to use it. If this new effort makes sense, people will start using it. If either organization violates open source licenses, they can kiss their business model goodbye. It's no big deal.
As for all the personal stuff, well, people need to think about ahead of time what they are investing their time in and what they are going to get out of it. In the business world, all you get is what is guaranteed to you contractually in writing (or by law). So, don't spend time developing open source software expecting that some profit or job will magically materialize. Either develop open source software under contract, or do it for fun or as a volunteer.
If you don't want your system to page to CF, put enough RAM into it and don't create a swap partition. If you are really worried, turn of atime updates and use a flash file system.
If you set up your file sharing software so that it deletes any song that someone downloads from your hard drive, then you can "accidentally" leave it open as much as you like. That's the equivalent of having your CD's stolen out of your unlocked car.
These companies do have copyrights on the songs in question and their copyrights are being violated. Going after the people who violate their copyrights seems legitimate to me. This is the way things should work.
What I have always objected to with the RIAA actions is that they have been trying to restrict what I can do even though I'm not trading in copyrighted content. It is the chilling effect on legitimate uses that have made past legal actions and laws like the DMCA so harmful.
This illustrates why RMS has been so adamant about calling it GNU/Linux: he really wanted to get across that GNU software and Linux are two separate entities. The GNU project has been quite careful about intellectual property. If the developers of the Linux kernel screwed up with intellectual property, that should not affect the GNU tools at all. But by lumping it all together as "Linux", companies like SCO may not just cast a shadow on the Linux kernel, but also on the completely unrelated GNU tools. And one of the simplest remedies to address the SCO claims would be to replace the Linux kernel with, say, BSD or the Hurd. Is "RedHat Linux" going to rename itself to "RedHat Hurd" then? I don't think so. In fact, as long as they have all the drivers they need, most people wouldn't even notice that they are running a different kernel.
But cellular == the phone company, which usually translates into expensive metering and obnoxious, slow telco beuracracy.
Have you been frozen in a block of ice for the last 30 years? There is no "the" phone company anymore. There are about half a dozen major cellular companies. That's what the people who use the same rhetoric as you ("big, bad bureaucracies") consider an efficient market and that is the pinnacle of monopoly busting in the US; it ain't gonna get any better than that, at least as long as campaign contributors and lobbyists have anything to say about it (which they do).
In any case, what makes you think that WiFi will be any better? Unless we get ubiquitous, free WiFi access courtesy of the government, any nationwide WiFi coverage will involve lots of money, lots of billing, big companies, and hence big bureaucracies. Guess who is one of the biggest WiFi hotspot providers? T-Mobile, a big cellular carrier. And they'll happily provide you with the same customer service and billing as they do for your T-Mobile cell phone.
If you take that point of view, then almost all Java programs are non-compliant and won't work properly across conforming implementations. Of course, maybe you are right: that's what we are actually seeing. Very few Java programs actually do run correctly across all major platforms...
But a number of them with a little work on Classpath combined DO make a whole Java platform.
No, unfortunately, they don't. Classpath isn't complete enough yet. It hasn't even reached JDK 1.1, let alone Java 2.
Again, what parts are missing that a proper spec would have? Is it just that there is not one single document with section 1.4.5.5.3.2.3.54.45 detailing the color to make the font on a JavaDoc output?
It's things like which pixels something like drawLine actually touches, how different open I/O streams interact when they are on the same file, what the functional relationship is between JFrame and Frame, etc. The Java spec has actually been greatly improved since 1.2, but whether it is sufficient to produce a compatible implementation is an open question until someone actually does.
First off, why would they be so stupid? If you listen at all to what Sun is saying (and watch thier actions) that is not even a remote possibility.
Sun is a dying company, and dying companies do stupid things. Look at SCO.
Secondly, I really doubt they could make IBM do this so easily as you seem to think. IBM is smarter than that, and has based thier whole business around Java
Why do you think IBM is pushing so hard for alternatives to things like Swing? They want to get away from having to depend on Sun proprietary code.
And then the war is lost, and you can all start developing OS apps on Windows.
Why does it matter to me what enterprise Linux users do? Most of the stuff that has come out of enterprise Linux efforts seems to have been a drag on Linux as far as I'm concerned (JFS, LVM, etc.). Linux's strength is from the bottom up: small systems, small servers, desktops, etc.
As you say, things are being cobbled together taht are 100% OS. So, there is no risk in using Java to base other OS projects on. It's like putting off a picnic because of concern about the possibility of meteor strikes.
I fully endorse people using the existing open source Java components: GNU gcj, Kaffe, Classpath, SWT, GnomeJava, Java-on-Mono. As they get better and more compatible with Sun Java, the better it will be for Sun Java.
But if you use proprietary Java APIs, you are getting into the same situation that you get with any other proprietary software: your future becomes inextricably linked to the decisions of your vendor, and your vendor does not have your best interest at heart. It is that situation that open source users should avoid, and it makes as much sense to avoid that for Sun Java as it does for any other proprietary software product. That's particularly true because Sun Java brings absolutely nothing new to the table technically--there is plenty of equivalent open source software and technology. The only thing Sun Java has going for it is the hype and the brand.
"nobody has demonstrated so far that they are capable of producing an independent implementation [of the Java platform]." So what about these VM's? [Kaffe]
None of those are implementations of the Java platform, they are only implementations of the Java language and virtual machine (and not very good ones at that).
What part of the specs are not up to snuff? The bytecode is 100% described in detail. The libraries all have JavaDoc describing exactly what the API does.
JavaDoc is detailed enough for application programmers, but it does not constitute a specification of the API suitable for independent implementation.
My point is that there are MANY VM's - you have at least Sun's and IBM's. Also these MANY VM's run on MANY platforms.
All existing, complete implementations of the Java platform depend on Sun licenses. That gives Sun the power to restrict what happens with any of those VM's for any particular platform. Sun has the power to kill Java on Linux any time they want to.
ava is THAT FUCKING IMPORTANT TO LINUX IN THE ENTERPRISE RIGHT NOW TODAY AT THIS VERY MOMENT. [...] Like it or not, Linux and Java share the same fate now.
Enterprise Linux and Linux are not the same. If Java for Linux went away tomorrow, most Linux users wouldn't even notice. And the small number of enterprise users that use Java on Linux would just take out their checkbooks and pay Sun again for Solaris machines.
However, what will probably happen in the medium term is that people will cobble together a Java-workalike out of stuff like JBoss, SWT, and other open source components. It won't be 100% compatible with Sun, but it will be 100% open source. The loser, in the end, will be Sun, who will have lost both control and standardization. In an extra twist of irony, the platform that pulls it all together may well be Mono, which already runs a lot of Java code just fine.
No, Java is a platform with multiple implementations of the compiler/JIT and (effectively) a single implementation of the libraries.
Java compilers/JITs achieve very good performance, having little overhead compared to analogous C code.
But the Java platform falls short in several areas.
First, the VM has an enormous memory footprint, and it starts up very slowly. VM sharing is supposed to address this, but it hasn't materialized..NET addresses this by letting you pre-compile CLR code into binaries; that doesn't make the code run faster, but it makes programs start up faster.
Second, Java's native code interface (JNI) is inefficient and Java cannot efficiently access native data structures. That makes it difficult to reuse existing, mature C/C++ libraries, and to interface efficiently with operating system facilities.
Third, Java's libraries are not designed for speed: their APIs impose a lot of overhead, and the actual implementations aren't very good either. Also, Java's libraries are designed for generality first, and speed and high-quality cross-platform support distant seconds (things like Java2D just don't run very well on all platforms).
Sun JRE is slow. The JVM runs as another layer on top of the OS, so of course it will be slower than if it were native to the OS. All Sun has to do is make a JM (Java Machine) chip that can be put into motherboards to do the processing at the hardware level, not hardware-os-software level.
Raw CPU performance is not the issue. Java code runs very fast in Sun's current implementation. A Java native chip would not help at all (and would be impossible to make succeed in the marketplace anyway). The problems with Sun Java performance are platform design problems. In a sense, Sun's focus on CPU performance has distracted them from addressing the real performance problems.
The point of licences in irrelivant when you can just write an implmenetation for free under whatever licences you like.
There is only one implementation of Java, together with its derivatives by licensees. As long as that is all there is, its license matters, because nobody has demonstrated so far that they are capable of producing an independent implementation.
Why not? I see you dropped my point about keeping old libraries around for old releases of Java if they work better.
You can't just mix and match libraries. If you run a version of Java linked against old libraries, it won't be able to load code linked against new libraries, it will have security holes associated with the old libraries, etc.
I see no, zero, nada, zilch difference between a distro release and something like a solaris release. There is none. The distro maintainers keep stable versions of Java around the same way Sun does.
Sun doesn't "keep stable versions of Java around", Sun has the option of recompiling Java and fixing bugs and incompatibilities in Java when they make a new operating system release. Because Sun owns the copyright, Sun gets to make those choices. Linux distributors, on the other hand, face the possibility that Sun stops making Java available or breaks the Java distribution whenever it suits Sun.
The ability to fix bugs and recompile packages from source is at the core of open source systems. It is what has made Linux such a success. It makes no sense for open source developers to say that open source is a good idea, but, hey, for Java we don't really need it.
None of them caught on because they offered poor coompatibility, because Windows is not a published spec - unlike Java which is.
The Windows and Java APIs are documented in pretty much the same way: as a huge collection of vendor-supplied documents aimed primarily at programmers. Neither set of documentation rises to the level of a "specification", and both have significant gaps. That's why making a third party Windows implementation was very difficult, and the same appears to be true for Java. Sun Java really is like Microsoft Windows in that regard.
If you're at all a fan of Linux, then you need to think about what a world where Java (the most commonly used enterprise programming language by far) is owned by MS and runs best on Windows servers. By-By Linux! Seriously, that is how it would be.
You say that it is perfectly fine if there exists only a single, proprietary implementation of Java as long as it is owned by Sun, but if that implementation were owned by Microsoft, it would be bad? Where is the logic in that?
I don't see any difference between Java being proprietary to Sun and Java being proprietary to Microsoft. Both Sun and Microsoft are companies that would like to see Linux go away because it eats into their business, and both have a strong incentive to make sure that Java runs best on their own servers and performs less well on Linux. That is exactly the problem.
Fortunately, it hasn't gotten to that point yet at all, since Java is not very important on Linux yet. As soon as there exists a full open source implementation of the Java platform on Linux, an implementation that neither Sun nor Microsoft can mess with, I'm all for widespread use of Java on Linux. Until then, Linux users should stay away from Java.
Whoopdee fuck. I can call C/C++ libraries just fine with Java, thanks (JNI).
Making a JNI interface is a lot of work. In contrast, from C#, you can call functions inside shared libraries directly with no glue code.
Furthermore, JNI interfaces are very high overhead, and Java is incapable of manipulating native data structures. In contrast, the C# native interfaces are essentially as fast as native calls, and C# can access native data structures directly with no overhead.
But why bother? If you want to use C++ libraries, just code in C++ to begin with.
For the same reason why I program in Python and Perl: I like high level languages and I like my own code to be safe, but I also like to take advantage of the huge number of existing, well-debugged, well-designed C and C++ libraries.
The fact of the matter is that MS only creates languages to sell their platform. Everything MS does is designed from the ground up to lock you in. To think that they don't have a similar plan for C# is just naive.
How does using an ECMA/ISO programming language with Linux-specific libraries lock me into Windows??? I don't care what Microsoft's plan is, I go by facts. And the facts are that C# gives me easy access to native libraries, as well as a high level language that improves on Java in a number of ways.
Yes, you can compile C# to the JVM, but you lose some performance and you lose the ability to use native code easily. The DotGNU compiler actually has support for this.
OTOH, you can compile Java to the CLR (C# runtime) with no loss in performance or functionality. Mono has support for that. People have actually run Eclipse under Mono that way.
If Sun ever releases their Java implementation open source, one of the first things that happens will be a port of Swing and other Java APIs to Mono so that Java programmers can run all their code on the Mono platform.
C Sharp the language is a standard, but this counts for little
A standard language with a minimal library seems to have worked well for C and C++.
The real question is whether Java won't just collapse under its own weight as it accrues more and more outdated crap.
since the platform (corresponding to J2SE or J2EE) is really the Dotnet framework, which is not standardized and remains proprietary and patented.
That means that Windows developers program to.NET APIs and Linux users use Gtk#, expat, and POSIX. That's just like C++: on Windows, developers use MFC, and on Linux they use Gtk+. Seems fine to me.
not only are there already multiple vendors and dozens of separate implementations
All conforming Java implementations depend on code licensed from Sun. That means that Sun completely controls the Java market.
Compare this with what the JCP has standardized (hint: pretty much everything and beyond)
You say that as if it's a good thing. It isn't.... and they have standardised less than 10% of the.NET APIs (just the CLR and C#).
Yes, isn't it great? That's just like C and C++: a standard language, a minimal standard library, and the rest is left to the market. You can even easily call existing C libraries from C#.
The issue is that RedHat has made a decision to only ship open source software in their distro. So you won't get the good video drivers or a good JVM. This could easily be solved if they just shipped Sun's JVM with it, and had the installer agree to the terms.
Why should they? Sun is in competition with RedHat, just like Sun is in competition with Microsoft. Microsoft didn't really want to rely on Sun-licensed software. Conversely, Sun was petrified that Microsoft might end up controlling some Java APIs that Java users would start to rely on.
Linux is in the same situation: if Java became widespread on Linux, Sun would effectively control that functionality on Linux, since there are no full Java implementations that aren't directly or indirectly licensed from Sun. That situation is no more palatable to RedHat or Linux users than the equivalent situation is to Sun or Microsoft.
C# code can call C/C++ libraries easily; even if the ECMA C# standard came with no libraries at all, C# would be a useful programming language on Linux. Of course, ECMA C# actually defines libraries that are much more extensive than what, say, ANSI C and ANSI C++ define.
Sun's approach with Java has largely been a failure as far as I'm concerned. WORA has meant a bloated set of standard libraries, libraries that are mediocre on Windows and worse than mediocre everywhere else. And Sun keeps churning out one poorly designed API after another.
The C/C++ approach has been an enormous success: there is a free market of libraries, approaches, and ideas. C# looks like it may follow that successful tradition precisely because ECMA/ISO C# does not define anything anywhere nearly as extensive as Java does. In different words, the fact that ECMA C# standardizes less than Sun Java is an advantage as far as I'm concerned.
Slashdot Mirror
So? Everybody has to pay taxes. A $471m deal is still a $471m deal.
And, in actual fact, Microsoft has been more successful than other companies in avoiding paying taxes, which is really pretty obscene for a company with one of the highest profit margins among the Fortune 500.
As I sit here, developing a program for our company using VS.NET and linked to a backend SQL Server database, I would have to disagree.
If Microsoft weren't selling VS.NET or SQL Server, would you be cleaning toilets instead? I don't think so. You would be programming in some other language for some other database server, say, Java and Oracle, or Python and PostgreSQL.
Furthermore, none of the $471m go to pay for your job, they exclusively go to Microsoft.
In other words, as a customer I get far more software value for my $1m given to Microsoft than I would get giving it to any other company. That presents me with greater opportunities to customize the software for my specific business needs.
No, Microsoft just overcharges you, and they can do that because they have a near monopoly position in many areas. They can also do it because people like you prefer wasting their employer's money on overpriced software instead of improving their skills to the point where they can do more with less.
Let's say every MS employee now gets a $30k bonus. Each one goes out and buys a new car... now you have job creation at car dealerships and manufacturing plants.
MS employees are fairly well-off. If you give an extra $30k bonus to someone who is well-off, they won't spend it. (The last $30k windfall I got just disappeared into my savings account.)
[Microsoft has a lot of its jobs overseas, so much of Microsoft's already measly job creation doesn't even take place in the US.] That's ok, the US military has a lot of its jobs overseas as well.
The US military overseas mostly consists of US citizens and US tax payers, so the US military workforce abroad is not comparable to Microsoft's workforce abroad.
In any case, personally I'm all for the US tax payer supporting the Indian and Chinese IT industry; God knows, the US has drained away enough talents from those countries. However, I suspect US tax payer support for foreign countries was not what people had in mind when they were arguing that this purchase was good because the $471m would "create jobs".
Actually, you're wrong. Think about all the support people who will be needed for all those machines. There's going to be a lot of IT people needed in the Army now to install and support all those systems. Either military personnel or outside contractors.
Whether you run Linux or Windows, you are going to need IT people to install and support those machines.
And to the degree that Windows is harder to maintain and support than Linux (which it probably is), the additional jobs it might create relative to Linux are unproductive: they cost money, but they don't produce any extra value or output. If you have the money to employ people in unproductive jobs, you might as well spend that money on having them do something productively.
And, of course, the $471m that you would save on licensing costs when going with Linux over Windows would be a nice chunk of money for tax breaks or other programs to help the economy.
But while it's a very good server OS it probably wouldn't meet the Army's needs very well on the desktop.
I disagree. The only reason many other organizations are still using Microsoft software is for compatibility with outside entities. But the Army is large and powerful enough that they can pick their desktop software. Something like OpenOffice running on Gnome or KDE is the ideal environment for them: robust, easy to use, powerful, and cheap.
The money won't be used to create jobs at Microsoft directly but it sure will create a lot of them indirectly.
No, the $471m will not create lots of outside jobs, the $471m will go to Microsoft investors. The outside jobs needed to install and maintain Windows will cost the tax payer additional hundreds of millions of dollars a year.
I like to see Microsoft get punished for their monopolistic behavior, but forcing them to distribute Java would set a bad precedent in my opinion. Courts should not force one company to act as the distributor for another company. They have a wide variety of other remedies at their disposal: fines, corporate breakups, restrictions on contractual agreements and pricing structure, jail time for executives, etc. Besides, Microsoft could have easily sabotaged this kind of distribution anyway and placed the blame on Sun ("it's not our fault that Sun's distribution isn't keeping up with Windows DLLs").
If decisions like this were allowed to stand, judges might start messing around with Linux distributions as well, and that would definitely not be good.
I RTFA and I saw NO reference to anyone paying twice. The article does not state this deal is for the OS and office, so you, Michael, should not assume anyone is paying twice.
Can you come up with a reasonable collection of Microsoft software that costs $950 per machine (on average)? I can't.
"Paying twice" seems like a pretty reasonable guess to me. That is, incidentally, also the situation in which many corporate customers are. Basically, the license you pay for with the machine doesn't quite cover enough.
Of course, the Army may be able to negotiate with some big PC vendor not to include an OEM license, but that usually doesn't help either because the vendors usually also pay Microsoft for all shipping units, one way or another.
If you are concerned with job creation, Microsoft is the wrong company to give money to. First of all, Microsoft needs much fewer employees than other industries to generate each $1m in revenue. In addition, since these are probably sales of existing software, there will be almost no job creation from those sales at all. Furthermore, Microsoft has a lot of its jobs overseas, so much of Microsoft's already measly job creation doesn't even take place in the US.
Open source is driven by market forces. If Gentoo makes sense, people will continue to use it. If this new effort makes sense, people will start using it. If either organization violates open source licenses, they can kiss their business model goodbye. It's no big deal.
As for all the personal stuff, well, people need to think about ahead of time what they are investing their time in and what they are going to get out of it. In the business world, all you get is what is guaranteed to you contractually in writing (or by law). So, don't spend time developing open source software expecting that some profit or job will magically materialize. Either develop open source software under contract, or do it for fun or as a volunteer.
Arguably, exchanging copies of music in order to add to your music library is commercial use--it's a kind of barter.
If you don't want your system to page to CF, put enough RAM into it and don't create a swap partition. If you are really worried, turn of atime updates and use a flash file system.
A similar machine is the OpenBrick
One difference is that the Northtec uses a harddisk, while OpenBrick uses CF cards by default.
Does anybody have any further experience comparing these two machines?
How well does the video input on the Northtec machine work?
If you set up your file sharing software so that it deletes any song that someone downloads from your hard drive, then you can "accidentally" leave it open as much as you like. That's the equivalent of having your CD's stolen out of your unlocked car.
These companies do have copyrights on the songs in question and their copyrights are being violated. Going after the people who violate their copyrights seems legitimate to me. This is the way things should work.
What I have always objected to with the RIAA actions is that they have been trying to restrict what I can do even though I'm not trading in copyrighted content. It is the chilling effect on legitimate uses that have made past legal actions and laws like the DMCA so harmful.
This illustrates why RMS has been so adamant about calling it GNU/Linux: he really wanted to get across that GNU software and Linux are two separate entities. The GNU project has been quite careful about intellectual property. If the developers of the Linux kernel screwed up with intellectual property, that should not affect the GNU tools at all. But by lumping it all together as "Linux", companies like SCO may not just cast a shadow on the Linux kernel, but also on the completely unrelated GNU tools. And one of the simplest remedies to address the SCO claims would be to replace the Linux kernel with, say, BSD or the Hurd. Is "RedHat Linux" going to rename itself to "RedHat Hurd" then? I don't think so. In fact, as long as they have all the drivers they need, most people wouldn't even notice that they are running a different kernel.
But cellular == the phone company, which usually translates into expensive metering and obnoxious, slow telco beuracracy.
Have you been frozen in a block of ice for the last 30 years? There is no "the" phone company anymore. There are about half a dozen major cellular companies. That's what the people who use the same rhetoric as you ("big, bad bureaucracies") consider an efficient market and that is the pinnacle of monopoly busting in the US; it ain't gonna get any better than that, at least as long as campaign contributors and lobbyists have anything to say about it (which they do).
In any case, what makes you think that WiFi will be any better? Unless we get ubiquitous, free WiFi access courtesy of the government, any nationwide WiFi coverage will involve lots of money, lots of billing, big companies, and hence big bureaucracies. Guess who is one of the biggest WiFi hotspot providers? T-Mobile, a big cellular carrier. And they'll happily provide you with the same customer service and billing as they do for your T-Mobile cell phone.
If you take that point of view, then almost all Java programs are non-compliant and won't work properly across conforming implementations. Of course, maybe you are right: that's what we are actually seeing. Very few Java programs actually do run correctly across all major platforms...
But a number of them with a little work on Classpath combined DO make a whole Java platform.
No, unfortunately, they don't. Classpath isn't complete enough yet. It hasn't even reached JDK 1.1, let alone Java 2.
Again, what parts are missing that a proper spec would have? Is it just that there is not one single document with section 1.4.5.5.3.2.3.54.45 detailing the color to make the font on a JavaDoc output?
It's things like which pixels something like drawLine actually touches, how different open I/O streams interact when they are on the same file, what the functional relationship is between JFrame and Frame, etc. The Java spec has actually been greatly improved since 1.2, but whether it is sufficient to produce a compatible implementation is an open question until someone actually does.
First off, why would they be so stupid? If you listen at all to what Sun is saying (and watch thier actions) that is not even a remote possibility.
Sun is a dying company, and dying companies do stupid things. Look at SCO.
Secondly, I really doubt they could make IBM do this so easily as you seem to think. IBM is smarter than that, and has based thier whole business around Java
Why do you think IBM is pushing so hard for alternatives to things like Swing? They want to get away from having to depend on Sun proprietary code.
And then the war is lost, and you can all start developing OS apps on Windows.
Why does it matter to me what enterprise Linux users do? Most of the stuff that has come out of enterprise Linux efforts seems to have been a drag on Linux as far as I'm concerned (JFS, LVM, etc.). Linux's strength is from the bottom up: small systems, small servers, desktops, etc.
As you say, things are being cobbled together taht are 100% OS. So, there is no risk in using Java to base other OS projects on. It's like putting off a picnic because of concern about the possibility of meteor strikes.
I fully endorse people using the existing open source Java components: GNU gcj, Kaffe, Classpath, SWT, GnomeJava, Java-on-Mono. As they get better and more compatible with Sun Java, the better it will be for Sun Java.
But if you use proprietary Java APIs, you are getting into the same situation that you get with any other proprietary software: your future becomes inextricably linked to the decisions of your vendor, and your vendor does not have your best interest at heart. It is that situation that open source users should avoid, and it makes as much sense to avoid that for Sun Java as it does for any other proprietary software product. That's particularly true because Sun Java brings absolutely nothing new to the table technically--there is plenty of equivalent open source software and technology. The only thing Sun Java has going for it is the hype and the brand.
"nobody has demonstrated so far that they are capable of producing an independent implementation [of the Java platform]." So what about these VM's? [Kaffe]
None of those are implementations of the Java platform, they are only implementations of the Java language and virtual machine (and not very good ones at that).
What part of the specs are not up to snuff? The bytecode is 100% described in detail. The libraries all have JavaDoc describing exactly what the API does.
JavaDoc is detailed enough for application programmers, but it does not constitute a specification of the API suitable for independent implementation.
My point is that there are MANY VM's - you have at least Sun's and IBM's. Also these MANY VM's run on MANY platforms.
All existing, complete implementations of the Java platform depend on Sun licenses. That gives Sun the power to restrict what happens with any of those VM's for any particular platform. Sun has the power to kill Java on Linux any time they want to.
ava is THAT FUCKING IMPORTANT TO LINUX IN THE ENTERPRISE RIGHT NOW TODAY AT THIS VERY MOMENT. [...] Like it or not, Linux and Java share the same fate now.
Enterprise Linux and Linux are not the same. If Java for Linux went away tomorrow, most Linux users wouldn't even notice. And the small number of enterprise users that use Java on Linux would just take out their checkbooks and pay Sun again for Solaris machines.
However, what will probably happen in the medium term is that people will cobble together a Java-workalike out of stuff like JBoss, SWT, and other open source components. It won't be 100% compatible with Sun, but it will be 100% open source. The loser, in the end, will be Sun, who will have lost both control and standardization. In an extra twist of irony, the platform that pulls it all together may well be Mono, which already runs a lot of Java code just fine.
Java isn't slow; Java is a language.
.NET addresses this by letting you pre-compile CLR code into binaries; that doesn't make the code run faster, but it makes programs start up faster.
No, Java is a platform with multiple implementations of the compiler/JIT and (effectively) a single implementation of the libraries.
Java compilers/JITs achieve very good performance, having little overhead compared to analogous C code.
But the Java platform falls short in several areas.
First, the VM has an enormous memory footprint, and it starts up very slowly. VM sharing is supposed to address this, but it hasn't materialized.
Second, Java's native code interface (JNI) is inefficient and Java cannot efficiently access native data structures. That makes it difficult to reuse existing, mature C/C++ libraries, and to interface efficiently with operating system facilities.
Third, Java's libraries are not designed for speed: their APIs impose a lot of overhead, and the actual implementations aren't very good either. Also, Java's libraries are designed for generality first, and speed and high-quality cross-platform support distant seconds (things like Java2D just don't run very well on all platforms).
Sun JRE is slow. The JVM runs as another layer on top of the OS, so of course it will be slower than if it were native to the OS. All Sun has to do is make a JM (Java Machine) chip that can be put into motherboards to do the processing at the hardware level, not hardware-os-software level.
Raw CPU performance is not the issue. Java code runs very fast in Sun's current implementation. A Java native chip would not help at all (and would be impossible to make succeed in the marketplace anyway). The problems with Sun Java performance are platform design problems. In a sense, Sun's focus on CPU performance has distracted them from addressing the real performance problems.
The point of licences in irrelivant when you can just write an implmenetation for free under whatever licences you like.
There is only one implementation of Java, together with its derivatives by licensees. As long as that is all there is, its license matters, because nobody has demonstrated so far that they are capable of producing an independent implementation.
Why not? I see you dropped my point about keeping old libraries around for old releases of Java if they work better.
You can't just mix and match libraries. If you run a version of Java linked against old libraries, it won't be able to load code linked against new libraries, it will have security holes associated with the old libraries, etc.
I see no, zero, nada, zilch difference between a distro release and something like a solaris release. There is none. The distro maintainers keep stable versions of Java around the same way Sun does.
Sun doesn't "keep stable versions of Java around", Sun has the option of recompiling Java and fixing bugs and incompatibilities in Java when they make a new operating system release. Because Sun owns the copyright, Sun gets to make those choices. Linux distributors, on the other hand, face the possibility that Sun stops making Java available or breaks the Java distribution whenever it suits Sun.
The ability to fix bugs and recompile packages from source is at the core of open source systems. It is what has made Linux such a success. It makes no sense for open source developers to say that open source is a good idea, but, hey, for Java we don't really need it.
None of them caught on because they offered poor coompatibility, because Windows is not a published spec - unlike Java which is.
The Windows and Java APIs are documented in pretty much the same way: as a huge collection of vendor-supplied documents aimed primarily at programmers. Neither set of documentation rises to the level of a "specification", and both have significant gaps. That's why making a third party Windows implementation was very difficult, and the same appears to be true for Java. Sun Java really is like Microsoft Windows in that regard.
If you're at all a fan of Linux, then you need to think about what a world where Java (the most commonly used enterprise programming language by far) is owned by MS and runs best on Windows servers. By-By Linux! Seriously, that is how it would be.
You say that it is perfectly fine if there exists only a single, proprietary implementation of Java as long as it is owned by Sun, but if that implementation were owned by Microsoft, it would be bad? Where is the logic in that?
I don't see any difference between Java being proprietary to Sun and Java being proprietary to Microsoft. Both Sun and Microsoft are companies that would like to see Linux go away because it eats into their business, and both have a strong incentive to make sure that Java runs best on their own servers and performs less well on Linux. That is exactly the problem.
Fortunately, it hasn't gotten to that point yet at all, since Java is not very important on Linux yet. As soon as there exists a full open source implementation of the Java platform on Linux, an implementation that neither Sun nor Microsoft can mess with, I'm all for widespread use of Java on Linux. Until then, Linux users should stay away from Java.
Whoopdee fuck. I can call C/C++ libraries just fine with Java, thanks (JNI).
Making a JNI interface is a lot of work. In contrast, from C#, you can call functions inside shared libraries directly with no glue code.
Furthermore, JNI interfaces are very high overhead, and Java is incapable of manipulating native data structures. In contrast, the C# native interfaces are essentially as fast as native calls, and C# can access native data structures directly with no overhead.
But why bother? If you want to use C++ libraries, just code in C++ to begin with.
For the same reason why I program in Python and Perl: I like high level languages and I like my own code to be safe, but I also like to take advantage of the huge number of existing, well-debugged, well-designed C and C++ libraries.
The fact of the matter is that MS only creates languages to sell their platform. Everything MS does is designed from the ground up to lock you in. To think that they don't have a similar plan for C# is just naive.
How does using an ECMA/ISO programming language with Linux-specific libraries lock me into Windows??? I don't care what Microsoft's plan is, I go by facts. And the facts are that C# gives me easy access to native libraries, as well as a high level language that improves on Java in a number of ways.
Yes, you can compile C# to the JVM, but you lose some performance and you lose the ability to use native code easily. The DotGNU compiler actually has support for this.
OTOH, you can compile Java to the CLR (C# runtime) with no loss in performance or functionality. Mono has support for that. People have actually run Eclipse under Mono that way.
If Sun ever releases their Java implementation open source, one of the first things that happens will be a port of Swing and other Java APIs to Mono so that Java programmers can run all their code on the Mono platform.
C Sharp the language is a standard, but this counts for little
.NET APIs and Linux users use Gtk#, expat, and POSIX. That's just like C++: on Windows, developers use MFC, and on Linux they use Gtk+. Seems fine to me.
A standard language with a minimal library seems to have worked well for C and C++.
The real question is whether Java won't just collapse under its own weight as it accrues more and more outdated crap.
since the platform (corresponding to J2SE or J2EE) is really the Dotnet framework, which is not standardized and remains proprietary and patented.
That means that Windows developers program to
not only are there already multiple vendors and dozens of separate implementations
All conforming Java implementations depend on code licensed from Sun. That means that Sun completely controls the Java market.
Compare this with what the JCP has standardized (hint: pretty much everything and beyond)
... and they have standardised less than 10% of the .NET APIs (just the CLR and C#).
You say that as if it's a good thing. It isn't.
Yes, isn't it great? That's just like C and C++: a standard language, a minimal standard library, and the rest is left to the market. You can even easily call existing C libraries from C#.
The issue is that RedHat has made a decision to only ship open source software in their distro. So you won't get the good video drivers or a good JVM. This could easily be solved if they just shipped Sun's JVM with it, and had the installer agree to the terms.
Why should they? Sun is in competition with RedHat, just like Sun is in competition with Microsoft. Microsoft didn't really want to rely on Sun-licensed software. Conversely, Sun was petrified that Microsoft might end up controlling some Java APIs that Java users would start to rely on.
Linux is in the same situation: if Java became widespread on Linux, Sun would effectively control that functionality on Linux, since there are no full Java implementations that aren't directly or indirectly licensed from Sun. That situation is no more palatable to RedHat or Linux users than the equivalent situation is to Sun or Microsoft.
C# code can call C/C++ libraries easily; even if the ECMA C# standard came with no libraries at all, C# would be a useful programming language on Linux. Of course, ECMA C# actually defines libraries that are much more extensive than what, say, ANSI C and ANSI C++ define.
Sun's approach with Java has largely been a failure as far as I'm concerned. WORA has meant a bloated set of standard libraries, libraries that are mediocre on Windows and worse than mediocre everywhere else. And Sun keeps churning out one poorly designed API after another.
The C/C++ approach has been an enormous success: there is a free market of libraries, approaches, and ideas. C# looks like it may follow that successful tradition precisely because ECMA/ISO C# does not define anything anywhere nearly as extensive as Java does. In different words, the fact that ECMA C# standardizes less than Sun Java is an advantage as far as I'm concerned.