Sure, it's not popular or common on the client-side in either application or applet form, but it does exist.
Most operating systems ship with some sort of Java VM, you should be able to deploy wherever you want and expect at least some support.
Sure, it's neither as fast as true binary code nor is the GUI as pretty as native apps, but if you wanted those you wouldn't be thinking about Java in the first place.
Java is as dead as Perl on the client. It's dead to all those who don't use it, but for those that do, it's indispensable.
It isn't like anyone was paying for their distros anyway.
The whole concept behind Open Source is that selling service is the way to make money. However, when no one is paying you and demanding your services even still, there's got to come a point where you realize that your "customers" are simply taking advantage of you.
Bravo, Redhat. For finally realizing that money doesn't come from beggars. Now maybe my RHAT shares will be a shit.
I always wondered what it was that attracted people to sysadministration. It seems like there is an inordinate number of Slashbots who are sysadmins or aspiring sysadmins and fewer programmers. Now this could just be a result of sysadmins having more time on their hands during the workday, but I am really curious.
Why did you choose system administration over programming?
Sun won't. It's their bread and butter to license Java compatibility logos. They'd be fools to allow logos to be used willy-nilly.
As it stands now, if you don't say you are "Java Compatible" and you don't use any Sun-trademarked logo, you are in the clear even if you can run Java programs. You can then include whatever toolkit you like and customize the JVM according to your own specs instead of Sun's. Unbranded Java, there's a lot of it out there.
The biggest difficulty in creating cross platform toolkits is resolving the different paradigms inherent in each platform.
X is based on a networking concept where anyone can access anyone else's screen as a network resource. This leads to multi-threading issues as it is possible for two people to use the same desktop, even same application, simultaneously. As a result, toolkits that have their origins in that environment like GTK and wxwindows have strong multi-threading support not to mention strong networking support.
OTOH, Windows was built around a single user concept, which from a networking perspective is more secure because a person's desktop isn't a networking resource (but that's neither here nor there). This results in the base windowing subsystem's reliance on processes as the fundamental object of execution (as opposed to threads). So toolkits built upon Windows (MFC, OWL, QT) are able to harness Windows's windowing support in a way that more easily and effectively takes advantage of the features of the subsystem.
Attempting to port one toolkit from its home platform to a foreign platform leads to problems of "look and feel". AWT and Swing are prime examples of toolkits that look strange whereever they are used. Likewise, wxwindows feels funny running on Windows and GTK looks funny. Hell, MFC doesn't even run on X.
What this all boils down to is that cross-platform development is always going to have limitations because the roots of each toolkit will decide its look and feel as opposed to the platform itself deciding the look and feel according to the platform's native interface.
Shark populations may be declining, but it isn't a result of the reasons stated in the article.
First off, it is important to note that sharks are DANGEROUS. Sharks have been known to attack humans without provocation. In recent years their shenanigans have included encroaching upon swimming areas of popular beaches. In the year 2002 their were an unprecedented amount of shark attacks. These attacks are a direct result of sharks, which are dangerous and unpredictable. A benefit of lower shark populations is decreased shark attack incidents.
Second, shark fin soup is absolutely delicious and the consumption of which should be encouraged not discouraged. Shark fins are not gristle as the article poster just blithely mentioned. It is primarily collagen which becomes gelatinous and tasty in soup or stir fry. Another thing to note is that species that turn out to be tasty also turn out to increase in population in the long run. Their are millions more cattle now than one thousand years ago. The same goes for chickens and pigs and turkeys and other meat animals. Harvesting sharks for food can only lead to increased populations.
That of course is a dilemma, but one that can be worked around by FARMING sharks. This way sharks can increase in population and feed hungry people without becoming a hazard to swimmers, surfers, and other innocent humans.
As it is UL being pulled into the markets. And though the article has a couple instances where UL is being brought in as test servers, there is no evidence of a wide-scale demand for Linux to replace existing telecom servers.
Linux has always been a small-scale server OS, best used for printer sharing, file sharing, and web serving. It can be loaded onto big iron without much trouble, but it still suffers performance (in the general sense of the word, not just speedwise) issues compared to commercial big iron Unix.
Java isn't interpreted. It's compiled to bytecode classes. Then those classes are pre-compiled to native code when run.
You are really talking about a specific VM when you say such a thing. It is widely known that Java VMs do not have to turn anything into machine code as a prerequisite to running Java code. It is specific implementations of the Java VM that compile everything to native code before running.
Several VMs do not compile the bytecode at all and simply run the program from an internal command tree. Several other VMs only compile frequently-used code regions into native code. Others turn the whole shebang into a giant binary executable before running.
It all depends on the VM. You can't really make such broad statements.
A runtime is a binary library that exports certain functions. The Win32 and glibc runtimes are a couple that Slashbots are probably somewhat familiar with. They have specialized routines that facilitate some kind action that the language itself does not directly support.
A VM is a completely different beast. It is a complete runtime environment for your program. Whereas a program that uses a runtime is typically compiled into machine code, a program that uses a VM is typically compiled at runtime from source (Perl) or parsed into memory from bytecode (Java).
It has become fashionable to call runtimes "VMs", especially in the Unix world where multiple APIs are supported on the same kernel, but it is a misnomer. (You'd expect the pedantry that is so prominent in the Unix culture to correct this, but I digress.)
In it, Larry proposes that I judge the outcome of his bet and the future of his job. I accept, and pledge to be a fair and reasonable arbiter.
(Although I suspect Larry may not have to worry much about condition (a). This is just a hunch, but I believe that Congress is more likely to approve legislation restricting sexually explicit spam than a bill mandating "ADV:" or its equivalent.)
Declan realizes off the bat that this is a false bet. There is no chance that condition (a) will be satisfied, so Lessig has in essence wagered nothing.
If you want to call your platform ELC-approved, you need to pay a licensing fee.
It just doesn't seem like it's worth the hassle.
Does the consortium have a suite of automated tests that can verify that the platform was implemented correctly? If not, this is still a lot of smoke and mirrors, especially so because people have been making embedded Linux devices for quite a while based on their own needs (Tivo).
Slashdot Mirror
It's funny how a technology based on whales' object location techniques has come full circle.
Sure, it's not popular or common on the client-side in either application or applet form, but it does exist.
Most operating systems ship with some sort of Java VM, you should be able to deploy wherever you want and expect at least some support.
Sure, it's neither as fast as true binary code nor is the GUI as pretty as native apps, but if you wanted those you wouldn't be thinking about Java in the first place.
Java is as dead as Perl on the client. It's dead to all those who don't use it, but for those that do, it's indispensable.
It isn't like anyone was paying for their distros anyway.
The whole concept behind Open Source is that selling service is the way to make money. However, when no one is paying you and demanding your services even still, there's got to come a point where you realize that your "customers" are simply taking advantage of you.
Bravo, Redhat. For finally realizing that money doesn't come from beggars. Now maybe my RHAT shares will be a shit.
That's almost a year away.
U.S. Geological Survey
They are one of the most hit servers in the government. I think they can take a back page Slashdot linking.
I always wondered what it was that attracted people to sysadministration. It seems like there is an inordinate number of Slashbots who are sysadmins or aspiring sysadmins and fewer programmers. Now this could just be a result of sysadmins having more time on their hands during the workday, but I am really curious.
Why did you choose system administration over programming?
It doesn't compile. Where is printf defined?
They both have to do with running the server on 9x or ME.
Is Apache's security really the problem here?
Sun won't. It's their bread and butter to license Java compatibility logos. They'd be fools to allow logos to be used willy-nilly.
As it stands now, if you don't say you are "Java Compatible" and you don't use any Sun-trademarked logo, you are in the clear even if you can run Java programs. You can then include whatever toolkit you like and customize the JVM according to your own specs instead of Sun's. Unbranded Java, there's a lot of it out there.
The biggest difficulty in creating cross platform toolkits is resolving the different paradigms inherent in each platform.
X is based on a networking concept where anyone can access anyone else's screen as a network resource. This leads to multi-threading issues as it is possible for two people to use the same desktop, even same application, simultaneously. As a result, toolkits that have their origins in that environment like GTK and wxwindows have strong multi-threading support not to mention strong networking support.
OTOH, Windows was built around a single user concept, which from a networking perspective is more secure because a person's desktop isn't a networking resource (but that's neither here nor there). This results in the base windowing subsystem's reliance on processes as the fundamental object of execution (as opposed to threads). So toolkits built upon Windows (MFC, OWL, QT) are able to harness Windows's windowing support in a way that more easily and effectively takes advantage of the features of the subsystem.
Attempting to port one toolkit from its home platform to a foreign platform leads to problems of "look and feel". AWT and Swing are prime examples of toolkits that look strange whereever they are used. Likewise, wxwindows feels funny running on Windows and GTK looks funny. Hell, MFC doesn't even run on X.
What this all boils down to is that cross-platform development is always going to have limitations because the roots of each toolkit will decide its look and feel as opposed to the platform itself deciding the look and feel according to the platform's native interface.
Shark populations may be declining, but it isn't a result of the reasons stated in the article.
First off, it is important to note that sharks are DANGEROUS. Sharks have been known to attack humans without provocation. In recent years their shenanigans have included encroaching upon swimming areas of popular beaches. In the year 2002 their were an unprecedented amount of shark attacks. These attacks are a direct result of sharks, which are dangerous and unpredictable. A benefit of lower shark populations is decreased shark attack incidents.
Second, shark fin soup is absolutely delicious and the consumption of which should be encouraged not discouraged. Shark fins are not gristle as the article poster just blithely mentioned. It is primarily collagen which becomes gelatinous and tasty in soup or stir fry. Another thing to note is that species that turn out to be tasty also turn out to increase in population in the long run. Their are millions more cattle now than one thousand years ago. The same goes for chickens and pigs and turkeys and other meat animals. Harvesting sharks for food can only lead to increased populations.
That of course is a dilemma, but one that can be worked around by FARMING sharks. This way sharks can increase in population and feed hungry people without becoming a hazard to swimmers, surfers, and other innocent humans.
It would be prudent to make sure that the server can withstand a building falling on top of it, no?
As it is UL being pulled into the markets. And though the article has a couple instances where UL is being brought in as test servers, there is no evidence of a wide-scale demand for Linux to replace existing telecom servers.
Linux has always been a small-scale server OS, best used for printer sharing, file sharing, and web serving. It can be loaded onto big iron without much trouble, but it still suffers performance (in the general sense of the word, not just speedwise) issues compared to commercial big iron Unix.
I'd just like it to be known that I do not shit on my HDs.
I do attempt to smear blood on the drives, though.
And I may have once ejaculated on a platter, but I was young and I needed the money.
Right inside your Recycle Bin there's the option to recover any program that you've deleted.
It's like magic!
Perhaps this story isn't so much a warning to hard drive discarders than it is a indictment of the American revolving credit infatuation/problem.
These previous users had a problem.
I only sell broken ones.
Java isn't interpreted. It's compiled to bytecode classes. Then those classes are pre-compiled to native code when run.
You are really talking about a specific VM when you say such a thing. It is widely known that Java VMs do not have to turn anything into machine code as a prerequisite to running Java code. It is specific implementations of the Java VM that compile everything to native code before running.
Several VMs do not compile the bytecode at all and simply run the program from an internal command tree. Several other VMs only compile frequently-used code regions into native code. Others turn the whole shebang into a giant binary executable before running.
It all depends on the VM. You can't really make such broad statements.
A runtime is a binary library that exports certain functions. The Win32 and glibc runtimes are a couple that Slashbots are probably somewhat familiar with. They have specialized routines that facilitate some kind action that the language itself does not directly support.
A VM is a completely different beast. It is a complete runtime environment for your program. Whereas a program that uses a runtime is typically compiled into machine code, a program that uses a VM is typically compiled at runtime from source (Perl) or parsed into memory from bytecode (Java).
It has become fashionable to call runtimes "VMs", especially in the Unix world where multiple APIs are supported on the same kernel, but it is a misnomer. (You'd expect the pedantry that is so prominent in the Unix culture to correct this, but I digress.)
12 minute cycles?
12 is divisible by 1, 2, 3, and 4?
12 is the number of apostles?
Just coincidence?
The mind boggles!
There will be flying cars to take us to and from work.
In it, Larry proposes that I judge the outcome of his bet and the future of
his job. I accept, and pledge to be a fair and reasonable arbiter.
(Although I suspect Larry may not have to worry much about condition (a).
This is just a hunch, but I believe that Congress is more likely to approve
legislation restricting sexually explicit spam than a bill mandating "ADV:"
or its equivalent.)
Declan realizes off the bat that this is a false bet. There is no chance that condition (a) will be satisfied, so Lessig has in essence wagered nothing.
If you want to call your platform ELC-approved, you need to pay a licensing fee.
It just doesn't seem like it's worth the hassle.
Does the consortium have a suite of automated tests that can verify that the platform was implemented correctly? If not, this is still a lot of smoke and mirrors, especially so because people have been making embedded Linux devices for quite a while based on their own needs (Tivo).
If Congress doesn't pass his proposed bill, he resigns.
Now anti-venom! Is there anything these miracle chickens can't do??