Slashdot Mirror

This might be EXTREMELY useful for corporate LAN/WAN's

Sun's SunRay has been doing this for years; you simply carry around your smart card, and insert it into your local terminal. All of your preferences travel with you. From their FAQ:

Sun Ray ultra-thin clients also support "Hot Desking," providing users with immediate access to their unique sessions from any Sun Ray ultra-thin client in their workgroup.

This might be EXTREMELY useful for corporate LAN/WAN's

Sun's SunRay has been doing this for years; you simply carry around your smart card, and insert it into your local terminal. All of your preferences travel with you. From their FAQ:

Sun Ray ultra-thin clients also support "Hot Desking," providing users with immediate access to their unique sessions from any Sun Ray ultra-thin client in their workgroup.

Don't really have to imagine anything Sunrays already do this - just they aren't widely deployed. Is it just my or is it getting boring having people think things don't exist just because Microsoft isn't doing it.

Sun's has had this working for years on Sun Ray thin clients. Your working session is frozen when you remove a smart card, and is resumed on another appliance when you put the smart card back in. It works all over the country, so a session can be resumed anywhere.

Look : you may not actually like Java, for whatever reason, but not facing up to the facts (facts that are easily available), won't actually make Java disappear.

What I don't like is people using meaningless numbers and half-truths to prop up some commercial product that isn't even very good technically. As for Java disappearing, it will do that on its own, and I predict, pretty soon.

Please tell me: where can I find that "free, certified complete and compatible, open source implementation of J2EE"?

JBoss and Tomcat.

See, here you are doing it again: you talk about "free, certified complete and compatible, open source", yet that is misleading. JBoss and Tomcat may be free and open source, but they are not all of J2EE, which includes J2SE. And the distinction isn't academic: in order to run JBoss or Tomcat in a "certified complete and compatible" environment, you need Sun-proprietary software. What good is it that JBoss is open source if the open source community has no control over the underlying platform and will never get such control?

Why do people like you keep misrepresenting Java as something that it isn't?

I have nothing against PHP; it's a great tool for some jobs, and I use it on some of my sites. But it's not the right tool for every job.

That sounds exactly like Sun's Sun Ray thin clients, except they use smartcards instead of floppies.

Put in your smartcard, and you get your session. Pull it out, and it disappears. Move to another terminal, repeat. The smardcard only has your keys.

No, i don't work for sun, and I just forgot my account data :)

What Every Computer Scientist Should Know About Floating-Point Arithmetic

Actually, the 'Java 2 Standard Edition Version 1.2' crap came out of Sun's contract with Microsoft, which required Microsoft to ship any class libraries that Sun included in a 1.x release.

I couldn't find a copy of Sun's contract with Microsoft, wherein this language could be found, but I did find an old copy of Sun's complaint against Microsoft which touches on some of the terms of the contract.

The Java versioning madness was all about keeping Microsoft on the hook for supporting new releases. That said, Sun has _always_ had squirrely release numbering. SunOS/Solaris is a prime case in point, Microsoft contract or no.

Look at these:

IBM z/OS V1.x
one vulnerabilty (in Sendmail, which was ported to z/OS)
By the way, most (if not all) parts of z/OS were written in PL/1.

IBM OS/400 - V4.x, V5.x
zero vulnerabilities
(Note, that OS/400's kernel ("SLIC"), written in C++, is absolutely closed code (afaik you can't even access its machine code on the iSeries 400's DASD), so nobody outside IBM knows, what kind of bugs might be in that kernel; anyway, because of its single-level storage architecture, this system has hardware pointer-in-memory protection, which, as a side-effect, prevents many of the most dangerous kinds of exploits, for example overwriting of return-addresses, overwriting of function pointers and such; so it's impossible to "smash the stack" on this machine)


Conclusion:
===========

To err is human; as long as people use Assembler, C or similar programming languages, they will probably cause buffer overflows and similar bugs; for this reason, we should take advantage of more intelligent hardware architecture, including features like tagged pointers and special CPU instructions for modifying addresses (so you still can change a function pointer, but only if you use the correct instruction; overwriting it using instructions for copying data areas (MOV on intel) would cause the pointer protection hardware to invalidate the pointer). Better hardware is a good foundation for better software. "Protected mode" (memory protection, preemptive multitasking, ...) brought us stable operating systems; some new hardware could get us stable and secure operating systems. By secure I DON'T mean hardware-addons like TCPA. TCPA is inadequate for a free-programmable computer architecture.

Use a suitable programming language to implement applications; you don't need to mess around with direct memory access, pointers and such, if you're programming software for accounting or a spread sheet application. Many commercial applications for z/OS and OS/400 are written in COBOL, PL/1, etc. rather than in C, and they do not seem to have nearly as many critical bugs as most C programs; OpenVMS people will tell you the same story, I don't know what programming language they used to write most of their applications, but I know it wasn't C.
If you can't get an open source Ada, Cobol, PL/1,... compiler, at least use C++ (use std::string).
Don't forget Java; java programs might not be as fast as compiled code, but especially non-GUI applications are still pretty fast, and Java is a well-designed language.

Unfortunately, there are no results for trusted operating systems such as Trusted Solaris; it would be interesting, whether the same bugs that are critical on standard operating systems could cause system access or any similarly critical escalation of privileges on trusted operating systems (my guess is, commonly not; these systems have extremely strong security implemented in kernel code). By the way, Solaris 10 will include many key security features that were only available in Trusted Solaris before (including privilege sets and compartment-like process separation).

Book hint: "The Inside Story of the IBM iSeries" by Frank Soltis, the system architect of the iSeries 400 (aka AS/400) and OS/400; especially interesting because of the fact, that this system's design is very different from common hard- and software architecture;

Look at these:

IBM z/OS V1.x
one vulnerabilty (in Sendmail, which was ported to z/OS)
By the way, most (if not all) parts of z/OS were written in PL/1.

IBM OS/400 - V4.x, V5.x
zero vulnerabilities
(Note, that OS/400's kernel ("SLIC"), written in C++, is absolutely closed code (afaik you can't even access its machine code on the iSeries 400's DASD), so nobody outside IBM knows, what kind of bugs might be in that kernel; anyway, because of its single-level storage architecture, this system has hardware pointer-in-memory protection, which, as a side-effect, prevents many of the most dangerous kinds of exploits, for example overwriting of return-addresses, overwriting of function pointers and such; so it's impossible to "smash the stack" on this machine)


Conclusion:
===========

To err is human; as long as people use Assembler, C or similar programming languages, they will probably cause buffer overflows and similar bugs; for this reason, we should take advantage of more intelligent hardware architecture, including features like tagged pointers and special CPU instructions for modifying addresses (so you still can change a function pointer, but only if you use the correct instruction; overwriting it using instructions for copying data areas (MOV on intel) would cause the pointer protection hardware to invalidate the pointer). Better hardware is a good foundation for better software. "Protected mode" (memory protection, preemptive multitasking, ...) brought us stable operating systems; some new hardware could get us stable and secure operating systems. By secure I DON'T mean hardware-addons like TCPA. TCPA is inadequate for a free-programmable computer architecture.

Use a suitable programming language to implement applications; you don't need to mess around with direct memory access, pointers and such, if you're programming software for accounting or a spread sheet application. Many commercial applications for z/OS and OS/400 are written in COBOL, PL/1, etc. rather than in C, and they do not seem to have nearly as many critical bugs as most C programs; OpenVMS people will tell you the same story, I don't know what programming language they used to write most of their applications, but I know it wasn't C.
If you can't get an open source Ada, Cobol, PL/1,... compiler, at least use C++ (use std::string).
Don't forget Java; java programs might not be as fast as compiled code, but especially non-GUI applications are still pretty fast, and Java is a well-designed language.

Unfortunately, there are no results for trusted operating systems such as Trusted Solaris; it would be interesting, whether the same bugs that are critical on standard operating systems could cause system access or any similarly critical escalation of privileges on trusted operating systems (my guess is, commonly not; these systems have extremely strong security implemented in kernel code). By the way, Solaris 10 will include many key security features that were only available in Trusted Solaris before (including privilege sets and compartment-like process separation).

Book hint: "The Inside Story of the IBM iSeries" by Frank Soltis, the system architect of the iSeries 400 (aka AS/400) and OS/400; especially interesting because of the fact, that this system's design is very different from common hard- and software architecture;

By their contributions to the BSDs? Apple uses FreeBSD a lot but it's only a trickle back. Sure, they give some gnawed bones to the FreeBSD kernel guys, but what about the rest of BSD?

Seeing this, it implies to me that you are just ranting with no idea what you talking about. The part of FreeBSD that Apple is not using is the kernel. They are using the BSD w/ Mach thing that they inherited from NeXT. It is the user space utilities that are mostly from FreeBSD. Instead of the ones that shipped with NextSTEP (the ones they licensed from Berkeley before BSD became free software) which were getting a bit long in the tooth, they grabbed most of /bin and /usr/bin/ from FreeBSD.

The comment about Open Source shipped by Sun seems misguided as well. First of all, Sun shipping open source software packages is a very recent phenomena. Solaris Freeware. shows the packages that ship with Solaris 9. A small portion of those titles were distributed with Solaris 8 (I'm thinking less than a half dozen. That was the release they added ssh and Apache.) In Solaris 7 and earlier, the only thing close to free software were the hacked up binary only versions of Sendmail and and Bind.

I don't quite understand why you keep harping on OpenOffice too. They bought a failing company producing an office productivity suite because they wanted some sort of word processing and spreadsheet option to sell with the workstation systems. It was sort of like SGI buying the MIPS CPU maker. It wasn't good for them to do, but it would be disastrous for them no to do.

And Sun doesn't ship a lot of boxes. They ship a lot of boxes for a server manufacturer, which isn't quite the same thing.

Exactly. Sun called Java 1.2.0 Java 2, so java 1.5.0 is called Java 5 becouse there won't be a Java 2.0.0 anyway.

However the name is "Java 2 Platform Standard Edition (J2SE) 5.0" :S

Wasn't SunOS at something like 5.3, then Solaris 2.4 through 2.7?

AFAIK: SunOS went to version 4.x, then came Solaris, which was SunOS 5.x. (If you telnet to a Solaris box, it will tell you it's SunOS 5.x.)

I'm not sure where the 2.x came from. I suppose it's a marketing-inspired number to differenciate from the old SunOS.

By the time they reached Solaris 2.7 (a.k.a. SunOS 5.7), they decided there would not be a Solaris 3.x, and they dropped the major number, so the next version was Solaris 8.

(I guess the next version would be X...assuming there's a next version)

That would be Solaris 10. It was announced a few months ago.

Any indications yet as to when we'll see Tiger on Tiger (which sounds vaguely like an educational nature film made by the somewhat kinky)? Once we get past OS X 10.4 (which, by the way, is another weird versioning scheme), it starts to sound like a great cats breeding program.

If *I* looked like that, I'm not sure I'd plaster my face all over the Internet!

No, its not Java 2 version 5. Its Java 5.

From the article:

Sun Microsystems, Inc. (Nasdaq: SUNW), the creator and leading advocate of Java technology, today introduced Java 2 Platform Standard Edition (J2SE) 5.0, the most significant upgrade to the Java platform and programming language since its initial release nearly one decade ago.

From the download page

J2SE 5.0 Beta 2
Download Java 2 Platform, Standard Edition 5.0 Beta 2

It reads to me like Sun will call this Java 2 Version 5.

I was going to make a joke about how Sun is still calling it the Java Development Kit release 1.1 for Java 2.0 version 5.0, but this has been frequently noticed by others in this thread. So for those who are not interested in sorting through the bewildering list of packages available on the Java Download page, here's an ugly ascii kitty cat.

^ ^
=o.o=
~

If you have a URL for these services, please post it here. I know several school administrators that would be interested in such services. I have three questions:

• Who does the admin once you set these up?
• Can these be configured for session mobility ala SunRays? I know that it can be done with VNC, but can it still be done with a physical Xterminal?
• Can these be integrated with some sort of physical authentication, like smartcards?

Never post your email address on slashdot. I got 900 emails!

I remember sending him an email. I also remember mentioning that the methodology (him mailing you the file) as opposed to downloading it or using Java Webstart was not the smarted way to go about doing this.

Finally, I also remember he never sent me an invite even though I asked. Oh well, glad it worked out for him in the long run.

At my university we have some 30-40 X terminals running on one Solaris server (a quad processor server with 4G RAM, aptly named "beast"). The thin clients are Sun Rays. I don't know how much they cost, but I know the X terminal principle is very flexible compared to the 4-terminals-on-one-PC option: you can use a single server to serve terminals that can be spread out over a wide area, instead of next to the PC in question. If there would just be a cheap X terminal solution available, I think it would be a perfect solution for public libraries and internet cafes.

Oh for the love of...

• SAX isn't Sun's API.
• It wasn't replaced, Sun added JAXP.
• SAX is not deprecated.
• It's still in the JDK.

Oh for the love of...

• SAX isn't Sun's API.
• It wasn't replaced, Sun added JAXP.
• SAX is not deprecated.
• It's still in the JDK.

What you're describing would break the equals() contract in Java and probably a number of other languages, causing container classes like hashtables to break into a thousand pieces or, if you're unlucky, work without error but in a completely unexpected way.

Mono definately has legal issues that need to be cleared up before it should be used. Microsoft can currently kill Mono anytime they wish.

• Microsoft HAS NOT put anything under a royalty-free licence by submitting the standard to the EMCA. The EMCA stipulates that the C# standard has to be released RAND (Reasonable & Non-Discriminatory) Licence. Microsoft can start charging fees at any time for implimenting a C# VM.
• Even if they never start charging money, they have pantented the Hell out of the standard and can sue Mono for infringment.

It may take time to get features in through the JCP, but it also ensures there are no hastily implemented hacks making their way into the system.

Now that's what I call comedy!

What are those deprecated classes and methods, then? Even things as simple as date and time classes and InputStreams were hacked in, then deprecated and replaced. Then there's the SAX parser, which was replaced with a totally different API...

Take a look here I think you'll find that many things tend to be tuned more toward Solaris environments first.

I totally disagree that Java has absolutely no aspects of a beautiful/easy-to-use language. I think you're neglecting the fact that when Java burst on the scene in '95, it provided a simple means to write cross platform applications in a way C/C++ did not out of the box.

I worked on a satellite system for NASA written in C++ that was originally spec'd to work on five UNIX platforms. Keep in mind this is in the days before Linux became widely adopted... and this system was a major headache because:

• Because of the lack of POSIX compliance between the platforms, we were in #ifdef PLATFORM_NAME hell. Heck, even when we tried to performance tune the application, we wound up with gobs and gobs of #pragma directives and custom code to either work around bugs in a target platform, or just improve performance (for example, by aligning data structures to specific address boundaries).
• Byte endian issues had to be solved at a fine-grained level, requiring each developer to write their own serialization/de-serialization code. At least until we began using Rogue Wave's Tools.h++.
• Helping folks manage deployment of their applications meant learning how each separate platform managed dynamically linked libraries. In fact, I recall silly bugs caused by circular dependencies in APIs we used that often required juggling the order of libraries during linking.

This is not to slam C++ in its current incarnation, but to point out that when Java first arrived on the scene, the restrictions and smaller set of APIs made it easy to ramp up developers who could then build cross-platform applications much quicker.

As for your specificpoints, let me explain where I disagree:

-primitive types and associated classes: When I want to store a variable of one the primitve types like int (the ones you use in every class) you have to wrap them into a class (Integer) which has no way to change the Value later. So everytime I want to e.g. increment a counter stored this way, I have to convert it back to int, increment it und create a new Integer-Object to store the incremented value back into my container-class.

Primitive types are (IMHO) a bit of a hack in Java, but they behave much like primitive types in C++. Granted, lacking generics (pre-Java 1.5), Java cannot support arbitrary collections of primitives, but consider this: if you want to store and manage collections of primitive types, couldn't you write your own class to either "wrap" the primitive type? I'd also recommend wrapping the Collection you're using to simplify the mutators.

-If I want to compare two Classes I have to use the equals-Method instead of a simple operator-overloading which would enable me to use ==

I can't count how many times I ran into incompatibly defined flavors of operator overloading in "mediocre" C++ code where bugs in operator overloading introduced logic errors that were hard to find.

Inn the case of equals(Object) versus the == operator, consider this: in Java they have two completely different purposes. If you want to compare two object references to see if they refer to the same object, use ==. If you want to compare the contents of the objects they refer to, use equals(Object). Consider the ambiguity and potential for flaws when the operator's behavior could be changed to deviate from comparing references to Objects!

This is a case where I believe that removing a feature from a language makes it easier for developers to avoid dealing with obscure bugs while trying to get an application done.

-When I retrieve an Object from a Container it is a java.lang.Object instead of the type I stored which totally negates the advantages of static typing Solved in Java 1.5 with Gener

and the most recent VMs allow VM sharing - you can make use of the same VM for more than one program, you statement is false.

You don't really share a JVM, at least not on Sun's latest implementation (doesn't the Apple Implemenation actually share the JVM? I'm not sure).

What does happen is that all the core classes get memory mapped to a file at startup, which is then marked readonly. Subsequent JVM's can then also use the same mmapped file, allowing for faster startup and diminished memory usage. This process is explained in detail here.

Java is not the best for command line programs mainly because VM initialization is expensive (in terms of time). This could be possibly alleviated by having a system-level VM that was initialized at boot time or something, and programs would just attach themselves to an already-initialized VM;

Startup time for commandline apps has impoved a lot with JDK 1.5^H^H^H 5.0.

The (albeit limited) implemetation of classdata sharing makes things run better.

All those "omg java is teh suxx0r !!1!111" people should try it once before perpetuating so called facts that stem from the days of JDK 1.O

If that's the case, maybe Apple and Sun should get together to patent the newer 3-d desktops so that Microsoft can't put that in Longhorn. Slashdot article on Sun's new desktop... Screenshots here. If Apple and Sun work together we'll all have to wait 10 more years while M$ re-works all their code! Yay!

Keep in mind that there are two aspects of Project Looking Glass at the moment. The first is the "proof of concept" demo (you can see a video of this demo here) and the second is the "developer's release" on java.net. Not all the features in the proof of concept are currently implemented in the developer's release.

Also, remember that this is an early access, open development project. Questions about to usefulness of these concepts can and should be openly debated. I discuss some of Sun's thinking in my blog.

Keep in mind that there are two aspects of Project Looking Glass at the moment. The first is the "proof of concept" demo (you can see a video of this demo here) and the second is the "developer's release" on java.net. Not all the features in the proof of concept are currently implemented in the developer's release.

Also, remember that this is an early access, open development project. Questions about to usefulness of these concepts can and should be openly debated. I discuss some of Sun's thinking in my blog.

The increase in international outsourcing is only going to compound this problem in the future. In my experience the outsourcing firms feel even less "investment" in codebases they contribute to than normal contractors. This, coupled with a definite mercenary attitude towards development can lead to some very dubious code. They are paid for rapid, loosely overseen development, aren't responsible for support, and their salary isn't based on the success or failure of the product. Even if they are held accountable for "borrowed" code, enforcing copyright and IP laws internationally is extremely difficult in the best of situations.

A related issue is where to set the line when copying is fair-use and when it becomes theft. The tutorials from Sun for Java contain some fairly useful code, but they also have a Sun copyright plastered across their headers. For example, the lack of a "TreeTable" widget in Java is compensated for by a detailed example of rolling your own, here. But if you look at the source, some of it is free of any headers, and other bits contain things like:

/*
* @(#)JTreeTable.java 1.2 98/10/27
*
* Copyright 1997, 1998 by Sun Microsystems, Inc.,
* 901 San Antonio Road, Palo Alto, California, 94303, U.S.A.
* All rights reserved.
*
* This software is the confidential and proprietary information
* of Sun Microsystems, Inc. ("Confidential Information"). You
* shall not disclose such Confidential Information and shall use
* it only in accordance with the terms of the license agreement
* you entered into with Sun.
*/

Personally, I'd never allow code derived from this into a sourcetree I managed out of paranoia, but I can completely see how most people (perhaps rightly) would see this code as fair game for reuse. Picking up code from an acquired company or contractor which borrows from code of similiar origins is almost unavoidable.

The screenshots for Metisse suck and you can only use FVWM - what gives? It is a great demonstration of how productive Java is though.

There was an article a while back saying that the language doesn't matter for security because it is bad programming that is responsible. Even without looking at the source I can guarentee there's no buffer overflows, double-free's, format string exploits, etc in Looking Glass. And I would bet my life savings there's at least several in Metisse.

There was an article recently about Java performance where most posters insisted it's still slow and jerky, but the movie of Looking Glass sure looks good to me. It's sad that people still use C/C++ to create lame hacks like this Metisse when there are such better alternatives. Can you imagine if the whole OS was written in a modern language?

I guess this is pretty technically cool, but as a user of a desktop system (aren't we all?) I'm not actually sure of how this would benefit me. Would I, for example, be more efficient in my job using this?

Have you checked out the video demo of using Looking Glass? It looks pretty slick, and while it's hard to say whether in its present form it would make a better desktop, it certainly shows that a 3D desktop could potentially be in many ways better than the modern 2D desktops.

The current projects like Looking Glass and Metisse aren't meant for large-scale use immediately. They are experiments in what a 3D desktop could offer, and whether it could provide a better user experience. In the future typical desktop computers will have more and more CPU/GPU power to spare, so speding it on the user interface is only beneficial.

After seeing the Looking Glass demo above, I'd say that anybody claiming straight out that a 3D desktop is of no use whatsoever is pretty short-sighted. Who knows, maybe Looking Glass will become the next killer desktop? Maybe a 3D desktop is a bad idea and counter-productive? These projects are made specifically to find that out.

It's true that Palm is the obvious choice for the budget conscious (besides the obvious and time tested pencil and notebook).

As for the physical standard, it seems to me that we're sort of getting there. Theoretically with bluetooth enabled devices you can add and remove what you need (or don't) from your handheld. However this only works for peripherals, not core components. You can't change the screen size or add memory that way... Storage is more or less standardized on SD cards (or CompactFlash on some models). Interface extensions (such as WiFi) should come in SD format as well.

So provided you stick with bluetooth stuff, and if it all works as advertized and if you don't buy Sony hardware (which refuses to use standard storage) and if SD cards indeed one day provide wireless network... we should get that physical standard.

Maybe. :)

Let's keep our fingers crossed :)

BTW I just saw (after writing my first comment above) that Sun had released a Java VM (J2ME) for PalmOS (v 3.5 or better) which should run on most current machines. Through Java, writing apps probably becomes much simpler than with the native toolset.
Of course this means you're stuck with a proprietary VM but you're writing apps for a proprietary system anyway. At least this way the apps will also run on WinCE and possibly on Java enabled phones, Symbian machines, etc.

More info :
J2ME
J2ME for PalmOS

It's true that Palm is the obvious choice for the budget conscious (besides the obvious and time tested pencil and notebook).

As for the physical standard, it seems to me that we're sort of getting there. Theoretically with bluetooth enabled devices you can add and remove what you need (or don't) from your handheld. However this only works for peripherals, not core components. You can't change the screen size or add memory that way... Storage is more or less standardized on SD cards (or CompactFlash on some models). Interface extensions (such as WiFi) should come in SD format as well.

So provided you stick with bluetooth stuff, and if it all works as advertized and if you don't buy Sony hardware (which refuses to use standard storage) and if SD cards indeed one day provide wireless network... we should get that physical standard.

Maybe. :)

Let's keep our fingers crossed :)

BTW I just saw (after writing my first comment above) that Sun had released a Java VM (J2ME) for PalmOS (v 3.5 or better) which should run on most current machines. Through Java, writing apps probably becomes much simpler than with the native toolset.
Of course this means you're stuck with a proprietary VM but you're writing apps for a proprietary system anyway. At least this way the apps will also run on WinCE and possibly on Java enabled phones, Symbian machines, etc.

More info :
J2ME
J2ME for PalmOS

Back in the earlier days of Java (1.1.6-1.1.8 era, 1997-98 I think) there was very little in the way of off the shelf persistence management. You had servlets and JDBC and that was about it. Everybody rolled their own database interface layer, and basically what worked well was to have the hand-written SQL hidden in a small set of classes that each know how to various persistence operations for one object. This practice has been canonized as the Data Access Object pattern and works pretty well.

Even with modern persistence frameworks like Hibernate (highly recommended, BTW) that have caching, you can hide that activity in a DAO and decide later whether you need to replace the autogenerated SQL with some fancy hand coded stuff. Complex object-relational mappings (i.e. not a simple table=class setup) are actually expressed declaratively so that's not something the coders have to worry about.

The point is that it's encapsulated, so any "impure" decisions that you must make in order to get the system working properly for real-world use are very localized.

I would say that mapping the object model to the data model directly in such a way that you can't change it later is actually a counterexample of encapsulation. Ideally they should look pretty similar but be mapped by some intermediate layer that can adjust for the differences.

You can see a working demonstration here.

Note: You might want to tie a scarf around your head to keep your jaw from smacking your keyboard.

Also: In the future, you might want to consider shoving a roll of mints up your butt so that when your foot comes out your mouth your breath won't reek of so much ass.

Personally I like this display from Sun. It has a USB hub, Svideo, DVI, and VGA inputs. It's matched the G5 since before the G5 came out and doesn't reuire a special video card.

Well, the GNOME Human Interface gudelines and the KDE User Interface Guidelines are there exactly for this. GNUStep probably uses the OpenStep ones, since it is an OpenStep replica.

Hint: in absence of a single authority having the power to dictate how thing should be done "OR ELSE", this is the only sane way to do it: define reasonable guidelines and tell developers about them: many will follow.

This ain't just someone's Ph.D project.

I find Sun's choice of pretty background pictures very distracting when attempting to evaluate the merits of this desktop system, and I'm sure this was intended as a marketing trick. I would have preferred shots with a plain background to really see the features of the desktop.

In fact, this shot is nothing more than the background! (and the 3d version of a standard 2d taskbar) They say, "Just imagine what is possible if it were live video." -- It's more like, "Imagine a pratical use for this '3D' desktop".

Because Sun has had to hash out many of the issues of scalable vector drawings, gradients, etc. that would be very useful in an SVG implementation that could be incredibly powerful for resolution independent, dynamic web applications in an open standard, open source way (as opposed to Flash or PDF).

[I know that ghostscript has many of those issues worked out, too, but the code base was started back in the days of C and DOS and might not be as nice to work from as the Java 2D API. The Mozilla and KDE SVG efforts might benefit from an open source Java 2D.]

The demos are really cool. But the biggest issue, which I think is apparent in the demos also, is that you get these frame rate drops. The best I can tell from playing around with Java3D, this happens because the API is allocating a bunch of objects during rendering. The garbage collector has to come by and get rid of them and it takes long enough to release the unused objects that it interferes with the rendering thread. This turns out to be down right distracting in animation.

What? I've used Java3D, and it seems to me that they went through great pains to ensure that nothing is allocated unless you ask it to be allocated. You're right, the GC can interfere with the rendering thread, but I've never had an issue with the Java3D library causing the GC to kick in. In fact, the Java3D API can look a little awkward when you're used to APIs that are not so sensitive about allocation. They usually design their APIs so you can reuse previously allocated objects. That way, you don't have to release them to the GC, and your performance is more predictable.

For an example of this, examine the GeometryArray class. First, note that it is highly mutable. Everything about the object can be modified, so you never have to create another instance if you already have a spare one lying around. Also, take a look at how all of the setXXX() functions are overloaded so you never have to allocate an object to call the setter. While the API could have just provided one set() method and required you to create an object of the correct type to call it, they decided to instead overload it for any reasonable type that could be used to represent that property.

Are you sure that it's Java3D that's allocating the objects and not the code you wrote?

I entered Equinox site and it doesn't seem to be using Java3D. At least the 3D samples have this label "No Java3D plugin required. No hardware rendering".
You should take a look at Sun GC site. Tuning the GC may help.

If this is indeed the grandparent posters problem, he's using strictfp on all his methods. I doubt he does, since few people even know of its existance.

However, I also do not believe the numbers he was posting. It did have that trollish odour to it. I would very much like to see his test code. There must be something wrong with it.

Here's a tutorial on the use of strictfp.

Here is the link to the blog entry about open sourcing solaris

If the final release of Looking Glass turns out to be as impressive as the demo shows, I don't think anyone will ever doubt Java as a 3D application language.