Slashdot Mirror

This is very likely in response not just to Citrix but to Sun's SunRay technology which is the ultimate thinclient - there is no OS on a SunRay it is basically a remote keyboard/mouse/usb hub/audio/framebuffer-display all hanging off a network interface.

SunRay is very heavily used in US Military applications because they really like the zero state on the desktop and no ability for state to be put there. It is even used with Trusted Solaris (which provides Mandatory Access Controls), to access Citrix services.

SunRay also has very simple and very effective desktop mobility, pull out smartcard move to new SunRay unit plug in card, reauthenticate, and off you go.

SunRay however does require dedicated Sun specific hardware, but that hardware is pretty cheap.

See Sun for more info.

Spoke a bit too soon. It looks like they're already pushing 10Gbit for regular traffic and getting >200MB/sec on NFS.

The V40z is Opteron-based, his link was wrong. The real link is here.

This one or
This one
or This one

ok, some of them are end of life, but hey you'll never know... ;-)

ps:I hope you have some spare money lying around...

Sun Fire V40z: up to 32 gb of memory

Bryan Cantrill's post on the fundamental right of reverse engineering.

You can't. But you can download it for free here: http://www.sun.com/software/solaris/get.jsp, then buy support if you wish.

Oh, you were trolling? Sorry, I didn't mean to give you a real answer and ruin your fun.

I don't know about the pipe lock, but for containers this guy at Sun put 190 containers on a 31GB disk. It is possible to cut them down, at least.

The man page for SMF says it's database is 'transactional' and is able to provide old configurations. I haven't done this, but it seems troubleshooting is possible. Also, there are a bunch of XML files in /var for SMF that are human readable. SMF is just a big step from the traditional init mechanism, and it will take a while for people to get used to it.

I mean, we had damn near purged the world of programmers who put their opening brace for a new code block on the same line as the conditional statement, and then that Gosling dude from Java went and set us back 20 years.

I feel your pain on this one. Most of the *good* Java programmers use the newline syntax, but unfortunately too many companies follow the "Java Standard Coding Conventions" that say you should put the stupid brace on the same line. ARRGGHHH!

Sun Solaris 9 looks to have 17 patches available although this does include applications for Solaris 9 too. I didn't check for security vs. bug problems to narrow it down even more so the list of critical security is probably pretty small.

Jim

If Linus now supports the concept of proprietry file formats and decries the reverse engineering thereof, should we shortly expect an announcement about the removal of the NTFS filesystem driver from his tree?

If not, why not?

How is reverse engineering the NTFS filesystem format different to reverse engineering the BitMover File format>

I suspect that when Linus made this statement he had not considered the ramifications, and I am looking forward to seeing a clarification.

See also http://blogs.sun.com/roller/page/tpenta/20050411#d id_linus_really_mean_to

Tp.

I'm more inclined to believe that binary compatibility is difficult on the open source operating systems because they simply aren't designed for it. OSS folks seem to have no problem with "just recompile" rather than doing a bit of extra work in making sure their bits will be stable.

You can already get those, from Sun.

absolutely.

A DAO hould not have business rules, and neither should the UI, the previous post was just rididulous to suggest otherwise - clearly, they don't understand the DAO pattern. Here's a decent reference from the much maligned java blueprints: http://java.sun.com/blueprints/corej2eepatterns/Pa tterns/DataAccessObject.html

BTW - I read and use Hibernate in Action, and that is a book worth buying.

Urgh! Sorry, the URL for Mr Schwartz's blog should be
http://blogs.sun.com/roller/page/jonathan/20050404 .

If you read Mr Schwartz' weblog entry from Monday he goes into more detail about this (I'm sorry I didn't find that earlier, to also link it in my submission). In his blog, he calls the GPL a form of "IP colonialism" -- that sounds a lot more like an attack than a benign observation.

Weirdly, the CDDL that Schwartz (in the ZDNet article as well as the blog) says he prefers over GPL endorses the
requirement that source of modifications be made available. It seems to differ mainly in someone else's ability to later
"distribute executables under a different license." So, oddly, it seems that the CDDL he advocates would also force the poor, unwashed "developing nations" to "disgorge the source code of their IP" back to "the community" where someone else (like Sun) could incorporate those, and release the application as a binary under a different (closed) license.

Maybe he is dreaming of the olden days, when Sun incorporated Berkeley BSD code in SunOS and closed it up. But if so, what's wrong with the BSD license? Oh -- right -- that license wouldn't require anyone to disgorge the source of their modifications.

Finally, I'm not sure what you didn't like about my counterexample. If "the wealthiest nations" hadn't already put a lot of code under GPL then "the developing nations" wouldn't be facing this so-called problem. In other words, they are already "benefiting" from GPL code before they start "suffering" from having to follow the GPL

If you read Mr Schwartz' weblog entry from Monday he goes into more detail about this (I'm sorry I didn't find that earlier, to also link it in my submission). In his blog, he calls the GPL a form of "IP colonialism" -- that sounds a lot more like an attack than a benign observation.

Weirdly, the CDDL that Schwartz (in the ZDNet article as well as the blog) says he prefers over GPL endorses the
requirement that source of modifications be made available. It seems to differ mainly in someone else's ability to later
"distribute executables under a different license." So, oddly, it seems that the CDDL he advocates would also force the poor, unwashed "developing nations" to "disgorge the source code of their IP" back to "the community" where someone else (like Sun) could incorporate those, and release the application as a binary under a different (closed) license.

Maybe he is dreaming of the olden days, when Sun incorporated Berkeley BSD code in SunOS and closed it up. But if so, what's wrong with the BSD license? Oh -- right -- that license wouldn't require anyone to disgorge the source of their modifications.

Finally, I'm not sure what you didn't like about my counterexample. If "the wealthiest nations" hadn't already put a lot of code under GPL then "the developing nations" wouldn't be facing this so-called problem. In other words, they are already "benefiting" from GPL code before they start "suffering" from having to follow the GPL

On his blog (http://blogs.sun.com/roller/page/jonathan) at the April 1 entry he wrote:
{Quote}

The Downside of Being an Officer of a Public Corporation ...is that it's very difficult to write a good April Fools blog without feeling the need for serious engagement from the corporate legal team.

And much though I love Sun's lawyers, creative cooperation doesn't seem in keeping with either April Fools day, or our collective fiduciary obligations.

But it's not for a lack of creative ideas. You'll have to trust me on that...

{End Quote}

You'll notice this line:

"And much though I love Sun's lawyers, creative cooperation doesn't seem in keeping with either April Fools day, or our collective fiduciary obligations."

And then your take out the April Fools day bit, you get:

"And much though I love Sun's lawyers, creative cooperation doesn't seem in keeping with our collective fiduciary obligations."

And this, ladies and gentlemen, is Jonathan Schwartz stating that creative cooperation is bad for Sun's investors.

And what is the FOSS movement except creative cooperation? I say JS is full of caca and needs to quit his cushy job, move to the hills, write some wicked software and release it under the GPL before he talks about the GPL again.

On his blog (http://blogs.sun.com/roller/page/jonathan) at the April 1 entry he wrote:
{Quote}

The Downside of Being an Officer of a Public Corporation ...is that it's very difficult to write a good April Fools blog without feeling the need for serious engagement from the corporate legal team.

And much though I love Sun's lawyers, creative cooperation doesn't seem in keeping with either April Fools day, or our collective fiduciary obligations.

But it's not for a lack of creative ideas. You'll have to trust me on that...

{End Quote}

You'll notice this line:

"And much though I love Sun's lawyers, creative cooperation doesn't seem in keeping with either April Fools day, or our collective fiduciary obligations."

And then your take out the April Fools day bit, you get:

"And much though I love Sun's lawyers, creative cooperation doesn't seem in keeping with our collective fiduciary obligations."

And this, ladies and gentlemen, is Jonathan Schwartz stating that creative cooperation is bad for Sun's investors.

And what is the FOSS movement except creative cooperation? I say JS is full of caca and needs to quit his cushy job, move to the hills, write some wicked software and release it under the GPL before he talks about the GPL again.

I used to work at Sun(search for rburns-that's me). Sun management _could_ have listened to the folks at Sun that were telling them Open Source would be the wave of the future. They chose not to-and instead in violation of their own principles went whining to politicians to get various kinds of corporate welfare-that was supposed to help their company and create jobs for Americans-and didn't.

So why should we listen to these guys at all?

For good measure, let's look at the documentation from a J2EE vendor here.

While PEAK sounds intriguing, I'm not sure that major projects started by Fortune 100 globals will leverage a technology that lacks the level of documentation quality you can find in other products in that space.

I bring this up because documentation is often an indicator of the level of quality you can expect in terms of support. This is not to say PEAK is bad or poorly written, just that the supporting documentation and resources don't match those available for J2EE implementations.

Remember -- it isn't the best technology that wins, but the technology that is most accessible. In the case of enterprise APIs, even though PEAK may be easier and more scalable (and this is an excerpt from their page): But PEAK is different from J2EE: it's a single, free implementation of simpler API's based on an easier-to-use language that can nonetheless scale with better performance than J2EE. ...it will need some time and some nurturing in order to compete for mindshare with developers and non-technical decision makers.

For good measure, let's look at the documentation from a J2EE vendor here.

While PEAK sounds intriguing, I'm not sure that major projects started by Fortune 100 globals will leverage a technology that lacks the level of documentation quality you can find in other products in that space.

I bring this up because documentation is often an indicator of the level of quality you can expect in terms of support. This is not to say PEAK is bad or poorly written, just that the supporting documentation and resources don't match those available for J2EE implementations.

Remember -- it isn't the best technology that wins, but the technology that is most accessible. In the case of enterprise APIs, even though PEAK may be easier and more scalable (and this is an excerpt from their page): But PEAK is different from J2EE: it's a single, free implementation of simpler API's based on an easier-to-use language that can nonetheless scale with better performance than J2EE. ...it will need some time and some nurturing in order to compete for mindshare with developers and non-technical decision makers.

For good measure, let's look at the documentation from a J2EE vendor here.

While PEAK sounds intriguing, I'm not sure that major projects started by Fortune 100 globals will leverage a technology that lacks the level of documentation quality you can find in other products in that space.

I bring this up because documentation is often an indicator of the level of quality you can expect in terms of support. This is not to say PEAK is bad or poorly written, just that the supporting documentation and resources don't match those available for J2EE implementations.

Remember -- it isn't the best technology that wins, but the technology that is most accessible. In the case of enterprise APIs, even though PEAK may be easier and more scalable (and this is an excerpt from their page): But PEAK is different from J2EE: it's a single, free implementation of simpler API's based on an easier-to-use language that can nonetheless scale with better performance than J2EE. ...it will need some time and some nurturing in order to compete for mindshare with developers and non-technical decision makers.

Uh, well, here?

The doc generators don't actually remove the need to, well, document things. It's just handy to be able to move around through hyperlinks, to be able to see documentation of all a class' members (without having to go look at its superclasses), and so on.

And it's surely good to keep the comments directly above the relevant code rather than in some separate header file, so they are (marginally) more likely to be up-to-date.

most important release of the year?

• Tiger
• Tiger
• Vader
• Revolutions (wrong year, does it count?)
• Half-Blood... oops! Wrong site for this entry...

On the other hand, it would be nice to be able to specify a maximum bandwidth to use for prefetching as another option. However, perhaps a proxy-cache (like Apache or Squid) could recognize the

X-moz: prefetch

Solaris isn't much better. The Solaris 9 recommended cluster is a 149.9 MB zip file. Go to the patch portal: http://sunsolve.sun.com/pub-cgi/show.pl?target=pat ches/patch-access to see how big they've gotten.

Obviously. But I wasn't the one claiming that the logo implies compatiblity, that was you. And the logo looks just the same on all implementations, afaik.:)

So what is it now, does the logo or doesn't it mean that implementations are compatible?

For another intersting bit of information that you seem to be missing, there is no backwards compatibility between 'point-releases' of a Sun implementation either. See http://java.sun.com/j2se/1.4.2/compatibility.html# incompatibilities .

Why are you assuming I am not checking them for myself?

Because you believe that Sun's implementation is compatible, but you don't know it and refuse to check. Instead you voluntarily chose to rely on hearsay. You defend relying on hearsay, saying that it doesn't matter for you because you don't implement VMs, which I find pretty amusing, as in another breath you say:

However, something without the 'Java' label, indicating a TCK pass, is not going anywhere near my commercial servers.

That's pretty funny, as you don't seem to really know what the Java label indicates, have not seen the test suites, and apparently have an idea of compatibility that James Gosling makes jokes about in interviews[1].

What I find really fascinating is that Sun released 1.4.2 with a known compatibility test suite failure according to the page I quoted above. So much for the logo guaranteeing passing the test suite, I guess.

cheers, dalibor topic

[1] 'Well, I tested it myself and it seems to work OK for me,' or 'Hi, a bunch of my friends tested it and it worked OK.' See http://programming.itmanagersjournal.com/programmi ng/05/03/17/0131245.shtml?tid=56

That's J2EE. I asked for proof that Sun's VM passes all the tests. That's J2SE. They are very, very different things.

If you want to prove it to yourself. Here is the website for some test suites: http://java.sun.com/developer/technicalArticles/JC Ptools/

That's just a link to a description of the testing tools. It's not the tools, nor is it the J2SE test suite. Everyone can put up a cute web page saying they are compatible with something, but hardly anyone can actually prove it. And without proof, such claims are worthless.

Why should I care?

Because it's pointless to argue about compatibility without knowing what it is, and having means to verify it. You made the assertion that Kaffe is incompatible, but you can't even prove that Sun is compatible. So what's your point about invoking that marketing nosense? The branding program is just a way for Sun and their business partners to market themselves together, as far as I can see. It has nothing to do with real, verifiable compatibility.

It's like a cargo cult: just because it has a coffee cup logo on it, it must automatically be compatible. Yeah, right :) Microsoft's VM had red coffee cups slapped on it, too, and that didn't seem to work that well for guaranteeing compatibility.

cheers, dalibor topic

That's J2EE. I asked for proof that Sun's VM passes all the tests. That's J2SE. They are very, very different things.

If you want to prove it to yourself. Here is the website for some test suites: http://java.sun.com/developer/technicalArticles/JC Ptools/

That's just a link to a description of the testing tools. It's not the tools, nor is it the J2SE test suite. Everyone can put up a cute web page saying they are compatible with something, but hardly anyone can actually prove it. And without proof, such claims are worthless.

Why should I care?

Because it's pointless to argue about compatibility without knowing what it is, and having means to verify it. You made the assertion that Kaffe is incompatible, but you can't even prove that Sun is compatible. So what's your point about invoking that marketing nosense? The branding program is just a way for Sun and their business partners to market themselves together, as far as I can see. It has nothing to do with real, verifiable compatibility.

It's like a cargo cult: just because it has a coffee cup logo on it, it must automatically be compatible. Yeah, right :) Microsoft's VM had red coffee cups slapped on it, too, and that didn't seem to work that well for guaranteeing compatibility.

cheers, dalibor topic

That's what Open Source is: developing software in an open manner because of a belief that software developed this way is technologically better than closed-source software.

1. Free Redistribution

2. Source Code

3. Derived Works

4. Integrity of The Author's Source Code

5. No Discrimination Against Persons or Groups

6. No Discrimination Against Fields of Endeavor

7. Distribution of License

8. License Must Not Be Specific to a Product

9. License Must Not Restrict Other Software

10. License Must Be Technology-Neutral

This is much much more than "From a practical standpoint, it is sufficient that the tool or language meets the needs of the developers and is available on the required platforms, and does not appear to be a patent or other legal liability."

I hope that no one tries to learn OOP from this. Not only is it a poor explanation and example of what OOP is, but the code wouldn't even compile if you were to try.

If you want to learn OOP with Java somewhere, try this introduction.

The JVM source code IS AVAILABLE under the Sun Community Source Licensing. You can try it for yourself.

The SCSL is NOT an open source license (it doesn't give you the right to redistribute modified versions), but still it is much better than closed source. J2SE 5.0 is also available under the JRL (Java Research License) that allows sharing binary-based research distributions of Java.

Sun is preparing a tweaked license for J2SE 6.0 called JIUL (Java Internal Use License), in an effort to show that "the company wants to make Java as open source as possible while maintaining platform compatibility". You can read two recent articles on this topic in infoworld and news.com .

As for the GPL-compatibility, I remind you that most open source licenses are NOT GPL-compatible. Neither the Apache License nor the Mozilla Public License are GPL-compatible and this has not stopped the Apache httpd nor the Firefox widespread adoption in the open source community. Expecting Sun to release its JVM source code under a GPL-compatible license is nonsense. What we can realistically expect in the near future is a license scheme that would allow free redistribution in a company. They make this to please large companies like IBM, that has been complaining for some time now that the Sun JVM is not open source.

However, nobody is forced to use the Sun JVM. GCJ and Kaffe are GPL, aren't they?

The JVM source code IS AVAILABLE under the Sun Community Source Licensing. You can try it for yourself.

The SCSL is NOT an open source license (it doesn't give you the right to redistribute modified versions), but still it is much better than closed source. J2SE 5.0 is also available under the JRL (Java Research License) that allows sharing binary-based research distributions of Java.

Sun is preparing a tweaked license for J2SE 6.0 called JIUL (Java Internal Use License), in an effort to show that "the company wants to make Java as open source as possible while maintaining platform compatibility". You can read two recent articles on this topic in infoworld and news.com .

As for the GPL-compatibility, I remind you that most open source licenses are NOT GPL-compatible. Neither the Apache License nor the Mozilla Public License are GPL-compatible and this has not stopped the Apache httpd nor the Firefox widespread adoption in the open source community. Expecting Sun to release its JVM source code under a GPL-compatible license is nonsense. What we can realistically expect in the near future is a license scheme that would allow free redistribution in a company. They make this to please large companies like IBM, that has been complaining for some time now that the Sun JVM is not open source.

However, nobody is forced to use the Sun JVM. GCJ and Kaffe are GPL, aren't they?

Your memory is apparently not as good as you think it is. Java was released as Java in early 1995.

You better check your facts

On the other hand, you can freely download jre and jdk from the sun website and though I'm not sure whether that is open sourced or not, there is always the open sourced blackdown java implementation.

The Java JRE and JDK may be free as in beer, but it isn't free as in speech. Far from it.

The Java JDK and Blackdown is open source, but it is encumbered. What I mean by encumbered is that it is distributed under a very wordy/legalese and restrictive license; read it for yourself to see what I mean. It's almost like an EULA. To make a long story short, it is open sourced, but it's proprietary, too.

Java is many things. It is a programming language. It is also a runtime environment in the form of a protable virtual machine. It also comes with a huge class library.

For some reason, that monkey Miguel went and decided to write his own version of M$'s Java clone, C#/.NET, for "Linux" (i.e. Unix-like OSes) to undermine everyone else's work.

Now, you can get branded Java from people other than Sun e.g. IBM. IBM is currently a great favourite of the slashdot peanut gallery.

In addition, gcc comes with a Java-language to native code compiler as well as byte code (to run on the evil, nasty closed-soure Sun (or IBM or whoever's) JVM).

If you don't like Sun, or IBM, or Blackdown or kaffe's JVM, including their JIT compilers which can optimise to exceed the efficiency of statically-compiled code, then you can always revert to gcc's Java language compiler.

However, I'm sure these facts will be conventiently ignored for the sake of a good, heated argument, and many rants.

Just like others have found out with C/C++ on other platforms, you can twiddle bits and get faster performance with Java on cell phones too. You just have to know what you're doing ;-) which hopefully Mr. Carmack will continue to do to find the secrets of J2ME technology that some already have discovered.

Also, you can deride JIT compilers on message boards, but if you take a look at Jbenchmark numbers, you'll see there is a world of difference between different Java VMs with different kinds of JITs, just like a Mustang with a 4-cylinder engine is different than a Mustang with a 5.0 liter engine.

It's easy to take pot-shots at Java technology for cell phones hiding behind a computer monitor, but those of us in the trenches who know how to work J2ME programming (like now John Carmack is starting to learn) will do well on the 650+ million cell phones that run J2ME technology.

Hinkmond

Java is not free, and this becomes painfully clear the moment one wants to build JDK/JRE on a non support platform like *BSD. As part of the build process you have to manually go to Sun site to agree to a license (after registering) before you can download needed sources.

Making a free product by introducing non-free base functionality is not the way to go.

I haven't heard anything so retarded since the last time I heard steve balmer give a speech. How excactly is ".net much more free than java"? Last time I checked, microsoft was not giving away any open sourced versions of any .net compilers without at least purchasing the operating system, so it's not really giving it away, plus its not open sourced. On the other hand, you can freely download jre and jdk from the sun website and though I'm not sure whether that is open sourced or not, there is always the open sourced blackdown java implementation.

So the closest thing I see to irony here is that in order to defend microsoft, you have to be totally ignorant to the everything, much like all of microsofts products.

The Java platform that runs on most cell phones is J2ME, which is a completely different animal than J2SE, the one that's used on PCs.

The differences are substantial. For example, some J2ME VM's don't garbage collect. Ever. That's because in some cases, it's not required.

To say that the J2SE (or J2EE) plaforms suck because a particular J2ME implementation is slow is like saying that internal combustion engines suck because your go-kart can only go 15 mph.

The Java platform that runs on most cell phones is J2ME, which is a completely different animal than J2SE, the one that's used on PCs.

The differences are substantial. For example, some J2ME VM's don't garbage collect. Ever. That's because in some cases, it's not required.

To say that the J2SE (or J2EE) plaforms suck because a particular J2ME implementation is slow is like saying that internal combustion engines suck because your go-kart can only go 15 mph.

I read the developer quickstart guide, and still can't figure out if this will help me with integrating a Java application.

Right now, I use an installer based on IzPack, which works but results in an application that must be started from a shell script and does not integrate in the desktop. In particular, the user can not just double click files that have been created with my application. Also annoing is the fact that the installer includes trivial libraries like log4j, which causes bloat. And worse, some libraries have to be downloaded manually, in my case JAI. I'd say my application is a horrible user experience under Linux.

However, the developer quick guide just keeps talking about about C compilers, GTK and other stuff I don't use or care about. Is there any point in taking a closer look at autopackage?

There's actually been some justification for this type of effect. Take a look at this paper that talks about classic principles in cartoon animation and how they can be applied to user interfaces.

When things happen my first suspicion is that the cock up theory is often the best explanation, even more so when complex software is involved, rather than assume a conspiracy.

Actually, null characters are used to terminate strings, so if there's one byte left to be read and it's a null character, the read routine would just return a string with length of zero. If it's the EOF character, it would return -1.

That's true in C, but not in Java. Try this code fragment:

byte[] bytes = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
String string = new String(bytes, "UTF-16LE");
System.out.println(string.length());
System.out.println("'" + string.codePointAt(1) + "'");

The first println will output "3" and not "0", even though it is a string of just null characters. You can verify this by the second println, which prints the bytes (as an integer) of the second character. It will ouptut "'0'" too.

Just one of the advantages of Strings as Objects. Of course, sometimes you just have to dig into the bytes as I did in this project (comments encouraged!).

They usually do provide both. I work on the J2EE Tutorial, which documents the APIs included in the J2EE platform. There's also the Java Tutorial, which documents the standard JDK/JRE platform APIs. For other APIs, check the BluePrints or other tutorials & code camps. Not to mention the case studies and the code samples bundled with other distributions.

The problem with including tutorial or extensive sample material in API documentation is it's too disparate, and not useful when dealing with more complex applications that use a number of APIs. If you're writing a servlet that uses JDBC to pull data from a database, where does the sample code go?

-ian

They usually do provide both. I work on the J2EE Tutorial, which documents the APIs included in the J2EE platform. There's also the Java Tutorial, which documents the standard JDK/JRE platform APIs. For other APIs, check the BluePrints or other tutorials & code camps. Not to mention the case studies and the code samples bundled with other distributions.

The problem with including tutorial or extensive sample material in API documentation is it's too disparate, and not useful when dealing with more complex applications that use a number of APIs. If you're writing a servlet that uses JDBC to pull data from a database, where does the sample code go?

-ian