Slashdot Mirror

It's huge (eats a PCI-slot) and noisy

Many workstation-class video cards take up multiple slots:

www.sun.com/desktop/products/graphics/xvr1000/
www.3dlabs.com/product/wildcat4/index.htm
www.3dlabs.com/product/wildcat3/wc3_6210.htm
mirror.ati.com/products/workstation/fireglx1/index .html

I have to wonder, though, how many free PCI slots you have in your case. Do you have one? Two? Three? All of them? With most components integrated, I would expect the average user to have three or more PCI slots free. Yes, some will buy FlexATX or MicroATX boards, but then they're buying for a specific purpose and even then I think it's unlikely they'll use all the slots.

The message was encoden in ASCII?... riiiiiggtthhh... LEARN TO ENCODE IN UTF-8 you alien loosers!

Funny, I thought the Java Community Process and the Bug Parade were step 2! As a result of feedback, Java has added nested classes, strictfp, generics, enums, foreach, reference objects, tons of library classes, as well as fixed thousands of bugs.

For when Jaron Lanier decides to update his website with 10,000,000 lines of script

Of course, if you have worked with ABAP before, then you will know why this is so....

PRAISE JESUS

I love this thing. Seriously. The 24" Sony CRT's are fine, but at the highest resolution it was only 80Hz. I can't handle 80Hz. 85 is the minimum for a CRT. The monitor was nice, don't get me wrong. But analog just sucks. There was still a slight difference in the convergence at the outer corners. It poured out heat like a fucking oven on self-clean and it broke my back to move it around to clean. It was just like a bastardization of technology. So I ditched it, and bought the Sun, and I will NEVER look back. 1920x1200 perfectly accurate pixels. The panel weighs nothing, generates almost no heat.

It has been my experience that people that bash LCDs don't own a good one, and secretly wish they did.

Castor and Sun's JAXB do the same thing for Java. You can use a Schema to generate Java classes, or define bindings between existing Java classes and an XML schema to do serialization and deserialization.

I think Java can't die that easily. Nearly all posts forget about a very big supporter of Java, IBM. IBM will never support Microsoft-propietary on its servers. (I mean, since IBM started eclipse, it's entire development platform is built and made for Java.

So with server suppliers Sun and IBM it's natural to use Java on the server. An when the backbone is Java, why not use the same environment (Java, JDBC-Drivers, XML-Access) on the client. (it's by far easier to maintain...)

But of course: It'd be great to spread JVM among the clients around the world, although JVM is a fairly "heavy" thing over the slow lines out there... (at least Sun's, which is the only "comfortable" under Windoze)

So the developing community should concentrate on making standard routines for installing the JVM by providing direct links on webpages and so on. (like this happened with Acrobat Reader which you can expect being installed on nearly every system connected to the internet)

The picoJava home page
Sun's annoucement almost 6 years ago that they and Rockwell Collins would be making picoJava chips

The picoJava home page
Sun's annoucement almost 6 years ago that they and Rockwell Collins would be making picoJava chips

You're missing the point. The byte code is left intentionally simple and unoptimized so that the JIT can optimize it. Have you ever looked at the output of javac? It's positively brain-dead and simple--there are no optimizations. Why the heck is that? Why would Sun fail, after all these years, to finally make a javac that outputs optimized byte code? (It's surely not because they lack the talent--look at Solaris for heaven's sake and PVDL's work in cc.) If you find yourself stumped by these questions, then you've not carefully throught through the nature of interpreted languages.

All of the improvements you've suggested (e.g., tail recursion) are done not by a human (who can make mistakes) but rather by a JIT. The run-time optimizations are inspired by Sun's work in Self. Read more at this place

Sun does lots of research into language theory, and Java/JIT has benefited from their work in Self and in other compiler areas.

The idea is that the common compiler fixes (constant folding, force reduction, tail recursion, loop unrolling, etc.) are so well defined that there's no point in doing them by (failable) hand. Instead, let the 4-th generation JIT accomplish them, and more.

dear reader the gnome armageddon has started,

first of all i want to clarify that this text was meant to be a source of information otherwise i wouldn't have spent so much time into writing it. belive me it took me a couple of days writing this text in a foreign language. even if you don't care at all for gnome, you may find some interesting information within this text that you like to read. please try to understand my points even if it's hard sometimes, otherwise you wake up one day and feel the need to switch to a different operating system.

on the following lines i'm trying to give you a little insight of the gnome community. the things that are going on in the back, the information that could be worth talking and thinking about.

many of us like the gnome desktop and some of us were following it since the beginning. gnome is a promising project because it's mostly written in C, easy to use, configurable and therefore fits perfectly into the philosophy of u*nix. only to name some of its advantages.

unfortunately these advantages changed with the recently new released version of gnome. the core development team somehow got the idea of targeting gnome to a complete different direction of users. the so called corporate desktop user. in other words they're targeting people that aren't familiar or experienced with desktop environments. usually business oriented people who are willing to pay money for getting gnome on their computers.

having this new target in mind, the core development team mostly under contract by companies like redhat, ximian and sun decided to simplify the desktop as much as even possible by removing all its flexibility in favor of an easy clean simple interface to not confuse their new possible customers. so far the idea of a clean easy to use desktop is honourable.

some of the new ideas, features and implementations such as gconf, an evil windows registry like system, new ordering of buttons and dialogs, the removal of 90%-95% of all visible preferences from the control center and applications, the new direction that gnome leads and the attitude of the core development team made a lot of users really unhappy. these are only a couple of examples and the list can easily be expanded but for now this is enough. now let me try to get deeper into these aspects.

you may imagine that users got really frustrated because their beloved gnome desktop matured into something they didn't want. during the time, the frustration of a not less amount of people increased. more, more and more emails arrived on the gnome mailinglists where users tried to explain their concerns, frustrations and the leading target of GNOME.

but the core development team of gnome don't give a damn about what their users are thinking or wanting and most of the time they come up with their standard purl. the reply they give is mostly the same. users should either go and 'file a bug' at bugzilla or the user mails are being turned so far that at the end they sound like being trolls or the user feedback is simply not wanted. whatever happens the answers aren't really satisfying for the user. even constructive feedback isn't appreciated.

if you gonna think about this for a minute then things gonna harden that they are directing into the commercial area. the core development team actually don't care for the complaining home user. it's more important for them to reach the customers with the cash. it seems that this has been told to them by the company leaders. everything about gnome has been decided already, a way back or direct communication isn't possible. don't get trapped by sentences like 'we listen to our users'. they listen to you - yes, to make funny silly jokes about you afterwards.

i thought that everything was build up on friendship, build on programming for fun, build on understanding each other. but the reality looks like it's all for the big money. the cash is what matters everything else is a lie and a dream. time for people to wake up.

not long ago they threw one of the most important long year core developer martin baulig out of team. a guy who worked really hard on getting gnome into the right direction. a nice friendly person who put all his time into gnome. but narrow minded gnome elites such as havoc pennington were responsible that he left the gnome project. the trouble and the pressure that was put on him was to much.

with the new gnome desktop a lot of user interface changes happened such as button reordering. needless to say that this confuse people who are used to the 'right' button ordering for ages. even our fellow linux guru alan cox wasn't thrilled about this idea. but the gnome elites such as havoc pennington, seth nickell, calum benson and dave bordoley knew it better. why following the road of any other desktop that exists ? why not doing something that don't confuse their users and still stay usable ? well it seems to be too easy. gnome needs to be different than anything else so they changed the button order which was one of the reasons that users became unhappy. they said that there was a hard fight about this and the decision was made to change the buttons. but i belive they simply copied the behaviour of macos because most of the gnome developers use a macintosh as either laptop or desktop. sad that they forgot to keep in mind that users tend to mix applications and that this will lead into weird button searching and clicking.

but as if this wasn't enough the same people decided that the new gnome human interface guides were the ultima non plus ultra in human interface guides. the announcement contained informations that the kde usability people got initiated into it. unfortunately the kde people heard about it the first time when seth nickell went to the kde mailinglist which happened after the announcement. you can imagine that they got highly pissed off about this attitude. you can read more on this link. to summarize it, the kde people clarified that gnome should care for their own business.

the problem that came with the new interface guides was, that every little gnome hacker started to become an user interface expert over night. a lot of gnome programs that we like to use matured into a disaster over night. hackers that never programmed correctly for their life started to blindly follow the hype of simplification. for an example look what happened to galeon's interface (pay attention for the last paragraph). even philip langdale a long year galeon hacker got highly indignant by the target that gnome leads and wrote this email to the galeon mailinglist.

here another reason why users became angry. the elite assumes, that the user knows nothing about their system. you find a couple of heavily insulting mails on their mailing lists containing sentences like the quoted ones.

• "the user don't know what a window manager is"
• "the user don't know what themes are"
• "the user don't know what a homedir is"
• "the user can't compile a kernel"
• "the user don't want to customize their desktop"
• "the user shouldn't see preferences which purpose they don't know"

such evil practices shouldn't be tolerated by the users and need to be fighted. u*nix users aren't stupid people. who actually gave havoc pennington the rights to decide what the user wants and what not ? various users told him that people who use a u*nix like system are well aware of their capabilities dealing with such a complex system. there's a reason why people are switching from alternative operating systems. they want to learn, they want to use the full power of the system, they want to change everything they like.

to top all this, look at the future plans of nautilus. the current maintainers got the idea of changing the whole nautilus concepts into an object oriented user interface design. you may be highly interested in reading the exact words of alex larsson's vision for nautilus' future direction by clicking on this link.

to summarize it, it's assumed that the user don't need to deal with his homedir or his whole filesystem because it may confuse him or because he don't understand it. the new concepts of nautilus should be that the user deal with symbols in the nautilus view. e.g. you get a cdrom symbol and by clicking on it you see the directory of your cdrom, you get a photo symbol and by clicking on it you get a list of all your pr0n pictures, you get a music symbol and by clicking on it you get a list of all your mp3's. you don't know where all these files are located because you don't deal with the bottom layer of your homedir or filesystem anymore as mentioned earlier.

the question is why are people that know nothing about their users, that know nothing about correct user interface design destroying gnome ? the users don't deserve all this specially those that backed gnome for all the years. even sun threw a bunch of so called user interface experts together and have them work on gnome. don't forget that sun are the creators of the common desktop environment. we don't need another cde clone named gnome. even havoc pennington author of the good user interfaces text isn't able to get his own written software following his rules.

not long ago there was an report about the 'two captains of nautilus' where the reporter (uraeus a gnome contributor himself) reported alexander larsson and david camp. you may imagine that such a report can't be taken serious because it's done by their own people. we here have a saying that sounds like this 'one crow doesn't hack the eye of another crow out'. now you can click on this link and read more. it may be interesting to read the replies from various users all over the globe of what they think about gnome and nautilus in general (please pay attention to the listed ip's there). another nice and informative reading can be found by clicking on this link.

the fileselector problem was a long discussed issue in the gnome community. finally they came to an solution for this and have decided to go for this ugly fileselector instead going for this one which was developed by a free volunteer for a long time and in general looks and behaves better.

most users have no problems with the idea of keeping things simple and clean. removing some not needed preferences was indeed a good idea but it doesn't stop. people started to remove everything from their apps. you're forced to use dubious programs like gconf-editor which basically works like the windows registry editor, to tweak uncommented preferences. i don't think that this is an advantage. even the possibility to tweak preferences with an editor was taken away with that ugly implementation of gconf. all your preferences are stored in a directory tree with an unknown amount of *.xml files. even if you delete programs their keys are still remaining orphaned in these trees and finding them is like playing trivia. at the end it's worth a discussion if a system driven by a single home user needs such a registry like system. we didn't need such a system for over 30 years but the gnome development team got the idea copying one of the most retarded systems from windows to u*nix. not to mention that the copy is more retarded than the original.

it's a shame to see how such a nice desktop got thrown into the trash by such people. but there is a lot more behind the scenes that i don't know about. everything around gnome is a big marketing strategy. poor people are working the hell out of gnome for nothing and companies such as those mentioned above are getting the big cash. for sure you could say - go and fork gnome - but seriously how can you go and fork gnome ? such a big project which needs a bunch of people to keep the code alive and compatible. well you know it's all about open source the code is signed under the gnu/gpl or gnu/lgpl, you can't own it. even the companies are aware of this. but if you can't own the code - go and hire their developers. you can direct them like puppets in any direction that you - as company - like. exactly this is happening with gnome.

well you could easily come up and tell me to simply not use gnome and let them do whatever they like. well, you are right with that but things are more complicated nowadays. gnome is influencing a lot of third party projects such as xfree86 which recently added a lot of gnome components into their cvs repository. please know that with the next coming xfree86 version you get a lot of gnome components without even knowing it. code like, gnome-xml, pkgconfig, fontconfig, xcursor and xft2 were mainly written by people who're heavily involved into gnome development. also the gimp is maturing more and more into getting the look and feel of a native gnome application. the cvs version of the gimp has a lot of gnome pixmaps inside and they are heavily working on integrate the gimp into gnome. if not today but the direction is sure and i fear the day this gonna happen.

it's ok that these things exist and it's ok to see xfree86 and the gimp are beeing hacked on. but please think about the people that don't like or use gnome. what about them ? why force them to have gnome components installed on their systems ? why can't gnome go the same way that kde went e.g. doing their own stuff without infecting other projects like aids. seeing more and more libraries and applications that were in no way related to gnome jumping on the pkgconfig boat which's really not needed. look what will happen to solaris, the world famous operating system on u*nix used by big companies and long years experts. they really plan to replace cde with gnome. i know that cde wasn't the best invention of desktops but it rarely crashed and it fits far better into the philosophy of xfree86 with their configuration system than gnome. you know the good old way having your settings defined with .xdefaults and all nice default configurations are going into /etc/x11/app-defaults/ and so on. understandable that the good old way may be blocking the future of applications for multiusersystems - but why must it have to be a windows registry like system that replaces future configuration ?

well to come to an end i personally don't like many of this stuff. i can't stand the button reordering, i don't like the gconf system and even more i don't like the commercial outsourcing of gnome and the bad influence that gnome has on other applications. the bad attitude of some gnome developers is another story since we are all different reacting humans. luckily there are people sharing some of my thoughts otherwise i wouldn't be able to proof my text with so many links. even amongst the gnome developers there are silent voices of people that hate many of these decisions and silently use something else. right now if you checkout the gnome cvs repository every day you find out that the whole gnome development seemed to came to an halt. the contributions to their cvs are poor. while projects such as kde are reaching easily 10-20k commits per month - gnome is getting around 1-2k per month on it's best times. it really looks like the situation of gnome is unclear so it would be better to have it not influence so much other programs or at the end we deal with an disaster.

now i hope this text was informative for you. i hope that you start to think about the situation and the global direction. the situation of gnome is unclear, their target is groggy too since i can't belive that the users that they are targeting ever heard of u*nix or linux. they plan to get out of the 0.05% desktop niche but this will for sure not happen if they continue their current direction and their bad ugly

Java programs aren't cross-platform. Otherwise I could download a single package to run on whatever OS I have.

Java is a platform, or at least Sun calls it that. Following that reasoning leads to absurdities like claiming Super Mario Brothers or StarCraft are cross-platform, since they work in emulators. You could say I'm being pedantic, that "running on a platform on platform A" is practically equivalent to "running on platform A", but that's not so.

To the point, suggesting the use of Swing imposes serious limitations on the project- mainly that it has to be written in Java and run on a JVM. The performance penalties are appreciable. (It is possible to use Swing to display a non-Java program, but ugly and impractical).

The other GUI toolkits that got good recommendations generally have multiple language bindings for them

PersonalJava is sold on devices with 64 megabytes of RAM, or even more.

The following site has many, non trivial, applications. Some are even free. Swing Sightings

First, a shameless plug: I'm working on a couple of C++ applications that are currently using FOX for the GUI (and other parts). The first one is a front end to the open source stats language R and it is called Obversive. This is the most active project, but it is still real tiny. The second project is a little chat client I'm writing called Bombyx which will work on the SILC and hopefully IRC. In addition to Bombyx, I've also developed a little GUI generator with Lua that makes FOX widgets pretty quickly. It's called GIG and you can get it from the Bombyx site mentioned previously. The intention with GIG is to make it work for any toolkit, but right now it does FOX only.

When I was working on these projects, I went through a huge number of toolkits and actually tried developing fast "mock-ups". My test was to see if I could get the first window I wanted in each project using available resources. If that worked, then I would try a couple of other windows. I also reviewed the designs of each and then went with what worked best at the time.

Here's my review of each of the toolkits I used. These are just my opinions, but they are based on actually using them in various platforms (or trying to).

FOX After all of this evaluation, I found that FOX was pretty much the best at the moment for clean, simple GUI building. It has pretty good docs (way better than wxWindows), and is fairly natural for coding. It also has some nice language bindings for various languages like Python, Ruby, and Eiffel. It doesn't have quite as many controls as wxWindows, and it doesn't work natively on as many platforms, but it is much easier to build and work with and much smaller. If you are porting a Windows application to another platform, you will probably be better off with wxWindows since they try to mimick the API design as much as possible (and of course, all it's problems too). Also, if you hate macros then you'll have a problem with FOX (and wxWindows too). A testimony to how easy FOX is comes from Obversive, where one developer had no C++ or FOX experience and has already created several complicated controls. Another developer has good C++ skills, but only worked with KDE previously. He not only developed an excellent Twin Table control, but also added lots of great features to it and in very little time.

FLTK I did the original work on Bombyx with FLTK. FLTK is a nice library, but it was just missing too many widgets to be useful. It was also rather buggy and it was a real pain to do delegation. There are, however, two really nice things about FLTK: no macros, excellent GUI builder. One of huge problems with ALL other toolkits I've ran into is that, when the developers start to make their GUI builder, the decide they need an entire IDE. I already have one thank you. I doubt some OSS project is really going to out-do my tool chain right now, especially if it's also working on the widgets. Just give me a simple builder please. FLTK got it right with FLUID--their GUI builder. It's real easy to use, super fast, and does one thing well: build interfaces. It was a little weird at times, but I checked out the latest and it worked great. Also, FLTK does not use macros for messaging which is nice for the C++ purists.

Cocoa I love Cocoa, but, Apple made a huge mistake by making it a MacOSX only beast. I think Apple could rule the world if I could spend my time writing my apps with a nice UI, great tools, and an easy language (Objective-C), and then click a button and have a Windows, Linux, HP-UX, and Solaris binary. You could do this with the original NeXT stuff, but Apple crippled Cocoa and friends. So, I reserve Cocoa for other useless programming that I only do on my MacOSX. There is GNUstep, but I couldn't get anything to work with it, and half the fun of Cocoa development is using Interface Builder (IB). BTW, IB is another GUI builder that is excellent, and also does just GUI building. Let's hope the wxWindows guys figure out this pattern and write a small GUI builder rather than their entire IDE which nobody seems to be able to compile but three dudes inside the cabal (sorry, it really burns me).

wxWindows I must say that wxWindows has a ton of nice widgets (I may steal their HTML widget) and works on a huge number of platforms. But, I kept getting burned in three areas: docs, dependencies, and bugs. Their docs are horrible. You have to hunt around the net looking for tutorials which are not very good anyway. Half the example applications in the distro don't even work so you can't rely on them, and it's just really hard to figure out what to do. I also hated having to add a billion other libraries to my build just to get wxWindows to work. I found it a problem when linking my application took longer than compiling all the files from scratch. Finally, just about everytime I went to use some widget, I found some bug or limitation that made it unusable. They have improved quite a lot from what I have heard, and people really rave about it, so I think everyone should give it a try. One thing also that annoyed me about wxWindows is that it does not support delegation very well. All the other toolkits I used either support delegation easily or practically require it. In wxWindows, I spent the better part of a week just trying to get one simple delegation design working and couldn't do it despite lots of help from people on various IRC channels. To me, things are broken if I have to subclass every time I want a widget. The wxWindows XML based resource files are supposed to fix this, but I won't hold my breath.

JFC/Swing The original version of Obversive was done in Swing with lots of other goodies. Java is my primary work language, and I really wanted to use it on the Obversive project, but we just kept running into performance problems. Frankly, Swing is just a P.I.G. and is really hard to code. None of the GUI builders available we tried proved to be that useful, and eventually we dropped it becuase it was just too huge. Ironically, we were able to prototype an almost complete GUI using FOX which runs on Linux, *BSD, Windows, and MacOSX (through the XDarwin or Apple X ports) in about 3 weeks time. This was mainly in part due to the slick design of FOX and simplicity, and partly in part because of the GIG code generator I put together. Oh, and we looked at SWT, but balked at the Linux or Windows only (and the fact that the flagship, Eclipse, ALWAYS crashes on Linux does not make me happy).

So, that's my experiences with these toolkits. I hope that helps answer the question, and I hope the reply wasn't too long. To summarize: Use FOX if you need C++ and good design. Use wxWindows if porting from MFC or if native controls are important. Use Swing if speed is not a problem, but cross platform really is. Use Cocoa if you only care about MacOSX and need to get something out quick. I actually prototype some UIs in Interface Builder on MacOSX, which says a lot.

Swing works on a single platform: Java. And not all Java, either.

I still recommend that if you are using Java, Linux is the way to go. The Java from Sun runs on Linux just as well as any Windows platform. It beats Java for Windows 9x by a mile. If you will only use opensource software, GCC's Java compiler (get a nightly build and compile it yourself rather than relying on what comes with your distribution, as those are older) is getting pretty darn near usable. It works for 97% of my stuff now. Similarly, the classpath libraries are reaching a point where I can usually substitute them for the sun libraries.

I still recommend that if you are using Java, Linux is the way to go. The Java from Sun runs on Linux just as well as any Windows platform. It beats Java for Windows 9x by a mile. If you will only use opensource software, GCC's Java compiler (get a nightly build and compile it yourself rather than relying on what comes with your distribution, as those are older) is getting pretty darn near usable. It works for 97% of my stuff now. Similarly, the classpath libraries are reaching a point where I can usually substitute them for the sun libraries.

Check out some of the equipment from Sun Microsystems, SGI, IBM, and Stereographics.

A bunch of their equipment is designed for a 10 year obsoletion-cycle. Cost's a hefty penny, though. Designed for business and major research universities.

At the University, we were using Creator3D graphics cards from Sun Microsystems. That was in 1999, and the general consumer market still hasn't caught up with that tech. Me, I'm still looking around for auto-stereoscopic monitors. Sharp is coming out with a consumer model next year, I hear.

JavaOS has been built to be fully ROMable for embedded applications, and can run with as little as 512K ROM and 256K RAM. For network computers, an entire system with JavaOS, the HotJavaTM Browser and space for downloading Web content and applets requires only 3MB ROM and 4MB RAM. JavaOS can be this small because it is almost completely written in Java.

Ace's Hardware needs to research real servers before talking about their "scalable" servers. Their numbers are really saying that their box performs like a dog.

For those of you interested in this topic here is a few pointers and words of wisdom.

Server scalabilty and performance has three basic metrics, thruput (urls/sec), simultaneous connections, and performance while overloaded. Of course, you could add latensy but I'd argue that with the correct design latency is directly proportional to the real work you are doing, bad design insertes arbitrary waits.

I know of a HTTP Proxy by a large ISP that does user authentications & URL authorization (re: database), header manipulation, and on-the-fly text compression at 3000 urls/sec for 2000-4000 simultaneous connections and maintains that performance under load by sheding connections, all this on a dual 1GHz Intel PIII box running a Open Source OS that starts with "L". That is a maximum of 260 Million URL/day, three orders of magnitude greater performance than Ace's Hardware stats.

The simple answer to the question "How do I create a scalable fast network server?" is Event-driven GOOD & Threads BAD. Event driven network communication is two to three orders of magnitude better performing than thread/thread-pool based network communications. See Dan Kegel's C10K web page. That means you must use non-blocking IO to client sockets and databases. Once you accomplish that small feat, dynamic content just consumes CPU; with 2.8 Ghz Xeon processors you have plenty of cycles for parsing HTML markup or whatever. Threads cause cache thrashing, and context switching. While thread programmers don't see the cost in their code, just read the kernel code and you'll see how much work HAS TO BE DONE to switch threads. Event driven programming just takes some state lookups (array manipulation) and a callback (push some pointers onto the stack and jump to a function pointer).

Desgin is FAR MORE IMPORTANT than which runtime you use (execution tree, byte code, or straight assembly). I have done some very high load network programming with Perl using POE.

Python has Twisted Python

Java has the java.nio and the brilliant event/thread hybrid library SEDA by Matt Welsch.

I am also looking into the programming language Erlang which builds concurrancy and event driven programming into the language. Further, Erlang is used by some big telco manufacturers to great effect (high performance and claimed 99.9999999% nine-nines reliability on a big app).

Sun Microsystems has some online certifications. I was kinda suprised on how reasonable the prices are for them too. cLiCKhERe

>>Until about 3 years ago the ONLY JVM on Windows was MSJVM, officially licenced from Sun Micro.

Oh, please, can you back it up with facts?

Mugabe and Bill have alot in common I guess. :)

hehe, maybe it is a coincidence that some java beans come from Zimbabwe, maybe they could use some more java there as well...

-v

How much money are you planning on spending? If you want really excellent training, it's going to cost a fair amount of money. Usually around $1500-$2500 ish a week. And you have to decide what you want training in. If you're interested in Solaris, Sun offers a bunch of classes in several New York facilities. Here's a link to their training site: Sun Solaris Training

The couple of classes I've had from Sun have been quite good. Some hands on on equipment that I don't own myself at clean facilities with knowlegable instructors. If you want Linux training, probably the easiest/best place to get it is from Red Hat. They also have a site in NYC, in the financial district, and they provide lunch every day (very cool). Their classes also have hands on labs, but the equipment isn't anything that you wouldn't have at your own house. They teach their classes on PCs. Red Hat's site is Red Hat Leaning Services

Going to the product manufacturer is usually the best way to get top notch training, I'm just using Sun and Red Hat as examples, they have been the ones that I was most happy with. They, product manufacturers, hire instructors who are familiar with the product and who can answer a fair amount (maybe even all) of your questions. And unlike CBT, can provide alternative explanations when the one they use just doesn't get through to you.

The big problem with going to these classes is that, while good, they can be prohibitively expensive. If this is a limiting factor for you, then someone above suggested Community College. I think that this was an excellent suggestion. They are far less expensive, but it's been my experience that the instruction is not always as good.

-Runz

As part of their contract, MS was forbidden to add public names to system packages (e.g. java.lang, java.net, etc). Nevertheless, they did so. There were some stretchers on both sides.

Microsoft PR claimed that Sun was forbidding them to add Windows specific extensions. This was silly - there was no problem with any number of packages named com.ms.* or whatever (except that the ms.com domain belongs to Morgan Stanley, and thus didn't follow the 3rd party naming convention - but that wasn't in the contract). There were some very nice extensions with proper names - like JDirect which let you call Microsoft DLL's without writing JNI glue. The problem was that Microsoft wanted to name some extensions java.*. This would of course cause the unwary programmer to inadvertantly create Java programs which only run on Windows - despite not knowingly using any MS specific packages. Exactly what MS wanted.

On Sun's part, the contract included a list of packages which Microsoft could not touch the public name space of. More system packages were added to Java 1.1. Sun claimed that Microsoft couldn't touch those either - reasonable, but they weren't in the specific list in the contract.

The completeness problem was along the same lines. Microsoft provided a complete 1.0 API. However, they left out components of the 1.1 API that competed with their own offerings. For instance, they left out RMI and offered DCOM support instead. Sun said that it was understood that the same restrictions regarding system name space pollution and completeness would apply to the packages of subsequent API versions. But this was not spelled out in the contract. It would not be in the ruthless spirit of Microsoft for them to follow the spirit of a contract if they could find a loophole.

Regardless of quibbling over whether the system package list under contract should expand to match new API versions, Microsoft polluted even core packages from 1.0 with handy additions sure to entice the unwary. So they were guilty even by the letter of the law.

For those of you more interested in blurbs and sound bites from the article:

Sun, based in Santa Clara, Calif., claims Microsoft views Sun's Java software as a threat because it can run on a variety of operating systems, not just on Microsoft's Windows.

Among tactics cited in the lawsuit, Sun alleges Microsoft promoted an incompatible form of Java that worked best on Windows and, most recently, dropped it from Windows XP, which was introduced in 2001.

Microsoft, which told Motz on Thursday that shipping Java with Windows was not a simple matter and could harm large corporate users of Windows, is almost certain to appeal--a move the judge anticipated.

Does anyone have details of what Microsoft claims was so hard about installing Java with Windows? Given that Sun already provide a complete Windows installer why can't they do this in 120 days? How could this "harm large corporate users". I know Microsoft are just stalling, but what argument did they put forward to the judge? Clearly it wasn't that convincing...

I wrote up my view of the article and posted it earlier. I think that (for obvious reasons) he tends to view things from a cryptography perspective and tends to miss what really happens "on the ground", but hopefully his voice will be influential in such matters among his colleagues.

I know two Java books that are definitely worth their money:

- Effective Java
and
- Java Platform Performance by Steve Wilson and Jeff Kesselman

Of the second book there is a HTML version available at this link

Four sample chapters from the ten in the book are available in PDF format at the books website.

You might be interested in reading this information at the VB developer center.

Thank you, a good review of an excellent book. I have maybe 10 java books, most of them from O'Reilly and none have been as beneficial to my development in Java as this one.

The code and the text are both very clear and concise, and you can read the book cover to cover, coming back later to study each advice more in depth.

I think you can get it from reading between the lines in the review, but just to make it clear to any curious beginner, this is not the first book you should buy if you are just starting to learn java. Use
The Java Tutorial instead, and maybe
Learning Java.

I tried to post it. I really did. The slashdot filters just wouldn't let me. Seems like 37 characters per line should be plenty. Whatever.

Apparently, there was a version 5.1. To wit:
Sun[tm] ONE Identity Server 5.1: Installation and Configuration

Heck, you need to learn reading official product specs are the most reliable source of info on a product and if that ain't true, just call your lawyer. On the Sun Website, it says and I quote:
"Supported:
* Sun Solaris[tm] 9 and 8 Operating Environments for 32- and 64-bit UltraSPARC®
* Microsoft Windows 2000 Server, Service Pack 2 or later
* Microsoft Windows 2000 Advanced Server
".
No linux, no Solaris x86, no Windows Whistler/XP, no Longhorn XP Alpha, no FreeBSD, NetBSD, OpenBSD, no Minix, no MicroBSD, no IRIX, no OpenUNIX, no Windows 2003 RC1/2. The list goes on.

"Is this protocol (JXTA) going anywhere yet? "

Two days ago, I asked Daniel Brookshier, author of articles and a book about JXTA (1), if JXTA-compliant collaboration software could become the platform of choice for socalled Global Issues Networks.

Global Issues Networks are proposed by Jean Francois Rischard, World Bank's vice-president for Europe, in solving the biggest worldproblems (2). Global Issues Networks start in Rischard's vision with a limit number of specialists, and should grow to many thousands of people in a few years time. In this networks people collaborate to define ways for solutions and should push governments in this directions. Global Issues Networks will need fast scaleable collaboration software-solutions.

I asked Daniel also how much time it will take to grow the technology?

His response:
"Yes, indeed JXTA will work. I can't imagine it taking too long to develop either. The next release should add the final touches to the ID system to make collaboration much easier to implement. As far as scalability, I don't see any problems. As to platform of choice, I believe that JXTA is the only platform that makes sense. The closed networks like Groove do not cause innovation. Specialty networks like Gnutella just don't have the breadth of API to do collaboration".

I hope you find this information interesting.

Regards,
Cor
(1) Article: Brookshier, D. (december 2002) "JXTA: P2P grows up".

Book: "JXTA: Java(TM) P2P Programming"

(2) www.rischard.net

"You can't just import an XML file and magically have it available to your program. You have to first put it through some sort of transformation, which requires work that is unnatural or unwieldy." -- Sean McGrath

yes you can

> At least it's got templates, I guess.

By the way, the next version of Java (1.5) will have templates. (see http://developer.java.sun.com/developer/technicalA rticles/releases/generics/)

Try here, but it's only warmed-over RedHat.

For his work on the programming language named Simula.

From: The History of Simula:
Although SIMULA never became widely used, the language has been highly influential on modern programming methodology. Among other things SIMULA introduced important object-oriented programming concepts like classes and objects, inheritance, and dynamic binding.

Not exactly.

No, both parties published the contract on their websites when the case started.

There's some info related to the SPARCLite here .

There's also some on Fujitsu Semiconductor's Web site as well.

Is this related to the embedded Java processor Sun announced a while back?

No.

I never read up on that, and I wasn't sure if they really meant it was running Java bytecode, or if it was merely a processor that was well-suited for Java. Native bytecode sure sounded unlikely.

"Sounds unlikely" does not necessarily imply "not true"; picoJava does, indeed, run Java bytecode as a native instruction set - or, at least, did, or was intended to; I can't find anything from Sun's home page that speaks of them selling any processors other than UltraSPARCs. A Google search for "Sun Microelectronics" found, as the topmost hit, a page for UltraSPARC processors, so perhaps they've killed off picoJava and microJava (I think microJava might not have had bytecode as its native instruction set), along with the MAJC chip (some VLIW thing) they were working on at some point. (You can still find stuff about picoJava, microJava, and MAJC on Sun's web site from the search box, but the papers you find look suspiciously orphaned.)

There's some info related to the SPARCLite here .

There's also some on Fujitsu Semiconductor's Web site as well.

Is this related to the embedded Java processor Sun announced a while back?

No.

I never read up on that, and I wasn't sure if they really meant it was running Java bytecode, or if it was merely a processor that was well-suited for Java. Native bytecode sure sounded unlikely.

"Sounds unlikely" does not necessarily imply "not true"; picoJava does, indeed, run Java bytecode as a native instruction set - or, at least, did, or was intended to; I can't find anything from Sun's home page that speaks of them selling any processors other than UltraSPARCs. A Google search for "Sun Microelectronics" found, as the topmost hit, a page for UltraSPARC processors, so perhaps they've killed off picoJava and microJava (I think microJava might not have had bytecode as its native instruction set), along with the MAJC chip (some VLIW thing) they were working on at some point. (You can still find stuff about picoJava, microJava, and MAJC on Sun's web site from the search box, but the papers you find look suspiciously orphaned.)

Meyers is apparently not the only one thinking that java needs templates: Preparing for Generics

not dead by any means.

Qube 3

i however think rolling your own is a much better deal if you RTFM and know what your doing. SunCobalt products are for the dumbest of the dumb if ya ask me. (or maybe the laziest of the lazy.)

forgot the </a>. sorry. //trigger happy submit button presser.