Slashdot Mirror

One real shortcoming is in the area of video drivers. Fortunately, XFree86 works on Solaris x86, addressing that problem rather nicely.

Neat, though I'm not much on the motorcycle thing after witnessing an acquaintance fatally crash. A HUD wouldn't have saved him, but perhaps a personal radar displayed on that HUD could give (motor and muscle) cyclists the information they need to avoid similar accidents. Combined with a wireless medical alert system, drivers - heck, regular folks - will have a much better chance of surviving an accident.

Even though I know you're joking, they did release (partial?) sources for Solaris 8, although it's no longer in effect for the average person. As others have noted, though, it wasn't and couldn't be GPLed.

Check Solaris Freeware, they have GNU binaries for Solaris SPARC/Intel 8 and 9.

Apache, wget, gcc, nmap, openssh, samba, tcpdump, you name it:

Solaris Freeware

You can also install Gnome 2.0 under Solaris!

GNOME 2.0 Desktop for the Solaris Operating Environment

Ricardo

First of all, why was the parent modded up funny? Maybe I'm just humor impaired, but I didn't get the joke.

Second, the reason you think Solaris on sparc is slow is that you've never used a new powerful sun machine. You probably have experience on Ultra5's or something. I've done some work on these and they are by no means slow. Horribly expensive, but not slow. Also note, that these are included in Sun's "entry-level server" section.

Solaris has lots of feature that are beginning to exist in linux (may exist, but not widely implemented) and the bsd's. One example dynamic reconfiguration. Getting some ram errors? Cool, swap it out. (while you're running) Real access controls work, i.e.: "setfacl -m user:mongo:r-- test"; the user mongo has specific (read only) access to the file test. yesm you can patch your kernel, but it's in solaris by default. Solaris containers are pretty cool too: think userspace linux w/ the expense of multiple kernels crossed w/ openmosix crossed w/ linux-HA.

Solaris may go a way. Solaris may become a legacy OS. There are some *really* cool things in solaris that do not exist in linux yet, though, and if they keep up the R&D, by the time mainsream linux has them, then they will have other really cool stuff. Does that mean that people will pay lots of $$ for them when they can install freebsd or linux for free? I don't know. I think that a lot of the stuff in there *is* worth it, and if the trend in the linux market place goes the way redhat wants it to, where you're going to be spending $300 for a copy of the os/server anyway, then I definitely think solaris is worth a look.

Solaris has lots of feature that are beginning to exist in linux (may exist, but not widely implemented) and the bsd's. One example dynamic reconfiguration. Getting some ram errors? Cool, swap it out. (while you're running) Real access controls work, i.e.: "setfacl -m user:mongo:r-- test"; the user mongo has specific (read only) access to the file test. yesm you can patch your kernel, but it's in solaris by default. Solaris containers are pretty cool too: think userspace linux w/ the expense of multiple kernels crossed w/ openmosix crossed w/ linux-HA.

Solaris may go a way. Solaris may become a legacy OS. There are some *really* cool things in solaris that do not exist in linux yet, though, and if they keep up the R&D, by the time mainsream linux has them, then they will have other really cool stuff. Does that mean that people will pay lots of $$ for them when they can install freebsd or linux for free? I don't know. I think that a lot of the stuff in there *is* worth it, and if the trend in the linux market place goes the way redhat wants it to, where you're going to be spending $300 for a copy of the os/server anyway, then I definitely think solaris is worth a look.

Free (beer) solaris x86 makes it accessable to poor college students. Whether or not Linux is the only relevent unix-like OS for x86, exposure to various systems, ie *BSD, Linux, Plan9, Solaris x86, is a good learning experience. I'm sure many /.ers got their start in computing that way.

>>Solaris 8/9 and CDE, what could be better...
Solaris 9 and Gnome...oh wait that's been standard for the the last couple of releases of 9.

And before people whine too much about hardware support...
For a port of XFree86 drivers to Solaris(even the VESA driver) please see: here
For nic drivers see here(I helped get the Realtek driver building with the Solaris/sparc version of gcc, previously you had to buy Sun's compiler to build the driver for a 10 dollar nic)
Or you might want to look here for links to other Solaris drivers.

Possibly worth mentioning would be the solaris xfree86 driver kit, which allows Sun's X server to use xfree86's video drivers. (Video cards being one of the most frequent sources of hardware incompatibility...)

x86 Platform, License Upgrades

Worth reading the hardware compatibility list before installing

Rus

Yes, this seems like a class that should be an elective after the basic OOP course.
Wouldn't it be better to focus (as an elective course) on cross-platform development like Java, which can run on Mac?

Wrong interpretation of "invested."

Royal Bank runs Sun Microsystems machines and software. They need Sun to stay around.

source: http://www.sun.com/finance/partnercompany.html at the bottom under "x.eye" heading see http://www.sun.com/finance/docs/rbcfin.pdf

http://www.microsoft.com/windowsxp/64bit/howtobuy/ default.asp

Windows XP 64-bit is already made -- for the Itanium. You either get to wait for them to port it to the Athlon64, or you get to find another one.

That's why some people use Sun.

Evolution is truly a first class application. Polished, debugged, good-looking, and professional.

That having been said, though, I am still disappointed by the fact that they are not supporting remote calendars out of the box. Sure, you can buy plugins to connect it to Exchange, or Netscape/iPlanet/SunONE/JES calendar server (whatever they're calling it this week), and presumably Groupwise (soon) ... but where's the built-in support for remote calendars using an open protocol? Folks like me who are developing open source groupware servers are anxiously awaiting good clientware to connect to. How about putting WCAP in the standard build? It's well-documented and much simpler than the disgusting mess the IETF is proposing (CAP has the dubious honor of being the one protocol even uglier than IMAP).

So how about it, codemonkeys? The sooner we get some real open source calendaring going, the sooner we can start to make a real challenge to Outlook. Microsoft loves the Outlook/Exchange lock-in. They love it so much that they're trying to do the same thing across their entire product line (Office 2003 has many ties to SharePoint server). The window of opportunity is open, but it won't be forever.

The pricing info is here.

Yes Solaris does have it. When I integrated it into Solaris (along with help from Alec Muffett & Casper Dik) we made it a pluggable framework by building on the data format you created - thank-you for having the foresight to use the $ char as a "magic" switch.

Details of the pluggable framework with a policy that allows for automigration on password change are available here: crypt.conf and policy.conf

Solaris source code is NOT needed to add new algorithms all code that uses crypt(3c) should continue to work. Code that changes passwords should use crypt_gensalt(3c) to create the salt.

Yes Solaris does have it. When I integrated it into Solaris (along with help from Alec Muffett & Casper Dik) we made it a pluggable framework by building on the data format you created - thank-you for having the foresight to use the $ char as a "magic" switch.

Details of the pluggable framework with a policy that allows for automigration on password change are available here: crypt.conf and policy.conf

Solaris source code is NOT needed to add new algorithms all code that uses crypt(3c) should continue to work. Code that changes passwords should use crypt_gensalt(3c) to create the salt.

Maybe not! Check this presentation out from the sun website.. It demos their new Project "Looking Glass" for desktops. It looks amazing!!! Wonder when they will package it on the desktop systems. This sure looks compelling enough for the average user..

And even then, there's not much hardware that scales like Sun's does. Think about this: if a processor has a bit of memory in cache, and another processor updates that value in RAM the original processor now needs an updated value. Scale that over 100+ processors.

Intel processors can't do it.

Yet Sparc/Solaris does it damn near linearly - for a hundred or more processors.

Where else but Sun can you get 100 or so 64-bit processors with uniform access to half a terabyte of RAM? Right here.

This proposed Walmart deal strikes me as exactly what Red Hat would be trying to do, if they were remaining in the market as a consumer distribution. The article doesn't even attempt to define the Java Desktop System (hence the above links), so there's really nothing in the way of comments as to how good the thing is.

Also, does the "Java" in the name of this product really mean that the desktop is in fact written in Java? I can't imagine that's the case, or why it would be desirable. But one analyst quoted in the article seems to take it as a given that this thing is written in Java:

I personally keep Java off my computer because it crashes the system...If Sun had the interests of the customer in mind, then the Sun desktop would be written in C and donated to Linux. Sun is no better than Microsoft.

From what I can see, if this deal comes to pass, Walmart may soon be selling Linux based systems with a highly polished front end, equipped with a suite of office/internet software that does everything an entry-level buyer could want. Seems to me that this would be a big step up from people buying XP boxes. It would increase the market share of Linux, and result in way more Linux software being developed.

So I have two questions. If anyone here has used the Java Desktop System, what do you think? And does anyone see any real downside to Linux if this deal is made?

This proposed Walmart deal strikes me as exactly what Red Hat would be trying to do, if they were remaining in the market as a consumer distribution. The article doesn't even attempt to define the Java Desktop System (hence the above links), so there's really nothing in the way of comments as to how good the thing is.

Also, does the "Java" in the name of this product really mean that the desktop is in fact written in Java? I can't imagine that's the case, or why it would be desirable. But one analyst quoted in the article seems to take it as a given that this thing is written in Java:

I personally keep Java off my computer because it crashes the system...If Sun had the interests of the customer in mind, then the Sun desktop would be written in C and donated to Linux. Sun is no better than Microsoft.

From what I can see, if this deal comes to pass, Walmart may soon be selling Linux based systems with a highly polished front end, equipped with a suite of office/internet software that does everything an entry-level buyer could want. Seems to me that this would be a big step up from people buying XP boxes. It would increase the market share of Linux, and result in way more Linux software being developed.

So I have two questions. If anyone here has used the Java Desktop System, what do you think? And does anyone see any real downside to Linux if this deal is made?

Enhanced crypt() Function Password encryption protects passwords from being read by intruders. Three strong password encryption modules are now available in the software:

* A version of Blowfish that is compatible with BSD systems

* A version of MD5 that is compatible with BSD and Linux systems

* A stronger version of MD5 that is compatible with other Solaris 9 12/02 systems

and System Administration Guide: Security Services

Enhanced crypt() Function Password encryption protects passwords from being read by intruders. Three strong password encryption modules are now available in the software:

* A version of Blowfish that is compatible with BSD systems

* A version of MD5 that is compatible with BSD and Linux systems

* A stronger version of MD5 that is compatible with other Solaris 9 12/02 systems

and System Administration Guide: Security Services

For example, Java uses a hybrid type system where most values (strings, array) are objects and have by-reference semantics, but primitive values (ints, longs, doubles, bools, etc.) do not behave as objects and have by-value semantics. It's less elegant for the programmer than some other languages (Smalltalk, Ruby, others?) where Everything Is An Object, but makes a big difference for performance and memory consumption (and memory usage patterns).

The Java language spec also goes into quite some effort to specify a threading model. IMO this is a great boon for people who want to build serious servers in Java... contrast this to many scripting languages, which (appropriately, perhaps) seem to treat concurrent programming as an afterthought.

Or if you take a look at Bjarne Stroustrup's Design and Evolution of C++, he mercilessly rejects adding any language feature that cannot be implemented without slowing down code that doesn't use the new feature. (I can't think of any examples right now, and I can't find my copy.)

Though the author of the post also defines scaling differently, I believe anyone talking Java scaling versus PHP, etc, should read this /. post in the context of this chapter of Designing Enterprise Applications with the J2EE(tm) Platform, Second Edition that deals with "Web-Tier Application Framework Design", particularly Model-View-Controller ("MVC") style frameworks.

In that paper "Model 1" and "Model 2" set-ups are described in some detail. In short, Model 1 is what most of us web hackers have probably done for years --

1.) A [php/jsp/asp] page for user data entry (data entry GUI) which forwards you to...
2.) Another [php/jsp/asp] for business logic that inserts the jive into an RDBMS, which then forwards you to...
3.) Another page where you might review your data, with links to (1.) or ...
4.) Another page to edit info which links to...
5.) Another page that edits/updates/deletes existing entries and sends you back to 3.)

You get the point. You've got php script or vbscript or Java slapped in between tags that dynamically create pages. That's Model 1.

Model 1 doesn't scale well. It is, however, a great way to get up quickly, and perfect for smaller sites. That's where PHP and dime store hackers find a home, and that ability comprises the "revolution" asp brought to the web.

Model 2 has a controller which tries to abstract as much as possible out of process described above. Check out this image from the Sun chapter mentioned above. See all the steps that go on from each POST from the client interface.

The point of it is that Java/JSP/J2EE allows -- and has the infrastructure as a langauge to support -- this sort of Model 2, MVC interface (As an aside, this is also one of the big advantages of .NET). You can quickly and easily usher these items around in a mature, object-oriented environment. Define an interface and a generic controller and you'll be able to swap around [in theory] fully-QA'd data delivery mechanisms in a modular fashion.

In PHP -- and even asp 3.0 -- this is a more difficult thing to pull off, as mentioned in the /. post I linked to above.

And this is where Tomcat shines -- as a key part of the infrastructure that allows more complex, scalable, generic objects and architectures. Most importantly, since J2EE is a language specification, saying Java scales well is accurate. It provides a true OO platform allowing you to implement Model 2's without jumping through hoops. PHP simply (in my experience) doesn't lend itself to this nearly so straighforwardly.

Now what Tomcat 5 does for me that 4 didn't to achieve this scalability (which many posts have well-documented) is what's most interesting about this story, to which I'll now return. ;^)

Though the author of the post also defines scaling differently, I believe anyone talking Java scaling versus PHP, etc, should read this /. post in the context of this chapter of Designing Enterprise Applications with the J2EE(tm) Platform, Second Edition that deals with "Web-Tier Application Framework Design", particularly Model-View-Controller ("MVC") style frameworks.

In that paper "Model 1" and "Model 2" set-ups are described in some detail. In short, Model 1 is what most of us web hackers have probably done for years --

1.) A [php/jsp/asp] page for user data entry (data entry GUI) which forwards you to...
2.) Another [php/jsp/asp] for business logic that inserts the jive into an RDBMS, which then forwards you to...
3.) Another page where you might review your data, with links to (1.) or ...
4.) Another page to edit info which links to...
5.) Another page that edits/updates/deletes existing entries and sends you back to 3.)

You get the point. You've got php script or vbscript or Java slapped in between tags that dynamically create pages. That's Model 1.

Model 1 doesn't scale well. It is, however, a great way to get up quickly, and perfect for smaller sites. That's where PHP and dime store hackers find a home, and that ability comprises the "revolution" asp brought to the web.

Model 2 has a controller which tries to abstract as much as possible out of process described above. Check out this image from the Sun chapter mentioned above. See all the steps that go on from each POST from the client interface.

The point of it is that Java/JSP/J2EE allows -- and has the infrastructure as a langauge to support -- this sort of Model 2, MVC interface (As an aside, this is also one of the big advantages of .NET). You can quickly and easily usher these items around in a mature, object-oriented environment. Define an interface and a generic controller and you'll be able to swap around [in theory] fully-QA'd data delivery mechanisms in a modular fashion.

In PHP -- and even asp 3.0 -- this is a more difficult thing to pull off, as mentioned in the /. post I linked to above.

And this is where Tomcat shines -- as a key part of the infrastructure that allows more complex, scalable, generic objects and architectures. Most importantly, since J2EE is a language specification, saying Java scales well is accurate. It provides a true OO platform allowing you to implement Model 2's without jumping through hoops. PHP simply (in my experience) doesn't lend itself to this nearly so straighforwardly.

Now what Tomcat 5 does for me that 4 didn't to achieve this scalability (which many posts have well-documented) is what's most interesting about this story, to which I'll now return. ;^)

I have to admit that I wasn't sold on the 'Java' desktop (whatever), but it seems that they are pushing the right buttons here.

I have to admit that I wasn't sold on the 'Java' desktop (whatever), but it seems that they are pushing the right buttons here.

Because Star Office costs money while OO is a free download.

SO: Retail MSRP $75.95

OO: Download here.

Obviously Sun is going to price OO "support only" much less than what SO costs with support.

Essentially, Sun knows these products are almost identical, OO is everywhere, and they could make some easy money and push SO by supporting OO in the office. Smart move if it works.

According to Sun's official OpenOffice support page, OpenOffice 1.1 is only supported on Windows, Solaris, and Linux...in other words, only platforms where StarOffice also exists...

Mozilla Calendar really needs to be folded directly into the Thunderbird system. People want a calendar in their email client, and that's that. The sooner this is done, the sooner Thunderbird can start kicking Outlook's butt.

The place where Mozilla Calendar is a bit weak right now is its server support. Sure, you can publish and subscribe using WebDAV, but that's not the same thing as having a true server-side calendar. And you still can't send and receive meeting invitations, or check other users' free/busy times.

Fortunately, there is a group at Penn State working on fixing this. They're writing a new calendar API that can be used to hook into arbitrary servers. That means that modules will be able to be written for any back end, such as Citadel, Sun calendar server, Kolab, or whatever else appears out there in the future.

I see too many companies take something that has been in an open-source product (like a Linux window manager) for years, and rewrite it, add a few features, and release it on Windows, for money. Probably the simplest example is popup blocking, even though most of them are free -- Mozilla and Firebird supported popup blocking long before even the first freeware plugin for Internet Explorer.

So the way to do this right is to do your homework. Before you even start planning on a project, make sure it is a unique project, and not something that could be a 3 kilobyte plugin to an existing project. If you want to try to sell 3 kilobyte plugins, it has to really be a killer app -- the only company I've seen do that successfully is CrossOver.

I realize that you could make an entirely new product with one killer feature, but if that feature could be implemented as a plugin to an existing product, it would take much less work for your competitor to do that, and it would annoy customers who don't want to have to use three different programs that do the same thing because each one has its own killer feature.

Next, if you think you can do it right and still make money, release your source code. Namesys has done this right, and though they make less money than they would otherwise, if you believe in good karma, they must be basking in it. A somewhat less successful way is to do what Netscape did with Mozilla and Sun did with StarOffice, which is based on OpenOffice -- create an open project, then make and sell a product based on that, possibly with a few added killer features (Netscape had spell checking before Mozilla did).

Perhaps the best way to do this is to make an open product and give it away, but charge for techsupport. I believe Mozilla has telephone techsupport now.

If you can't do that, at least be open about your development process. Release early and often. Document everything. Allow people to extend your product somehow, even if it's not with source code -- Half-life does this extremely well. Only charge for the really major updates, and charge less for an update. Listen to your community, and make them a community, not just a consumer base. You want a dialog with that community.

And remember that it's software, and that while there are real costs to developing it, the cost of distributing it (and making new copies) can be very close to 0, so charge appropriately.

Be independent. By that, I mean don't leech off of other companies -- particularly their weaknesses. For example, Symantec and many others sell products that would not exist if Windows was better, and ultimately make a worse experience for the consumer. There's a lot of websites out there that sell products designed to erase your internet history -- do NOT make a product like that. If people really cared so much about their history, they would use a product other than Microsoft Internet Explorer -- a product that deletes your history when you tell it to.

Whatever else your website is, don't just make it a brochure. Make it informative. Even redhat has, as long as I can remember, made their homepage in a way that's designed to hype rather than inform. I should be able to go to your site and click on "about" or "overview" for a description of what your product does -- if not in technical terms, at least not in marketing terms. I don't want to hear about a product that "enhances productivity" but won't say how it "enhances productivity". I should also be able to click on something like "contact" to send you an email.

An open bug database and a forum are also very useful things. Make sure they are open. Don't censor the forum based on content, and for the love of God don't censor the bug database! Good rea

I see too many companies take something that has been in an open-source product (like a Linux window manager) for years, and rewrite it, add a few features, and release it on Windows, for money. Probably the simplest example is popup blocking, even though most of them are free -- Mozilla and Firebird supported popup blocking long before even the first freeware plugin for Internet Explorer.

So the way to do this right is to do your homework. Before you even start planning on a project, make sure it is a unique project, and not something that could be a 3 kilobyte plugin to an existing project. If you want to try to sell 3 kilobyte plugins, it has to really be a killer app -- the only company I've seen do that successfully is CrossOver.

I realize that you could make an entirely new product with one killer feature, but if that feature could be implemented as a plugin to an existing product, it would take much less work for your competitor to do that, and it would annoy customers who don't want to have to use three different programs that do the same thing because each one has its own killer feature.

Next, if you think you can do it right and still make money, release your source code. Namesys has done this right, and though they make less money than they would otherwise, if you believe in good karma, they must be basking in it. A somewhat less successful way is to do what Netscape did with Mozilla and Sun did with StarOffice, which is based on OpenOffice -- create an open project, then make and sell a product based on that, possibly with a few added killer features (Netscape had spell checking before Mozilla did).

Perhaps the best way to do this is to make an open product and give it away, but charge for techsupport. I believe Mozilla has telephone techsupport now.

If you can't do that, at least be open about your development process. Release early and often. Document everything. Allow people to extend your product somehow, even if it's not with source code -- Half-life does this extremely well. Only charge for the really major updates, and charge less for an update. Listen to your community, and make them a community, not just a consumer base. You want a dialog with that community.

And remember that it's software, and that while there are real costs to developing it, the cost of distributing it (and making new copies) can be very close to 0, so charge appropriately.

Be independent. By that, I mean don't leech off of other companies -- particularly their weaknesses. For example, Symantec and many others sell products that would not exist if Windows was better, and ultimately make a worse experience for the consumer. There's a lot of websites out there that sell products designed to erase your internet history -- do NOT make a product like that. If people really cared so much about their history, they would use a product other than Microsoft Internet Explorer -- a product that deletes your history when you tell it to.

Whatever else your website is, don't just make it a brochure. Make it informative. Even redhat has, as long as I can remember, made their homepage in a way that's designed to hype rather than inform. I should be able to go to your site and click on "about" or "overview" for a description of what your product does -- if not in technical terms, at least not in marketing terms. I don't want to hear about a product that "enhances productivity" but won't say how it "enhances productivity". I should also be able to click on something like "contact" to send you an email.

An open bug database and a forum are also very useful things. Make sure they are open. Don't censor the forum based on content, and for the love of God don't censor the bug database! Good rea

On Windows you can use Rio Music Manager, Real, or Rio Music Manager Lite (the Java app). On Linux, OS X, etc, you need to use Rio Music Manager Lite. Because the drive runs a journaling filesystem based on another Rio product, it currently is not exposed as a USB mass storage device. Samba is GPL, which the Rio engineers said precluded them from adding SMB support (it would have to be directly linked into the player binary as the Karma runs ECOS).

You can see screenshots of Rio Music Manager Lite here

When you asked about the speed, do you mean the speed of the Java app, or the speed of ethernet transfers? It's USB1 ethernet USB2. I don't recall the exact #'s offhand, but there are threads on riovolution.com that have all the details. As far as the speed of the Java app, it's hard to quantify that. If I said "it runs like any Java app", that sounds bad because of a lot of superstition. All I can say is that it's very usable and the core is based on a similar app for the Empeg that has been in development for over two years, so it's got quite a few optimizations in there.

The Karma, RMM, and RMML all support Ogg metadata both as ID3v2 tags and in Ogg comments.

It saves your place in the playlist, in the currently playing song, and even lets you create bookmarks that snapshot your current playlist and position so you can go listen to something else and come back later.

So I used to use Java JDK 1.2, and it was fine. Then, whenever I used it, I'd get hit by waves of superheated gasses. Now it's really solid. And I've found out why: it's completed the Sun End of Life Process.

Athlon MP wasn't tremendously successful penetrating the server market, but Opteron appears to be making serious headway!

IBM has the e325, and Sun is about to introduce Opteron servers in a big way. Opteron thorougly rips Intel's x86 server offerings, especially in 2P and 4P configurations, and is extremely competitive with Itanium at a lower price (and with no software recompiles required).

Opteron should also do really well in the workstation and high-end PC markets.

This is all great for AMD, since Opteron is a high-margin part that kills Intel's high-margin x86 parts. The design wins with major OEMs just keep on coming...

OOP will lead to more robust, easier to maintain and higher quality software

It did.

> We have no idea what Sun was thinking when choosing this or whether Sun's version 1 software meets corporate needs.

I see no basis for this statement. Since it's not fully functional, it doesn't meet anyone's needs.
Given Sun's track record in research and development, we can be reasonably sure Sun is aware of the different environments (casual vs corporate vs homogenized) that an OS can be tailored to. It is clearly headed for corporate use. The only reason Sun would shaft media drivers (like DVD compatibility), which are trivial, is because they specifically don't want to consider them in their market. That specific "question" HAS been answered. You might want to read the FAQ question #1

1. Q.
What is the Sun Java Desktop System?

A.
Sun Java Desktop System is a comprehensive, secure, highly affordable enterprise desktop solution that is simple to use and works with existing infrastructure. The software consists of a fully integrated client environment based on open source and standards including a GNOME desktop environment, StarOffice productivity suite, Mozilla browser, Evolution e-mail and calendar client, Java 2 Standard Edition, and a Linux operating system.

Future releases of Java Desktop System are planned to support workstations and Sun Ray thin clients running the Solaris Operating System.

Yeah, it's for people who love to torture themselves with file dialogs so painful you'll suddenly realised how wonderful Windows is.... er... oh, hmmm....

This great advance of consistency from the company who has forced me to endure CDE as the standard default desktop right up to solaris 9. And their brand new Solaris Patch Pro tool still standardized on Netscape 4.7x! Don't expect too much here... move along.

Just trying to figure out if this plot is intended to make Windows look good, or to make Swing look good... hard choice... very sneaky.

Uhhh... dumass... their talkin bout jhava teh programming langauge.

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 fo

this sound just like the whole sunray thin client thing.

Interesting for newbie programmers, maybe. After you code for more than a month you'll find things like this that give you arbitrary precision integers.

All the spec is going to do is something computer people have wanted for years- to ditch the old archaic BIOS.

Open Firmware, anyone? It's only been available for around 15 years or so. Oh, and it's a real IEEE standard, unlike whatever thing Phoenix/Microsoft will be foisting on us.

Perhaps someone will tell us what the benefits of the randomly-changeable bios are.

Casting is far more elegant...look at the base for the $3600.00 Sun 24.1" TFT-LCD monitor. It just takes talent.

As for anodizing...way out of date. Today, items like this are powder-coated.

It does?