Slashdot Mirror

If you like van der Linden as an author [in real life, he seems to be something of a cocktail party marxist], you should try his Expert C Programming: Deep C Secrets. It's a great read for the intermediate to advanced C programmer; I once used it as the basis for a course I taught in intermediate C.

Sun Microsystems really expensive server OS

Beware, Solaris no longer costs an arm and a leg. Try downloading it for free or purchase the media kit for <$50US.

Solaris gets expensive only when you set up an SMP server. Generally, the licensing fee is included in the invoice for the hardware. Even then, it really isn't hard to digest.

Sun Microsystems really expensive server OS

Beware, Solaris no longer costs an arm and a leg. Try downloading it for free or purchase the media kit for <$50US.

Solaris gets expensive only when you set up an SMP server. Generally, the licensing fee is included in the invoice for the hardware. Even then, it really isn't hard to digest.

Here's more on Sun's Anti-Passport Plans. Not a bad read. It does point out the importance of a vendor-free implementation.

HTML has two important ideas/areas:

1. structured content (semantic markup, like in LaTeX)
2. easy presentation (it's easy to get a nice rendering)

HTML both was successful and sucks at the same time because it works in both areas moderately well.

People have worked on improving both areas. The first part, holding content, led to the development of XML, which holds great promise of standardized logical markups. The second part, focussing on pretty display lead to stuff like Java Applets and indeed Flash.

The interesting thing is that Sun, for a long time, didn't manage to provide users with painless to install and use Java VMs, while Flash had no trouble at all providing Flash Players to all major platforms. While Java Applets very often do not work, I can't remember having encountered any faulty Flash presentation yet.

However Sun seems to have woken up lately. Since 1.3, and the introduction of the Java plug in, it has been much less pain to use Java than before. Then there is Java Web Start, which made it really, really easy to get, install and use Java applications. See some demos here to experience Web Start.

This stuff is an example how web applications look like. Note that these apps are no longer confined to a square area in the browser (however even applets benefit from Java Web Start execution, because it is easier to update and version them).

Plus the 2D Api of Java introduced high quality graphical rendering (it was written by Sun and Adobe initially). It has the potential to create better looking graphics than what Flash offers.

But here we have the potential reason why Flash took off, while Java didn't:

• Flash was targeted at the community of graphical designers, people that use Photo Shop, with good graphical design talent. What they lack in programming talent, Macromedia helped out with creating authoring software.

• Java however was targeted at the programming community. Sun could have created software that helped the programmers to create great looking apps. But execept for the visual brush up that came with Swing, and the aforementioned 2D API, there is much lacking. Example: a Java lib with the graphical capabilities of the GIMP or Photo Shop is something I would wish, plus tutorials in interface design to bring that graphical power to an esthetic use.

As a programmer, I would love to see more Java than Flash. But I believe this is not going to happen until Sun would create authoring software similiar to Macromedia's, that would enable graphic artists with low programming skills to create high quality graphics output, but where the result is not some flash file, but a Java jar instead. This is possible, but would require a definite commitment from Sun. Too bad they don't cooperate with Adobe on this one.

Enterprise JavaBeans, and Session Beans in particular, provide these services. RMI is used as the transport layer, and the application server (EJB container) handles authentication and session tracking, often along with redundancy, administration, and a host of other goodies...

The author spends a bit of time talking about Custom socket factories in RMI, which is used to make RMI calls over SSL sockets.

Here's 'the scoop' from sun. It refers to JDK 1.3 - as far as I know, everything you need is in JDK 1.4 now, no need to get the JSSE ppackages.

Either way if you go with W2K you will soon discover that it is a maintenance nightmare compared to *NIX (basically, multi-user support was kludged onto the NT kernel, as opposed to being designed to be there in the first place).

If you do not have to use Windows then you could consider Sun Rays.

If you have a small number of people who would need Windows access then you could setup a Citrix MetaFrame server and have those users run the Solaris ICA client.

We have two Sun Ray servers here with about 60-70 Sun Rays between the two right now. We're also running a Citrix MetaFrame for UNIX server (for the curious on Slashdot, for after hours dial-up support). The only real problem we have is with graphics intensive applications. Lots and lots of display deltas do not mix with any thin client technology.

Sunrays from Sun are the best and most popular choice. They have been deployed in many areas in the US and out including Canada and Europe.

Sunrays from Sun are the best and most popular choice. They have been deployed in many areas in the US and out including Canada and Europe.

I was searching the internet the other day and came across a few articles of interest.
For one, I found an article about how researchers over at Oswego State University (of New York)
found the largest prime number to date! Incredible!

As I continued on I went over to Amazon and found this book. It's mainly about how you can encrypt every email you send using Java. I didn't
believe it at first so I stopped over at java.sun.com to check it out and found this article in
their "press release" section which seems to confirm this.
Not bad, but that wasn't the only information I found today.

I was over at Yahoo News and learned about how HP's newest line of calculators
will be able to run linux. Again, this is hard to beleive so I checked it out and found it was true over.
The link they had on HP's website was dead so I went over to Google and found it cached here.

All in all - it's a good time to live!

Here's a link to what Sun Microsystems has to say about this book and it's version of security.

• Myth: KDE is more integrated than GNOME
  Reality: The oft-heard cry of the noisiest KDE advocates. No explanation is given - the reader is expected to simply grok the wholesomeness of KDE, and the lack of this mystical quality in GNOME. It's nonsense of course. Neither desktop is particularly "integrated" compared to Windows XP, and certainly not compared to any version of the Apple Mac. Whatever "integrated" really means.

• Myth: KDE is easier to use
  Reality: Again, such nebulous arguments are never explained, and the reader is expected to simply understand the truth of the zealots statement. Both KDE and GNOME have user-interface irritations (indeed, all systems do) - but "ease of use" is not a simple thing to measure. KDE has never been subjected to detailed user testing, unlike GNOME [gnome.org], and the claims of user-friendliness are from crazed supporters and not average users. Furthermore, the KDE faithful rarely look beyond simple-minded copying of Windows, and forget that administering a desktop system is just as important as having widgets in the correct place on the toolbar. For example: What about application installation and removal? GNOME has the excellent RedCarpet [ximian.com] by Ximian [ximian.com], which makes the installation, removal and updating of applications trivial. KDE users are expected to fend for themselves with brutal command line driven systems. GNOME also has the excellent Ximian setup tools to handle various very tricky cross-platform and potentially risky system configuration operations - KDE offers none of this, only a few small half-assed Linux-only tools, which make no attempt at check-pointing to return to known working configurations.

• Myth: KDE is more popular
  Reality: In what sense? Arguably more people use KDE - but it is a close run thing. Most KDE zealots claim the results of online polls as proof of their superior userbase - which is, quite frankly, complete and utter nonsense. Online polls are the joke of the century; it doesn't even require a motivated script kiddie to render then worthless. A single post alerting the faithful on a zealot-ridden site can skew the result so much it makes American presidential elections look fair and well organised. Popularity is also difficult to measure when both GNOME and KDE are frequently installed on the same system. Indeed, the systems can co-exist and even run at the same time, except for certain applications such as panels. Many KDE users actually run GNOME applications for their superior features and stability, not realising that by doing so they are barely running KDE at all.

  One of the few solid measures of popularity is the adoption in commercial use - and here, GNOME is far ahead, with both Hewlett-Packard [hp.com] and Sun Microsystems [sun.com] committing to using GNOME as the desktop for their Unix systems. This also ties in with the previously mentioned ease of use - Sun's major contribution to the GNOME project is in the areas of user/developer documentation, testing, accessiblity and user-testing. Three of the less glamourous parts of desktop development. The arrival of the GNOME 2.x series will see these contributions reach fruitition and allow GNOME to make a quantum leap ahead of KDE in most of the basic computer/user issues.

• Myth: Konqueror is the best Linux browser
  Reality: Oh for a penny every time this lie is told in any KDE story! Konqueror [konqueror.org] is not a bad piece of software - its authors deserve praise for the work done in it. However, the sheer amount of orgasmic praise lavished by the KDE faithful is completely out of proportion to its actual quality. It is quite unreliable and even simple standards compliant pages can crash it quite comprehensively. It is also lax in its support of basic web standards compared to either Mozilla [mozilla.org] or Opera [opera.com]. It is also extremely slow - much slower than the latest incarnations of the GNOME Nautilus [eazel.com] filemanager/browser (a target of much KDE FUD during its development).
  .

• Myth: KDE applications are better/more advanced than GNOME ones due to the ease of developing in C++ using the Qt toolkit
  Reality: Easily the most common wail heard by KDE developers, and yet it is easily disproved by looking at the actual applications for GNOME/GTK [gtk.org] and KDE/Qt [trolltech.com]. KDE applications often have larger version numbers than GNOME ones... an old trick played by commerical software developers. Most KDE apps seem to jump for 1.x releases long before they are ready - KOffice [koffice.org] being the best example. None of the components in Koffice are worthy of a 1.0 release, let alone 1.1 or 1.2.

  GNOME applications [gnome.org] wait longer and get more testing in their 0.x stages and despite shorter development phases mature more quickly and reach stable featureful release states more quickly. Some examples of this are the superb Evolution [ximian.com] (groupware/email), Gnumeric [gnome.org] (spreadsheet), Pan [rebelbase.com] (newsreader), The GIMP [gimp.org] (image manipulation), Abiword [abisource.com] (word processing), RedCarpet [ximian.com], X-Chat [xchat.org] (IRC client), XMMS [xmms.org] (media player), Galeon [sourceforge.net] (web browser), and for developers: Glade [gnome.org] and Anjuta [sourceforge.net]. All of these packages ooze quality, and far outclass the KDE counterparts. It is no understatement to say that GNOME is at least 18 months ahead of KDE in applications, and pulling still further ahead.

  It's not only in the area of user applications that GNOME is lightyears ahead. With the forthcoming 2.x a number of impressive behind the scenes technology will finally mature: component technology (bonobo [gnome.org]), media (Gstreamer [gstreamer.net]), internationalisation (pango [pango.org]). As a developement platform, GNOME 2.x is, conservatively, 2-3 years ahead of KDE. And what's more, because it is not tied to a lowest common denominator cross-platform bloat-fest like the Qt toolkit, the lead (as with applications) can only increase further.

  Yet despite all this, we are still regularly fed the lie that Qt and C++ makes application and desktop development easier. Judge for yourself.

• Myth: KDE is faster and takes less memory than GNOME
  Reality: KDE is written in C++. While this is not necessarily a problem, it can be when Visual Basic reject programmers (which the KDE project is overrun with) do not know enough to avoid important pitfalls that plague C++ software projects. Stupid use of autoincrementing operators and iteration with C++ objects, and masses of unnecessary allocations and deallocations of memory, are two of the most common. KDE suffers badly from both problems.

  Perhaps the most cretinous of all problems is blaming the extremely slow startup times of KDE apps on GCC. The GNOME 1.x releases were hardly svelt (2.x fixes many of these issues), but GNOME is a fashion cat-walk superwaif when compared to KDE's 500lb fat-momma cheese-burger scoffing trailer trash. One need only look at the recent fuss over ugly KDE hacks (such as prelinking) to see the problem inherent in the poor KDE architecture and basic design flaws.

• Myth: GNOME development is slower. KDE releases faster.
  Reality: Fundamental misunderstanding. KDE releases as one big lump of code due to its use of C++ and the many problems this causes with libraries. The project bumps the version number of the entire KDE system for the smallest modifications. GNOME, on the other hand is componentized and each component releases on a (almost) separate schedule, bumping it's own version number but not the main GNOME version (1.4, for example). Occasional releases of the entire GNOME system happen, and that's when the GNOME version number is bumped (currently it is at 1.4). To see this in action, use RedCarpet and you will see regular updates to GNOME components. GNOME development is not slower, it is in fact faster and more advanced. Lamers and newbies, however, fail to understand the advantages of this method and just see KDE 1.1.1 followed a few weeks later by KDE 1.1.2. Wow! KDE roolz.

• Myth: TrollTech is a friend of Free software.
  Reality: TO BE WROTE -- IDEAS Qt started out as non-Free. KDE developers knew this violated the GPL, didn't care, stole others' GPL code by porting it to link (in violation of the license) with Qt and are therefore untrustworthy. KDE core developers work for TrollTech. Expensive per developer licensing for writing closed-source with Qt. Trolltech only moved towards the GPL because of the success of GNOME. Labyrinthine licensing nightmare. Gradual migration of features into Qt (and so into TrollTech's IP portfolio), allowing easy porting of apps to the revenue generating Windows world (see TheKompany for a perfect example), thereby making KDE irrelevant.

• Myth: Most good GNOME apps are actually GTK applications.
  Reality: TO BE WROTE -- IDEAS Most KDE apps, such as those from The Kompany [thekompany.com] are actually Qt apps because they want to port to the more lucrative Windows/Qt market.

  Myth: KDE is more than attractive - GNOME/GTK is ugly
  Reality: Mosfet liquid theme is an ugly and unstable hack. GNOME GTk icons are of a far higher quality than the cartoonish and confusing KDE ones. Qt is basically a Windows-look on a Unix platform.

This troll was reposted from the Troll Library without permission of the original author. If you object to this post, or if you wish to add your troll to the Troll Library, please reply to this message.

Sun can't market StarOffice6 unless you can buy it from somewhere. There will be loads and loads and loads of home users and small businesses who will come to StarOffice because it is being marketed. They will see the adverts, and then the next time they're wandering round PC World with a few quid burning a hole in their pocket, they'll cough for a copy.

Having bought it, they'll install it. Then they'll start boring their workmates about it - they're not clever enough to experiment with GNU/Linux, so they'll show off to their colleagues about how clever they are to be using StarOffice. (These are the same people who bore you about the processor speed of their new machine, but don't know what chipset is running on their mobo).

You'll hear them in the office "blah blah blah blah StarOffice blah blah blah really very good, only $50 blah blah blah Microsoft better buck their ideas up blah blah blah".

And you can feel smug about having sent them a document which you wrote on OpenOffice on GNU/Linux, and they think they're clever to be able to read it (because they pressed "Next" a few times).

Never foget how stupid, vain and banal the people are that Sun are aiming at.

Dunstan

PS a quick word on the Solaris version being free - this, of course, isn't aimed at Solaris workstation users, rather at businesses who are considering deploying Sunray solutions, so after buying the servers, network infrastructure and appliances, you don't have to pay software royalties for running an office suite. Add in a Tarantella infrastructure, and you can work on the same desktop on the SunRay in the office, or in a browser at the internet cafe.

It's all starting to come together.

Benchmarks are a mixed blessing. It's always nice when a benchmark favors your brand, but the tables are easily turned just by citing another benchmark. A newer jbb2000 result, for example.

This is why benchmarks are so highly overrated. What seems to be true one day isn't the next.

Fact is, the IBM pSeries compete in the same market as the Sun Starfire servers. In this arena, the benchmarks are just going to bounce around as each company edges forward. The SPEC historical data reflects this.

(And for the record, I think this is great. If you aren't happy with OO, then pay your $35 and get a supported version. As long as SO and OO use the same code base, like Mozilla and NS, I think it's a good move by Sun.)

In one hand we have Sun Increasing [its] Commitment to Gnome, and yet on the other it's abandoning a critical product in its battle against MSFT and professing that Linux on the Mainframe [is] Not a Good Idea. Microsoft are regularly raising the bar when it comes to talking to their client operating systems from non Windows Servers (eg the infamous Kerberos PAC), so surely having your own office suite appearing on Windows clients can't hurt, especially as everything starts to look like a big (.NET centred) communications network. I wonder what IBM thinks about all this? I get the feeling they're closer to the mark than Sun, and if nothing else they've decided their direction and are throwing their whole weight behind it, which is commendable (certainly preferrable over this wishy washy floundering from Sun). And what's with bashing Linux *and* pulling Solaris for Intel architectures. Ok, so you're a hardware vendor, but how's anyone meant to know their way around Solaris with uni labs migrating to Linux left right and centre and with you revoking any chance a hobbyist had of playing with it without parting with arms and legs for Sun hardware? Why don't you just let go of Java so we can stop concerning ourselves with what direction you've chosen for today and get on with ensuring J2EE retains its position in the web services market.

Probably the biggest difference will be the lack of support for the Sun ONE WebTop(whatever, exactly, that is) in OpenOffice.

I can do everything linux can on Solaris

Easy. Sun have provided the ability for third parties to write drivers for Solaris for as long as I can remember. See here for everything you need to know. If you're going to slate Solaris, at least base it on facts. I have been using both Solaris and Linux for over 10 years now. I can do almost everything on Solaris that I can do on Linux, and I can do almost everything on Linux that I can do on Solaris. Both are good operating systems, and each have their strengths and weaknesses. Use whichever one is right for you for the task in hand, and be thankful you don't have to use Windows...

Why would Microsoft buy Amiga though, if it's really true (it kind of seems unlikely, given .NET presumably is a head-to-head rival to AmigaDE, they're not going to throw out the CLI now and replace it with DE surely?)

• Because Elate is at the machine code level and thus allows true language agnosticity, which is a point that MS pushes hard for .NET, but can't deliver on?
• Because the CLI could easily be layered upon Elate, and then run on most any handheld or desktop?

...Or are they just itching to get their hands on the AutoConfig(tm) patents that prevented P&P from being efficient? Seems a little late for that, but...

That bit about AutoConfig is interesting too... For those that have never experienced it, Amiga AutoConfig allowed all expansion (Zorro) cards to have drivers in ROMS on the cards. You would just plug in the card, reboot, and the driver would be uploaded and run.

This is all very tied to a single platform (Amiga in this case), but Sun has made a lot of progress in this field with JINI, where the drivers are made in Java, and there's also actual interface programs built in.

The coolest demonstration I ever saw was when some Sun guys hooked up a FireWire HD and a digital camera to the same box. Two little icons appeared in windows (Camera, HD). By double clicking on the Camera icon, a (Java, stored in the camera) interface appears, displaying the pictures in the camera in an explorer like way. Clicking the HD made the contents of it (from the Java program stored in the HD) also appear in a explorer like window.

Then, they just drag a picture from the camera to the HD...

True Plug-and-Play (on any system!) requires an architecture agnostic solution of this kind!

You will need a virtual language, and I guess Tao's version is as good as (or better than!) any...

1. Servlets are supported by many vendors - so if one implementation sucks, the others may not. Also, if one J2EE vendor goes bust & all their source code catches fire, my servlets will run on another engine.
   
2. Servlets are a light framework - offering full unrestricted access to the Java API
   
3. Servlets can be written by anybody who knows Java - so if I need to, I can hire servlet-programmers very easily (almost everybody in my developer network knows Java and has written servlets before)
   
4. There is a large community of servlet developers - evidence that it is a sound technology
   
5. As someone who actually develops too, servlets *are* a sound technology!
   

From a Linux advocates point of view, there isn't much difference between Sun and Microsoft. Don't be fooled by the saying "My enemy's enemy is my friend", because it doesn't apply here.

Sun sure seemed to be Linux's friend about a week ago while they were flaunting Linux on their new x86 server line.

Check out the Sun Broadens Support for Linux feature.

Sun's pissed that they can't run multiple instances of an OS on their E15K systems.

They are both Unix(-like), both solve the same problems but Linux does it cheaper and allows you to look ath the source code.

Actually, the price of Solaris is not really that expensive unless you are using a system with very many CPUs. A single user copy if you download it is pretty much free. It is the hardware needed to run it on that is expensive. Also, the solaris source code is available.

I doubt Sun really cares that badly about the success of Solaris so much as they care about the failure if IBM. As far as I can tell, this article is mostly pushing the fact that a cluster of low end Sun boxes running Linux will be better than an IBM mainframe running Linux.

They are both Unix(-like), both solve the same problems but Linux does it cheaper and allows you to look ath the source code.

Actually, the price of Solaris is not really that expensive unless you are using a system with very many CPUs. A single user copy if you download it is pretty much free. It is the hardware needed to run it on that is expensive. Also, the solaris source code is available.

I doubt Sun really cares that badly about the success of Solaris so much as they care about the failure if IBM. As far as I can tell, this article is mostly pushing the fact that a cluster of low end Sun boxes running Linux will be better than an IBM mainframe running Linux.

Solaris was introducted in 1991

Wasn't there a story not too long ago that mentioned how Sun was going to support Linux on lower-end machines, but NOT on the high-end Enterprise systems? (bah, I can't find the link) Anyway, people were saying "Well, Linux isn't ready for Enterprise-type systems yet, so keeping the proprietary *nices on these systems isn't a big deal."

Now, Sun comes right out and says this, and people start complaining? Sure, perhaps Sun is trolling for /. Yeah, right.

You may think I'm biased: I work for Sun, after all. Don't get me wrong - I'd absolutely *love* to take one of the *THIRTY* E10k's I have sitting around me at the moment and install Linux on it. Or, rather - I'd love to TRY. But I don't have any real notion that any version of Linux, AS IT STANDS RIGHT NOW, will work as well as Solaris on that box.

Sure, Solaris isn't very user-friendly. GNU/Solaris (Solaris with GNU Tools) is better, but still not anywhere near what most Linux folks are used to when it comes to command-line fun. However, Solaris is *made* to work with Sun hardware. And it does, very well.

I doubt it highly that someone is going to go buy a US$4M E10k/E15k box and start porting Solaris tools and system utilities *just* so people can run Linux on those systems. Right now, the only reason people have installed Linux at ALL on those systems is for bragging rights.

If you want to outlay the cash and start-a-porting, I applaud you. I really do. But I won't hold my breath.

I thought not.

Therefore, the clear winner is Zope. An added benefit is that Python is developed by Guido van Rossum. Judging from his name, he probably comes from some crazy South American country, and they're always fighting for the cause (ie Communism). Using the product of a communist nation is a sure way to stick it to M$$!!!~ Don't worry about having to switch languages, just fire your developers, it's all the rage!! You can pick up some cheap, Free Software-friendly coders from under some bridges or something. (Don't worry about the smell, you'll get used to it - once you are emancipated and embrace Free Software that is!!!)

HTH, HAND!!

Regarding Sun and XML, here is a story from the Sun home page back on March 10th, 1998, shortly after the XML 1.0 spec was approved:

http://www.sun.com/980310/xml/

Here is Jon Bosak's recollection of the orgins of the W3C's XML project:

http://java.sun.com/xml/birth_of_xml.html/

And here is the original W3C Working Draft of November 14th, 1996. Note at the bottom of the page, Jon Bosak, of Sun Microsystems was the chair of the SGML Editorial Review Board:

http://www.w3.org/TR/WD-xml-961114.html/

While Sun was not directly responsible for XML, nor did Sun "invent" XML, one of the key players was on the Sun payroll.

While you are ranting, what are your opinions on IBM's assinine attempt to allow royalty bearing standards at the W3C?

Regarding Sun and XML, here is a story from the Sun home page back on March 10th, 1998, shortly after the XML 1.0 spec was approved:

http://www.sun.com/980310/xml/

Here is Jon Bosak's recollection of the orgins of the W3C's XML project:

http://java.sun.com/xml/birth_of_xml.html/

And here is the original W3C Working Draft of November 14th, 1996. Note at the bottom of the page, Jon Bosak, of Sun Microsystems was the chair of the SGML Editorial Review Board:

http://www.w3.org/TR/WD-xml-961114.html/

While Sun was not directly responsible for XML, nor did Sun "invent" XML, one of the key players was on the Sun payroll.

While you are ranting, what are your opinions on IBM's assinine attempt to allow royalty bearing standards at the W3C?

4. At one time, Scott McNealy admitted that Sun had indeed been the brainchild behind XML.

Please read: Jon Bosak on the birth of XML

I attended the SGML '96 Conference in Boston where Jon Bosak first presented XML to the world. The first copy of the standard was < 10 pages bound in a little blue booklet IIRC. And yes, I think it is quite fair to say that Sun was the brains behind XML. Best comment about the idea was from a friend of mine who called the new XML idea "Topless SGML."

Interestingly, Microsoft was also a serious contributor to the first XML effort. This was at the height of the browser war. I remember one of the SGML ISO committee reps telling me that many of the SGML ISO folks were quietly rooting for MS to succeed because Netscape refused to have anything to do with SGML.

The number of C books is slightly more than there were 10 years ago. we have the classics of K&R C, The C answer book, The Unix programming env and a large number of other worthless titles. Compare that to Pascal books. There are now 3 at the local Borders. How about Ada, also less than 5 but a decade ago ranked more shelf space than java and C# combined. Most of the Java space has been reallocated to C#. To me that means its as trendy as the wrong color skirt at a fassion show.

Bill Joy might be James Goslings boss considering Bill is a founding member of Sun and Chief Scientist and Corporate Executive Officer while James can't even seem to mention his title on his Sun Labs web page

The number of C books is slightly more than there were 10 years ago. we have the classics of K&R C, The C answer book, The Unix programming env and a large number of other worthless titles. Compare that to Pascal books. There are now 3 at the local Borders. How about Ada, also less than 5 but a decade ago ranked more shelf space than java and C# combined. Most of the Java space has been reallocated to C#. To me that means its as trendy as the wrong color skirt at a fassion show.

Bill Joy might be James Goslings boss considering Bill is a founding member of Sun and Chief Scientist and Corporate Executive Officer while James can't even seem to mention his title on his Sun Labs web page

Actually, they should be ashamed to sell that as suitable for heavy duty. This is freaking 2002, not 1992. An UltraSparc III has 8 MB of L2 cache. A MIPS R12000 has (or can have) the same amount. IBM Power4s have similar amounts. (USIII has 32K instruction and 64K data L1 cache, and R12k has 32K of L1, for the sake of comparison.)

I admit I don't have any hard data to back this up, but it's my suspicion that it's in large part the large L2 cache that causes Sparcs to thrash Intels at some tasks. There's a good page on some processor design considerations at SETI@UNC.

. . . 64 max CPUs together ( E15k will have more ), or 8 CPUs.

The E15k already has more: up to 106 processors. And you're right, the supposition that SPARC is dead simply because of the current financial state of Sun is pretty silly.

Even more silly to me is the fact that people are still equating Mhz to the overall value of a chip. And before people start whining, I'm not talking about the "Megahertz Myth", either. Currently, per-chip computing power is dirt cheap. It seems to me that factors like scalability, power consumption, and (as you mentioned) error checking are quickly becoming more important in general-task CPU's.

--Mid

Fud, fud, fud. I can't speak for the other companies but Sun can easily afford to fund R&D on the next generation SPARC chip, they've got 6 billion $ cash in hand. Let alone investments, and have done for over 2 years. BTW the current generation is UltraSPARCIII, UltraSPARCIV is just a fabrication improvement. Work is already underway on UltraSPARCV's design. Sun's crown jewels are SPARC/Solaris, when Sun stops working on their own OS/CPU/Server platform it's time to stop investing in them.

Actually, I was just transferred to the UltraSPARC 4 project at Sun in Burlington, MA. I don't know of the official release date, though I've heard rumors of early 2003. I'm amazed at the quality of FUD in this "article" and that it actually made it to the front page of Slashdot.

Yeh, this is a constant aggro for me as I try to develop JNLP based apps. I've already submitted one complaint about this, but it didn't make it into the bug parade. I just put in another, more strongly worded request - we'll see what happens.

In the meantime, you might want to consider OpenJNLP, which we're targetting for interim use until JavaWS works right.

For your install problem (separate JavaWS install on Linux), see Bug Parade 4636877 and get your votes in!

Don't get me wrong, I'm using the NIO libraries anyway because my company's system needs them, but I was running into a new bug a week for a while. I was hoping they'd have fixed at least the major ones by the time it became official. The workarounds for some of them are just awful.

My major sore points:

• The Selector only supports 63 channels on Win32 (that'll help your scalability :)
• The Selector doesn't work the same across platforms. On Win32 works like WSAAsyncSelect() (only reports channels when something was blocked before), it acts like select() (reports channels whenever they match the requested ops). (Damnit. Write-Once-Run-Just-On-UNIX?)
• Selector.wakeup() breaks after 4096 calls on Linux (Guess I just won't make any new connections :)

Don't get me wrong, I'm using the NIO libraries anyway because my company's system needs them, but I was running into a new bug a week for a while. I was hoping they'd have fixed at least the major ones by the time it became official. The workarounds for some of them are just awful.

My major sore points:

• The Selector only supports 63 channels on Win32 (that'll help your scalability :)
• The Selector doesn't work the same across platforms. On Win32 works like WSAAsyncSelect() (only reports channels when something was blocked before), it acts like select() (reports channels whenever they match the requested ops). (Damnit. Write-Once-Run-Just-On-UNIX?)
• Selector.wakeup() breaks after 4096 calls on Linux (Guess I just won't make any new connections :)

Don't get me wrong, I'm using the NIO libraries anyway because my company's system needs them, but I was running into a new bug a week for a while. I was hoping they'd have fixed at least the major ones by the time it became official. The workarounds for some of them are just awful.

My major sore points:

• The Selector only supports 63 channels on Win32 (that'll help your scalability :)
• The Selector doesn't work the same across platforms. On Win32 works like WSAAsyncSelect() (only reports channels when something was blocked before), it acts like select() (reports channels whenever they match the requested ops). (Damnit. Write-Once-Run-Just-On-UNIX?)
• Selector.wakeup() breaks after 4096 calls on Linux (Guess I just won't make any new connections :)

I don't think sun is laying or hiding things from us; 1. It's not an 'unsafe' mode like in the CLR, it apears to be just a wrapper around some JNI calls. It's not the same thing.

2. It may be undocumented but you can do the exact same thing with the documented java.nio.ByteBuffer

3. It's not that 'unsafe' you can only access bytes in memory you have allocated yourself

2. Why does this facility justify a language change, as opposed to a library solution?

We recognize that a language change is a serious effort, not to be undertaken lightly. The library approach was considered. It was, however, deemed essential that the runtime cost of assertions be negligible if they are disabled. In order to achieve this with a library, the programmer is forced to hard-code each assertion as an if statement. Many programmers would not do this. Either they would omit the if statement and performance would suffer, or they would ignore the facility entirely.

The link is java.sun.com as far as I'm concerned. As of right about now (14 Feb, a sunny Swedish afternoon) I don't see any Release Candidate and/or 'rc' in the filename (well, the Sparc version has...).

What you're missing is probably clearing of cache and throat.

Java *can* be made to run as fast as C/C++ apps but it's rare and only for certain applications of Java. Different compiling and runtime techniques technique such as JIT compiling and using HotSpot can get "primitive functions" - those on arrays of int, floats, etcetera to near comparable C/C++ code. However, the Java built-in libraries have enough built-in bloat to make further promises of speed indistinguishability just plain misleading ("it works fine, just avoid this list of 50 poorly implemented classes"). No, Java the language isn't slow, but Java the set of Sun library implementations has many, many deficiencies.

Also, I wasn't saying that all of Java is one big bug but you can't argue that there are a tremendous amount of bugs in Java's standard APIs. Things like horizontal scrolling not working for JTables. I mean c'mon, really - that's just a standard bounds checking and listener notification algorithm and the bug has been around since 1998. I know JTree has major problems (e.g., node rendering of icons works differently for nodes being edited than those not) and the DefaultTreeNodes in the Java API are overwritten to no end other than inefficiency. Drag and drop doesn't work with multiple items, thus almost no one ever uses DnD in the apps I work on - hell, even I don't because at least I can rely on copy and paste. Well, within the same application, actually, outside of the same VM trouble starts.

It's even cooler though, because the "write once, run everywhere" of Java actually works if you write good code).

Well yes, it runs, but it is far from guaranteed that it runs _well_. I took some of my company's Java apps that ran well under Windows and tried them under OS X and they were dog slow. At one point I managed to get ProcessViewer to report CPU usage over 100%! Highlight some text in your browser - that's what it does. Two simple math coordinate checks, a couple calls to drawRect and drawChars, written about as efficiently as Java allows but with every set of mouse movements I saw the CPU usage shoot through the roof. [The reason I made a custom class for this was because JTextArea and JEditPane were horrendous due to my need for special formatting - I have literally 50 times better performance now than with JEditPane and about 10 times better performance than with JTextArea on my wintel machine.] I know JBuilder runs fine on my machine (I suspect some Mac-specific code or vm settings) but Java isn't at all guaranteed to run well across platforms. Of course, my machine is 3 years old - so is Java 1.2 SE but as I was saying, Sun relies on hardware to catch up. I'm sure it would run fine on a 1 GHz dual processor G4. [Actually I think graphics cards have a large part in Java's performance.]

they assume that anything that is fast, stable and looks and feels platform native wasn't written in Java

Believe me, when something crashes that means to me that it wasn't written in Java. I have never dealt with another language so stable. Even when internal exceptions are thrown I've seen apps soldier on through their own bad states and actually still work, though they do of course become flaky. LnF hasn't really been much of an issue either - Windows and Linux have always looked like crap (haven't tried XP yet) so I've never expected Java apps on either of them to look good and really wouldn't care if widgets on them weren't completely "native-looking". On Mac, it looks sweet except for text rendering. It really is the performance problems and the bugs in Sun's libraries that are the worst thing about Java. The bugs are actually probably more annoying because they are the let-downs "Oh, look it has this great gui widget" and then ten days later "Oh crap that widget has a horrible bug and I'm completely reliant on Sun to fix it or else I have to either write my own version of that widget or steal their source, fix it, recompile it and then only be able to use it internal to the company." It's not a great working method - if they allowed for people to make fixes to Sun code instead of all of us having to either live with the bugs or rewrite entirely new classes, Java would have a much better set of library implementations. Instead people like me have to decide whether we can spare the time to write whole new versions of objects with the same functionality but, well, functional, or tell our boss and have our PR tell our customers "Yes, we know that doesn't work right. It's a problem with Java and there's nothing we can do to fix it." Believe me, as a professional programmer I can tell you that happens over and over again and it is a situation that benefits no one (well, except if you have direct competition that isn't reliant on sun's java libraries, then they benefit).

C'mon what are you talking about bloat? It's not so bad.... </sarcasm>

Larkfellow wrote:

However I will note that, while the Java Web Start was installed on Windows, I didn't find any version of it for linux.

From the Java Web Start guide:

On Microsoft Windows platforms, the Java Web Start Product is installed silently during the installation of the Java 2 SDK and JRE. Look for a Java Web Start icon on your desktop. There will also be an entry for Java Web Start in the Start --> Programs menu.

On Solaris and Linux platforms, the installation script for the Java Web Start product is contained within a zip file that is located in the jre directory of the Java 2 SDK (or in the top level of the JRE). Move the zip file to a location where you would like to install the Java Web Start product. We recommend that this location be outside the Java 2 SDK or JRE directory structure. Unzip the file and run the install.sh script to install the Java Web Start product.

Here-http://java.sun.com/products/jsse/index.html
"It implements a Java version of SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols and includes functionality for data encryption, server authentication, message integrity, and optional client authentication. Using JSSE, developers can provide for the secure passage of data between a client and a server running any application protocol (such as HTTP, Telnet, NNTP, and FTP) over TCP/IP."

Among them: "enhancements" to java.math

Hilarious. Basically a reader-friendly translation of "We hardcoded what was previously a free parameter because people were too st00pid to use it properly."