Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
IBM

Quick Death for JavaOS 69

Posted by Roblimo from the another-one-bites-the-dust dept.
Bill Brooks writes "Sun and IBM announced that they are bailing out of working together on JavaOS for Business. If you've never heard of it, JavaOS for Business was a project that Sun and IBM agreed to work on together to produce a new version of an operating system that would run Java software on so-called 'thin clients.' The operating itself has only been around, in an embryonic form, since May of 1995, and the Sun/IBM joint venture started in 1997, shipping its first release in August of last year. A commercial operating system axed a year into its first release. Is M$ the only software company that can give a commercial OS time to find its market?"
This discussion has been archived. No new comments can be posted.

Quick death for JavaOS More

Quick death for JavaOS

Comments Filter:
  • Methinks the rise of Linux has a lot to do with this. If you a need a thin client to provide basic OS services to a JVM you don't need to look any further than Linux which runs on just about everything already, and is modular enough that it can easily be slimmed down as much as you need for each platform.

    As both companies now see Linux growing happily in similar niches it doesn't really make sense for either of them to be spending money on developing and maintaining yet another proprietary "open" platform.
    Consciousness is not what it thinks it is
    Thought exists only as an abstraction
  • The drivers are also written in Java. I think C was an option, but the idea was that you would be able to write your driver entirely in Java if you wanted to.
  • > Thin Clients are dead.

    My understanding is that in common parlance, the web browser is considered a "thin client". That being the case, I would have to dispute your above claim.

    Also, in the web development industry, Java is all the rage for building applications in the form of Servlets and (presumably soon) EJBs. In that industry, Java is vital.
  • Yes! I think I could write an ext2fs driver in two lines of perl code.. "Today PerlOS came out, written in an astounding 34 lines of code (with each line being approximately 80k characters long)
  • As others will most doubt suggest -- why not just stuff it atop a (possibly cut down) Linux kernel?
    John
  • I don't know where people here have their sources from, but javaOS isn't written in Java. The name was simply a marketing ploy, and to indicate the fact that it would have been "The best platform to run Java on".

    JavaOS was purchased by Sun. It was originally called ChaOS, by some french company. A small real time OS IIRC. Do a net search for it - there may still be some URL's left about it.

    Matt.

    perl -e 'print scalar reverse q(\)-: ,hacker Perl another Just)'
  • and I guess Star Divisions Java version (which is more of a Java-Client/C++-Server combo) is the main reason Sun bought them.

  • There is already an open source project called jos (http://www.jos.org). They could probobly benefit from this, of course.
  • Maybe I've had too much coffee this morning but I can't for the life of me understand why people keep trying to push this whole thin client thing down our throats. Sheesh...I think TC's are great for some industries but for the majority it will never be popular. So I'm glad they pulled the plug. Blah

    Why is it that companies like Sun can come up with these great ideas ( Java ) and then try to plug it into all of these areas where it doesn't fit. Why not let Java evolve a little first, then try to shove it down our throats :) I get so annoyed at all of the people who jump on the bandwagon everytime something new hits the streets...technology often times needs to mature before we can see the best fit for it. It's sad today that we are so driven by what's best for the stockholders and not what's best for technology.

    Imagine how badly tcp/ip would have been screwed up if it were developed by a company whose goal was to beat another company to the punch. Luckily when they developed tcp/ip the goal was to get it right. Look at how long it took ARPANET to evolve into what it is today...I'm sort of on a tangent here but some of these ideas just seem so bad that I have to wonder what drives these them.

    Now...I've got to get back to writing my real-time nuclear reactor web based monitoring system (Written in Java of course).
  • I think you are on the right idea, but might be missing the target.

    Yes a corporate desktop has dropped from around $3000-5000 to under $1500.

    This had led partly to the failure of Java.

    But on top of that, the problem with Java and the thin-client idea is that it relies on fat network pipes. While the costs of more powerful network hardware(gigabit ethernet, etc.) has come down... The main chunk of cost of deploying a better network primarily lies in rewiring the building. Replacing all your Cat-3 with Cat-5, bringing in fibre-optic cable, etc.

    And that cost hasn't gone down. The cable costs are about the same, and the labor prices have gone up.

    When you start deploying more and more computers in the organization, it doesn't make sense to place everything on your servers and then beef up your infrastructure. Not when computers are so damn cheap, and you can push and store the binaries at the client level.
  • Yeah, Be and BeOS have been around for some years now, but you have to wonder how much longer they'll have to make a go of their OS. They recently reported revenue growth, but their net earnings are still losing about a dollar per share. Their share price has dropped since their IPO.

    I really like BeOS and I hope it succeeds, but it doesn't look too likely that they can give their OS too much longer to find its market.

    --JT
  • definately the monitor ;) Who needs more than 12" anyways?
  • JavaOS was always a stupid idea. For example, it had almost no driver support. You couldn't print from it.

  • I never heard of it called "JavaOS for Business" so I don't know. But yeah, you definately have JavaOS on there. I wish I could mess around with JavaOS.
  • I've always wondered how difficult it would be to embed the Perl engine into the Linux kernel. Then people could use people to write their device drivers. Most device drivers just slice and dice data streams, which is exactly what Perl is great at doing!

    While not quite a PerlOS, some Perl Mongers are rewriting the classic Unix commands in Perl. It's called the Perl Power Tools: [perl.com]
    The Unix Reconstruction Project. Many Unix commands, like more, ls, grep... use C to dangerously reimplement functionality that is already in Perl. Using Perl would put an end to buffer overruns and other accidents in Unix commands, improving security.
  • I think this is the result of several things -
    at least one of which is Linux.

    But Sun and IBM certainly didn't help themselves
    any - there were not one, not two, but at
    least three competing products they were
    posing in varying guises as a Java OS:
    - JavaOS for Consumers
    The original - and I assume still continuing effort at an OS.
    - JavaOS for Business
    Dead
    - JavaPC
    Developed by Sun's Israeli division to
    "rescue" low-end PCs; an environment that ran on
    DOS, AFAICT.

    Oddly enough, the JavaPC idea had some features
    that made it superiour to its more marketed
    cousins, like the ability to use a local hard
    drive.

  • Thin Clients are dead. Check out the lovely work by hive.www.media.mit.edu or something like that. I never understood how they intended to empower people by thin clients in an industry where if you don't have the software and hardware you are nowhere and powerless. The Internet is not a storehouse for just e-mail, greeting cards, sports, stocks, and porn.
  • Perl is an excellent tool for CGI programming and other similar tasks where the system vastes a lot of time to communicate with some SQL server or open/close files.

    But using Perl engine to create slow-and-dirty drivers... Don't think it's a good idea.
  • Posting this a day late, so I'm not sure that anyone will read this :(

    One of the reason for Java not being as fast as C (apart from the fact that it is usually interpreted, not compiled) is that it is running on OSes (when i refer to OSes here, I mean OSes/Kernals) optimized for making C style code run fast, and some Java things will run inefficently because of this.

    To be more specific:
    (1) Most OSes don't have low level support for garbage collection. This means for example that the virtual memory model can't be easily tuned to use information that the garbage collector might provide about which pages can be swapped out. An OS with gc either built into it, or considered in the design may result in much faster gc.

    (2) In OSes with protected memory, calling any function in the kernal requires a context switch, and there is a lot of overhead required for context switches, and for managing this protection. A lot of the reason for this protection is because C is a dirty language that can do horrible things with pointers.

    This overhead slows Java down, when Java doesn't _need_ much of this sort of protection, because it is built into the langauge model that things like pointer arithmetic aren't allowed.

    (2a) A Java OS would only need threads, not full processes.

    (3) Java checks for errors at runtime like writing off the end of an array. Ok, there is not much that can be done about that overhead. This point is not relavant to my argument, but is added for completeness in explaining why Java is slow.

    Therefore, it is circular (i.e. incorrect) reasoning to say that because Java doesn't run fast on sytems designed for C, that Java is no good, therefore don't use it for an OS.

    If a Java OS was built that was tuned for Java, any C code that was run on it would have to be run in a 'sandbox' where things were protected against that process, and I'm guessing that in this case Java might well compare favourably with C.

    Aside: such a OS might be really good for LISP too, which has some similar properties.

    Another point is that Java code tends to be much less buggy (no buffer overflows, leaks, double deletes), so even if it is a_little_ slower, it is well worth using to get a more stable result.

    Disclaimer: I haven't been following JavaOS, so my arguments might not apply to that specific project.
  • I don't think it's that Microsoft is the only company that can afford to let a commercial OS find it's market. It's more likely reaction to the general development community realization that Java isn't that well suited to interactive user applications.

    Java has found a home in servlets, not applications.
  • Java will never be as fast as C. It simply isn't appropriate for an OS. I believe that the JavaOS was to be written mostly in Java, with device drivers etc. in C. However it makes much more sense to start with a functional, speedy OS (say, Linux) and wrap the kernel/libc functionality in Java code.
    --
    Man is most nearly himself when he achieves the seriousness of a child at play.

  • JavaOS (Score:1)

    by acid ( 78399 )
    Sun and IBM should have given javaOS more time and maybe promoted it better..

  • BEOS (Score:1)

    by rE^d ( 80118 )
    havn't BEOS been around since around some years now??
  • Well, i feel much better now. For a minute there I was afraid sun would make a Java version of Star Office. I feel much better now.:)
  • Star Division *already has* a Java version of StarOffice.
  • C will never be as secure as Java. C simply isn't appropriate for an OS.

    The assertion that Java will never be as fast as C is absurd. There are a number of issues that need to be worked out before "Java > C", but they are happening, incremental step by incremental step. (Hopefully this process will succeed before Java dies an unnatural death, but the effort will help other related languages that will follow). Java got big enough that the tremendous effort required to develop the needed compiler technology could finally be directed at a modern programming language instead of only at the hoary old relics Fortran and C.

    Oh and by the way, your statement should also have read "C will never be as fast as Fortran. It simply isn't appropriate for an OS."

    But the real criticism that I am currently wondering about is whether Java could be sufficiently better than C for reasoning about Real Time OS's. There are other languages much better than either. Multimedia is Real Time, and predictable and bounded execution times might be more important than speed. And "predictable-to-compilers" execution paths probably are likely to be highly susceptible to heavy optimization.

    While the apparent death of JavaOS is disappointing, it hardly spells the end of "Java in the Kernel".
  • Blah blah blah. Same old FUD.

    --

  • lets not forget the fact that they actually had a working JavaOS (proof of concept) It just wasn't marketable but that had nothing to do with performance. I would also like to point out that there are Java environments for palm computers and windows CE machines. Those are machines that are far smaller than the type of machine that the JavaOS was targeting (terminals with a nice processor and some memory).

    It seems everytime the word Java is dropped in a story on slashdot there are some persons who triomfantically claim that it will never be as fast as C. Apart from the fact this is irrelevant, I also think it's a false statement. Especially if there is going to be Java optimized hardware (like majc from sun) we might very well see Java programs outperforming the c variant. This is already happening on the serverside with the hotspot VM.

    Besides Moore's law as been active ever since Java was introduced in 1995. Computers are about 4 times as fast now. Also current Java VM's are far more efficient than they were in 1995. So please stop the speed whining whenever Java is mentioned.

    So a kernel built for 90% on Java is not a such a bad idea (from the point of view of performance). Especially if you want your kernel to be highly portable. Of course JavaOS was a bad implementation of this concept (lacking features).

    Somewhere in the story it is mentioned that:
    "Sun, meanwhile, claims that the widespread adoption of "Internet standards" have made both the JavaOS for Business and the Lean Client/Network Computer spec unnecessary."

    I think this is the bottomline. There no longer is a need for a pure JavaOS. In the past two years linux has become the portable operating system. The apps ontop of linux are also portable so there is no need to write them in Java. I think we are going to see a lot of linux/Java combinations on several types of machines (from servers to embedded stuff) in the future.

  • The first JavaOS was essentially a research project, writing an OS in Java to see what was missing from JDK 1.0 ... slow as all get-out. The outside world heard about it because Sun was crazy to pitch Java as usable for everything. (I mean that in multiple senses!) So it jumped straight from research to "product".

    The second JavaOS ("JavaOS for Business") was basically JDK 1.1 hosted on top of a real time OS that Sun had bought, "Chorus". Somehow that never got ported to enough different platforms to make Chorus a better choice than one of the better established real time OS configs. It was the right idea, but the core OS wasn't portable enough to be interesting to its target customers - they couldn't create commodity hardware and compete purely on the cost of the resulting "thin client" systems.

    Sun has a curious attitude towards Operating System Software. They want to own it, since if it integrates smoothly with their hardware, they can get some competitive advantages. It's not so odd, really, it's pretty traditional; but it's also far from their Open Systems for Open Minds roots. So they keep trying to do OS research to create some proprietary value. Going for a "big win" of some kind without understanding that customers still value the "open systems" model, still value the fact that Sun's competing on execution (and fumbles sometimes) rather than relying on vendor lockin. (They go to MSFT for that game.)

    The Spring OS was nothing but a research project, and it never performed well enough to make anyone really want to run it. But it got funded for years (instead of layered software products) as sort of a mascot for a proprietary OS technology. When Spring got canned, many of the same folk went to do JavaOS I (the research project), which got canned for the same reasons Spring did: it was a big, slow non-solution to a non-problem. So nobody would choose to buy it. It got forced down their throats as the guts of the first JavaStation, and they chose not to buy.

    JavaOS for Business wasn't needed either. Just take an off-the-shelf RTOS and slap a JDK on it. You're in business. Just -- Sun could never control that hardware infrastructure, it'd be too open. Great software model; but they want to make hardware money instead.

    Canning this project was overdue, and is no loss at all from the business or technical perspectives. None at all. (Though doesn't it make you wonder what will replace it? :-)

    - Jojo

  • Maybe ... there were two "JavaOS" products. Both got canned, this news is about the second one.

    Think of "JavaOS" as the name for the OS that ran on a particular kind of "thin client", which was called the JavaStation. JavaStation never really sold well. A big part of it was because all incarnations of JavaOS were pretty much crap.

    Other kinds of "thin client" can work better.

    - Jojo

  • They ought to... I mean, just because Sun/IBM couldn't "do" it, doesn't mean that the rest of the programming community couldn't.

    Then again, I can't/don't program, but if I did, I'd help out.

    And that, dear friends, is my $0.00002 worth.
  • The truth of the matter is that IBM is just one completely screwed up company. They cannot create ANY kind of excitement around any of their products. IBM is a complete loser when it comes to software. Look at OS/2: fantastic technology and a fantastic product (I use it every day), but the IBM leaders just could not get the entire company behind it. Same with JavaOS. IBM is a service company. Yes, they sell hardware and software, but they can't convince anyone to buy any of it. OS/2 is just one example. Did you know that they tried to create an office suite that would compete against MS Office?

    The hardware is no different. The PC Company lost $1B last year. That's a staggering amoung. And the people who make AS/400's don't do ANY marketing whatsoever - they don't even know how their products compare against other computers, because their marketing people just sit on their fat asses and don't do anything.

    I used to be a programmer at IBM, but I left disgusted. I can't understand how ANYONE would want to be a programmer at IBM - no one really gives a damn about your product, and entire multi-million dollar projects involving dozens or hundreds of people can easily get cancelled in one day.

    Don't blame JavaOS - it's a great idea. But the people at Sun who thought that IBM would stick with it are completely naive.

Slashdot Top Deals

One good reason why computers can do more work than people is that they never have to stop and answer the phone.

Close