Slashdot Mirror

I just sent an email to the other Julian Taylor I found with a sun address.

250 Julian.Taylor@Central.Sun.COM... Recipient ok

I guess we'll see what he says.

-Lucas

Complaining about 'will not fix' items on an older JRE is dumb as their must be SOME reason for the 1.4. If everything could have been fixed in 1.3.1, it would have been 1.3.2.

There's a difference between postponing a bug to a later release and classifying it as "will not fix". "Will not fix" implies that it will never be fixed.

Further I personally was told not to rely on the "sun" classes as they change.

True, but this has nothing to do with the linked atricle.

The article writer suggest that each release of the JRE causes classes to be dropped and added. I have NEVER experienced this and its a violation of SUN's stated practice.

No, what he actually says is that minor releases make non-backwards-compatible changes. While removing a class would be one example of this, there are more sublte changes that can break programs. The example they give is "In JDK 1.1 Class.fields() returns only public variables. In 1.2, protected and private variables are returned." This would break applications that use that method.

"4. It is not backward-compatible across minor releases." Then this fool goes and compares 1.3 to 1.4 or 1.1 to 1.2 as IF those are minor releases. (anyone that uses java knows the 3rd digit has been the minor one)

Not true. The first digit is the major number, the second is the minor, the third is the patch. According to Sun's own compatibility guidelines, patch releases should not break compatibility at all. Minor releases should be compatible with old applications, and major releases (e.g. if Sun ever makes a JDK 2.0.0) don't have to be compatible at all. However, Sun break these rules, and there are long lists of incompatibilities between old apps and new Java versions. They usually suggest ways to fix the applications that don't break compatibility with old Java VMs, but that doesn't help vendors who have already shipped applications.

This is one of the reasons why Java applications have to be tested on every VM they may need to run on - not just every brand of VM, but every version and platform too. "Write once, run everywhere" is a nice marketing myth.

Complaining about 'will not fix' items on an older JRE is dumb as their must be SOME reason for the 1.4. If everything could have been fixed in 1.3.1, it would have been 1.3.2.

There's a difference between postponing a bug to a later release and classifying it as "will not fix". "Will not fix" implies that it will never be fixed.

Further I personally was told not to rely on the "sun" classes as they change.

True, but this has nothing to do with the linked atricle.

The article writer suggest that each release of the JRE causes classes to be dropped and added. I have NEVER experienced this and its a violation of SUN's stated practice.

No, what he actually says is that minor releases make non-backwards-compatible changes. While removing a class would be one example of this, there are more sublte changes that can break programs. The example they give is "In JDK 1.1 Class.fields() returns only public variables. In 1.2, protected and private variables are returned." This would break applications that use that method.

"4. It is not backward-compatible across minor releases." Then this fool goes and compares 1.3 to 1.4 or 1.1 to 1.2 as IF those are minor releases. (anyone that uses java knows the 3rd digit has been the minor one)

Not true. The first digit is the major number, the second is the minor, the third is the patch. According to Sun's own compatibility guidelines, patch releases should not break compatibility at all. Minor releases should be compatible with old applications, and major releases (e.g. if Sun ever makes a JDK 2.0.0) don't have to be compatible at all. However, Sun break these rules, and there are long lists of incompatibilities between old apps and new Java versions. They usually suggest ways to fix the applications that don't break compatibility with old Java VMs, but that doesn't help vendors who have already shipped applications.

This is one of the reasons why Java applications have to be tested on every VM they may need to run on - not just every brand of VM, but every version and platform too. "Write once, run everywhere" is a nice marketing myth.

Complaining about 'will not fix' items on an older JRE is dumb as their must be SOME reason for the 1.4. If everything could have been fixed in 1.3.1, it would have been 1.3.2.

There's a difference between postponing a bug to a later release and classifying it as "will not fix". "Will not fix" implies that it will never be fixed.

Further I personally was told not to rely on the "sun" classes as they change.

True, but this has nothing to do with the linked atricle.

The article writer suggest that each release of the JRE causes classes to be dropped and added. I have NEVER experienced this and its a violation of SUN's stated practice.

No, what he actually says is that minor releases make non-backwards-compatible changes. While removing a class would be one example of this, there are more sublte changes that can break programs. The example they give is "In JDK 1.1 Class.fields() returns only public variables. In 1.2, protected and private variables are returned." This would break applications that use that method.

"4. It is not backward-compatible across minor releases." Then this fool goes and compares 1.3 to 1.4 or 1.1 to 1.2 as IF those are minor releases. (anyone that uses java knows the 3rd digit has been the minor one)

Not true. The first digit is the major number, the second is the minor, the third is the patch. According to Sun's own compatibility guidelines, patch releases should not break compatibility at all. Minor releases should be compatible with old applications, and major releases (e.g. if Sun ever makes a JDK 2.0.0) don't have to be compatible at all. However, Sun break these rules, and there are long lists of incompatibilities between old apps and new Java versions. They usually suggest ways to fix the applications that don't break compatibility with old Java VMs, but that doesn't help vendors who have already shipped applications.

This is one of the reasons why Java applications have to be tested on every VM they may need to run on - not just every brand of VM, but every version and platform too. "Write once, run everywhere" is a nice marketing myth.

Complaining about 'will not fix' items on an older JRE is dumb as their must be SOME reason for the 1.4. If everything could have been fixed in 1.3.1, it would have been 1.3.2.

There's a difference between postponing a bug to a later release and classifying it as "will not fix". "Will not fix" implies that it will never be fixed.

Further I personally was told not to rely on the "sun" classes as they change.

True, but this has nothing to do with the linked atricle.

The article writer suggest that each release of the JRE causes classes to be dropped and added. I have NEVER experienced this and its a violation of SUN's stated practice.

No, what he actually says is that minor releases make non-backwards-compatible changes. While removing a class would be one example of this, there are more sublte changes that can break programs. The example they give is "In JDK 1.1 Class.fields() returns only public variables. In 1.2, protected and private variables are returned." This would break applications that use that method.

"4. It is not backward-compatible across minor releases." Then this fool goes and compares 1.3 to 1.4 or 1.1 to 1.2 as IF those are minor releases. (anyone that uses java knows the 3rd digit has been the minor one)

Not true. The first digit is the major number, the second is the minor, the third is the patch. According to Sun's own compatibility guidelines, patch releases should not break compatibility at all. Minor releases should be compatible with old applications, and major releases (e.g. if Sun ever makes a JDK 2.0.0) don't have to be compatible at all. However, Sun break these rules, and there are long lists of incompatibilities between old apps and new Java versions. They usually suggest ways to fix the applications that don't break compatibility with old Java VMs, but that doesn't help vendors who have already shipped applications.

This is one of the reasons why Java applications have to be tested on every VM they may need to run on - not just every brand of VM, but every version and platform too. "Write once, run everywhere" is a nice marketing myth.

Complaining about 'will not fix' items on an older JRE is dumb as their must be SOME reason for the 1.4. If everything could have been fixed in 1.3.1, it would have been 1.3.2.

There's a difference between postponing a bug to a later release and classifying it as "will not fix". "Will not fix" implies that it will never be fixed.

Further I personally was told not to rely on the "sun" classes as they change.

True, but this has nothing to do with the linked atricle.

The article writer suggest that each release of the JRE causes classes to be dropped and added. I have NEVER experienced this and its a violation of SUN's stated practice.

No, what he actually says is that minor releases make non-backwards-compatible changes. While removing a class would be one example of this, there are more sublte changes that can break programs. The example they give is "In JDK 1.1 Class.fields() returns only public variables. In 1.2, protected and private variables are returned." This would break applications that use that method.

"4. It is not backward-compatible across minor releases." Then this fool goes and compares 1.3 to 1.4 or 1.1 to 1.2 as IF those are minor releases. (anyone that uses java knows the 3rd digit has been the minor one)

Not true. The first digit is the major number, the second is the minor, the third is the patch. According to Sun's own compatibility guidelines, patch releases should not break compatibility at all. Minor releases should be compatible with old applications, and major releases (e.g. if Sun ever makes a JDK 2.0.0) don't have to be compatible at all. However, Sun break these rules, and there are long lists of incompatibilities between old apps and new Java versions. They usually suggest ways to fix the applications that don't break compatibility with old Java VMs, but that doesn't help vendors who have already shipped applications.

This is one of the reasons why Java applications have to be tested on every VM they may need to run on - not just every brand of VM, but every version and platform too. "Write once, run everywhere" is a nice marketing myth.

Java is backwards compatible for most of it's recent releases.

Anyway, regardless of the JVM, applets are only applets.

I hate to sound trite, but the fact that you place so much importance on applets (they are, after all, the only example of the technology that you imply exists) leads me to believe you're not really versed in the current trends in Java. The simple fact is that no one use's applets anymore; certainly there is no new development going on in that area. Most Java applications are written for the J2EE platform.

Even at that, those who do wish to write the modern equivalient of applets use Java Web Start, which is much more robust and doesn't operate within the confines of a browser.

WTF? Look, bitch boy. Read here:
this fucking article

Read it closely and you'll answer your own fucking question.

Give me your paypal and I might send you a nickel so you can buy yourself a fucking clue.

You can download a "Try & Buy" version of Forte 6 for Intel that will work for 30 days. That should at least be long enough to decide whether or not you're missing out because the compiler you use is $2000 cheaper.

Forte 6 Update 2 Try & Buy

It doesn't look like this has changed it all, at least by looking at the website. Of course, Sun may be totally justified by doing this - they have to recover their costs somehow, and besides, it may not matter for a server machine - but at the same time, comparing saying Solaris is free in the same way as Linux is a bit deceiving.

I would be curious what other think about this ... for instance, is the gcc available for Solaris? Does Forte (Sun's compiler collection) have any advantages?

well, solaris 8 has been free for at least 2 years....
to bad it isn't now, check it out if you don't believe me. $20 american for either solaris 8 or 9 (and i'm canadian! i can't afford $20 american!). By free they mean no licensing (you still have to pay for either the media or the d/l).. don't believe me? check here.

well, solaris 8 has been free for at least 2 years....
to bad it isn't now, check it out if you don't believe me. $20 american for either solaris 8 or 9 (and i'm canadian! i can't afford $20 american!). By free they mean no licensing (you still have to pay for either the media or the d/l).. don't believe me? check here.

Hell, I don't think Sun even offers an x86 version of their C/C++ compiler

well... there's openwindows:

here's the text

here's the picture

Non-commercial usage is available at no charge

Thats cool and all, but you still have to pay $20 to download the ISOs [sun.com].

Not to mention that you have to pay if you are using a multiple-CPU system:

For systems with a capacity of 2 or more CPUs, users can purchase licenses...
Licensing Policies

I guess that rules me out, then... :-P

Download it and copy at will, it's FREE.

"you may not make copies of Software, other than a single copy of Software for archival purposes."

From Binary Code License Agreement.

No, read it again.

The $20 is for Download Only. If you want the free X86 media shipped out to you for personal use it's $95.

Again, it's certainly worth $95 but I detest the whole trickery behind it all.

Here is the Intel based HCL list, but nothing about Solaris 9 yet.

Non-commercial usage is available at no charge

Thats cool and all, but you still have to pay $20 to download the ISOs.

I guess it's a good deal. Free would be better though.

Just like one of the top requests for enhancement in the Java bug-parade states, covariant return types could have done most of the work of Generics without the additional clumsy syntax. (i.e. sub-classes could override return values of overriden methods to return sub-classes of the original return values instead)
overall, I'd rather have this than nothing...

In fairness to Nokia, the fact that you can run MIDP apps on this device does provide a certain level of compatibility between this and Palms. So, for a java developer such as myself, once you write the game logic you just have to customize the interface to whatever device you're working with. Sure it's not 100%, but it's also not nothing.

The thing that does suck though is that MIDP is only availble by way of an 'add-on' to Palms. So you can't expect a palm device to have it (unless you load it yourself). But, bearing in mind that this is a very different device than a palm, Nokias approach seems kind of reasonable.

• "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"

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

You could follow the link in the story and find out what Sun has to say about it -- it's in their FAQ. Basically, the key word is "network-aware".

From a what-Sun's-not-saying standpoint, I imagine it appeals to them that you can write closed-source software for GNOME without having to pay Trolltech.

Installing the medialib packages (not part of Solaris or the GNOME download) should improve peformance. You can download these from here

Please read this message at http://wwws.sun.com/software/star/gnome/get/#downl oad:
a security vulnerability in the GNOME Print Manager could allow unauthorized reading of files. To resolve this issue, after installation of GNOME 2.0, execute the following command (as root user):
chmod u-s /usr/lib/gnome-print-manager-remote

Check out the Sun GNOME 2.0 Performance Troubleshooting Guide. Perhaps it can help you.

Well, first off there's the entry in their FAQ, titled "Why did Sun choose to support GNOME instead of KDE?", but that's a bit light on details.

A couple years ago I went to a presentation from Sun about Gnome, and they went into more details, but my slides are at home. The couple that leap to mind though: there were the licensing questions with QT. There was also the fact that Gnome's C based rather than C++, and the large portion of Sun folk were much more comfortable working w/ C rather than C++.

When I get home, I'll dig up my slides, and if they add anything more to this discussion (since lots more people will probably respond by then, and I'm not sure how indepth they went into this particular topic), I'll append something more.

sun has predicted this kind of questions and answered in their FAQ

quoting from http://wwws.sun.com/software/star/gnome/faq/genera lfaq.html#4q0

Q. Why did Sun choose to support GNOME instead of KDE?

A. GNOME and KDE are both powerful desktop environments. Sun has completed a comprehensive technical review of both environments and concluded that GNOME's architecture is a better match for Sun's software strategy, which promotes the creation and use of highly distributed, network-savvy software, as well as easy access to data wherever it might be located. One example is GNOME's innovative use of CORBA for network-aware interprocess communication between disparate systems. Others are the Bonobo component architecture, which enables easier creation of compound documents and system-wide scripting while promoting code reuse, and GConf, the network- and component-aware configuration management system.

Solaris in less than 16 KB!?! and available on the 2600?!? Where can I download Solaris 9?

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

Trusted Solaris

Pit Bull from Argus Systems

IIRC, these are more common Un*ces that are patched to provide "capabilities" - that is, instead of the root being the one-size-fits-all user that has enough privileges to get anything done, different kinds of access are broken down so that if a running program getw 0wned, it limits the damage.

Theo's answer to that probably would be, "code it right in the first place and it won't GET 0wned!!!", which is a valid point, the devil (no pun intended) is in the details.

BTW, I first came across EROS comes from Alan Cox in an interview with Robert Metcalfe a few years ago (remember the "Open Sores" series of articles? Great trolling, Bob!), in response to a question of what he thought was going to be the next big thing after Linux. He was impressed with the response (having previously accused Linux-y types of monomaniacal zeal), but it didn't overturn his opinion at the time that Linux was doomed. Oh well. (This comes to you courtesy of the similarly fated Internet.)

I seem to recall that when compiling BLAS for an AMD chip, one of the ./configure options was to use the 3DNow! extensions. There was a warning against doing that, since the speedup came at the expense of accuracy, in some situations. See here .

...beyond what is found in, for example;

[warning 5+mb download]

http://www.sun.com/processors/manuals/usIII_um.p df
?

If that's not good enough, fine, what areas need
more info? What exactly are they looking for?

Depending on your requirements, perhaps commercial UNIX isn't so bad after all. This isn't intended to be a troll; I'm trying to say that Free GNU/Linux is complementary to the commercial UNIX business model in the real marketplace. Even RedHat is willing to sell you extended support, which furthers this argument (i.e., RedHat is becoming more like the commercial UNIX vendors in time).

Great story! However, you can get all kinds of user manuals, hardware manuals, software manuals, etc from http://docs.sun.com You can read them on-line, download Adobe Acrobat versions, and purchase the documents as well. It's a lot easier than it used to be... HMM, no Sparc 1 manual, but the Sparc Classic and similar is at http://docs.sun.com/db/doc/801-2176-13:

Great story! However, you can get all kinds of user manuals, hardware manuals, software manuals, etc from http://docs.sun.com You can read them on-line, download Adobe Acrobat versions, and purchase the documents as well. It's a lot easier than it used to be... HMM, no Sparc 1 manual, but the Sparc Classic and similar is at http://docs.sun.com/db/doc/801-2176-13:

Sun, with ANY kind of documentation, is going to be a royal pain in the ass. Here, i'll give you a personal example. One day, I picked up a SparcStation 1 at a surplus auction.

My experience was quite different. I was trying to get some Sun Xterminals (rather old; they were basically Sparcstation 2's without hard drives) booting and serving up displays from a Red Hat machine, instead of the aging Sparcserver we were about to retire.

We had support contracts with Sun for several machines, but not the Xterminals or the Sparcserver they booted from. I put in a request with Sun (via a web form) anyway. Within a few hours, someone at the local Sun office was on the phone to me. The next morning, I had a single copy of the manuals on my desk, via courier.

PS - there's a heap of stuff on docs.sun.com

OTOH, DHTML usually is a pain for both users and developers.

This is completely laughable. Since its first release (as an add-on package, not even part of the JDK) Swing has been one of the most mature and best designed GUI toolkits available. The only three allegations which can be justifiably levelled against Swing are:

• Swing has historically had performance problems, and these have not been entirely addressed;
• Swing was difficult to develop by virtue of not having GUI builders (but no more difficult than most other non-script toolkits without builders);
• Swing presents a GUI model slightly more complex than is typical, and many developers dive in without understand it (this is especially true for X-Windows developers who have less experience with threads and the concept of a separate thread dedicated to the GUI.

Most developers who complain about the difficulty of using Swing are simply missing the point. I have had developers argue for hours about how terrible the table/tree components are, because you have to do "all that useless shit with models", and you can't just say "table.setCellAt(x, y, value)". Similarly there are a dearth of developers (especially those from the MS Windows world) who understand the need for layout components, as opposed to using absolute dimensions and coordinates.

For anyone who disses Swing, make sure you've read the Java Look and Feel Design Guidelines. Better than a Swing manual or introduction, it investigates building real-world applications with Swing, focusing on user experience and usability.

Swing's support for consistent navigation; centralised control over colours, widget L&F and localization; as well as its powerful and extensible widget set (e.g. TreeTables and the SwingSet2 demo) put it years ahead of most other toolkits, even now. Java's native L&F has improved over the years, to the extent that (for win32 at least) you can create Java apps that look native.

But Swing is not a silver bullet. With any cross platform toolkit you will run into problems. Qt, GTk, and Wx all have issues that need to be resolved when porting the app using them to a new platform. Similarly there is some effort to ensure that your Java/Swing application looks and behaves consistently on all its target platforms. In my experience Swing is far more portable than other toolkits, with the possibly exception of Tk. If performance is paramount in your application, then Swing is not for you; but this certainly doesn't make it unsuitable for an average business application.

This is completely laughable. Since its first release (as an add-on package, not even part of the JDK) Swing has been one of the most mature and best designed GUI toolkits available. The only three allegations which can be justifiably levelled against Swing are:

• Swing has historically had performance problems, and these have not been entirely addressed;
• Swing was difficult to develop by virtue of not having GUI builders (but no more difficult than most other non-script toolkits without builders);
• Swing presents a GUI model slightly more complex than is typical, and many developers dive in without understand it (this is especially true for X-Windows developers who have less experience with threads and the concept of a separate thread dedicated to the GUI.

Most developers who complain about the difficulty of using Swing are simply missing the point. I have had developers argue for hours about how terrible the table/tree components are, because you have to do "all that useless shit with models", and you can't just say "table.setCellAt(x, y, value)". Similarly there are a dearth of developers (especially those from the MS Windows world) who understand the need for layout components, as opposed to using absolute dimensions and coordinates.

For anyone who disses Swing, make sure you've read the Java Look and Feel Design Guidelines. Better than a Swing manual or introduction, it investigates building real-world applications with Swing, focusing on user experience and usability.

Swing's support for consistent navigation; centralised control over colours, widget L&F and localization; as well as its powerful and extensible widget set (e.g. TreeTables and the SwingSet2 demo) put it years ahead of most other toolkits, even now. Java's native L&F has improved over the years, to the extent that (for win32 at least) you can create Java apps that look native.

But Swing is not a silver bullet. With any cross platform toolkit you will run into problems. Qt, GTk, and Wx all have issues that need to be resolved when porting the app using them to a new platform. Similarly there is some effort to ensure that your Java/Swing application looks and behaves consistently on all its target platforms. In my experience Swing is far more portable than other toolkits, with the possibly exception of Tk. If performance is paramount in your application, then Swing is not for you; but this certainly doesn't make it unsuitable for an average business application.

In addition to Swing and SWT there are also other cool Java client API's.

Java 2D For doing lots of fun stuff with antialiased text, fonts, composting, etc.

Java Advanced Imaging For advanced image processing

Java Media Framework For capture, playback, and streaming of audio and video.

In addition to Swing and SWT there are also other cool Java client API's.

Java 2D For doing lots of fun stuff with antialiased text, fonts, composting, etc.

Java Advanced Imaging For advanced image processing

Java Media Framework For capture, playback, and streaming of audio and video.

In addition to Swing and SWT there are also other cool Java client API's.

Java 2D For doing lots of fun stuff with antialiased text, fonts, composting, etc.

Java Advanced Imaging For advanced image processing

Java Media Framework For capture, playback, and streaming of audio and video.

In some environments, 3 years is less than shit. In such places testing alone takes 8 months and more.

Anyway, look at this!
Pretty fucking impressive, isn't it? Solaris is, for this reason, one of the good choices for companies such as mine (R&D mobile phone industry, 50.000+ people).

limewire

ant

J2ME apps for mobile phones & stuff

Swing (Sun's tech that lets you create GUIs the same xplat) stinks. But even Sun admits it, and (see the same link) they are doing something about it. Swing is no longer "a way for database apps to display debugging information in X11".

I'm still hoping for a Swing replacement from Sun that'll ship with its java virtual machines, but until then we have IBM's SWT which ties the widgets much more closely to native counterparts and Apple's attempts to merge Swing directly to native GUI widgets. We're nowhere close to Windows.Forms yet, but Swing's not so bad that you can't get the hang [notice I didn't say Swing] of things quickly.

The point being that you have options. Once you get the hang of Window Managers (doesn't take long) and creating some sort of Model for everything (from sorting tables to adding new values to lists), you can do complicated layouts that work xplat more quickly in the text editor of your choice than you could hack up a static UI (ie, that doesn't resize well) in the Visual Basic IDE -- which, as everyone knows, is really what makes VB GUIs "so easy".

(Aside: Even more importantly would be a standards-compliant parallel to what Microsoft's Web Forms does for IE... a quick, smart widget toolkit for the web. A "JWeb Forms" for JSP would do a lot to enable smart web-enabled UIs to Java web services.)

And there's nothing about Java that stops it from being a great client-side language short of Swing. Moore's Law and clever JIT VMs have pretty much done away with any show-stopping speed issues. Another hurdle is the fact that Java only compiles to bytecodes, making [even commercial] apps trivial to decompile, but if you look at VB 7 (aka, VB.NET) and C#, Java's most closely related competitors, they've got the same problems.

And sure, Java is more "Write once, test everywhere" than "... run everywhere", but you're not going to find an easier port from one platform to the next than Java. It commoditzes the user's operating system, and that's a great thing.

And heck, I'm using it. At least I'm putting my money where the keyboard is.

Not the mention the popular Java IDE Eclipse. Now that Microsoft has to ship the Java VM, you'll probably see more of Java Web Start.

... and poised to dominate the new mobile applications market.