Slashdot Mirror

That's right, all of the best software engineers in the world are working for Sun and everyone else is on crack ... and Linux is losing to Solaris in such a big way on Wall St. and Sun have been able to keep using their same old development methodologies, don't change what works right?

You're right. Some of the best software engineers in the world are working for Sun. Sun's been hammered in the market place because it didn't react well to the dot-com bust. No layoffs, no significant restructuring or refocusing for years. Everyone cut margins and moved to commodity hardware, except Sun. (Note - Times have changed, see Galaxy and Coolthreads lines) The fact that Linux is "great" is precisely because it adheres to many of the design principals of a Unix-type Operating System and because it's free -- as in freedom, not beer. I also happen to think the BSDs are great, and that they've contributed a lot to the F/OSS community. But if you can't see all the amazing things coming out of the Open Solaris project that I just wish was in Linux, then there's no use even discussing it with you.

Sun has it's problems, but the engineers there are not one of them, and frankly you seem to be implying that they re somehow trying to impede progress or shut developers out of Open Solaris. On the contrary, they're working with Open Solaris contributors every single day. Let's not confuse high standards with a lack of enthusiasm for community building.

By your logic, Microsoft operating systems must be technically superior to Linux, because of both profit margin and marketshare right?

There will come day where we expect our compilers to encode parallel information into the code so it will run faster on our 1024 core machines. Interprative languages are going to be struggling to do that "just-in-time" like they struggle to do any optimizations now "just-in-time".

Which you will see is possible, once you get away from your preconceptions.

I knew this conversation would be full of misconceptions as soon as I saw that it classified non-native languages as "interpreted/JIT". Runtimes like Java and .NET have not been based on either interpreters or Just-In-Time compilers for almost a decade. They use dynamic compilers which optimize on the basis of what the program is actually doing. This is something that no C++ compiler can do. This kind of optimization can result in "interpreted" applications that are actually faster than native apps. Not always, of course — it depends on what kind of application you're running. But it does happen.

Also the notion that optimization is about producing the most efficient machine language possible has been obsolete since about the time they stopped using Z80s in PCs. Software applications nowadays are more than symbol crunchers: they consist of complicated I/O and network components, which have to work together for the app to run efficiently. And adding multicore processors to the mix does not reassert the importance of micro-optimization. Quite the opposite: a multicore application is a concurrent (what people used to call "multithreaded") application. Actually, concurrency has been important ever since processors got so painfully fast — but now that the Mhz wars have been replaced by the multicore wars, concurrency is 10 times as important. And the best native code compiler on the planet does nothing to help a concurrent program run better. Only a good concurrent runtime can do that.

When early releases of the Java runtime ran so slowly, everybody blamed the fact that it was based on a simple bytecode intpreter. That was certainly part of the problem, but there were many other parts. One of these was the fact that Java's concurrency API was absurdly primitive and inefficient. That's no longer the case. And with a modern, powerful concurrency API, the Java runtime can handle your umpteen-core systems as well as any native code runtime.

Hey buddy, it's time for you to sit yo' ass down, warm up the chair, and learn how to set up and use JumpStart(TM) to deploy Flash(TM) archives.

Installation lasts a few minutes, literally. Systems are deployed and configured fully automatically, without human intervention.

If you use just the JumpStart(TM) framework, you get to write rulesets selecting (or deselecting) exactly which packages you want (or don't want).

http://docs.sun.com/ is that way.

And BTW, there's a far better and more powerful shell than that bash PoS. It's called tcsh, the Tenex C-shell.

Choose one of the distros below - Schillix, BeleniX and Nexenta all have live CDs available in order to try
things out.

Solaris Express
http://www.sun.com/software/solaris/solaris-expres s/get.jsp

Schillix
http://schillix.berlios.de/

BeleniX
http://www.genunix.org/distributions/belenix_site/ belenix_home.html

NexentaOS
http://www.gnusolaris.org/

marTux
http://user.cs.tu-berlin.de/~mbeinsx/marTux/

What if /usr is down or needs a low-level fsck? I've always been told that that would mean you are totally screwed, unless you have static binaries in /.

1. By default, all UFS slices have logging enabled in S9+patches and up. The chances of requiring to do a low-level fsck are fairly remote.
2. If you do lose /usr, chances are good you're going to want to recover it from backup anyway just to be on the safe side.
3. In most cases, / and /usr are on the same disk. If you lose one due to hardware failure, you're probably going to lose the other one too.
4. As I mentioned in another post, all of the vital bits that were in /usr/lib are now in /lib.

Another option is to utilize and plan for using LiveUpgrade. That allows you to 'clone' your running OS onto other slices, perform upgrades on them, patch them, etc, while the system is running... your only downtime is the time it takes to reboot. If for some reason /usr fails, you can reboot onto your alternate root copy and then do repairs.

Make then entire system available as a pkg-get repository, not just the blastwave contributed programs. I don't want to download 4 cds of nonsense. Let me have one CD for a base install and ftp just the parts I want with pkg-get.

pkgadd, BTW, also supports quite a few URL constructs (e.g., pkgadd http://blah/blah). In this form, the other end of the pkgadd has to be a package stream, however, so that limits its usefulness with the DVD contents.

I haven't done any X-based installs, but my main bitch with the console install is that it is fairly inflexible. You get four options for package selection 1)really stripped down 2)stripped down 3)everything, 4)everthing plus OEM drivers. Finer grained control in package selection would be nice. Also nice would be a task-based pre-canned install set a la tasksel in debian or like what anaconda gives you in RH. Example: selecting a DNS task would install BIND but not X.

Please add some polish and make the default paths sane. Yes, I know this is a minor thing, but why do I have to spend several minutes adding /opt/sfw/bin:/usr/bin/:/usr/local/bin to my skel and .profile

Would somebody please statically compile bash already? I've scoured google and I can't find one. Yes, I know sh and ksh, but I prefer bash and think it to be more capable and easier to use. It would be nice to have it available in single user mode.

Make then entire system available as a pkg-get repository, not just the blastwave contributed programs. I don't want to download 4 cds of nonsense. Let me have one CD for a base install and ftp just the parts I want with pkg-get.

pkgadd, BTW, also supports quite a few URL constructs (e.g., pkgadd http://blah/blah). In this form, the other end of the pkgadd has to be a package stream, however, so that limits its usefulness with the DVD contents.

I haven't done any X-based installs, but my main bitch with the console install is that it is fairly inflexible. You get four options for package selection 1)really stripped down 2)stripped down 3)everything, 4)everthing plus OEM drivers. Finer grained control in package selection would be nice. Also nice would be a task-based pre-canned install set a la tasksel in debian or like what anaconda gives you in RH. Example: selecting a DNS task would install BIND but not X.

Please add some polish and make the default paths sane. Yes, I know this is a minor thing, but why do I have to spend several minutes adding /opt/sfw/bin:/usr/bin/:/usr/local/bin to my skel and .profile

Would somebody please statically compile bash already? I've scoured google and I can't find one. Yes, I know sh and ksh, but I prefer bash and think it to be more capable and easier to use. It would be nice to have it available in single user mode.

As much as I'd love to love Java, and as much as I know most people would if it truly delivered all that it promised, there are a lot of issues with it that can tend to cause problems. One example that bit my company:

Our company writes and sells a large medical imaging archival system, and one of the components of it is a web-based front-end using Tomcat, which accesses the backend database for pretty much everything.

Recently a feature was added to our software which opens a database connection to the various other servers in the system to check the status of their queues. This worked fantastically in testing, but when it was deployed, we found sites whose frontend became completely unresponsive.

After some digging, our developers found these:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =4263113
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =4912686

The long and the short of it is that JDBC calls (DriverManager.getConnection()) are sychronous, meaning that you can only be opening one connection at a time. This works fine in an ideal circumstance, but if one of the hosts you're trying to connect to happens to be off the network, then all threads in all apps in that JVM have to wait before they can open a connection.

As a result, when our background thread cycles through the databases to check the status of their queues and comes across a down server, DriverManager.getConnection() blocks - for three minutes! - while the TCP connection times out. This means that our entire application locks up completely, since every action requires a database connection. Sun's response?

'Introducing a change such as this risks breaking existing applications that have come to expect this behaviour.'

I like Java, but problems like this are just absurd. In C, I could either rewrite the library, or (preferably) change the source of the existing library. Failing that, I could fork separate processes instead of threads (ugly and inefficient). In Java, I don't have this option, because it affects the entire JVM. Fortunately, there is a workaround, but it's not a particularly fantastic one.

Java/C#/etc have a great deal of benefits over C/C++/etc, but there are always going to be problems as long as someone else decides what should be fixed and how. The real question is whether or not, for your application, the benefits outweigh the (potential) drawbacks.

As much as I'd love to love Java, and as much as I know most people would if it truly delivered all that it promised, there are a lot of issues with it that can tend to cause problems. One example that bit my company:

Our company writes and sells a large medical imaging archival system, and one of the components of it is a web-based front-end using Tomcat, which accesses the backend database for pretty much everything.

Recently a feature was added to our software which opens a database connection to the various other servers in the system to check the status of their queues. This worked fantastically in testing, but when it was deployed, we found sites whose frontend became completely unresponsive.

After some digging, our developers found these:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =4263113
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =4912686

The long and the short of it is that JDBC calls (DriverManager.getConnection()) are sychronous, meaning that you can only be opening one connection at a time. This works fine in an ideal circumstance, but if one of the hosts you're trying to connect to happens to be off the network, then all threads in all apps in that JVM have to wait before they can open a connection.

As a result, when our background thread cycles through the databases to check the status of their queues and comes across a down server, DriverManager.getConnection() blocks - for three minutes! - while the TCP connection times out. This means that our entire application locks up completely, since every action requires a database connection. Sun's response?

'Introducing a change such as this risks breaking existing applications that have come to expect this behaviour.'

I like Java, but problems like this are just absurd. In C, I could either rewrite the library, or (preferably) change the source of the existing library. Failing that, I could fork separate processes instead of threads (ugly and inefficient). In Java, I don't have this option, because it affects the entire JVM. Fortunately, there is a workaround, but it's not a particularly fantastic one.

Java/C#/etc have a great deal of benefits over C/C++/etc, but there are always going to be problems as long as someone else decides what should be fixed and how. The real question is whether or not, for your application, the benefits outweigh the (potential) drawbacks.

it depends on what you need, an interpreted laguage will always need more memory and resources than a native code, even the JVM is made with c++ and drivers are too as well, and c++ is portable enough (java is more portable just because you doesn't need to recompile for any cpu you use).

Now, in the modern world companies not only program for the PC but there are servers, handhelds, cellphones and another apps where the memory really matter, for example: compare the available apps under a mobile device which uses brew apps (verizon mobile for example) and those which j2me apps (sprint or virgin); at this level (mobile apps) is not a good idea to use java "because it is portable" because most of those phones has the same kind of cpu (arm9 or arm7) and even if those where different you would need to modify your app because every phone has different specifications (display screen, sound support, memory, etc), in which case has no sense at all because you still have to modify your source code for each device.

At the PC, it is not a good idea to have your 1gb-sized app made in java it would be a waste of resources for example netbeans, let it open for 4 hours and see how much your memory is consumed (leaks?) I have seen lot of cases where simply closing the app is not enough and you have to reboot the pc, I would never say a customer "Your app is slower because it was done in java in order to have it more portable", another thing is you can't develop drivers or operating systems under an interpreted language, (no, not even vista, the core is not develop in an interpreted language).

the worst thing about native languajes is (IMAO) you have to be confident about the VM, if the VM has a vulnerability or a memory leak then you have it unless you use a jit compiler (which had to be developed under a native language).

Some apps would convine native code with interpreted code (http://java.sun.com/j2se/1.4.2/docs/guide/jni/JNI ) where heavy or vital process are implemented under a native code and the common process are done with java or other languages, but this kills the portability of the application :) .

We need a decent ubiquitous 3D plugin for things like showing off stuff you can buy in 3D.

Java3D works nicely... http://java.sun.com/products/java-media/3D/

• Sun Microsystems Solaris and Linux Training
• IBM AIX Training
• IBM Linux Training
• HP's HP-UX Certification Training
• HP's Tru64 UNIX® Training
• Red Hat Training
• Novell SUSE Linux Training
• HP's NonStop UX Training
• Apple's Mac OS X Server Training
• And, if you're really sick... SCO's SCO UNIX Training

Solaris is bad example ;) It's properly supported OS. I will cite Alan Hargreaves:

  Solaris 2.6 was released in February 1997. Last ship was July 2001. It drops off support in July this year. That makes for nine years of support, the first six of which were complete with rfe and cosmetic bugs being fixed.

How about Solaris 8? Solaris 8 was released in March 2000. We have still not done that last ship for it, so this means that there will be phase one suport for at least until mid 2008, and phase 2 support until at least mid 2011. Folks, that's 11 years and still may be more depending on when we have the last ship of Solaris 8.


Old age don't exclude OS from getting proper support. Microsoft is just beeing lazy and greedy. They want to force upgrades on people. Too bad Win98 was good enough OS for many, many people. They don't need anything above (ME, XP, Vista). Now MS is playing dirty tricks.
It's funny how MS is saying ,,our Operating System suck''. Similar to their ,,Office dinosaurs'' campaign (discrediting their own office suite!).

But Sun doesn't even publish source

That's FUD, pure and simple - the source is available for download right on the same page as the rest of the JDK download links. You have to agree to one of two licences and have a (free) Sun Download Center account to get it, but it *is* available.

NForce support for a 1U rack mount server using Linux? Try http://store.sun.com/ or http://www.sun.com/servers/entry/x4100/specificati ons.jsp/ - their 1U X2100 and X4100 systems are cheap, fast, 1U Opteron boxes based around NForce chipsets.

NForce support for a 1U rack mount server using Linux? Try http://store.sun.com/ or http://www.sun.com/servers/entry/x4100/specificati ons.jsp/ - their 1U X2100 and X4100 systems are cheap, fast, 1U Opteron boxes based around NForce chipsets.

Quite frankly, for something like Flickr, I wouldn't mind running a client app as long as there's an easy, reliable way of updating it (like what's implemented in Firefox - binary diffs). That app, however, must run on three platforms in order to work for me, because I use Mac OS X, Windows and Linux.

For $50 you can get a USB keyboard from Sun either PC-style or UNIX-style (X3738A) layouts. Just drop X3738A into Sun's store and there you go. It's hard to find any other way. It has gobs of extra keys, and the extra keys work great on Macs (like the volume, power and help key) and can be made to work on Linux. I haven't figured out how to get the volume keys or additional F-keys to work on Windows.

Word of warning, the X3738A is a massive keyboard. it has f-keys on the top and on the side. It has esc where ~ normally it, it has ~ where backspace normally is. And of course ctrl where caps lock normally is. Having esc right above TAB is rather nice for vi. the position of \ and ~ and backspace might set some people off. (you can certainlly get the PC layout version instead). the keys are slightly shallower than most keyboards, and they have a tiny amount of resistance and then quitely pass and are easy to press. it teaches you to type more lightly which can dramatically reduce hand and wrist pain.

I've destroyed a few of them with beer and with water. I've also repaired a few that have been completely full of water all night (cat knocked a waterbottle ontop of it, it filled the keyboard up to the brim and sat there all night). taking it apart and rubbing any black corrossion off the celephane membrane with a scouring pad of emory cloth seems to be the way to go, just don't crack the delicate traces or entire sets of keys won't work anymore (an expensive conductive paint pen is needed to repair that).

I don't believe in buying $7 keyboards anymore. my gf still goes for those super cheap ones, she wears the letters off and puts deep groves in the keys from all the typing she does. I don't understand how she doesn't kill her hands with cheap ass keyboards.

Oh yeah, and the search in multiple frames function is broken.

And do not tell me frames suck... they ARE being used and the functionallity is broken.

I've yet to see an API explain their underlying algorithims

The documentation for Java SE collections gives some guarantees about running time. For instance, adding an element to an ArrayList is O(1) amortized, and searching a TreeMap is O(log n). In fact, TreeMap documentation states that it uses a red-black tree.

This is a thin client, not ultra-thin. It still has an OS, and a bad one too. And is more expensive than the ultra-thin stateless client from SUN. The server side software runs on Solaris and Linux and the ultrathin goes for $249, you can find used for around $100.

http://www.sun.com/sunray/sunray2/

Disclosure - I am a Sun employee. Hopefully unaffected by this move. I am speaking for myself here, not for the company.

Having said that, this is a targeted cut. Not a cheese-paring '10% everywhere' as has happened in the past. The execs have taked a hard look at our business and decided that we'll focus on what makes sense for Sun. Areas that don't make the cut will be, well, cut. What's remaining will be left intact.

In fact, my group has open reqs that we are actively filling. Unusually, these are entry-level positions. If you're fresh out of college and want to 'live in interesting times', as the Chinese proverb has it, then take a look.

Cheers,

Pat

Disclosure - I am a Sun employee. Hopefully unaffected by this move. I am speaking for myself here, not for the company.

Having said that, this is a targeted cut. Not a cheese-paring '10% everywhere' as has happened in the past. The execs have taked a hard look at our business and decided that we'll focus on what makes sense for Sun. Areas that don't make the cut will be, well, cut. What's remaining will be left intact.

In fact, my group has open reqs that we are actively filling. Unusually, these are entry-level positions. If you're fresh out of college and want to 'live in interesting times', as the Chinese proverb has it, then take a look.

Cheers,

Pat

Or you could just get one of these . Doesn't fit in a wall socket, but it's a full-fledged thin client (doesn't require a "terminal server" [how quaint!] environment). Also doesn't come with keyboard/mouse/monitor (supports DVI or VGA). Not sure what the advantage of either of these is, but I guess if you need them, they're nice to have. Actually, the one I listed supports smart cards, so it's handy if you move around a lot (your session gets switched to whichever node you plug your card into, kind of like using VNC). For $250, you might be able to make a case for thin clients, but for $400, it's a bit tougher.

Jonathan Schwartz's blog says a lot more behind the decision to cut the 5,000 employees. You may or may not agree with the decision, but it's far more informative about the direction Sun is heading in than the /. submission link.

http://blogs.sun.com/roller/page/jonathan?entry=ph ase_2

Project Semplice brings people with Visual Basic skills to Java the cost-effective way.

The whole point of DTrace is that it allows you to gather information
that you couldn't obtain before. See some examples here:
  http://blogs.sun.com/roller/page/bmc/20040805
here:
  http://users.tpg.com.au/adsln4yb/dtrace.html#OneLi ners
and here:
  http://www.sun.com/software/solaris/howtoguides/dt racehowto.jsp

Declaration of interest: I work for Sun, use DTrace, demonstrate it and
see the expressions of stunned delight on the faces of people
when they suddenly recognise its power.

The whole point of DTrace is that it allows you to gather information
that you couldn't obtain before. See some examples here:
  http://blogs.sun.com/roller/page/bmc/20040805
here:
  http://users.tpg.com.au/adsln4yb/dtrace.html#OneLi ners
and here:
  http://www.sun.com/software/solaris/howtoguides/dt racehowto.jsp

Declaration of interest: I work for Sun, use DTrace, demonstrate it and
see the expressions of stunned delight on the faces of people
when they suddenly recognise its power.

The CDDL under which the code in question was released is a slightly modified version of the Mozilla Public License. So if you used Mozilla or firefox or whatever to post that screed, then you've clearly sinned against the church of RMS.

Oh, and the CDDL IS an OSI approved license, so that means DTrace IS (by the definition most programmers who don't wear Birkenstocks agree on) Open Source.

As a developer, if you value your work, the GPL is the better license under which to release code, as it means no-one can take your work, close the source, and sell it as their own.

CDDL Section 3.1:

Any Covered Software that You distribute or otherwise make available in Executable form must also be made available in Source Code form and that Source Code form must be distributed only under the terms of this License. You must include a copy of this License with every copy of the Source Code form of the Covered Software You distribute or otherwise make available. You must inform recipients of any such Covered Software in Executable form as to how they can obtain such Covered Software in Source Code form in a reasonable manner on or through a medium customarily used for software exchange.

Give me a moment, and I'm sure I'll think of one.

lol java on the mars rovers...

That actually made you laugh out loud?

Not sure what the big deal is. They already use java to control the things.
old news.

We're now making serious progress on open sourcing Java (and despite the cynics, using a GPL license is very much *on* the table), while focusing the debate on what matters most: not access to lines of code (that's already widely available), but ensuring compatibility.

Because Java's syntax is enough like C++ that many C++ veterans are desperate to see it have all the ghastly "features" of C++ that make C++ a nightmare to maintain. Go look at the Top 25 Requests for Enhancement: operator overloading and chdir are still getting votes from those veterans. And then there's all the requests for const by C++ veterans who can't grasp the immutability pattern.

Because Java's syntax is enough like C++ that many C++ veterans are desperate to see it have all the ghastly "features" of C++ that make C++ a nightmare to maintain. Go look at the Top 25 Requests for Enhancement: operator overloading and chdir are still getting votes from those veterans. And then there's all the requests for const by C++ veterans who can't grasp the immutability pattern.

Because Java's syntax is enough like C++ that many C++ veterans are desperate to see it have all the ghastly "features" of C++ that make C++ a nightmare to maintain. Go look at the Top 25 Requests for Enhancement: operator overloading and chdir are still getting votes from those veterans. And then there's all the requests for const by C++ veterans who can't grasp the immutability pattern.

Because Java's syntax is enough like C++ that many C++ veterans are desperate to see it have all the ghastly "features" of C++ that make C++ a nightmare to maintain. Go look at the Top 25 Requests for Enhancement: operator overloading and chdir are still getting votes from those veterans. And then there's all the requests for const by C++ veterans who can't grasp the immutability pattern.

Yeah, he mentions it in the article but doesn't explain it and I have never heard of it before this article. I don't see any sort of non-disclosure agreement in the licensing, infact I see quite the opposite in the SUN COMMUNITY SOURCE LICENSE Version 2.3 (Rev. Date Sept. 29, 2004)

http://java.sun.com/j2se/1.5.0/scsl_5.0-license.tx t

It has language like this:
compile, reproduce and distribute Original Code and Upgraded Code in Executable form, and Reformatted Specifications to anyone for Research Use by You.

IANAL but it appears to allow one to commercially distribute changes with some restrictions to compatibility:

b) Distribution of Executable Code. You may distribute the Executable version(s) of Compliant Covered Code under a license of Your choice, which may contain terms different from this License, provided (i) that You are in compliance with the terms of this License, and (ii) You must make it absolutely clear that any terms which differ from this License are offered by You alone, not by Original Contributor or any other Contributor.

No where do I see any mention of non-disclosure. If anything, it just seems like double speak on Stallman's part to generate confusion.

There's conditions that require you to make fixes to the code freely available and jump through some hoops of standards. Granted it's not as "free" as EMACS, but if it had been J++ would have taken over and we'd be stuck with a third rate standard that would only work with M$ products since only their virtual machine would work with J++ and the vision of write once, run anywhere would be much further away than it is today.

Wrong. The current eBay implementation was designed to use Java, not haphazardly pulled into it. http://www.sun.com/service/about/success/ebay5.htm l

From a discussion on BayPiggies about MVC:

Someone wrote: "a lot of the related literature seems to use MVC as the canonical example of a design pattern"

MVC is the canonical example of the "Cargo Cult" design pattern of blindly aping Smalltalk without understanding it or considering if there are any more appropriate design patterns.

http://en.wikipedia.org/wiki/Cargo_cult

I've never heard a good explanation of what a "controller" is really supposed to do (other than entangle brittle dependencies between the view and the model, and allow programmers to bill for more hours maintaining the code). But people always throw in that extra "controller" class and its requisite complexity, just because Smalltalk uses them, and it doesn't feel right imitating Smalltalk without the whole MVC trifecta.

Just because MVC is a commonly used and cited "pattern" doesn't mean it's the best one to use in all cases. It's better to have a "purpose" than a "pattern".

http://osteele.com/archives/2003/08/rethinking-mvc

-Don

If all the messages between the model and the view have to go through the controller, then it sounds like a bunch of middleware glue to me. Maybe somebody should write a SWIG-like tool that automatically writes all your controllers for you, since it sounds like a horrible mess to have to write and maintain by hand. I prefer the KISS approach of not using controllers at all. Given any piece of software, there's always going to be a bunch of miscellaneous functionality and glue code that doesn't fit into the nice little boxes envisioned by the designers. With MVC cargo-cult designs, all that miscellaneous stuff gets thrown into the "Controller" class, so it's more appropriately called "Model/View/Etcetera".

MVC was originally designed for Smalltalk, which is a dynamic language with closures, so it just doesn't work as well with static languages like Java (which eventually had to fake closures with inner classes). Java programmers end up abusing controllers to make up for deficiencies in the language that aren't such a big deal in other languages (like dynamically dispatching named events to methods, persistence, scripting, and customizing methods and properties of individual objects, etc). They end up re-inventing little pieces of other languages like Smalltalk, Lisp and Python, and the poor Controller (Etcetera) ends up being where they dump all that glue code that would otherwise be built into the programming language and framework.

-Don

Smalltalk was successful for the same reason the Lisp Machines (including MIT's CADR, Symbolics' Genera, TI's Exploder, Xerox's Interlisp-D) were successful: they had a rich, wonderful, interactive programming environments, which supported exploratory programming, and let you examine, modify and debug the entire state of the system, from the user interface all the way down to the file system and networking. Smalltalk was also successful in that it inspired and influenced a lot of other important languages like Self, which led to the Java hotspot compiler: http://research.sun.com/features/tenyears/volcd/pa pers/ungar.htm

The Eclipse platform was heavily influenced by IBM's extensive work on Smalltalk, and it shows. Sun's doing themselves a lot of self-inflicted damage by boycotting Eclipse, not because it sucks or they have anything that can touch it, but simply because they can't take the joke about its name. (But that's how IBM planned it -- who said a big blue corporation couldn't have a sense of humor?)

More on the "Cargo Cult" design pattern: http://www.softpanorama.org/SE/anti_oo.shtml

-Don

The complexity comes from King Solomon's solution of dissecting the input ha

... and while you're at it, don't forget Sun's grid...

This comes up a lot on the Sun's Java Fourms and the response I always like to give that when learning Java you should avoid using a full-blown IDE until you can compile and run applications from the command line and use the online javadocs, otherwise you learn a tool, i.e. Eclipse, NetBeans, Intellij, etc., rather than the language and/or "how to program". Saying all that, I do think it's ok if students want to use an editor like JEdit or TextMate, that provides syntax highlighting and code formatting.

This and other technologies have found their way into Java 1.6. The implementation details are being dealt with. So what's your beef now?

To answer with your own quote: "Yes it is theoretically possible. And yet no one has done it. Stop talking about hypotheticals. We're talking about code that exists today, not in your wild imaginations." But I do agree the problems the JVM has aren't inherent to VMs in general. For example, OCaml's VM doesn't have these problems.

Check out this Flash demo for Java Studio Creator 2.1.

Assuming that the students already have a somewhat firm knowledge of Java, then all they need to be taught is how to set up a Tomcat server and how a tomcat server works (paths and such). Then simply refer them to the HttpServlet class. I think learning how the server runs and how it handles files is a lot more difficult than writing the actual code.

I seriously doubt the current implementation of Java would fit inside a 400 MHz x86 computer that's designed more to be energy-efficient and small than to be fast. If Java is to run on the OLPC computer, it needs a smaller, simpler implementation.

Check out http://java.sun.com/products/cdc/, it's for smaller computers than their regular J2SE. Here is similar stuff from IBM: http://www-128.ibm.com/developerworks/websphere/zo nes/wireless/weme_eval_runtimes.html.

I run this on a 400 MHz MIPS (Au1500 from AMD) and it works just fine. 400 MHZ x86 should actually be faster and, depending on available memory, may be better off running J2SE.

Basically, here are JVMs for cellphones, server farms and everything in between.

Besides the fact that there is already a JVM that implements the Real-Time Specification for Java and is available for free from Sun? There's even a introduction for it to help developers get an idea of just what it has to offer.

What the hell are you talking about? it forwards you to a Sun resellers site. I made a mistake. The link is Sunsolve.sun.com

You attitude towards the "weight and complexity" of Java is also out of date. Early versions of Java had a reputation (deserved, alas) for being bloated and slow. But nowadays, the Java runtime isn't any heavier or more complex than most of the runtimes you need to run most of the software out there. Even a C++ program, if it has any features had all, has a heavy-duty runtime. Besides which, the optimizing features of Sun's Java VM adds power, it doesn't take it away.

In any case, the specs of the $100 laptop are not that bad. Aside from lacking a hard disk, it's not much less powerful than a typical laptop sold in the US about 5 years ago.

The /. post mentions "support" from Debian, Ubuntu and Gentoo, but nothing more. A press release from Sun contains a quote from Anthony Towns:

"We are really pleased to see Sun's increasing involvement in the free software community, from the opening of the Solaris Operating System source and now the re-licensing of Java technology to be compatible with GNU/Linux distributions, and are looking forward to building stronger ties with the Sun community in the future", said Anthony Towns, Debian Project Leader.

Marketing speak from Debian? Anyhow, it does confirm that Debian is convinced this is open enough "to be compatible."

This may not be a popular sentiment here, but I think the statement the failure of open source Java
means that it can't be used on millions of $100, Linux-powered PC's ... to bring affordable computing
to children in developing nations is a bit of a cheap shot. The way it is stated, it makes Sun look
like some sort of terrible ogre, that is denying children access to computers, when it is the program
creator that does not allow Java on the laptops.

It is similar to the argument people make saying "corporations that make genetically modified food
are causing people in Africa to starve", in countries that forbid the import of genetically modified
food. The policy, not the companies making the food, are what is causing the lack of that particular
food to be used.

Don't get me wrong, it would be great if Sun made Java open source, but what they have now is not evil.
The software is free as in beer to use, and as such would add no more cost to the laptops, if installed, it would just conflict
with the philosophy of the program's founder.

Also, if you want to write your own JVM, Sun has written books to let you do just that.
It is not an easy project, it is similar to JBoss in complexity, but JBoss was written. If the CTO at
RedHat was that concerned about Java not being on the laptops, he could have part of his company work
on an open source JVM implementation. That company has a lot of resources, and would be more able
to manage a project of that complexity than several freelance developers in their free time.