Slashdot Mirror

I keep hearing that the US goverment favors Sun and their hard/soft -ware big time. So can I conclude that they are just stupid and (which seems pretty common) "know best how to run their business" ?

I mean, just take a look at a random outdated workstation and you'll notice it has an embedded cardreader. Solaris also has native support for this kind of security measures and whats more; even their object oriented language which is always mentioned with regards to stability and security has full support for keycard authentication. So, where did they go wrong ?

I keep hearing that the US goverment favors Sun and their hard/soft -ware big time. So can I conclude that they are just stupid and (which seems pretty common) "know best how to run their business" ?

I mean, just take a look at a random outdated workstation and you'll notice it has an embedded cardreader. Solaris also has native support for this kind of security measures and whats more; even their object oriented language which is always mentioned with regards to stability and security has full support for keycard authentication. So, where did they go wrong ?

I keep hearing that the US goverment favors Sun and their hard/soft -ware big time. So can I conclude that they are just stupid and (which seems pretty common) "know best how to run their business" ?

I mean, just take a look at a random outdated workstation and you'll notice it has an embedded cardreader. Solaris also has native support for this kind of security measures and whats more; even their object oriented language which is always mentioned with regards to stability and security has full support for keycard authentication. So, where did they go wrong ?

Here you go. Get your info straight from Sun. See the section on runtime errors.
http://java.sun.com/j2se/JM_White_Paper_R6A.pdf [sun.com]

Getting your adolescent friends to second your opinion or creating a second account to bolster yourself is completely juvenile.

For your info I'm over 30, have a bachelor and masters, and have been doing this for some years...all of which has no bearing on the truth of what I've said of course.

Look I've seen code break. You haven't. I don't care if you get a team of 30 coders with a combined experience of 900 years to tell me their apps haven't broken. I've seen apps break, and not only when the code's compiled for a later JRE. We've had to develop specific workarounds and re-release stuff due to this. I can't show you because I'm bound by an employment contract and I'm not about to embarass my employer even if I wasn't. That you don't believe me doesn't make an inkling of difference to my life. Enjoy your fantasy.

If you are going to reply at all the first thing I challenge you to do is explain this migration guide by Sun for Java 1.3 to 5.0:
http://java.sun.com/j2se/JM_White_Paper_R6A.pdf ...complete with a whole section on runtime issues

More references. Again not the best. Wish I could show you my good example but see above.
http://forum.java.sun.com/thread.jspa?threadID=731 921&messageID=4212821
http://www.codecomments.com/archive251-2005-5-4986 00.html
http://forum.java.sun.com/thread.jspa?threadID=432 494&messageID=2042086
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =4783788
http://helpdesk.wisc.edu/page.php?id=2891
http://www.javalobby.org/java/forums/t18329.html
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =6204839

The above links very clearly show installing the latest JRE is not sufficient to run all your old code. With many Java applications, you can't just remove all older versions of a JRE and upgrade to the latest.

I also recall that if your code is applet based, the tags used to invoke the JRE changed after Microsoft dumped their custom JVM due to the legal action between Sun and MS.

The bottom line is that you're calling anyone who has seen anything break due to a newer JRE a fool and a liar based on your "30 years of experience". I know for a fact that this is false. Your arrogance is astounding and your insistance on this makes me wonder what you've been doing for 30 years since I know of no complex environment where the runtime backward compatibility is so fantastic that you don't need to test a new version to be sure it works for your application.

Look I've seen code break. You haven't. I don't care if you get a team of 30 coders with a combined experience of 900 years to tell me their apps haven't broken. I've seen apps break, and not only when the code's compiled for a later JRE. We've had to develop specific workarounds and re-release stuff due to this. I can't show you because I'm bound by an employment contract and I'm not about to embarass my employer even if I wasn't. That you don't believe me doesn't make an inkling of difference to my life. Enjoy your fantasy.

If you are going to reply at all the first thing I challenge you to do is explain this migration guide by Sun for Java 1.3 to 5.0:
http://java.sun.com/j2se/JM_White_Paper_R6A.pdf ...complete with a whole section on runtime issues

More references. Again not the best. Wish I could show you my good example but see above.
http://forum.java.sun.com/thread.jspa?threadID=731 921&messageID=4212821
http://www.codecomments.com/archive251-2005-5-4986 00.html
http://forum.java.sun.com/thread.jspa?threadID=432 494&messageID=2042086
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =4783788
http://helpdesk.wisc.edu/page.php?id=2891
http://www.javalobby.org/java/forums/t18329.html
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =6204839

The above links very clearly show installing the latest JRE is not sufficient to run all your old code. With many Java applications, you can't just remove all older versions of a JRE and upgrade to the latest.

I also recall that if your code is applet based, the tags used to invoke the JRE changed after Microsoft dumped their custom JVM due to the legal action between Sun and MS.

The bottom line is that you're calling anyone who has seen anything break due to a newer JRE a fool and a liar based on your "30 years of experience". I know for a fact that this is false. Your arrogance is astounding and your insistance on this makes me wonder what you've been doing for 30 years since I know of no complex environment where the runtime backward compatibility is so fantastic that you don't need to test a new version to be sure it works for your application.

Look I've seen code break. You haven't. I don't care if you get a team of 30 coders with a combined experience of 900 years to tell me their apps haven't broken. I've seen apps break, and not only when the code's compiled for a later JRE. We've had to develop specific workarounds and re-release stuff due to this. I can't show you because I'm bound by an employment contract and I'm not about to embarass my employer even if I wasn't. That you don't believe me doesn't make an inkling of difference to my life. Enjoy your fantasy.

If you are going to reply at all the first thing I challenge you to do is explain this migration guide by Sun for Java 1.3 to 5.0:
http://java.sun.com/j2se/JM_White_Paper_R6A.pdf ...complete with a whole section on runtime issues

More references. Again not the best. Wish I could show you my good example but see above.
http://forum.java.sun.com/thread.jspa?threadID=731 921&messageID=4212821
http://www.codecomments.com/archive251-2005-5-4986 00.html
http://forum.java.sun.com/thread.jspa?threadID=432 494&messageID=2042086
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =4783788
http://helpdesk.wisc.edu/page.php?id=2891
http://www.javalobby.org/java/forums/t18329.html
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =6204839

The above links very clearly show installing the latest JRE is not sufficient to run all your old code. With many Java applications, you can't just remove all older versions of a JRE and upgrade to the latest.

I also recall that if your code is applet based, the tags used to invoke the JRE changed after Microsoft dumped their custom JVM due to the legal action between Sun and MS.

The bottom line is that you're calling anyone who has seen anything break due to a newer JRE a fool and a liar based on your "30 years of experience". I know for a fact that this is false. Your arrogance is astounding and your insistance on this makes me wonder what you've been doing for 30 years since I know of no complex environment where the runtime backward compatibility is so fantastic that you don't need to test a new version to be sure it works for your application.

Look I've seen code break. You haven't. I don't care if you get a team of 30 coders with a combined experience of 900 years to tell me their apps haven't broken. I've seen apps break, and not only when the code's compiled for a later JRE. We've had to develop specific workarounds and re-release stuff due to this. I can't show you because I'm bound by an employment contract and I'm not about to embarass my employer even if I wasn't. That you don't believe me doesn't make an inkling of difference to my life. Enjoy your fantasy.

If you are going to reply at all the first thing I challenge you to do is explain this migration guide by Sun for Java 1.3 to 5.0:
http://java.sun.com/j2se/JM_White_Paper_R6A.pdf ...complete with a whole section on runtime issues

More references. Again not the best. Wish I could show you my good example but see above.
http://forum.java.sun.com/thread.jspa?threadID=731 921&messageID=4212821
http://www.codecomments.com/archive251-2005-5-4986 00.html
http://forum.java.sun.com/thread.jspa?threadID=432 494&messageID=2042086
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =4783788
http://helpdesk.wisc.edu/page.php?id=2891
http://www.javalobby.org/java/forums/t18329.html
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =6204839

The above links very clearly show installing the latest JRE is not sufficient to run all your old code. With many Java applications, you can't just remove all older versions of a JRE and upgrade to the latest.

I also recall that if your code is applet based, the tags used to invoke the JRE changed after Microsoft dumped their custom JVM due to the legal action between Sun and MS.

The bottom line is that you're calling anyone who has seen anything break due to a newer JRE a fool and a liar based on your "30 years of experience". I know for a fact that this is false. Your arrogance is astounding and your insistance on this makes me wonder what you've been doing for 30 years since I know of no complex environment where the runtime backward compatibility is so fantastic that you don't need to test a new version to be sure it works for your application.

Look I've seen code break. You haven't. I don't care if you get a team of 30 coders with a combined experience of 900 years to tell me their apps haven't broken. I've seen apps break, and not only when the code's compiled for a later JRE. We've had to develop specific workarounds and re-release stuff due to this. I can't show you because I'm bound by an employment contract and I'm not about to embarass my employer even if I wasn't. That you don't believe me doesn't make an inkling of difference to my life. Enjoy your fantasy.

If you are going to reply at all the first thing I challenge you to do is explain this migration guide by Sun for Java 1.3 to 5.0:
http://java.sun.com/j2se/JM_White_Paper_R6A.pdf ...complete with a whole section on runtime issues

More references. Again not the best. Wish I could show you my good example but see above.
http://forum.java.sun.com/thread.jspa?threadID=731 921&messageID=4212821
http://www.codecomments.com/archive251-2005-5-4986 00.html
http://forum.java.sun.com/thread.jspa?threadID=432 494&messageID=2042086
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =4783788
http://helpdesk.wisc.edu/page.php?id=2891
http://www.javalobby.org/java/forums/t18329.html
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =6204839

The above links very clearly show installing the latest JRE is not sufficient to run all your old code. With many Java applications, you can't just remove all older versions of a JRE and upgrade to the latest.

I also recall that if your code is applet based, the tags used to invoke the JRE changed after Microsoft dumped their custom JVM due to the legal action between Sun and MS.

The bottom line is that you're calling anyone who has seen anything break due to a newer JRE a fool and a liar based on your "30 years of experience". I know for a fact that this is false. Your arrogance is astounding and your insistance on this makes me wonder what you've been doing for 30 years since I know of no complex environment where the runtime backward compatibility is so fantastic that you don't need to test a new version to be sure it works for your application.

... my dev enviornment(JBoss,PostgreSQL, SJSES8.0 and other stuff with gcvs also)... And yes I dont own a Mac as it is of no use to me, I am an enterprise architect...

JBoss: included since 10.2
http://developer.apple.com/internet/java/enterpris ejava.html

PostgreSQL on the Mac: easy
http://developer.apple.com/internet/opensource/pos tgres.html

SJSE: looks like it's not there, yet, but it will be
http://forum.sun.com/jive/thread.jspa?threadID=960 29&messageID=329768#329768
I use Eclipse...

gcvs: I'm guessing you mean some CVS client - there are plenty (MacCVS springs to mind)

By the way my wife who has a masters in biology is currently using Ubuntu...

Oh yeah? Well my wife has a masters in nursing, and she uses a mac. So there! Neener Neener.

As an example of turning bug instances into bug patterns, I always read through the list of bugs fixed in each version of the jdk1.6.0 builds. In build 89, a bug was fixed in the serialization of ArrayBlockingQueue.

I wrote a FindBugs bug detector to look for similar cases: a class with transient fields, but no readObject or readResolve method to restore the field. I had to tune the detector a bit (for example, raise the priority if it is set to a non-default value in the constructor). I'm still doing some tuning, but at the moment the new detector reports warnings in 47 jdk 1.6 b89 classes, 18 of which are confirmed to be bugs. This took me a total of 5 hours of work.

Bugs listed below (these have been reported to Sun); this detector isn't in the current 1.0 release of FindBugs, but is available is the latest CVS snapshot, and will be in the next release.

  Bill Pugh

-----

java.security.Timestamp and java.security.CodeSigner:
        they have a transient myhash field used to cache the hashCode that is
        initialized to -1. If you serialize/deserialize one of these
        and invoke hashCode on the result, you'll get an incorrect hashCode of 0.

javax.management.AttributeList
        has a transient boolean field tainted. If you add something other than an Attribute
        to an AttributeList, serialize/deserialize it, and then invoke asList(), you get back
        a List that contains something that isn't an Attribute. If you call asList() on
          the original AttributeList, you get an exception.

javax.management.relation.RoleList
javax.management.relation.RoleUnresolvedList
        problems isomorphic to the above problem

sun.util.BuddhistCalendar
        has a transient field yearOffset that is initialized in the constructor. If you
        serialize/deserialize a BuddhistCalendar, you get back a broken BuddhistCalendar
        that computes dates incorrectly (off by 543 years)

javax.swing.DefaultDesktopManager
        has a transient field floatingItems that is initialized to an empty array of Rectangles, and
        it sure looks like the code is assuming that floatingItems is assumed to be nonnull, so
        if you serialize/deserialize it, it will be broken (of course, I can never be sure if
        anybody seriously intends for awt/swing objects to be serialized.

com.sun.rowset.CachedRowSetImpl
com.sun.rowset.FilteredRowSetImpl
com.sun.rowset.JdbcRowSetImpl
com.sun.rowset.JoinRowSetImpl
com.sun.rowset.WebRowSetImpl
com.sun.rowset.internal.CachedRowSetReader
com.sun.rowset.internal.CachedRowSetWriter
com.sun.rowset.internal.InsertRow
com.sun.rowset.internal.SyncResolverImpl
com.sun.rowset.internal.WebRowSetXmlReader
com.sun.rowset.internal.WebRowSetXmlWriter
com.sun.rowset.providers.RIOptimisticProvider
        all initialize in their constructors transient fields pointing to resource bundles
                for providing localized error messages, and the resource bundle will be null if the
        an object is deserialized and serialized.

javax.smartcardio.CommandAPDU
        has 3 transient fields (nc, ne and dataOffset) that are computed by the call to parse in the constructor
        from the apdu array. However, if the object is serialized/deserialized, the fields will have their
        default values.

I'm going to keep lobbying for IEEE 1275-1994, thanks. (That's OpenFirmware, in case any of you heathens don't know. It's still the only boot ROM with its own song!

Actually there are rather a lot of these. Sun maintains a list of some of them here

and (distributed) supercomputing power for companies that wouldn't or couldn't dream of using a supercomputing facility.

you mean like the sun grid? we all seen how well that worked out.

"Deployment"? Who uses that word?

Er, all sorts of people. Even web developers and software engineers.

It's just a word meaning "put something in place and get it ready".

I don't think people assumed the worst as much as his website implied the worst.

Well yes, it might have implied the worst, but people were still pretty damn stupid to believe it's for real. I'm pretty sure the next person to nuke the world isn't going to put a nice Flash countdown up on the web.

I did find the website horrifying. Not because I thought something bad was going to happen, but because it demonstrated just how dumb lots of people can be. If anybody thought this was the precursor to some kind of catastrophe, then they belong in a home being looked after by qualified professionals.

"Microsoft Office has built-in help for people with disabilities ..
.. OpenDocument-based products do not yet" - John Winske

Why a document standard would affect a screen reader defies logic. Could you list any functionality that Microsoft Office provides the disabled that you believe does not exist in Open Source. May I remind you that the American Foundation of the Blind (AFB) awarded Gnome and Sun the Helen Keller Achievement Award in 2002. Sun being one of the originators of Open Office.

In this document we have Adobe answering some of the points raised in the "Joint Statement on Open Source & Open Documents in Massachusetts" released by your Disability Policy Consortium and the Bay State Council of the Blind.

I can't recommend a specific provider, but I would like to point out that moving to Linux does not mean abandoning your ASP code. Java System ASP is cross platform; you can provide ASP content using a Linux, Windows, Solaris, or other *nix server.

Do you *NEED* .NET? Can you learn something else? Something cross platform, maybe? Surely there's something out there that will do the job?

As others have noted in this thread, the mainstream media continues to repeat the falsehood that Microsoft is responsible for the accessibility of MS-Office (which is to say, the extent to which Windows assistive technology vendors have special-cased and reverse-engineering MS-Office). David Berlind's interview with Curtis Chong of the National Federation of the Blind make this very clear (see his blog at: http://blogs.zdnet.com/BTL/?p=2163

As others have noted in this thread, the mainstream media continues to repeat the falsehood that Microsoft is responsible for the accessibility of MS-Office (which is to say, the extent to which Windows assistive technology vendors have special-cased and reverse-engineering MS-Office). David Berlind's interview with Curtis Chong of the National Federation of the Blind make this very clear (see his blog at: http://blogs.zdnet.com/BTL/?p=2163

Yes, you're missing the point of what I'm saying - I in fact agree with you. What I am saying is that, in a world where one can no longer charge for the right to use software, the only place there is left to earn a living is by providing value to the software user at the point where they need it. I have explained this in detail before but essentially what I my "Software Market 3.0" point says is that once Freedom 0 is guaranteed, business models based on restrictions on use can no longer work, and all business models available in the F/OSS future are based on delivering value - service, support, bug-fixing and so on - at the point where the customer can no longer provide those things themselves based on skills. The whole point of my job is to help Sun transition into that F/OSS future.

Well, I decided to stay at Sun because in my personal opinion the company has found a new direction and energy under new leadership, focussing on providing the systems to deliver the next generation of computing in a world where open source is dominant. I think the company is returning to its roots and heading in the right direction at last.To give you some examples:

• Sun has refocussed its systems business, producing excellent new server systems both based on Opteron and on SPARC which run both Solaris and GNU/Linux at a highly competitive price point even before the lower running costs are considered. Don't take my word for it - go get one and try it for free.
• It has committed to open sourcing its software portfolio in recognition of the shift taking place in the way software is being used, over to the world of "Social Production" that Benkler describes.
• Sun has restructured to focus on its core business, into four divisions - software, systems, storage and service - and is managing costs well without losing flexibility.

Doubtless there are plenty on Slashdot who'll come over to throw rocks, but I'm very pleased all this and more is happening as there was a time not so long ago when I would not have been so positive (or keen to stay). As it is (and regardless of what Bruce may say), I'm proud to be running Sun's open source strategy on the watch where Sun's Java implementations all go open source.

Well, I decided to stay at Sun because in my personal opinion the company has found a new direction and energy under new leadership, focussing on providing the systems to deliver the next generation of computing in a world where open source is dominant. I think the company is returning to its roots and heading in the right direction at last.To give you some examples:

• Sun has refocussed its systems business, producing excellent new server systems both based on Opteron and on SPARC which run both Solaris and GNU/Linux at a highly competitive price point even before the lower running costs are considered. Don't take my word for it - go get one and try it for free.
• It has committed to open sourcing its software portfolio in recognition of the shift taking place in the way software is being used, over to the world of "Social Production" that Benkler describes.
• Sun has restructured to focus on its core business, into four divisions - software, systems, storage and service - and is managing costs well without losing flexibility.

Doubtless there are plenty on Slashdot who'll come over to throw rocks, but I'm very pleased all this and more is happening as there was a time not so long ago when I would not have been so positive (or keen to stay). As it is (and regardless of what Bruce may say), I'm proud to be running Sun's open source strategy on the watch where Sun's Java implementations all go open source.

Well, I decided to stay at Sun because in my personal opinion the company has found a new direction and energy under new leadership, focussing on providing the systems to deliver the next generation of computing in a world where open source is dominant. I think the company is returning to its roots and heading in the right direction at last.To give you some examples:

• Sun has refocussed its systems business, producing excellent new server systems both based on Opteron and on SPARC which run both Solaris and GNU/Linux at a highly competitive price point even before the lower running costs are considered. Don't take my word for it - go get one and try it for free.
• It has committed to open sourcing its software portfolio in recognition of the shift taking place in the way software is being used, over to the world of "Social Production" that Benkler describes.
• Sun has restructured to focus on its core business, into four divisions - software, systems, storage and service - and is managing costs well without losing flexibility.

Doubtless there are plenty on Slashdot who'll come over to throw rocks, but I'm very pleased all this and more is happening as there was a time not so long ago when I would not have been so positive (or keen to stay). As it is (and regardless of what Bruce may say), I'm proud to be running Sun's open source strategy on the watch where Sun's Java implementations all go open source.

Oops, I didn't use the permalink for Simon's blog entry referenced in the parent.

Sun may release the source code to the JVM however they'll use a license that has serious restrictions. After reading lots of Sun blogs and talking to several people at Sun, I'm convinced that Sun really doesn't get open source or how it works. Solaris is a perfect example of this. In terms of Java, the license will almost surely contain clauses that disallow forks of the JVM.

Unless Sun really steps up or releases Java under a real open source license, without ridiculous restrictions (so other people can pick up Suns slack), I believe Java is in for a really tough time trying to survive the next 5-10 years. Look at how long its taken Swing to become reasonably decent, and yet even in Java 6 it still has serious problems. Look at the mess that is the Date API, NIO, JMF, Netbeans etc. Examples of terrible design decisions exist all throughout the standard API and additional Sun packages. Even a lot of people at Sun admit this, however these issues don't get fixed because Sun refuses to lose backwards compatibility (even though they've failed at that several times already). The API has so many depreciated methods that it's practically disgusting to look at.

The JCP process is not transparent, is way to slow and is a serious pain in the ass to get involved with. You want to get involved and fix bugs/write code, not gonna happen unless you sign a myriad of forms and sign lots of your rights over to Sun. Just being involved also means that you can't work on other JVM implementations. Furthermore, with the JCP you get the privilege of writing extensive JSRs and then waiting for them to take years to start seriously looking at them. You want to fix a bug or add an additional feature to Java, write a JSR and maybe it will be included in Java 10 in 10 years! Look at the bug list for Java, some of the bugs have been around for years.

For an example of the JCP not being a transparent community process, we only have to look back a few weeks when Sun out of the blue decided to include Apache Derby in the Java 6 JDK (which they've renamed JavaDB for inclusion with the JDK...). No JSR and no warning given to the JCP, just Sun unilaterally making the decision on what's best for Java. What a stupid decision that was... Who the hell, besides total beginners, wants a database included in the JDK? Are Java programmers really so inept that they can't go to the Derby website and download a jar file? What happens when a serious bug is found in Derby? Are they going to release an update to the JDK? How long will it take before the version included in the JDK is outdated? A few weeks, a few months tops... What are they going to bundle next with the JDK? That POS Netbeans? Glassfish? JOGL? Suns control over Java is running it into the ground.

Oh by the way, when Sun says "a couple months" they really mean 10 or more months.

Tell these guys that too: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =4504839
Working on unsigned data coming in from another source is VERY bug prone in Java. Writing file format readers in Java is a nightmare.

I replied as I usually do, indicating it's "months rather than years", making it clear that the way to interpret that comment is that it's double-digit months and not September!"

SimpleDateFormat dFormat = new SimpleDateFormat("yyyy-MM-dd\'T\'HH:mm:ssZ");

Slower than Office? How is that possible?

http://java.sun.com/

what is stopping Linux and the Open Source community from doing it? Oh, that's right- it's easier to just complain about MS than to actually get your hands dirty. Nevermind then, carry on.

• Pooled Storage Model
• Always consistent on disk
• Protection from data corruption
• Live data scrubbing
• Instantaneous snapshots and clones
• Fast native backup and restore
• Highly scalable
• Built in compression
• Simplified administration model

what is stopping Linux and the Open Source community from doing it? Oh, that's right- it's easier to just complain about MS than to actually get your hands dirty. Nevermind then, carry on.

• Pooled Storage Model
• Always consistent on disk
• Protection from data corruption
• Live data scrubbing
• Instantaneous snapshots and clones
• Fast native backup and restore
• Highly scalable
• Built in compression
• Simplified administration model

Seriously, how could you not heard of it? http://www.sun.com/
O_o

Right, lets see what we have here. SCO Unix, a Unix variant which isn't really well known apart ofcourse from the black suiing pages. Further more; to use it I'd have to cough up quite some cash. But what can SCO Unix offer me more? Perhaps paying up even more to be allowed and use their development tools. I wonder what would happen if I fail to understand some of their licenses.

Now, on the other hand I know of this other company which also does something with Unix which, strangely enough, is available for free. Not only that, they even allow me to use their development tools completely free of charge. Not just that, no, whenever I use one of their products they send me a full license for the specific product which doesn't expire, doesn't allow this other company to suddenly go back on their promise, doesn't limit me to use their products and most of all: doesn't have this weird taste of hypocracy.

This other company even allows me to use their tools and technology to do some nifty mobile programming and I don't even have to attend any courses if I don't want to. Just read or download a tutorial online.

Gee, this is a hard choice. Do I go for some money which hardly covers my expenses and the option of a free car or do I go with free stuff available now which can (and is likely to:) dramaticly increase my options to find myself a nice job.

Such tough choices, NOT.

Right, lets see what we have here. SCO Unix, a Unix variant which isn't really well known apart ofcourse from the black suiing pages. Further more; to use it I'd have to cough up quite some cash. But what can SCO Unix offer me more? Perhaps paying up even more to be allowed and use their development tools. I wonder what would happen if I fail to understand some of their licenses.

Now, on the other hand I know of this other company which also does something with Unix which, strangely enough, is available for free. Not only that, they even allow me to use their development tools completely free of charge. Not just that, no, whenever I use one of their products they send me a full license for the specific product which doesn't expire, doesn't allow this other company to suddenly go back on their promise, doesn't limit me to use their products and most of all: doesn't have this weird taste of hypocracy.

This other company even allows me to use their tools and technology to do some nifty mobile programming and I don't even have to attend any courses if I don't want to. Just read or download a tutorial online.

Gee, this is a hard choice. Do I go for some money which hardly covers my expenses and the option of a free car or do I go with free stuff available now which can (and is likely to:) dramaticly increase my options to find myself a nice job.

Such tough choices, NOT.

Right, lets see what we have here. SCO Unix, a Unix variant which isn't really well known apart ofcourse from the black suiing pages. Further more; to use it I'd have to cough up quite some cash. But what can SCO Unix offer me more? Perhaps paying up even more to be allowed and use their development tools. I wonder what would happen if I fail to understand some of their licenses.

Now, on the other hand I know of this other company which also does something with Unix which, strangely enough, is available for free. Not only that, they even allow me to use their development tools completely free of charge. Not just that, no, whenever I use one of their products they send me a full license for the specific product which doesn't expire, doesn't allow this other company to suddenly go back on their promise, doesn't limit me to use their products and most of all: doesn't have this weird taste of hypocracy.

This other company even allows me to use their tools and technology to do some nifty mobile programming and I don't even have to attend any courses if I don't want to. Just read or download a tutorial online.

Gee, this is a hard choice. Do I go for some money which hardly covers my expenses and the option of a free car or do I go with free stuff available now which can (and is likely to:) dramaticly increase my options to find myself a nice job.

Such tough choices, NOT.

Right, lets see what we have here. SCO Unix, a Unix variant which isn't really well known apart ofcourse from the black suiing pages. Further more; to use it I'd have to cough up quite some cash. But what can SCO Unix offer me more? Perhaps paying up even more to be allowed and use their development tools. I wonder what would happen if I fail to understand some of their licenses.

Now, on the other hand I know of this other company which also does something with Unix which, strangely enough, is available for free. Not only that, they even allow me to use their development tools completely free of charge. Not just that, no, whenever I use one of their products they send me a full license for the specific product which doesn't expire, doesn't allow this other company to suddenly go back on their promise, doesn't limit me to use their products and most of all: doesn't have this weird taste of hypocracy.

This other company even allows me to use their tools and technology to do some nifty mobile programming and I don't even have to attend any courses if I don't want to. Just read or download a tutorial online.

Gee, this is a hard choice. Do I go for some money which hardly covers my expenses and the option of a free car or do I go with free stuff available now which can (and is likely to:) dramaticly increase my options to find myself a nice job.

Such tough choices, NOT.

Right, lets see what we have here. SCO Unix, a Unix variant which isn't really well known apart ofcourse from the black suiing pages. Further more; to use it I'd have to cough up quite some cash. But what can SCO Unix offer me more? Perhaps paying up even more to be allowed and use their development tools. I wonder what would happen if I fail to understand some of their licenses.

Now, on the other hand I know of this other company which also does something with Unix which, strangely enough, is available for free. Not only that, they even allow me to use their development tools completely free of charge. Not just that, no, whenever I use one of their products they send me a full license for the specific product which doesn't expire, doesn't allow this other company to suddenly go back on their promise, doesn't limit me to use their products and most of all: doesn't have this weird taste of hypocracy.

This other company even allows me to use their tools and technology to do some nifty mobile programming and I don't even have to attend any courses if I don't want to. Just read or download a tutorial online.

Gee, this is a hard choice. Do I go for some money which hardly covers my expenses and the option of a free car or do I go with free stuff available now which can (and is likely to:) dramaticly increase my options to find myself a nice job.

Such tough choices, NOT.

Right, lets see what we have here. SCO Unix, a Unix variant which isn't really well known apart ofcourse from the black suiing pages. Further more; to use it I'd have to cough up quite some cash. But what can SCO Unix offer me more? Perhaps paying up even more to be allowed and use their development tools. I wonder what would happen if I fail to understand some of their licenses.

Now, on the other hand I know of this other company which also does something with Unix which, strangely enough, is available for free. Not only that, they even allow me to use their development tools completely free of charge. Not just that, no, whenever I use one of their products they send me a full license for the specific product which doesn't expire, doesn't allow this other company to suddenly go back on their promise, doesn't limit me to use their products and most of all: doesn't have this weird taste of hypocracy.

This other company even allows me to use their tools and technology to do some nifty mobile programming and I don't even have to attend any courses if I don't want to. Just read or download a tutorial online.

Gee, this is a hard choice. Do I go for some money which hardly covers my expenses and the option of a free car or do I go with free stuff available now which can (and is likely to:) dramaticly increase my options to find myself a nice job.

Such tough choices, NOT.

"Telecommuting" means working away from the normal office environment. This guy was a "teleworker." Sure, he isn't NORMALLY a teleworker (e.g. he usually works out of the office). But he took work home. He was telecommuting. There would have been little chance of this data being stolen had he not "telecommuted."

Telecommuting has drawbacks. The number one issue is that the home is not usually a good environment for work. This includes issues of safety and data security. Operations are at risk if you do not take sufficient precautions.

One interesting solution to this is thin client computing. I've experimented with Sun Ray thin clients that connect over a broadband connection back to a server. No data is stored on the thin client. All it really transmits is pixels and keyboard and mouse clicks (encrypted, too). That's the right way to approach this. Never store data away from the people paid to protect it (then make sure those people do a good job).

I'll say it for the third and last time: Microsoft has to use a production cycle because that's the only way they can create and deploy the ungodly number of patches that are necessary to fix all the security holes they've managed to create.

If Sun's programmers had to release that many security patches, they'd have to do it on a cycle too. (Assuming they didn't just shoot themselves.) They don't do it on a cycle because they don't do that many security patches because they've never screwed up to the point where it was necessary.

Solaris Patch Report Updates as of Jun/16/2006:

http://patches.sun.com/reports/2.5.1_patch_report
http://patches.sun.com/reports/2.6_patch_report
http://patches.sun.com/reports/7_patch_report
http://patches.sun.com/reports/8_patch_report
http://patches.sun.com/reports/9_patch_report
http://patches.sun.com/reports/10_patch_report

Solaris 2.5.1: 243 patches, 2,098 bugs.
Solaris 2.6: 270 patches, 3,280 bugs.
Solaris 7: 309 patches, 3,157 bugs.
Solaris 8: 582 patches, 9,126 bugs.
Solaris 9: 493 patches, 5,849 bugs.
Solaris 10: 319 patches, 3,311 bugs.

First patch I see is for the 1st June 1994 and the last I see is for 16th June 2006. That's 2,216 patches addressing 26,821 bugs in 4,398 days.

A patch every 2 days and a bug addressed every 4 hours.

572 of those patches are security related. Meaning that Sun releases a security patch almost every week.

Micrsoft might be worse than that, but Sun are still releasing a crap load of patches.

I'll say it for the third and last time: Microsoft has to use a production cycle because that's the only way they can create and deploy the ungodly number of patches that are necessary to fix all the security holes they've managed to create.

If Sun's programmers had to release that many security patches, they'd have to do it on a cycle too. (Assuming they didn't just shoot themselves.) They don't do it on a cycle because they don't do that many security patches because they've never screwed up to the point where it was necessary.

Solaris Patch Report Updates as of Jun/16/2006:

http://patches.sun.com/reports/2.5.1_patch_report
http://patches.sun.com/reports/2.6_patch_report
http://patches.sun.com/reports/7_patch_report
http://patches.sun.com/reports/8_patch_report
http://patches.sun.com/reports/9_patch_report
http://patches.sun.com/reports/10_patch_report

Solaris 2.5.1: 243 patches, 2,098 bugs.
Solaris 2.6: 270 patches, 3,280 bugs.
Solaris 7: 309 patches, 3,157 bugs.
Solaris 8: 582 patches, 9,126 bugs.
Solaris 9: 493 patches, 5,849 bugs.
Solaris 10: 319 patches, 3,311 bugs.

First patch I see is for the 1st June 1994 and the last I see is for 16th June 2006. That's 2,216 patches addressing 26,821 bugs in 4,398 days.

A patch every 2 days and a bug addressed every 4 hours.

572 of those patches are security related. Meaning that Sun releases a security patch almost every week.

Micrsoft might be worse than that, but Sun are still releasing a crap load of patches.

I'll say it for the third and last time: Microsoft has to use a production cycle because that's the only way they can create and deploy the ungodly number of patches that are necessary to fix all the security holes they've managed to create.

If Sun's programmers had to release that many security patches, they'd have to do it on a cycle too. (Assuming they didn't just shoot themselves.) They don't do it on a cycle because they don't do that many security patches because they've never screwed up to the point where it was necessary.

Solaris Patch Report Updates as of Jun/16/2006:

http://patches.sun.com/reports/2.5.1_patch_report
http://patches.sun.com/reports/2.6_patch_report
http://patches.sun.com/reports/7_patch_report
http://patches.sun.com/reports/8_patch_report
http://patches.sun.com/reports/9_patch_report
http://patches.sun.com/reports/10_patch_report

Solaris 2.5.1: 243 patches, 2,098 bugs.
Solaris 2.6: 270 patches, 3,280 bugs.
Solaris 7: 309 patches, 3,157 bugs.
Solaris 8: 582 patches, 9,126 bugs.
Solaris 9: 493 patches, 5,849 bugs.
Solaris 10: 319 patches, 3,311 bugs.

First patch I see is for the 1st June 1994 and the last I see is for 16th June 2006. That's 2,216 patches addressing 26,821 bugs in 4,398 days.

A patch every 2 days and a bug addressed every 4 hours.

572 of those patches are security related. Meaning that Sun releases a security patch almost every week.

Micrsoft might be worse than that, but Sun are still releasing a crap load of patches.

I'll say it for the third and last time: Microsoft has to use a production cycle because that's the only way they can create and deploy the ungodly number of patches that are necessary to fix all the security holes they've managed to create.

If Sun's programmers had to release that many security patches, they'd have to do it on a cycle too. (Assuming they didn't just shoot themselves.) They don't do it on a cycle because they don't do that many security patches because they've never screwed up to the point where it was necessary.

Solaris Patch Report Updates as of Jun/16/2006:

http://patches.sun.com/reports/2.5.1_patch_report
http://patches.sun.com/reports/2.6_patch_report
http://patches.sun.com/reports/7_patch_report
http://patches.sun.com/reports/8_patch_report
http://patches.sun.com/reports/9_patch_report
http://patches.sun.com/reports/10_patch_report

Solaris 2.5.1: 243 patches, 2,098 bugs.
Solaris 2.6: 270 patches, 3,280 bugs.
Solaris 7: 309 patches, 3,157 bugs.
Solaris 8: 582 patches, 9,126 bugs.
Solaris 9: 493 patches, 5,849 bugs.
Solaris 10: 319 patches, 3,311 bugs.

First patch I see is for the 1st June 1994 and the last I see is for 16th June 2006. That's 2,216 patches addressing 26,821 bugs in 4,398 days.

A patch every 2 days and a bug addressed every 4 hours.

572 of those patches are security related. Meaning that Sun releases a security patch almost every week.

Micrsoft might be worse than that, but Sun are still releasing a crap load of patches.

I'll say it for the third and last time: Microsoft has to use a production cycle because that's the only way they can create and deploy the ungodly number of patches that are necessary to fix all the security holes they've managed to create.

If Sun's programmers had to release that many security patches, they'd have to do it on a cycle too. (Assuming they didn't just shoot themselves.) They don't do it on a cycle because they don't do that many security patches because they've never screwed up to the point where it was necessary.

Solaris Patch Report Updates as of Jun/16/2006:

http://patches.sun.com/reports/2.5.1_patch_report
http://patches.sun.com/reports/2.6_patch_report
http://patches.sun.com/reports/7_patch_report
http://patches.sun.com/reports/8_patch_report
http://patches.sun.com/reports/9_patch_report
http://patches.sun.com/reports/10_patch_report

Solaris 2.5.1: 243 patches, 2,098 bugs.
Solaris 2.6: 270 patches, 3,280 bugs.
Solaris 7: 309 patches, 3,157 bugs.
Solaris 8: 582 patches, 9,126 bugs.
Solaris 9: 493 patches, 5,849 bugs.
Solaris 10: 319 patches, 3,311 bugs.

First patch I see is for the 1st June 1994 and the last I see is for 16th June 2006. That's 2,216 patches addressing 26,821 bugs in 4,398 days.

A patch every 2 days and a bug addressed every 4 hours.

572 of those patches are security related. Meaning that Sun releases a security patch almost every week.

Micrsoft might be worse than that, but Sun are still releasing a crap load of patches.

I'll say it for the third and last time: Microsoft has to use a production cycle because that's the only way they can create and deploy the ungodly number of patches that are necessary to fix all the security holes they've managed to create.

If Sun's programmers had to release that many security patches, they'd have to do it on a cycle too. (Assuming they didn't just shoot themselves.) They don't do it on a cycle because they don't do that many security patches because they've never screwed up to the point where it was necessary.

Solaris Patch Report Updates as of Jun/16/2006:

http://patches.sun.com/reports/2.5.1_patch_report
http://patches.sun.com/reports/2.6_patch_report
http://patches.sun.com/reports/7_patch_report
http://patches.sun.com/reports/8_patch_report
http://patches.sun.com/reports/9_patch_report
http://patches.sun.com/reports/10_patch_report

Solaris 2.5.1: 243 patches, 2,098 bugs.
Solaris 2.6: 270 patches, 3,280 bugs.
Solaris 7: 309 patches, 3,157 bugs.
Solaris 8: 582 patches, 9,126 bugs.
Solaris 9: 493 patches, 5,849 bugs.
Solaris 10: 319 patches, 3,311 bugs.

First patch I see is for the 1st June 1994 and the last I see is for 16th June 2006. That's 2,216 patches addressing 26,821 bugs in 4,398 days.

A patch every 2 days and a bug addressed every 4 hours.

572 of those patches are security related. Meaning that Sun releases a security patch almost every week.

Micrsoft might be worse than that, but Sun are still releasing a crap load of patches.

It is by the beans of Java that thoughts acquire speed

Acquire speed? Guess you don't mean this.

It all depends on what you are trying to do

For some workloads, many servers with four drives each may work. This is the Petabox/Google model. This works if you have a parallelisable problem and can push most of your computation out to the storage servers.
Remember, you don't have a 300Tb drive, you have 300 servers, each with 1Tb of local storage.

For other workloads, you need a big disk aray and SAN, probably from Hitachi, Sun, or HP. This is the traditional model. Use this if you need a really big central storage pool or really high throughput.
Many SAN arrays can scale into the PB range without too much trouble.

Nowadays, a PB is enough to arch your eyebrows, but otherwise not that amazing. It seemes that commercial storage leads home storage by 1000. When home users had 1GB drives, 1TB was amazing. Now that some home users have 1TB, many companies have 1PB.

A new class may contain new methods that need to be inlined in the appropriate places. So the Java HotSpot performance engine must be able to dynamically deoptimize (and then reoptimize if necessary) previously optimized hot spots, even during the execution of the code for the hot spot. Without this capability, general inlining cannot be safely performed on Java technology-based programs.

That's right, all of the best software engineers in the world are working for Sun and everyone else is on crack ... and Linux is losing to Solaris in such a big way on Wall St. and Sun have been able to keep using their same old development methodologies, don't change what works right?

You're right. Some of the best software engineers in the world are working for Sun. Sun's been hammered in the market place because it didn't react well to the dot-com bust. No layoffs, no significant restructuring or refocusing for years. Everyone cut margins and moved to commodity hardware, except Sun. (Note - Times have changed, see Galaxy and Coolthreads lines) The fact that Linux is "great" is precisely because it adheres to many of the design principals of a Unix-type Operating System and because it's free -- as in freedom, not beer. I also happen to think the BSDs are great, and that they've contributed a lot to the F/OSS community. But if you can't see all the amazing things coming out of the Open Solaris project that I just wish was in Linux, then there's no use even discussing it with you.

Sun has it's problems, but the engineers there are not one of them, and frankly you seem to be implying that they re somehow trying to impede progress or shut developers out of Open Solaris. On the contrary, they're working with Open Solaris contributors every single day. Let's not confuse high standards with a lack of enthusiasm for community building.

By your logic, Microsoft operating systems must be technically superior to Linux, because of both profit margin and marketshare right?