Slashdot Mirror

It's not the lack of the community embracing the architechture, it's OEMs not producing a 64bit system that is affordable. Look at the damn prices for an Itanium1 or Sparc station.

Yeah, a SparcStation is like $10 on ebay now, who can afford that! ;)

I actually have a bunch of the IPX workstations, they are a nice form factor, and can withstand a huge amount of weight. Typically, I use them as stands for my SGI Indigo's to keep them off the floor in case of a flood.

Personally, I recommend the Ultra 1 machines, if anyone is seriously looking for an older Sun box. They are very well built machines, and are deceivingly fast (they boot solaris 9 about 5x as fast as a new 280R), and make great little machines to play around with. I use one for testing custom jumpstart installs because they post so damn fast. Just get an an Ultra 1E as they have the fast ethernet interface (and probably no graphics, which you don't need anyways.) A system with around 256mb of ram and a couple small scsi disks shouldn't set you back more than $120 max.

See the Sun System Handbook for hardware specifics.

Just don't expect to do any number crunching on one. My theory is if I develop on one of them and things run tolerably fast, then my apps will haul on a real machine. :)

Remember iPlanet? Approaching 0 on the latest web surveys as Apache dominates that space.

iPlanet was rebranded by Sun as the Sun ONE line - not just the webserver but the appserver, webserver, mail.. sorry 'Messaging' server, and also includes their new IM server talked about here.

Admittedly still at 1% in the webserver space (from here), but you can be sure that that 1% is SME and greater - paying customers. Sun do just fine out many of the large chunks of business software like these that they sell (naturally together with their hardware).

If you read the post you replied to more carefully, you might notice that it mentioned Solaris - not Linux - as the OS that routinely runs on 32+ processors. I can name one vendor off the top of my head that sells 32+ processor boxes that run Solaris as a single system image - Sun Microsystems

Now, step back for a minute and think why Suns UltraSparc and Solaris solution is so strong. Simple, at the risk of repeating the marketing guys the lure is that you can give your development and deployment guys a bunch of cheap Sunblade 150s or some cheap UltraSparc blades and whatever they come up with can be moved straight onto anything up to and including an F15K without recompiling. Put yourself in the place of a big corporation. Your putting together a new system, you have no idea just how big a load it will eventually have to take (say in 5 years). Today, sure you could run it on high end Linux box, but what happens if 6 months in the system needs a bigger box? If you chose Sun in the first place you simply buy the bigger box and move over. No porting, no redevelopment, and you know there is always a bigger, faster system you could move to. It buys you severe scalability that Linux isn't placed today to provide.

Now, about not supporting Linux, what about the LX50, the Sun Open Desktop that is coming soon, the Lintel blades (Coming Soon(TM)) the fact that the entire Sun One stack (web, directory, identity, etc, etc, etc) is either available now for Linux or coming soon, not to mention Star/OpenOffice.

So what is the perceived issue? I think people don't see Sun offering Linux on the UltraSparc range and thing they don't get it. Sun does get it, but look at their selling point for the last 10 years, total scalability. Linux doesn't provide this yet so they can't buy into it. What they are doing is making Solaris as compatible with Linux as possible, whilst at the same time helping Linux by providing software (openoffice, SunOne and much more) and I believe some kernel code too.

Believe me, when Linux is ready for the F15K class systems Sun will be ready for Linux to be there.

Disclaimer - I work for Sun, but nothing I have said here is not already public information.

Now, step back for a minute and think why Suns UltraSparc and Solaris solution is so strong. Simple, at the risk of repeating the marketing guys the lure is that you can give your development and deployment guys a bunch of cheap Sunblade 150s or some cheap UltraSparc blades and whatever they come up with can be moved straight onto anything up to and including an F15K without recompiling. Put yourself in the place of a big corporation. Your putting together a new system, you have no idea just how big a load it will eventually have to take (say in 5 years). Today, sure you could run it on high end Linux box, but what happens if 6 months in the system needs a bigger box? If you chose Sun in the first place you simply buy the bigger box and move over. No porting, no redevelopment, and you know there is always a bigger, faster system you could move to. It buys you severe scalability that Linux isn't placed today to provide.

Now, about not supporting Linux, what about the LX50, the Sun Open Desktop that is coming soon, the Lintel blades (Coming Soon(TM)) the fact that the entire Sun One stack (web, directory, identity, etc, etc, etc) is either available now for Linux or coming soon, not to mention Star/OpenOffice.

So what is the perceived issue? I think people don't see Sun offering Linux on the UltraSparc range and thing they don't get it. Sun does get it, but look at their selling point for the last 10 years, total scalability. Linux doesn't provide this yet so they can't buy into it. What they are doing is making Solaris as compatible with Linux as possible, whilst at the same time helping Linux by providing software (openoffice, SunOne and much more) and I believe some kernel code too.

Believe me, when Linux is ready for the F15K class systems Sun will be ready for Linux to be there.

Disclaimer - I work for Sun, but nothing I have said here is not already public information.

Now, step back for a minute and think why Suns UltraSparc and Solaris solution is so strong. Simple, at the risk of repeating the marketing guys the lure is that you can give your development and deployment guys a bunch of cheap Sunblade 150s or some cheap UltraSparc blades and whatever they come up with can be moved straight onto anything up to and including an F15K without recompiling. Put yourself in the place of a big corporation. Your putting together a new system, you have no idea just how big a load it will eventually have to take (say in 5 years). Today, sure you could run it on high end Linux box, but what happens if 6 months in the system needs a bigger box? If you chose Sun in the first place you simply buy the bigger box and move over. No porting, no redevelopment, and you know there is always a bigger, faster system you could move to. It buys you severe scalability that Linux isn't placed today to provide.

Now, about not supporting Linux, what about the LX50, the Sun Open Desktop that is coming soon, the Lintel blades (Coming Soon(TM)) the fact that the entire Sun One stack (web, directory, identity, etc, etc, etc) is either available now for Linux or coming soon, not to mention Star/OpenOffice.

So what is the perceived issue? I think people don't see Sun offering Linux on the UltraSparc range and thing they don't get it. Sun does get it, but look at their selling point for the last 10 years, total scalability. Linux doesn't provide this yet so they can't buy into it. What they are doing is making Solaris as compatible with Linux as possible, whilst at the same time helping Linux by providing software (openoffice, SunOne and much more) and I believe some kernel code too.

Believe me, when Linux is ready for the F15K class systems Sun will be ready for Linux to be there.

Disclaimer - I work for Sun, but nothing I have said here is not already public information.

Now, step back for a minute and think why Suns UltraSparc and Solaris solution is so strong. Simple, at the risk of repeating the marketing guys the lure is that you can give your development and deployment guys a bunch of cheap Sunblade 150s or some cheap UltraSparc blades and whatever they come up with can be moved straight onto anything up to and including an F15K without recompiling. Put yourself in the place of a big corporation. Your putting together a new system, you have no idea just how big a load it will eventually have to take (say in 5 years). Today, sure you could run it on high end Linux box, but what happens if 6 months in the system needs a bigger box? If you chose Sun in the first place you simply buy the bigger box and move over. No porting, no redevelopment, and you know there is always a bigger, faster system you could move to. It buys you severe scalability that Linux isn't placed today to provide.

Now, about not supporting Linux, what about the LX50, the Sun Open Desktop that is coming soon, the Lintel blades (Coming Soon(TM)) the fact that the entire Sun One stack (web, directory, identity, etc, etc, etc) is either available now for Linux or coming soon, not to mention Star/OpenOffice.

So what is the perceived issue? I think people don't see Sun offering Linux on the UltraSparc range and thing they don't get it. Sun does get it, but look at their selling point for the last 10 years, total scalability. Linux doesn't provide this yet so they can't buy into it. What they are doing is making Solaris as compatible with Linux as possible, whilst at the same time helping Linux by providing software (openoffice, SunOne and much more) and I believe some kernel code too.

Believe me, when Linux is ready for the F15K class systems Sun will be ready for Linux to be there.

Disclaimer - I work for Sun, but nothing I have said here is not already public information.

Now, step back for a minute and think why Suns UltraSparc and Solaris solution is so strong. Simple, at the risk of repeating the marketing guys the lure is that you can give your development and deployment guys a bunch of cheap Sunblade 150s or some cheap UltraSparc blades and whatever they come up with can be moved straight onto anything up to and including an F15K without recompiling. Put yourself in the place of a big corporation. Your putting together a new system, you have no idea just how big a load it will eventually have to take (say in 5 years). Today, sure you could run it on high end Linux box, but what happens if 6 months in the system needs a bigger box? If you chose Sun in the first place you simply buy the bigger box and move over. No porting, no redevelopment, and you know there is always a bigger, faster system you could move to. It buys you severe scalability that Linux isn't placed today to provide.

Now, about not supporting Linux, what about the LX50, the Sun Open Desktop that is coming soon, the Lintel blades (Coming Soon(TM)) the fact that the entire Sun One stack (web, directory, identity, etc, etc, etc) is either available now for Linux or coming soon, not to mention Star/OpenOffice.

So what is the perceived issue? I think people don't see Sun offering Linux on the UltraSparc range and thing they don't get it. Sun does get it, but look at their selling point for the last 10 years, total scalability. Linux doesn't provide this yet so they can't buy into it. What they are doing is making Solaris as compatible with Linux as possible, whilst at the same time helping Linux by providing software (openoffice, SunOne and much more) and I believe some kernel code too.

Believe me, when Linux is ready for the F15K class systems Sun will be ready for Linux to be there.

Disclaimer - I work for Sun, but nothing I have said here is not already public information.

Now, step back for a minute and think why Suns UltraSparc and Solaris solution is so strong. Simple, at the risk of repeating the marketing guys the lure is that you can give your development and deployment guys a bunch of cheap Sunblade 150s or some cheap UltraSparc blades and whatever they come up with can be moved straight onto anything up to and including an F15K without recompiling. Put yourself in the place of a big corporation. Your putting together a new system, you have no idea just how big a load it will eventually have to take (say in 5 years). Today, sure you could run it on high end Linux box, but what happens if 6 months in the system needs a bigger box? If you chose Sun in the first place you simply buy the bigger box and move over. No porting, no redevelopment, and you know there is always a bigger, faster system you could move to. It buys you severe scalability that Linux isn't placed today to provide.

Now, about not supporting Linux, what about the LX50, the Sun Open Desktop that is coming soon, the Lintel blades (Coming Soon(TM)) the fact that the entire Sun One stack (web, directory, identity, etc, etc, etc) is either available now for Linux or coming soon, not to mention Star/OpenOffice.

So what is the perceived issue? I think people don't see Sun offering Linux on the UltraSparc range and thing they don't get it. Sun does get it, but look at their selling point for the last 10 years, total scalability. Linux doesn't provide this yet so they can't buy into it. What they are doing is making Solaris as compatible with Linux as possible, whilst at the same time helping Linux by providing software (openoffice, SunOne and much more) and I believe some kernel code too.

Believe me, when Linux is ready for the F15K class systems Sun will be ready for Linux to be there.

Disclaimer - I work for Sun, but nothing I have said here is not already public information.

Now, step back for a minute and think why Suns UltraSparc and Solaris solution is so strong. Simple, at the risk of repeating the marketing guys the lure is that you can give your development and deployment guys a bunch of cheap Sunblade 150s or some cheap UltraSparc blades and whatever they come up with can be moved straight onto anything up to and including an F15K without recompiling. Put yourself in the place of a big corporation. Your putting together a new system, you have no idea just how big a load it will eventually have to take (say in 5 years). Today, sure you could run it on high end Linux box, but what happens if 6 months in the system needs a bigger box? If you chose Sun in the first place you simply buy the bigger box and move over. No porting, no redevelopment, and you know there is always a bigger, faster system you could move to. It buys you severe scalability that Linux isn't placed today to provide.

Now, about not supporting Linux, what about the LX50, the Sun Open Desktop that is coming soon, the Lintel blades (Coming Soon(TM)) the fact that the entire Sun One stack (web, directory, identity, etc, etc, etc) is either available now for Linux or coming soon, not to mention Star/OpenOffice.

So what is the perceived issue? I think people don't see Sun offering Linux on the UltraSparc range and thing they don't get it. Sun does get it, but look at their selling point for the last 10 years, total scalability. Linux doesn't provide this yet so they can't buy into it. What they are doing is making Solaris as compatible with Linux as possible, whilst at the same time helping Linux by providing software (openoffice, SunOne and much more) and I believe some kernel code too.

Believe me, when Linux is ready for the F15K class systems Sun will be ready for Linux to be there.

Disclaimer - I work for Sun, but nothing I have said here is not already public information.

Now, step back for a minute and think why Suns UltraSparc and Solaris solution is so strong. Simple, at the risk of repeating the marketing guys the lure is that you can give your development and deployment guys a bunch of cheap Sunblade 150s or some cheap UltraSparc blades and whatever they come up with can be moved straight onto anything up to and including an F15K without recompiling. Put yourself in the place of a big corporation. Your putting together a new system, you have no idea just how big a load it will eventually have to take (say in 5 years). Today, sure you could run it on high end Linux box, but what happens if 6 months in the system needs a bigger box? If you chose Sun in the first place you simply buy the bigger box and move over. No porting, no redevelopment, and you know there is always a bigger, faster system you could move to. It buys you severe scalability that Linux isn't placed today to provide.

Now, about not supporting Linux, what about the LX50, the Sun Open Desktop that is coming soon, the Lintel blades (Coming Soon(TM)) the fact that the entire Sun One stack (web, directory, identity, etc, etc, etc) is either available now for Linux or coming soon, not to mention Star/OpenOffice.

So what is the perceived issue? I think people don't see Sun offering Linux on the UltraSparc range and thing they don't get it. Sun does get it, but look at their selling point for the last 10 years, total scalability. Linux doesn't provide this yet so they can't buy into it. What they are doing is making Solaris as compatible with Linux as possible, whilst at the same time helping Linux by providing software (openoffice, SunOne and much more) and I believe some kernel code too.

Believe me, when Linux is ready for the F15K class systems Sun will be ready for Linux to be there.

Disclaimer - I work for Sun, but nothing I have said here is not already public information.

Now, step back for a minute and think why Suns UltraSparc and Solaris solution is so strong. Simple, at the risk of repeating the marketing guys the lure is that you can give your development and deployment guys a bunch of cheap Sunblade 150s or some cheap UltraSparc blades and whatever they come up with can be moved straight onto anything up to and including an F15K without recompiling. Put yourself in the place of a big corporation. Your putting together a new system, you have no idea just how big a load it will eventually have to take (say in 5 years). Today, sure you could run it on high end Linux box, but what happens if 6 months in the system needs a bigger box? If you chose Sun in the first place you simply buy the bigger box and move over. No porting, no redevelopment, and you know there is always a bigger, faster system you could move to. It buys you severe scalability that Linux isn't placed today to provide.

Now, about not supporting Linux, what about the LX50, the Sun Open Desktop that is coming soon, the Lintel blades (Coming Soon(TM)) the fact that the entire Sun One stack (web, directory, identity, etc, etc, etc) is either available now for Linux or coming soon, not to mention Star/OpenOffice.

So what is the perceived issue? I think people don't see Sun offering Linux on the UltraSparc range and thing they don't get it. Sun does get it, but look at their selling point for the last 10 years, total scalability. Linux doesn't provide this yet so they can't buy into it. What they are doing is making Solaris as compatible with Linux as possible, whilst at the same time helping Linux by providing software (openoffice, SunOne and much more) and I believe some kernel code too.

Believe me, when Linux is ready for the F15K class systems Sun will be ready for Linux to be there.

Disclaimer - I work for Sun, but nothing I have said here is not already public information.

Now, step back for a minute and think why Suns UltraSparc and Solaris solution is so strong. Simple, at the risk of repeating the marketing guys the lure is that you can give your development and deployment guys a bunch of cheap Sunblade 150s or some cheap UltraSparc blades and whatever they come up with can be moved straight onto anything up to and including an F15K without recompiling. Put yourself in the place of a big corporation. Your putting together a new system, you have no idea just how big a load it will eventually have to take (say in 5 years). Today, sure you could run it on high end Linux box, but what happens if 6 months in the system needs a bigger box? If you chose Sun in the first place you simply buy the bigger box and move over. No porting, no redevelopment, and you know there is always a bigger, faster system you could move to. It buys you severe scalability that Linux isn't placed today to provide.

Now, about not supporting Linux, what about the LX50, the Sun Open Desktop that is coming soon, the Lintel blades (Coming Soon(TM)) the fact that the entire Sun One stack (web, directory, identity, etc, etc, etc) is either available now for Linux or coming soon, not to mention Star/OpenOffice.

So what is the perceived issue? I think people don't see Sun offering Linux on the UltraSparc range and thing they don't get it. Sun does get it, but look at their selling point for the last 10 years, total scalability. Linux doesn't provide this yet so they can't buy into it. What they are doing is making Solaris as compatible with Linux as possible, whilst at the same time helping Linux by providing software (openoffice, SunOne and much more) and I believe some kernel code too.

Believe me, when Linux is ready for the F15K class systems Sun will be ready for Linux to be there.

Disclaimer - I work for Sun, but nothing I have said here is not already public information.

...and Livescript has evolutionary roots in Self, a language developed by Sun

I'll second that. I recently purchased three Sun GDM-5410 monitors (21" flat Trinitrons) for $225 from a Sun reseller that was advertising them on eBay. They were about 2.5 years old, off-lease from a Texas Instruments facility. The reseller was close enough to my home for local pick-up, so I saved shipping-- usually the catch to an otherwise good eBay deal on a big monitor.

The same reseller also had some slightly older Sun GDM-5010PT monitors (21" vertically flat Trinitrons), for $125. I'd had one of each model on my desk at work. The 5410 is much sharper, but the 5010 might be good for cheaply outfitting a room for LAN parties, if you were so inclined. (I was happy with the 5010 at work for years, until I saw a 5410.)

Specs on both models are here

The only downside is that it weighs 31Kg, which makes it a little awkward to move. It'll probably outlive me though. ;-)

Other monitors I've used were a slightly damaged 17" rebadged MAG or CTX I got for free (after it was slightly damaged during a move at my former employer) and a 15" Iiyama that I paid ~300GBP for back in 1995. Iiyamas are worth every penny.

--

is support for more than 4GB of memory a first for 32-bit x86 operating systems?

As others have noted, Windows NT 5.0^H^H^H^H^H^H2000 also supports it.

To my knowledge everything you've said is absolutely true. What you're omitting is the details of Microsoft's contract with Sun. To quote from it:

Subject to the satisfaction of Section 2.6(b)(iii), Licensee agrees that any new version of a Product that includes the Java Language compilation function that Licensee makes commercially available to the public after the most recent Compatibility Date shall include a mode which a Tool Customer may use to permit such Product to pass the Java Language Test Suite that accompanied the Significant Upgrade; provided, that any version of a Product which, as of the most recent Compatibility Date, is being beta tested by third parties, shall be exempt from such requirement.

(the whole contract is available here)

This was one of Microsoft's key points in their defense. Their compiler includes multiple modes. This allowed the developer to choose to support those specific features and forget compatibility or not use them and keep portability. So yes they did "intentionally break their own version of Java" if your defition of break is offer a mode that is compatible and a mode that isn't compatible. Furthermore Microsoft's JVM would be able to run any Java program - after all it passed the tests at some point (even though it's obviously out of date now).

And really what this gets down to is that Sun is treating a "standard" programming language like no one has treated a "standard" programming language before. Here I'm using standard to mean a programming language that has multiple competing implementations (so I'm ignoring things like Delphi, Visual Basic, etc... but including languages such as C and C++).

Traditionally these programming languages are open to people adding their own extensions. Let's look at C++. C++ has a standard way of adding extensions - they're prefixed with a double underscore - the C++ designers recognized that what they've provided is just a starting point. Beyond standard extensions people have extended the language in other various ways too, for example Qt with their pre-processor. This takes very non-C++ compatible code and transforms it into C++. Microsoft has a whole bunch of __declspec() extensions that let you export functions from DLLs, declare variables as being thread local, and other interesting things. Every vendor who builds a C++ product can add extensions that make their product better for the environment it's designed. This is in stark contrast to Sun where nothing interesting can happen outside the standards org.

So Microsoft approached Java in the same way they approach any other language. They liked the idea of a JITed GCed language. You can see it in .NET. They also happened to like the Win32 platform. And their customers did too. And their customers had tons of legacy code. And Microsoft wanted to enable support of this in the most efficient manner possible.

And with any other language no one would of cared. But Sun was TRYING to screw Microsoft(really who loses the most from cross-platform software? could have Sun's intentions been anything else?). And Microsoft wanted to continue to invest and support their platform. So when Microsoft outmanuevered them in the product space they brought on their lawsuit (which they didn't win - really, who thinks the settlement was in Sun's favor today? Microsoft got exactly what they wanted - a lawsuit and a product that went away).

Sun is now offering UltraSparc IIIi processors:
http://www.sun.com/processors/UltraSPARC-IIIi/

They do have some similarities to AMD's opteron processor:
- 1 MB on-chip L2 cache
- integrated memory controller
- 128bit DDR Ram
- large L1 cache

It should be interesting to compare those two processors.

my personal reading the the remarks was that Sun is now thinking of using Opterons instead of Xeons for future products. Given the product choice and testing phases Sun normally goes through, I wouldn't expect something for some time. Like a year at least. Especially since Sun are generally expected to announce 1U and 2U Xeon based systems in 3 months time...

btw, how come a Sun "rumour" story gets posted twice, but a product launch doesn't even get a mention? Anyone want a dual-processor 1U UltraSPARC system, with 4 1Gbit ethernet ports, advanced remote monitoring, dual SCSI and other goodies starting at $3000?

Here's a list of all the new products Sun released on Tuesday

Microsoft intentionally extended the core API by introducing additional instructions to access the underlying Win32 operating system. Had they done this by providing a separate API, there would not have been any problems.

Unfortunately, Microsoft chose to take a different approach and introduced new operators into the core byte-code interpreted by the Virtual Machine. As these additional instructions were only valid within Microsoft's version, users were effectively left with no choice but to use the exact VM for which the code was compiled. This decision by Microsoft to modify the base instruction set of the Java language made it impossible to port code from one platform to another, thereby ensuring that users would have to remain on the Windows platform. In fact, Java programs compiled for MS's VM would not even work on the same OS if another vendor's VM was used to run it. This is why some applets wouldn't work with the JVM shipped with Netscape (which was Sun's JVM).

The instruction set supported by a Java VM is determined and maintained by Sun. In order to implement your own VM, you must agree to a license with Sun stating that you will not modify the core instruction set. In adding direct support for OS access (such as formatting a hard drive), Microsoft violated this license agreement. Microsoft also added their own keywords to the core language (delegate and multicast) which further ensured incompatibility.

The Java byte code is a single byte in size and, as a result, the Java VM spec supports up to 256 op codes. Not all of them are used, however. Out of those potential 256 opcodes, only 200 valid operators are specified. Opcode 186 is not used, opcode 201 is used for debugging, and codes 254 and 255 are used for trapping and tracing. The remaining opcodes are reserved for future use. Clearly, if a compiler introduces new opcodes, the other compilers won't know about them and won't be able to run programs built with those opcodes. This is in direct violation of the VM specification and is exactly what Microsoft did. This was the basis for the Sun v. Microsoft lawsuit, for which Microsoft was found in willful violation.

So, it would seem as if Microsoft did intentionally break their own version of Java.

If you still do not understand how Microsoft did this on purpose, I suggest that you take a look at the Java Virtual Machine Specification, as well as a nice book on general compiler theory.

Microsoft intentionally extended the core API by introducing additional instructions to access the underlying Win32 operating system. Had they done this by providing a separate API, there would not have been any problems.

Unfortunately, Microsoft chose to take a different approach and introduced new operators into the core byte-code interpreted by the Virtual Machine. As these additional instructions were only valid within Microsoft's version, users were effectively left with no choice but to use the exact VM for which the code was compiled. This decision by Microsoft to modify the base instruction set of the Java language made it impossible to port code from one platform to another, thereby ensuring that users would have to remain on the Windows platform. In fact, Java programs compiled for MS's VM would not even work on the same OS if another vendor's VM was used to run it. This is why some applets wouldn't work with the JVM shipped with Netscape (which was Sun's JVM).

The instruction set supported by a Java VM is determined and maintained by Sun. In order to implement your own VM, you must agree to a license with Sun stating that you will not modify the core instruction set. In adding direct support for OS access (such as formatting a hard drive), Microsoft violated this license agreement. Microsoft also added their own keywords to the core language (delegate and multicast) which further ensured incompatibility.

The Java byte code is a single byte in size and, as a result, the Java VM spec supports up to 256 op codes. Not all of them are used, however. Out of those potential 256 opcodes, only 200 valid operators are specified. Opcode 186 is not used, opcode 201 is used for debugging, and codes 254 and 255 are used for trapping and tracing. The remaining opcodes are reserved for future use. Clearly, if a compiler introduces new opcodes, the other compilers won't know about them and won't be able to run programs built with those opcodes. This is in direct violation of the VM specification and is exactly what Microsoft did. This was the basis for the Sun v. Microsoft lawsuit, for which Microsoft was found in willful violation.

So, it would seem as if Microsoft did intentionally break their own version of Java.

If you still do not understand how Microsoft did this on purpose, I suggest that you take a look at the Java Virtual Machine Specification, as well as a nice book on general compiler theory.

quite true.they are calling it throughtput computing Quite interesting IMHO, if they are able to produce it soon enough.

Sun is now offering UltraSparc IIIi processors:
http://www.sun.com/processors/UltraSPARC-IIIi/

They do have some similarities to AMD's opteron processor:
- 1 MB on-chip L2 cache
- integrated memory controller
- 128bit DDR Ram
- large L1 cache

It should be interesting to compare those two processors.

For example, one of Sun's servers can have up to 106 processors, 1/2 terabyte of memory, 172 GB/sec. aggregate bandwidth, 18 domains, 72 hot-swap PCI slots, etc., etc., and can be clustered.

Newer Macs don't have as extensive a BIOS (and I'm not sure what is in it), but Apple now protects itself in other ways.

From this point of view, Apple completly changed its approach. In the old days, systems were often free (you can download system 7.5) but the hardware was locked down. Nowadays the hardware is quite open, and so is the kernel, but the upper layer OS is locked down.

If he booted off the 'Install' CD and got mired in Webstart, he had already lost. That appears to be something the Sun engineers tricked up for marketing to keep them safe and out of the way. To install Solaris properly you boot off CD1, which is also bootable, and it gives you a regular unkludged Solaris install.

Stuff like that is detailed in a valuable 'short cut' document from Sun, the wonderful Solaris 80/20 Guide, officially 'Solaris OE Guide for New System Administrators: The 20% of Solaris knowledge that solves 80% of your needs'.

If there is any chance of you ever wanting to explore Solaris, download and archive this document now . It's a real hassle, I just found out, to locate it on the docs.sun website, so bookmark this. It's one hell of a good cribsheet.

To back up my own post, would you seriously not buy this for $3000? That's a freakin fast machine - 1Ghz Sun Ultra IIIi, 512MB Ram, 4 X gigabit ethernet ports, 64 bit PCI slot... damn.

How are they going to build 106 cpu boxes with opterons?

Maybe somebody more familiar with the architecture can chime in here...?

I no longer work for Sun (I left a year and half ago), but that's what we were told at the time (~2 1/2 years ago), as I said - it was apparently an exotic configuration using pre-production kit, and the DoD are notably absent from the 'Success Stories' section of the F15K product page, for whatever reason :). Let me be more precise about what Sun currently offers to customers (all of this publicly available on Sun's website, I checked).

Sun has had Remote Shared Memory products for years (then SCI, just recently Sun Fire Link (codename wildcat)), Sun Cluster 3.0 gives you the shared devices, global filesystem, failure monitoring etc. (either using RSM or DLPI interconnects such as gigabit Ethernet, and uses the ultra low-latency Solaris xdoors IPC mechanism, on a bunch of separate Solaris instances. That stuff is currently being used for commercial HA clustering. HPC customers are using the Sun HPC ClusterTools software which provides the Sun MPI library (good whitepaper here). This is a different programming model from standard SMP, but allows you to use high-speed low-latency RSM, interconnect failover - all that good stuff - on a bunch of servers running separate instances of Solaris.

The Sun Fire Link is an interesting piece of interconnect technology because it plugs directly into the server's crossbar, couple that fact with a lot of new cc-NUMA code in Solaris 9, and much of SunCluster 3's core functionality being built into Solaris and I'll leave you to draw your own conclusions as to what sort of product announcements might be coming along soon.

But I'm just a pundit these days...

What about a CPU that natively grokked Java?

Crap, here's the link. That'll teach me to always click Preview.

and maybe theo will finally get the sparc docs he needs.

Y'know, IBM have (or at least used to have) a deal with the US govt. that means that the govt. gets priority on orders. If there are N mainframes left in the warehouse, and the govt. needs N, then they get 'em and commercial customers wait. I read about this in a book about Oracle, funnily enough. They were doing some government work (the original Oracle was a project for the CIA to store data on magnetized strips of mylar) and so could get an IBM mainframe. Everyone saw they had a mainframe, thus must be a successful company (this was before they were actually making money) and that made it easier for them to hire staff and buy stuff!

Anyway, I know Sun do a lot of work with with both the govt. and the military, so if Theo wants the docs, a quick phone call to DARPA should be all it takes.

Do you remember Scott McNealy's Java Ring?

The most recent example is the "virtual key" codes in the KeyEvent Java class. Namely, what is the difference between VK_PLUS and VK_ADD !? You can look up their values - VK_ADD is 107, VK_PLUS is 521 - so they aren't synonyms. My guess would be one is produced using "Shift-Equals" on many keyboards, and the other is next to the 6 and the 9 on the numeric pad. But the docs helpfully don't say which is which. (Fortunately, simply looking to see if the character field is "+" is probably sufficient.)

(Also look for VK_SEPARATER , which is included for backwards compatibility, and VK_SEPARATOR , which replaces it. There are numerous instances of spelling errors throughout the Java API. Plus, this is another VK for which I have no clue where it is on the keyboard - maybe it isn't present on PC-104 QWERTY boards?)

But, yes, the most frusterating experience I have had in programming isn't from my own code, but from trying to figure out official documentation. Especially when the documentation is provably wrong - no, you can't use a comma-separated list as a value to cursor in IE6's CSS, despite the documentation saying that it works.

I know there are other, worse examples, but this is what comes to mind. (I remember spending an entire summer trying to get Java code to call an Oracle stored procedure, and failing. I spent a lot of time reading Slashdot that summer, while trying to come up with another method to force it to work. We finally decided it was impossible.)

Of course, incomplete and incorrect documentation are not just found in commerical software - many open source libraries are even worse.

The most recent example is the "virtual key" codes in the KeyEvent Java class. Namely, what is the difference between VK_PLUS and VK_ADD !? You can look up their values - VK_ADD is 107, VK_PLUS is 521 - so they aren't synonyms. My guess would be one is produced using "Shift-Equals" on many keyboards, and the other is next to the 6 and the 9 on the numeric pad. But the docs helpfully don't say which is which. (Fortunately, simply looking to see if the character field is "+" is probably sufficient.)

(Also look for VK_SEPARATER , which is included for backwards compatibility, and VK_SEPARATOR , which replaces it. There are numerous instances of spelling errors throughout the Java API. Plus, this is another VK for which I have no clue where it is on the keyboard - maybe it isn't present on PC-104 QWERTY boards?)

But, yes, the most frusterating experience I have had in programming isn't from my own code, but from trying to figure out official documentation. Especially when the documentation is provably wrong - no, you can't use a comma-separated list as a value to cursor in IE6's CSS, despite the documentation saying that it works.

I know there are other, worse examples, but this is what comes to mind. (I remember spending an entire summer trying to get Java code to call an Oracle stored procedure, and failing. I spent a lot of time reading Slashdot that summer, while trying to come up with another method to force it to work. We finally decided it was impossible.)

Of course, incomplete and incorrect documentation are not just found in commerical software - many open source libraries are even worse.

The most recent example is the "virtual key" codes in the KeyEvent Java class. Namely, what is the difference between VK_PLUS and VK_ADD !? You can look up their values - VK_ADD is 107, VK_PLUS is 521 - so they aren't synonyms. My guess would be one is produced using "Shift-Equals" on many keyboards, and the other is next to the 6 and the 9 on the numeric pad. But the docs helpfully don't say which is which. (Fortunately, simply looking to see if the character field is "+" is probably sufficient.)

(Also look for VK_SEPARATER , which is included for backwards compatibility, and VK_SEPARATOR , which replaces it. There are numerous instances of spelling errors throughout the Java API. Plus, this is another VK for which I have no clue where it is on the keyboard - maybe it isn't present on PC-104 QWERTY boards?)

But, yes, the most frusterating experience I have had in programming isn't from my own code, but from trying to figure out official documentation. Especially when the documentation is provably wrong - no, you can't use a comma-separated list as a value to cursor in IE6's CSS, despite the documentation saying that it works.

I know there are other, worse examples, but this is what comes to mind. (I remember spending an entire summer trying to get Java code to call an Oracle stored procedure, and failing. I spent a lot of time reading Slashdot that summer, while trying to come up with another method to force it to work. We finally decided it was impossible.)

Of course, incomplete and incorrect documentation are not just found in commerical software - many open source libraries are even worse.

The most recent example is the "virtual key" codes in the KeyEvent Java class. Namely, what is the difference between VK_PLUS and VK_ADD !? You can look up their values - VK_ADD is 107, VK_PLUS is 521 - so they aren't synonyms. My guess would be one is produced using "Shift-Equals" on many keyboards, and the other is next to the 6 and the 9 on the numeric pad. But the docs helpfully don't say which is which. (Fortunately, simply looking to see if the character field is "+" is probably sufficient.)

(Also look for VK_SEPARATER , which is included for backwards compatibility, and VK_SEPARATOR , which replaces it. There are numerous instances of spelling errors throughout the Java API. Plus, this is another VK for which I have no clue where it is on the keyboard - maybe it isn't present on PC-104 QWERTY boards?)

But, yes, the most frusterating experience I have had in programming isn't from my own code, but from trying to figure out official documentation. Especially when the documentation is provably wrong - no, you can't use a comma-separated list as a value to cursor in IE6's CSS, despite the documentation saying that it works.

I know there are other, worse examples, but this is what comes to mind. (I remember spending an entire summer trying to get Java code to call an Oracle stored procedure, and failing. I spent a lot of time reading Slashdot that summer, while trying to come up with another method to force it to work. We finally decided it was impossible.)

Of course, incomplete and incorrect documentation are not just found in commerical software - many open source libraries are even worse.

The most recent example is the "virtual key" codes in the KeyEvent Java class. Namely, what is the difference between VK_PLUS and VK_ADD !? You can look up their values - VK_ADD is 107, VK_PLUS is 521 - so they aren't synonyms. My guess would be one is produced using "Shift-Equals" on many keyboards, and the other is next to the 6 and the 9 on the numeric pad. But the docs helpfully don't say which is which. (Fortunately, simply looking to see if the character field is "+" is probably sufficient.)

(Also look for VK_SEPARATER , which is included for backwards compatibility, and VK_SEPARATOR , which replaces it. There are numerous instances of spelling errors throughout the Java API. Plus, this is another VK for which I have no clue where it is on the keyboard - maybe it isn't present on PC-104 QWERTY boards?)

But, yes, the most frusterating experience I have had in programming isn't from my own code, but from trying to figure out official documentation. Especially when the documentation is provably wrong - no, you can't use a comma-separated list as a value to cursor in IE6's CSS, despite the documentation saying that it works.

I know there are other, worse examples, but this is what comes to mind. (I remember spending an entire summer trying to get Java code to call an Oracle stored procedure, and failing. I spent a lot of time reading Slashdot that summer, while trying to come up with another method to force it to work. We finally decided it was impossible.)

Of course, incomplete and incorrect documentation are not just found in commerical software - many open source libraries are even worse.

The most recent example is the "virtual key" codes in the KeyEvent Java class. Namely, what is the difference between VK_PLUS and VK_ADD !? You can look up their values - VK_ADD is 107, VK_PLUS is 521 - so they aren't synonyms. My guess would be one is produced using "Shift-Equals" on many keyboards, and the other is next to the 6 and the 9 on the numeric pad. But the docs helpfully don't say which is which. (Fortunately, simply looking to see if the character field is "+" is probably sufficient.)

(Also look for VK_SEPARATER , which is included for backwards compatibility, and VK_SEPARATOR , which replaces it. There are numerous instances of spelling errors throughout the Java API. Plus, this is another VK for which I have no clue where it is on the keyboard - maybe it isn't present on PC-104 QWERTY boards?)

But, yes, the most frusterating experience I have had in programming isn't from my own code, but from trying to figure out official documentation. Especially when the documentation is provably wrong - no, you can't use a comma-separated list as a value to cursor in IE6's CSS, despite the documentation saying that it works.

I know there are other, worse examples, but this is what comes to mind. (I remember spending an entire summer trying to get Java code to call an Oracle stored procedure, and failing. I spent a lot of time reading Slashdot that summer, while trying to come up with another method to force it to work. We finally decided it was impossible.)

Of course, incomplete and incorrect documentation are not just found in commerical software - many open source libraries are even worse.

The most recent example is the "virtual key" codes in the KeyEvent Java class. Namely, what is the difference between VK_PLUS and VK_ADD !? You can look up their values - VK_ADD is 107, VK_PLUS is 521 - so they aren't synonyms. My guess would be one is produced using "Shift-Equals" on many keyboards, and the other is next to the 6 and the 9 on the numeric pad. But the docs helpfully don't say which is which. (Fortunately, simply looking to see if the character field is "+" is probably sufficient.)

(Also look for VK_SEPARATER , which is included for backwards compatibility, and VK_SEPARATOR , which replaces it. There are numerous instances of spelling errors throughout the Java API. Plus, this is another VK for which I have no clue where it is on the keyboard - maybe it isn't present on PC-104 QWERTY boards?)

But, yes, the most frusterating experience I have had in programming isn't from my own code, but from trying to figure out official documentation. Especially when the documentation is provably wrong - no, you can't use a comma-separated list as a value to cursor in IE6's CSS, despite the documentation saying that it works.

I know there are other, worse examples, but this is what comes to mind. (I remember spending an entire summer trying to get Java code to call an Oracle stored procedure, and failing. I spent a lot of time reading Slashdot that summer, while trying to come up with another method to force it to work. We finally decided it was impossible.)

Of course, incomplete and incorrect documentation are not just found in commerical software - many open source libraries are even worse.

I used OOo Draw to specify the animated elements, and traced out their paths via other elements and object prperties.

well, taste differs. if you want to have VB-like drag-n-drop UI design functionality why not go for Fotre (or it's m,ore on the edge cousin Netbeans) or go and buy JBuilder from Borland. THere're other RAD IDEs that spring to mind as well, VisualCafe' for example (haven't used it for ages though - NetBeans and IntelliJ does all I want)

OS24Ever wrote: "I seem to remember something about network computers. As far as I can tell that was the biggest bit of vapor hardware ever. I've never seen anything like that in the enterprise." You've never heard of a SunRay?

It's worth mentioning that even Sun comes down hard on AWT/Swing, and shows some of its flaws in their own report, The AWT Focus Subsystem.

Sun even has the guts to plainly state that Windows GUI techs in C++ and VB are improvements over Java options in the following section:

In addition, many developers noted that the APIs for FocusEvent and WindowEvent were insufficient because they did not provide a way for determining the "opposite" Component involved in the focus or activation change...

Since Microsoft Windows provides this functionality for free, developers migrating from Microsoft Windows C/C++ or Visual Basic to Java had been frustrated by the omission. (emph mine)

I believe Windows.Forms in .NET continues the intuitive GUI design Windows developers came to expect in the VB IDEs.

C# certainly took lessons from Java, and now Sun is returning the favor. The above document deals mostly with changes to GUI techs in Java 1.4 and flaws in 1.3 and prior, but this new survey at Sun makes me hopeful that Sun might, indeed, go back to the drawing board.

As Frederick P. Brooks, Jr. said in The Mythical Man-Month , always "Plan to Throw One Away"!

The bindings are possible. You can use JNI (Java Native Interface) to hook Java code directly to C or C++. It's a tad contorted, but not nearly as torturous as using CORBA to do it.

Public Standards: C# 2, Java 0

Supported platforms: C# 1 (Windows), Java 3 (Windows, Linux, Solaris) (and that's just from Sun).

Vendors: C# 1 (Microsoft), Java 5 (Sun, IBM, BEA, Oracle, Allaire) (in fairness there are many more Java vendors... those are the 'big ones').

So the score is already 8 to 4, and what you'd find is a lot more '1s' in the C# column which read 'Microsoft', 'Microsoft', 'Windows', 'Windows', etc.

And going back to 'public standards': when Microsoft Office publishes a set of DTDs which comprise a very public 'standard'... I'll be shocked. Their 'XML-based openness' in Office 11 is far from that goal.

Red Hat Linux 9 Technical Changes (or when the RELEASE-NOTES are just not enough) by Dax.Kelson@GuruLabs.com
Copyright 2003 Guru Labs, L.C.
Intro Over the past eight years or so, I've been excited each time a new version of Red Hat Linux gets released. During the past few years, people have even been writing reviews of each release. As a general rule, I've been dissatisfied by the superficialities, inaccuracies, and irrelevancies in the reviews often times performed by someone who does not have intimate knowledge of Red Hat Linux. A systems administrator needs an in-depth review that covers relative to the previous release:

• Architectural & behavioral changes
• Installer changes
• Changes to included software packages

Normally, with each new release of Red Hat Linux, someone here at Guru Labs combs through it looking for the above changes to update the Guru Labs Linux courses. This time it was my turn, and I decided to simultaneously write a technical review for the system administrators out there. I hope that the results are satisfactory.

Abbreviation notes:
RHL = Red Hat Linux
RH = Red Hat Inc.
Architectural & behavioral changes There were many changes between RHL7.3 and 8.0, for example, the use of root=LABEL=/ in the /boot/grub/grub.conf file, the replacement of Xconfigurator with the redhat-config-xfree86 program, and the new dhclient DHCP client daemon. There are not nearly as many behavioral changes from RHL8.0 to RHL9, yet the ones that exist are significant. Kernel 2.4.20-8 The kernel in RHL8.0 was based on the 2.4.18 kernel. Despite the name, the RHL 2.4.20-8 kernel is based on 2.4.20 plus bug fixes identified up through 2.4.21-pre4-ac4. During the past couple years, the RHL kernels have included back ported functionality from development kernels that has proven stable. The new RHL9 kernel is no exception. Major changes since RHL8.0 include:

• Addition of Native POSIX Thread Library (NPTL) for standards based threading support with impressive performance. This is definitely a nice addition, however, I anticipate that sys admins who add patches on-top-of the RHL kernel from 3rd party (UML, FreeSWAN, etc) sources will have a more difficult time getting the patches to apply and work cleanly. Presumably when the 2.6 kernel comes out, the divergence of the RHL kernel will drop substantially.
• • Certain applications using the old LinuxThreads API in a certain manner may no longer work (was that vague enough?)
  • In particular if using Java, update to the latest version from Sun at:
  • http://java.sun.com/j2se/1.4.1/download.html
  • The WIN32 API translation software, WINE, suffers from this problem. Proper fixes are in the works, however, workarounds exist.
  • Installing and running Oracle 9i R2 has major issues since it includes two different older embedded Java JVMs that don't work with NPTL. The solution is stick with RHL8.0 or the officially supported Red Hat Linux AS edition.

ACPI support appeared in a beta (as well as in a 8.0 beta), but was removed for the final shipping kernel.

Filesystem ACL and EA support appeared in the betas, but was pulled for the final shipping kernel. I was really looking forward to ACLs and EAs support in RHL (Solaris had support since 2.5.1), maybe an errata kernel will re-add the feature.

• To see what software specifically supports

• Architectural & behavioral changes
• Installer changes
• Changes to included software packages

Normally, with each new release of Red Hat Linux, someone here at Guru Labs combs through it looking for the above changes to update the Guru Labs Linux courses. This time it was my turn, and I decided to simultaneously write a technical review for the system administrators out there. I hope that the results are satisfactory.

Abbreviation notes:
RHL = Red Hat Linux
RH = Red Hat Inc.
Architectural & behavioral changes There were many changes between RHL7.3 and 8.0, for example, the use of root=LABEL=/ in the /boot/grub/grub.conf file, the replacement of Xconfigurator with the redhat-config-xfree86 program, and the new dhclient DHCP client daemon. There are not nearly as many behavioral changes from RHL8.0 to RHL9, yet the ones that exist are significant. Kernel 2.4.20-8 The kernel in RHL8.0 was based on the 2.4.18 kernel. Despite the name, the RHL 2.4.20-8 kernel is based on 2.4.20 plus bug fixes identified up through 2.4.21-pre4-ac4. During the past couple years, the RHL kernels have included back ported functionality from development kernels that has proven stable. The new RHL9 kernel is no exception. Major changes since RHL8.0 include:

• Addition of Native POSIX Thread Library (NPTL) for standards based threading support with impressive performance. This is definitely a nice addition, however, I anticipate that sys admins who add patches on-top-of the RHL kernel from 3rd party (UML, FreeSWAN, etc) sources will have a more difficult time getting the patches to apply and work cleanly. Presumably when the 2.6 kernel comes out, the divergence of the RHL kernel will drop substantially.
• • Certain applications using the old LinuxThreads API in a certain manner may no longer work (was that vague enough?)
  • In particular if using Java, update to the latest version from Sun at:
  • http://java.sun.com/j2se/1.4.1/download.html
  • The WIN32 API translation software, WINE, suffers from this problem. Proper fixes are in the works, however, workarounds exist.
  • Installing and running Oracle 9i R2 has major issues since it includes two different older embedded Java JVMs that don't work with NPTL. The solution is stick with RHL8.0 or the officially supported Red Hat Linux AS edition.

ACPI support appeared in a beta (as well as in a 8.0 beta), but was removed for the final shipping kernel.

Filesystem ACL and EA support appeared in the betas, but was pulled for the final shipping kernel. I was really looking forward to ACLs and EAs support in RHL (Solaris had support since 2.5.1), maybe an errata kernel will re-add the feature.

• To see what software specifically supports ACLs and EA

well, it's not entirely an impossible language...
take Java Language Specification's definition of whitespace, which includes space, tab, form feed, and line terminator. There are languages that require very few characters, such as brainfuck. There are irritating languages like that one. In fact, two characters is enough to form a language.

However, according to Mr. Bunny's Big Cup o' Java(TM) , whitespace is the computer's way of telling you that you haven't done any work.

>EXCEPTION: java.lang.NullPointerException: name

Update your JRE