Slashdot Mirror

Geesh people, Runtime morphing is NOT NEW. The company that Sun bought to do the Hotspot VM did it with Smalltalk YEARS before Transmeta.

Close enough. Sun didn't buy a company as far as I know. The technology comes mostly from the Self group at Sun. This is credited (but maybe not enough!) in the Hotspot whitepaper (try searching for 'Self').

[Begin shameful namedrop]When I was visiting the Self group in '96, they told me how frustrated they were that they knew how to speed up Java and couldn't get the Java guys to pay any attention... it was good to see that they got the message across eventually.[end shameful namedrop]

Dynamic optimisation is totally not new but there's always room for more research.

By the way Self is really worth checking out. How many environments let you change your inheritance at runtime? Or blitz the machine by visually manipulating the interpreter's settings?

RyanS

Geesh people, Runtime morphing is NOT NEW. The company that Sun bought to do the Hotspot VM did it with Smalltalk YEARS before Transmeta.

Close enough. Sun didn't buy a company as far as I know. The technology comes mostly from the Self group at Sun. This is credited (but maybe not enough!) in the Hotspot whitepaper (try searching for 'Self').

[Begin shameful namedrop]When I was visiting the Self group in '96, they told me how frustrated they were that they knew how to speed up Java and couldn't get the Java guys to pay any attention... it was good to see that they got the message across eventually.[end shameful namedrop]

Dynamic optimisation is totally not new but there's always room for more research.

By the way Self is really worth checking out. How many environments let you change your inheritance at runtime? Or blitz the machine by visually manipulating the interpreter's settings?

RyanS

Close enough. Sun didn't buy a company as far as I know. The technology comes mostly from the Self group at Sun. This is credited (but maybe not enough!) in the Hotspot whitepaper (try searching for 'Self').

When I was visiting the Self group in '96, they told me how frustrated they were that they knew how to speed up Java and couldn't get the Java guys to pay any attention... it was good to see that they got the message across eventually.[end shameful namedropping]

Dynamic optimisation is totally not new but there's always room for more research.

By the way Self is really worth checking out. How many environments let you change your inheritance at runtime? Or totally blitz the machine by visually manipulating the interpreter's settings?

RyanS

Close enough. Sun didn't buy a company as far as I know. The technology comes mostly from the Self group at Sun. This is credited (but maybe not enough!) in the Hotspot whitepaper (try searching for 'Self').

When I was visiting the Self group in '96, they told me how frustrated they were that they knew how to speed up Java and couldn't get the Java guys to pay any attention... it was good to see that they got the message across eventually.[end shameful namedropping]

Dynamic optimisation is totally not new but there's always room for more research.

By the way Self is really worth checking out. How many environments let you change your inheritance at runtime? Or totally blitz the machine by visually manipulating the interpreter's settings?

RyanS

A quick look at Google pulled up about 6,000 articles, mostly old. Have a look around, you're bound to find someone who knows something at these sites:

Here's an old slashdot article about Solaris8. From this article, I don't see Solaris8 on x86 becoming a hot development platform, but judge for yourself.

Here's an older looking page about sound on x86 hardware with Solaris.

Here's one from Gnome. This is one of the slickest desktops around. If it don't do sound yet, try KDE.

Look for atricles with your specific hardware and linux. I found out that MediaGX had some Linux sound support that way. It's just some hardware that I had. That sound was supported was luck of the draw. I'll bet you want better assurances than that. Sun has a forum for questions like this, here.

Hopefully, someone who knows something will answer your post. I'd like to know what you find, please post back if you learn anything useful.

A quick look at the right part of the Solaris x86 HCL shows a number of machines with more than 4 CPUs which have been certified as working with Solaris on Intel:

• Hitachi HA8000/380 UWRAID (8 CPUs, PII-Xeon-450) - one of three Hitachi machines of this size
• NCR WorldMark 4380 (8 CPUs, PP-200 1 MB)
• NEC Express5800-HX6100 (6 CPUs, PP-200)
• Zenith Data Systems Express5800-HX6100 (6 CPUs, PP-200)
• Intel OCPRF100 (8 CPUs, PIII-Xeon-550)

One of the reasons why there aren't more is that there aren't that many x86 motherboards with support than more than four CPUs.

That said, I'd prefer to use Sun hardware for more than four CPUs anyway - there is so much more to a system than the number of CPUs in the box after all.

It should be noted that in my article I didn't say that I'd only use x86 machines for SMP. There was also no mention of "heavy duty SMP" either. After all, when people talk about SMP on x86 systems, its rarely in the context of "heavy duty" :) Also, given the context of the original article - the use of Unix as servers in an office environment. Unless your office is very large or you're doing some large scale calculations or database work you're not going to need large scale SMP machines. You can make use of relatively low end x86-based machines to perform the day-to-day file and print serving - I wouldn't want a rather expensive 64 way Sun machine sitting idle doing nothing more than running samba.

IMHO I'd rather engineer systems which have a number of smaller machines than go for one large machine if possible. That said, this could be achieved using domains with the E10000 (or the domain software on a number of smaller machines).

Sorry, but I just have to chuckle when I see the man who picked Java for us over Self, getting all concerned about technology advances.

First, this is not a web-only service. We do like to provide web interfaces to as much as possible, but we do realize that for some things, program compliation and testing included, nothing can substitute for shell access.

A lot of people are asking about other hardware architectures and OS's. For now, the Compile Farm is i386 based, and contains several Linux distributions and FreeBSD. This does not mean that we have ruled out other possibilities. This is just another step in what we hope can be an expanding feature set for Open Source developers on SourceForge.

There is a lot of setup involved in something like this Compile Farm, not the least of which is having thousands of skilled Open Source developers with shell accounts on a set of boxes. We're attempting to keep things as secure as possible while also offering enough features to make this thing useful. One reason for the limited number of distributions/architectures/OS's now is the limitation of variables in a very complex system. Hopefully, we can work out the kinks in this system soon so that it can become a valuable resource to developers who might not otherwise have the capability of getting their hands on so many different machines.

Please be patient as we test this new system. We're definately open to criticism, but please also be constructive with it so that we can continue to improve these services. Thanks to all of the SourceForge users who have contributed patches, criticism, and helpful suggestions. Every day my confidence in the Open Source model increases...

That doesn't make it any less useful if you are stuck with a machine that doesn't have serial BIOS support.

I hope, however, that PC vendors will start to adopt the (open firmware standard). People are working on an open source implementation for PCs.

You are right in saying that having to package the same program n times because there exist n Linux distributions is annoying.

However I disagree with your comparison with the Unix situations. This comparison has been agressively fed to the press by Microsoft, although it is vastly inaccurate:

• Unix vendors (such as Sun, HP) sold proprietary operating systems running on incompatible hardware platforms. While paying lip service to API compatibility, they kept APIs very much incompatible with each other. Compiling a package on several of these systems meant maintaining a database of various weirdnesses.
• Linux vendors sell the same free operating system on the same platforms. They basically sell a copy of the same free software. APIs are mostly identical. Differences between distributions as for software programmers are minimal, and efforts are being made to lessen them (for instance, for configuration files).

I tried one out last friday, JSwat. I thought it was ok, but still needs quite a bit of work and is more geared toward loading the class itself and debugging locally then attaching to a running VM. But it can do that.

--

This glitch is well known, but there is a fix. Take a look at Sunsolve, (SRD B 20427). (Not sure if this is publicly available).

Like Java? [a C rip-off]

Sun openly admits that Java was heavily influenced by C++ (while Microsoft never mentions symbolic links in Unix!). Here are some quotes from the original Java White Paper:

When we started the project, we intended to use C++, but encountered a number of problems.

we tried to stick as close as possible to C++ in order to make the system more comprehensible.

The object-oriented facilities of Java are essentially those of C++, with extensions for more dynamic method resolution that came from Objective C.

See the difference?

To summerize, if you can start the servlet engine's VM in debug mode you can then connect to it with a remote debugger like jdb. You have to get the password from wherever the VM's standard out goes. The page I listed up above gives directions on how to do this with the JSDK's Java Web Server.

As far as other developement. I've been using iPlanet's iWS 4.1 beta. It works pretty good. I haven't tried setting Tomcat up yet, but on the Tomcat mailing list they are getting together a beta for version 3.1 which is VERY close to meeting the Servlet 2.2 specs and will be the reference implementation once it is done. The beta release canidate 1 should be up today.

As somebody else mentioned standard out and the servlet response are also good places to send information especially if you don't want to run your VM in debug mode or can't. One thing about iWS 4.1, I don't think the standard out and standard error are directed to a file by default. I had to open my own servlet logging files and redirect System.out and System.err to them myself from within a servlet.

For developement I use JBuilder on NT, and vim occasionally under linux. I have had no platform problems with moving my Java class files from NT to linux. On linux I am using the latest blackdown release of the JDK. In fact for one application I have the web server (iWS 4.1 beta) running under linux and it loads pre-compiled servlets that exist on an SMB mounted directory that exists on an NT machine. It hasn't acted any different from the web server running on NT with JRun as the servlet engine. (well I had some JSP problems, but that was a difference in implementation of the JSP specs between iWS and JRun)

--

• Traditional data processing, where XML encodes the data for a program to process
• Document-driven programming, where XML documents are containers that build interfaces and applications from existing components
• Archiving -- the foundation for document-driven programming, where the customized version of a component is saved (archived) so it can be used later
• Binding, where the DTD or schema that defines an XML data structure is used to automatically generate a significant portion of the application that will eventually process that data

Plus, bugfixes come quite quickly (usually on the order of once a month or so), instead of in two service packs a year.

No, you are incorrect. Take a look at: Java Request For Enhancements. The Java port was *by far* the number one requested enhancement ever. I am not saying there is anything wrong, just don't say Linux users never ask for anything from big companies.

--Ivan, weenie NT4 user: bite me!

It's usually the case that most programmers quite rightly leave this kind of thing to the underlying OS/platform. Which is fine until that is broken - check out this bug report at Sun (free login reqd). The vanilla 1.2 JVM for Unix was not able to parse "29 Feb 2000" into a Date object due to a very obscure bug introduced in Java2. There is a fix, but I know that at least a few people/companies got caught out.

See: http://developer. java.sun.com/developer/bugParade/bugs/4209272.html

1) Would the user want to book mark the information in the right hand frame? If IE 5 is your standard browser this is not an issue.

2) Would anyone want to send a url that links to one page on the right hand side of the app? For instance the help desk might want to send an email saying the new customer form is here http://ourbox/ourapp/newcust.html

3) If some one does link to the right hand page of the app with out the enclosing frame does it still work? see Java Docs with Frames. They uses frames but if you direct link to the main content area it is still useable see: Java Docs No Frames

4) What is the impact of frames on printing information form your app

These are some of the questions you would need to answer before you can say that your app is an exception to the rule that frames suck most of the time. -Peace Dave

1) Would the user want to book mark the information in the right hand frame? If IE 5 is your standard browser this is not an issue.

2) Would anyone want to send a url that links to one page on the right hand side of the app? For instance the help desk might want to send an email saying the new customer form is here http://ourbox/ourapp/newcust.html

3) If some one does link to the right hand page of the app with out the enclosing frame does it still work? see Java Docs with Frames. They uses frames but if you direct link to the main content area it is still useable see: Java Docs No Frames

4) What is the impact of frames on printing information form your app

These are some of the questions you would need to answer before you can say that your app is an exception to the rule that frames suck most of the time. -Peace Dave

"The Java virtual machine does not assume any particular implementation technology, host hardware, or host operating system. It is not inherently interpreted, but can just as well be implemented by compiling its instruction set to that of a silicon CPU. It may also be implemented in microcode or directly in silicon." from Chapter 1, the Introduction.

Since the JVM is responsible for garbage collection, this implies that the concept of implementing memory management in the hardware is at least 4 years old.

I find it hard to believe no one's thought of this idea before for C, C++ (and so on) either.

I wouldn't knock it till they try it or, at least, someone publishes some calculations that prove or disprove the possibility of major speed-ups.

I agree with you that it's a pain to have to do a cast on something the compiler ought to have figured out can't cause a type safety violation. Type polymorphism (ie, templates) is definitely the biggest thing missing from Java. Fortunately, they're adding it (see?). In fact, there's already an compiler that will do it- it's just not Sun-blessed. (But the .class files that GJ spits out are ostensibly bytecode-compatible with regular java, so no special JVM is required to run them.)

I agree with you that it's a pain to have to do a cast on something the compiler ought to have figured out can't cause a type safety violation. Type polymorphism (ie, templates) is definitely the biggest thing missing from Java. Fortunately, they're adding it (see?). In fact, there's already an compiler that will do it- it's just not Sun-blessed. (But the .class files that GJ spits out are ostensibly bytecode-compatible with regular java, so no special JVM is required to run them.)

2) Motherboards are overpriced. I honestly can't say I've ever priced a Sun Motherboard. There is no such animal.

Then what is the SPARCengine Ultra AXe-300. :) It is A Low Cost, High-Performance Motherboard for Thin Servers, Server Appliances and Configured Servers.

You can find a tech manual in pdf here .

Noel

RootPrompt.org -- Nothing but Unix

2) Motherboards are overpriced. I honestly can't say I've ever priced a Sun Motherboard. There is no such animal.

Then what is the SPARCengine Ultra AXe-300. :) It is A Low Cost, High-Performance Motherboard for Thin Servers, Server Appliances and Configured Servers.

You can find a tech manual in pdf here .

Noel

RootPrompt.org -- Nothing but Unix

• Later in the year, Sun's replacement for the Starfire, code named Serengetti will be launched. This will have
• up to 128 CPUs in one box, and you can cluster them (so that they appear to be 1 machine) using a special fiber interconnect, for up to 1024 CPUs, probably using a COMA memory structure (similar to ccNUMA), something Sun have been working on for many years.

You might also invest in a reference like O'Reilly's Java in a Nutshell; if you're comfortable reading on the computer, there's a CD version that includes the contents of several other Java books.

Also be sure to look over the downloadable references provided by Sun.

Around our company we usually recommend the two-book series Horstmannn and Cornell's Core Java. It's best if you know a language like C or C++ before reading this. These books are very well-written and they don't skimp on the hard stuff. One may wish to consider glossing over the increasingly deprecated AWT material in favor of some other book on JFC and Swing, when the time comes to learn GUI stuff.

I was quite skeptical about HotSpot's claims until I experienced it for myself. Having it or something similar for Linux would be a boon to Java programming, IMO.

There was a JavaLive chat yesterday about the Java on Linux stuff. They haven't put up the transcripts yet though.

For Java 1.3 from Sun, the Windows version will come out first, then Solaris then Linux. However, they do want to syncronise all releases together and should do this at or before Java 1.4 - might happen first for a maintenance release.

hmmm...

This microsoft "dot-truth" marketing summary
looks familiar. I think it's their answer to
sun's "reality check" that's been on their
site for years:

http://www.sun.com/dot-com/realitycheck/index.ht ml


The archives show several anti-windows articles.

Don't fret - these things are all coming back from the dead :-)

Check out Squeak Smalltalk or Self (now also on the Mac besides Sparc machines). Even GNU Smalltalk has come back from the dead and will be getting great JIT technology real soon now.

The Self page has moved to http://www.sun.com/research/self/index. html. (Actually, the entire 'SunLabs' tree has moved to http://www.sun.com/research, it appears.) The project is described as no longer being active, although the last release of Self, 4.1, was last month.

I find it hard to believe that Compaq would not run their website on their own hardware.

Uh... hello? &nbsp Why would you think that Solaris doesn't run on Compaq hardware? &nbsp From Sun's Solaris 8 page:

System Requirements

SPARC (32-/64-bit) or Intel Architecture (32-bit) platforms
Disk space: 600 Mbytes for desktops; 1 Gbyte for servers
Memory: 64 Mbytes minimum

It's being done by Sun with the picoJava and SPARC cores.

eg3.com has a list of Open Source hardware links.

Tom Coonan has donated a free 8-bit microprocessor core to the Open Source IP community. One interesting aspect of this is that you can "build it yourself" using an FGPA booted from an EEPROM you can burn yourself.

And speaking of FGPAs, Xilinx has a whole page of IP for downloading and burning into their FGPAs here. What makes this super-spiffy is that you can write logic for these things and program them yourself--they download the gate configuration logic from an external ROM (or EPROM) or other source. In fact, many people are using these things by downloading the gate configuration from other sources, such as a data file.

The Open Source Hardware community apparently is thinking along the lines of using FGPAs to experiement with creating a various open source microprocessor cores in order to get the bugs out. Once the bugs are out, you can then create an ASIC core from the same data files and burn chips for production. What makes this strategy interesting is that probably for around $500 (or less) in hardware, you can build your own test bed. In fact, I could see building an FGPA "loader" which is basically a 6502 and a UART chip connected to your serial port which contains all the logic necessary to boot and download logic into an FGPA from your desktop as a sort of "in-circuit" emulator.

But my hardware days are behind me, at least for now...

Sun's developer connection reports 9342 open bugs for java. Sun's Java has also been around for a while.

Bugzilla reports 5422 open bugs for mozilla. Granted mozilla is only alpha, but still.

Now if Microsoft really integrates everything into the OS as they claim, this bug count should include bugs for IE and their version of java as well. ;-)

In 1987 Sun Microsystems shipped a Networked Extensible Windowing System (NeWS) that was based on an object-oriented superset of PostScript.

Although that project is dead (sadly), part of it lived on in Java. One problem was that the Unix programming community did not embrace PostScript hcking. It's hard to debug, too. NeWS was also slow, although on a SPARCstation 20 (like a slow Pentium) it wasn't much slower than X for most things and faster for some others (e.g. it had better font support!).

There were some attempts to make publicly available versions of NeWS but I have not seen anything about these for several years. SinceI no longer keep the OpenWindows FAQ, maybe no-one told me, though :-)

The Berlin Consortium's project is the closest thing I'm aware of today, and at least some of the Berlin designers aer/were aware of NeWS.

The DPS/X extension is a shadow of NeWS, a toy by comparison. NeWX's Display PostScript is closer, better in some ways, although the NeWS language extensions seemed to me better done.

I agree with the StarOffice/MS Office analysis, which is why I brought up StarPortal. Although this may not be the perfect solution for large-scale enterprise yet, it is a great step in the right direction and it is free (in price).

HipNerd

Don't forget StarOffice.

They're not releaseing RPC source.

Yes, they are. Sun's announcement says:

NEW YORK, NY -- February 2, 2000 -- Sun Microsystems Inc. today made three important announcements as part of its ongoing efforts to advance the Internet through open standards: it is releasing the source code for a key component of the Network File System (NFS) protocol under the new Sun Industry Standards Source License; it will double the level of funding it began last year for a University of Michigan project to develop a Linux implementation of NFS version 4; and, finally, it will release its rights to the NFS trademark.

The Network File Sharing System (NFS) file access protocol - originally introduced by engineers at Sun Microsystems in 1985 - allows users the convenience of accessing and sharing remote files across the network. The key component of NFS that Sun is releasing to the open source community today is known as Transport Independent Remote Procedure Call protocol, or TI-RPC. TI-RPC is one of the foundations of NFS, and a key component of the security advancements in version 4. TI-RPC provides technology that allows developers to create efficient, network-scalable client-server applications.

(emphasis mine).

Now, they have, in fact, released pre-TI-RPC source, and older versions of the TI-RPC source, under a rather unrestrictive license; one of those is used in FreeBSD (and probably the other BSDs; I don't have 4.4-Lite source handy at home to check whether it had that source, but I think it did) for userland ONC RPC support. I don't know whether glibc has its own independent ONC RPC implementation for stuff such as NIS.

I suspect that one reason they're releasing the current version of TI-RPC is that it will presumably include an implementation of GSSAPI authentication and of the Kerberos V5 flavor of same, to use as a sample implementation, given the comments about TI-RPC being "a key component of the security advancements in version 4" (which I think might refer to stronger authentication than AUTH_UNIX a/k/a AUTH_SYS being required).

They're releasing the NFS interface/protocol.

"Releasing" in what sense? The NFS V2 spec and the NFS V3 spec (along with the ONC RPC spec, the XDR spec, the portmapper/RPCBIND spec, the specs for the DES and Kerberos (V4) authentication mechanisms for ONC RPC, the spec for the GSSAPI authentication mechanism in ONC RPC, and information on using Kerberos V5 as a GSSAPI flavor in ONC RPC) have been publicly available for a while. (The NFS specs also include the specs for the corresponding versions of the mount protocol, although they don't cover the small change Larry McVoy made to create V2 of the mount protocol; Sun screwed up and didn't put the lock manager protocol into the V2 spec, and the V3 spec only lists what changed between earlier versions and the lock manager V4 that goes with NFS V3, so for a while it was only available as part of an expensive X/Open document, but the "XNFS" document with it is now available online.)

They're not releaseing RPC source.

Yes, they are. Sun's announcement says:

NEW YORK, NY -- February 2, 2000 -- Sun Microsystems Inc. today made three important announcements as part of its ongoing efforts to advance the Internet through open standards: it is releasing the source code for a key component of the Network File System (NFS) protocol under the new Sun Industry Standards Source License; it will double the level of funding it began last year for a University of Michigan project to develop a Linux implementation of NFS version 4; and, finally, it will release its rights to the NFS trademark.

The Network File Sharing System (NFS) file access protocol - originally introduced by engineers at Sun Microsystems in 1985 - allows users the convenience of accessing and sharing remote files across the network. The key component of NFS that Sun is releasing to the open source community today is known as Transport Independent Remote Procedure Call protocol, or TI-RPC. TI-RPC is one of the foundations of NFS, and a key component of the security advancements in version 4. TI-RPC provides technology that allows developers to create efficient, network-scalable client-server applications.

(emphasis mine).

Now, they have, in fact, released pre-TI-RPC source, and older versions of the TI-RPC source, under a rather unrestrictive license; one of those is used in FreeBSD (and probably the other BSDs; I don't have 4.4-Lite source handy at home to check whether it had that source, but I think it did) for userland ONC RPC support. I don't know whether glibc has its own independent ONC RPC implementation for stuff such as NIS.

I suspect that one reason they're releasing the current version of TI-RPC is that it will presumably include an implementation of GSSAPI authentication and of the Kerberos V5 flavor of same, to use as a sample implementation, given the comments about TI-RPC being "a key component of the security advancements in version 4" (which I think might refer to stronger authentication than AUTH_UNIX a/k/a AUTH_SYS being required).

They're releasing the NFS interface/protocol.

"Releasing" in what sense? The NFS V2 spec and the NFS V3 spec (along with the ONC RPC spec, the XDR spec, the portmapper/RPCBIND spec, the specs for the DES and Kerberos (V4) authentication mechanisms for ONC RPC, the spec for the GSSAPI authentication mechanism in ONC RPC, and information on using Kerberos V5 as a GSSAPI flavor in ONC RPC) have been publicly available for a while. (The NFS specs also include the specs for the corresponding versions of the mount protocol, although they don't cover the small change Larry McVoy made to create V2 of the mount protocol; Sun screwed up and didn't put the lock manager protocol into the V2 spec, and the V3 spec only lists what changed between earlier versions and the lock manager V4 that goes with NFS V3, so for a while it was only available as part of an expensive X/Open document, but the "XNFS" document with it is now available online.)

Open Firmware is IEEE 1275. The home page is

http://playground.sun.com/1275/

The idea behind Open Firmware came from Sun during their transition from MC68000 CPUs to SPARC. Problem: two different CPU architectures, and you want to write add-in board device drivers just once, rather than N times for N different processors.

Solution: put an interpreter on the motherboard, written native for the processor on the motherboard, and write the drivers for the peripheral boards (which go into PROMs on the peripheral boards) in the interpreted language. This way, the system can boot from devices that were never envisioned when the motherboard was designed.

This is a standard that WinTel world would do well to adopt.

Open Firmware is IEEE 1275. The home page is

http://playground.sun.com/1275/

The idea behind Open Firmware came from Sun during their transition from MC68000 CPUs to SPARC. Problem: two different CPU architectures, and you want to write add-in board device drivers just once, rather than N times for N different processors.

Solution: put an interpreter on the motherboard, written native for the processor on the motherboard, and write the drivers for the peripheral boards (which go into PROMs on the peripheral boards) in the interpreted language. This way, the system can boot from devices that were never envisioned when the motherboard was designed.

This is a standard that WinTel world would do well to adopt.

It is not an Apache problem. It is not a Microsoft problem. It is not a Netscape problem. In fact, it isn't even a problem that can be clearly defined to be a server problem or a client problem. It is an issue that is truly cross platform and is the result of unforeseen and unexpected interactions between various components of a set of interconnected complex systems.

Sun also has the whole book available on the web, along with updates and errata. Just follow the appropriate links from http://java.sun.com/products/jlf/guidelines.html.

OOP concepts have been championed for about a decade now, and OO concepts have crept in all over the place.

Dude, objects and classes were put into SIMULA even before the first implementation of C was released. A decade? Try three decades.

SIMULA history

Solaris being freely available and open source is almost definitely an advantage to the community

Yes, if Solaris ever became "freely available and open source", that might be cool.

However, I've yet to see any signs of that happening; the term under which Sun have said they'll make source license available don't seem particularly like "open source" to me:

What can I do with the code?

Under the terms of the license, you are free to modify, compile and use any changes you make. Although there is no limit to what you may change, there are limitations on what you may do with those changes.

You may not redistribute any portion of the Solaris 8 source code internally or externally, which means you may not make copies or pass your CDs on to someone else. Similarly, although you will retain any intellectual property and other rights provided to you by law, you do not have the right to redistribute any portion of the Solaris 8 source code that you received from Sun. If you want to make your source code modifications available to other Solaris source code licensees, you can do so by passing the changes back to Sun, and Sun will then post them to a secure website that you and other registered users may access.

(emphasis mine).

I will take this opportunity to remind all fellow Daemons to register with Sun's Java Developer Connection and vote for the Java 2 SDK port to FreeBSD!

While there has been an official Linux port, there is no native Java 2 SDK for FreeBSD. Please, all members of JDC, go here and cast your votes to have Sun release this software. We are up to 2766 votes so far. It took 4551 votes before Sun released the Linux version, so we're almost there, right? ;-)

(However, I am well aware that the release of the Linux port was due in large part to the excellent folks from Blackdown.)

Here are a few of the tons of comments on the "bug report" page where you can vote for this RFE (request for enhancement).

• "FreeBSD is one of the favorite OS to run servers, and Java is becoming the favorite language to write server applications."
• "Daemon News supports this project. DN will also issue a certification if it runs well on BSD."
• "Due to the stability we use either Solaris or FreeBSD. It is very tiresome not being able to develop on FreeBSD for deployment on Solaris. Using solely Linux is not an option for me."
• "It's a pity that we can't develop on a OS that is very popular among small ISPs."
• "As has been said, not having Java ports for these platforms helps only Microsoft, and hurts the people Sun really seems interested in helping: the Open Source community."
• "With official support of Java2 on FreeBSD from SUN, I would be able to finally abandon NT platform and use my prefferd FreeBSD OS for most of my projects."

You must be registered in the JDC (Java Developer Connection) to vote. Registration is free and quick, so if you're a Java developer or just have a general interest on FreeBSD or Java, please go sign up and vote!