Slashdot Mirror

Did the author forget that Sun offers Red Hat on its workstations?

This is slightly off your point, but interestingly, "big iron" might be in for a bit of a comeback . I agree with you that the beige box looked poised to win out in the late 90s, but its rise was predicated on cheap energy to an extent most of us didn't appreciate back then. When energy prices double or triple over what they were last decade, suddenly consolidating all those generic, standalone x86 PCs into virtual instances living inside one, massive, efficient mainframe makes a lot more sense. Sun knows this and markets on it extensively. And companies who have opted for the thousands-of-PCs approach in their datacenter are doing everything they can to keep the price of electricity down--without it they're screwed.

They're both public...

Sun

Red Hat

Can you recommend any good beginner references to get started with J2EE stuff?

FWIW, you should probably start with Glassfish (aka Sun Java System Application Server) and Netbeans. That combination is extremely smooth for J2EE development and will have you up and running in no time flat. (Plus it's all open source. ;-)) Just visit Netbeans.org and grab the full version or the version with Glassfish bundled.

Once you get it setup, you can configure features like the JDBC connections through the admin console on http://localhost:4848. The default user/pass is admin/adminadmin.

You can then review the official tutorial here. It covers the concepts pretty well. Truth be told, though, you can skip most of the details for now and jump straight to servlets. Servlets are Java objects that respond to network requests. HTTPServlets thus have methods like doGet, doPost, doPut, etc. All you have to do is read in the parameters passed and write out to the output stream. Due to their relative simplicity, the JavaDocs tend to be the best reference for programming servlets:

http://java.sun.com/products/servlet/2.2/javadoc/

(Don't be fooled, though. Simple ideas are some of the most powerful.)

The one part that's not covered by the JavaDocs is the deployment. You will need to understand the web.xml file for mapping servlets to URIs. Thankfully, Netbeans has some GUI tools that can help you understand the format and how it works. Advanced servlet development can have a whole chain of cool stuff like classes that intercept requests before and after the servlet runs (filters) and event listeners on session creation and destruction.

Once you understand servlets, then you can move on to JSP pages. At their simplest, JSP pages are HTML with code that get compiled internally by the server into servlets that print out the HTML. (Take a look at the generated code sometime to understand JSPs inside and out.) Modern JSPs should be written with taglibs. Taglibs basically work off the page attributes collection. Rather than working with solid page variables, entries are created inside the hashtable used to store page attributes. (These are attributes that exist only for the period of the request.) The standard pattern for these is that you execute a tag to retrieve a collection of information, then you use tags to output and/or loop through the values.

Servlets and JSPs can be chained by using the RequestDispatcher.include and forward methods. This allows you to not only include one page inside another, but you can also use the page attributes to forward data around. e.g. Let's say you have a servlet that reads from the database in response to a user's input. It can then dump the results into an attribute and call off to a JSP for rendering of that data.

Once you get that stuff down, you can start looking into the other features of J2EE. The JNDI directory is a wonderful way to handle connection pools. Don't put your connection information in your pages! Let the J2EE server manage the pools through the directories. This will make your application more adaptable. JMX allows you to wire up all kinds of meta-data about your app in the same way that SNMP is used to manage network devices. The authentication system can be used to automatically restrict resources without having to write protection code into your application. Java messaging can be used to send messages between systems. JavaMail is obvious. Support for SOAP/XML-RPC/REST and other features are built into the server and are easy to use. EJBs are best ignored unless you're developing a compute engine. (If you don't know what that is, all the more reason to ignore EJBs.) Java Server Faces should be avoided at all costs.

While that just barely scratches the surface of J2EE power and scalability, hopefully it will be enough to get you started. :-)

Can you recommend any good beginner references to get started with J2EE stuff?

FWIW, you should probably start with Glassfish (aka Sun Java System Application Server) and Netbeans. That combination is extremely smooth for J2EE development and will have you up and running in no time flat. (Plus it's all open source. ;-)) Just visit Netbeans.org and grab the full version or the version with Glassfish bundled.

Once you get it setup, you can configure features like the JDBC connections through the admin console on http://localhost:4848. The default user/pass is admin/adminadmin.

You can then review the official tutorial here. It covers the concepts pretty well. Truth be told, though, you can skip most of the details for now and jump straight to servlets. Servlets are Java objects that respond to network requests. HTTPServlets thus have methods like doGet, doPost, doPut, etc. All you have to do is read in the parameters passed and write out to the output stream. Due to their relative simplicity, the JavaDocs tend to be the best reference for programming servlets:

http://java.sun.com/products/servlet/2.2/javadoc/

(Don't be fooled, though. Simple ideas are some of the most powerful.)

The one part that's not covered by the JavaDocs is the deployment. You will need to understand the web.xml file for mapping servlets to URIs. Thankfully, Netbeans has some GUI tools that can help you understand the format and how it works. Advanced servlet development can have a whole chain of cool stuff like classes that intercept requests before and after the servlet runs (filters) and event listeners on session creation and destruction.

Once you understand servlets, then you can move on to JSP pages. At their simplest, JSP pages are HTML with code that get compiled internally by the server into servlets that print out the HTML. (Take a look at the generated code sometime to understand JSPs inside and out.) Modern JSPs should be written with taglibs. Taglibs basically work off the page attributes collection. Rather than working with solid page variables, entries are created inside the hashtable used to store page attributes. (These are attributes that exist only for the period of the request.) The standard pattern for these is that you execute a tag to retrieve a collection of information, then you use tags to output and/or loop through the values.

Servlets and JSPs can be chained by using the RequestDispatcher.include and forward methods. This allows you to not only include one page inside another, but you can also use the page attributes to forward data around. e.g. Let's say you have a servlet that reads from the database in response to a user's input. It can then dump the results into an attribute and call off to a JSP for rendering of that data.

Once you get that stuff down, you can start looking into the other features of J2EE. The JNDI directory is a wonderful way to handle connection pools. Don't put your connection information in your pages! Let the J2EE server manage the pools through the directories. This will make your application more adaptable. JMX allows you to wire up all kinds of meta-data about your app in the same way that SNMP is used to manage network devices. The authentication system can be used to automatically restrict resources without having to write protection code into your application. Java messaging can be used to send messages between systems. JavaMail is obvious. Support for SOAP/XML-RPC/REST and other features are built into the server and are easy to use. EJBs are best ignored unless you're developing a compute engine. (If you don't know what that is, all the more reason to ignore EJBs.) Java Server Faces should be avoided at all costs.

While that just barely scratches the surface of J2EE power and scalability, hopefully it will be enough to get you started. :-)

Oh for the love of God. You have no idea what you're talking about.

http://java.sun.com/products/jsp/

Use JSTL. Don't use JSF. There, good to go.

I was there when the first version of Tapestry was introduced the internet. It was an interesting idea, but it took quite a few revisions to make it into something useful. Today it's an alternative to JSPs for rendering, but it by no means retires the use of JSPs. Same with Velocity and Wicket. And if you try to introduce me to Spring as if it's the latest and greatest thing (rather than a technology that's been around since the turn of the century), I will have to smack you. ;-)

Of course, all of this just points to the flexibility of the J2EE platform. (Primarily the servlet layer, but using a full J2EE implementation has a variety of pleasant advantages.) Which is why I feel like getting a lobotomy every time I have to work with ASP.NET 2.0 code. It's like going from a Cadillac to a Power Wheels. (Pow-pow-power wheeeeeelsss...)

if $400 for a motherboard is an issue, why are you worrying about security? YOU obviously don't need that kind of security, but someone else might.

look at crypto accelerators. these are boards that plug into PCI or PCIe sockets and are just a big blob of epoxy. and they cost a lot more than $400. these are designed like that so encryption keys can't be obtained by hot-"yanking" the device off the computer. these also have a killer circuit, so a battery will erase the keys on power loss.

http://www.sun.com/products/networking/sslaccel/suncryptoaccel6000/index.xml

You're only mentioning OpenLDAP which is a good option but why would you ignore Sun's Java directory server ? I'm using this one at home as part of the Java Enterprise System and based on my own experience I'd say that you don't want to mess with things like OpenLDAP and the likes.

Not because these products would be bad or anything, on the contrary, but because these Sun products are a little more developed and advanced when it comes to system administration. With OpenLDAP you'll be writing up a lot of scripts yourself to get things to work as you want it to. Sun's directory server comes with a full flexed administration interface free of charge. You can script or you can click your way around, you'll be the one deciding that. And also important; this stuff was around long before Fedora and the likes even had these kind of solutions, perhaps with the exception of RedHat's RHEL.

I can't help wonder if you're not falling into the common trap by assuming FOSS to be free software by definition. Sorry but that is NOT the way it works. If you're looking for free software then say so. Or do you plan to tinker with this software yourself as well? Because in that case I can't help being my cynical self by wondering why the heck you'd need to ask people on /. about this instead of grabbing your obvious choices to check them out and discover for yourself if these products meet your demands. That is what matters here. And if a quick google search is too much to ask (note how it also mentions the Java Directory Server at page 2?) then I can't help wonder what extra value the open source part will be. It doesn't look to me as if you'll be hunting down the source code and its (sometimes meager) documentation to find ways to enhance said software yourself.

Which brings me to my closing point: why change in the first place? Please don't assume that by simply installing a free Linux solution you'll reduce your total cost of ownership. Implementing such a change takes time for research and the implementation itself. And thats not even mentioning possible educational costs. We're not talking about a point and click solution per facto. So also keep this in the back of your mind that by switching environments you might be hitting your budget more than you expected or anticipated. Just because something is free does not make that better by definition.

Alas, I wish you much wisdom in your final pick and good luck with the migration should you decide to go through.

You're only mentioning OpenLDAP which is a good option but why would you ignore Sun's Java directory server ? I'm using this one at home as part of the Java Enterprise System and based on my own experience I'd say that you don't want to mess with things like OpenLDAP and the likes.

Not because these products would be bad or anything, on the contrary, but because these Sun products are a little more developed and advanced when it comes to system administration. With OpenLDAP you'll be writing up a lot of scripts yourself to get things to work as you want it to. Sun's directory server comes with a full flexed administration interface free of charge. You can script or you can click your way around, you'll be the one deciding that. And also important; this stuff was around long before Fedora and the likes even had these kind of solutions, perhaps with the exception of RedHat's RHEL.

I can't help wonder if you're not falling into the common trap by assuming FOSS to be free software by definition. Sorry but that is NOT the way it works. If you're looking for free software then say so. Or do you plan to tinker with this software yourself as well? Because in that case I can't help being my cynical self by wondering why the heck you'd need to ask people on /. about this instead of grabbing your obvious choices to check them out and discover for yourself if these products meet your demands. That is what matters here. And if a quick google search is too much to ask (note how it also mentions the Java Directory Server at page 2?) then I can't help wonder what extra value the open source part will be. It doesn't look to me as if you'll be hunting down the source code and its (sometimes meager) documentation to find ways to enhance said software yourself.

Which brings me to my closing point: why change in the first place? Please don't assume that by simply installing a free Linux solution you'll reduce your total cost of ownership. Implementing such a change takes time for research and the implementation itself. And thats not even mentioning possible educational costs. We're not talking about a point and click solution per facto. So also keep this in the back of your mind that by switching environments you might be hitting your budget more than you expected or anticipated. Just because something is free does not make that better by definition.

Alas, I wish you much wisdom in your final pick and good luck with the migration should you decide to go through.

It may not be opensourced yet, but Sun has released almost their entire enterprise stack for free for anyone to use, including their DSEE, with unlimited entries. It can synchronize with AD, and they have a good deployment planning guide for synchronizing with AD and there are guides all over the place regarding authenticating Windows off of LDAP servers.

It may not be opensourced yet, but Sun has released almost their entire enterprise stack for free for anyone to use, including their DSEE, with unlimited entries. It can synchronize with AD, and they have a good deployment planning guide for synchronizing with AD and there are guides all over the place regarding authenticating Windows off of LDAP servers.

Comparison of Open Web Server (OWS) and Sun Java System Web Server (SJSWS): http://wikis.sun.com/display/wsFOSS/Features+Comparison

This is the core of the Sun's current Webserver 7. The submitter linked to a blog that described it as Netscape Enterprise Server (it's great-great-grandfather) rather than the blog that clearly points out Sun open sourcing the core of their current Webserver is misleading.

I added some more notes about it on my blog here: http://blogs.sun.com/jyrivirkki/entry/more_of_open_sourced_web

After some years it was renamed the SunONE Web Server and most recently renamed again to the JES Web Server (Sun just like to keep you confused, thus the constant renaming of the product!)

First of all they're not going to open source the entire product but only the webserver core. That is not too surprising considering how Solaris has slowly started to adopt web services for options way beyond your common webserver. I can see that not everyone grasps these tidbits since Sun is indeed a little vague with certain information.

But I think its silly that you assume that SunONE got renamed. SunONE eventually came to an halt and got re-written (the core was basically all which remained) and a new Administrative webinterface was added. The product then became the Sun Java Webserver 7. So SunONE got basically "renamed" (rehauled is a better word IMO) to SJWS. And as to JES; the Sun Java Enterprise System.. That is merely a whole suite consisting of several components. You have your basic webserver, LDAP server, mail server, application server, portal server, and so on.

And guess what ? Instead of re-inventing the wheel all Sun did was basically putting their webserver product into this Java suite. Even SunONE was part of the previous JES suite. So I think that Aker's blog is simply silly and this particular post really isn't worth the attention IMO.

Granted; Sun has done some pretty silly things and their website can indeed be very confusing at times. Just look at the link I added; does this give you the impression that you, as an individualist or a private business, can download and utilize JES free of charge? Those things have always been very confusing with Sun. But their examples and explanation of what a product really is or what it consists of has never been vague. So I think its a little cheap to write something up which you obviously haven't looked into for one second, only to blame Sun because their information would be vague. Thats rubbish IMO.

LDAP, email imap/pop

Those were different products often bundled as part of a complete Netscape (later IPlanet) solution. Those are now sold as Sun Java System Directory Server Enterprise Edition and Sun Java System Messaging Server, respectively.

And this code isn't the dead version of Netscape Enterprise Server. It's the core to Sun Java System Web Server, yet another piece of the Sun Java Enterprise System.

Make sense? Next order of business, then. May I have a call for all those in favor of firing Sun's marketing department? (Slashdot crash in 3... 2... 1...)

LDAP, email imap/pop

Those were different products often bundled as part of a complete Netscape (later IPlanet) solution. Those are now sold as Sun Java System Directory Server Enterprise Edition and Sun Java System Messaging Server, respectively.

And this code isn't the dead version of Netscape Enterprise Server. It's the core to Sun Java System Web Server, yet another piece of the Sun Java Enterprise System.

Make sense? Next order of business, then. May I have a call for all those in favor of firing Sun's marketing department? (Slashdot crash in 3... 2... 1...)

LDAP, email imap/pop

Those were different products often bundled as part of a complete Netscape (later IPlanet) solution. Those are now sold as Sun Java System Directory Server Enterprise Edition and Sun Java System Messaging Server, respectively.

And this code isn't the dead version of Netscape Enterprise Server. It's the core to Sun Java System Web Server, yet another piece of the Sun Java Enterprise System.

Make sense? Next order of business, then. May I have a call for all those in favor of firing Sun's marketing department? (Slashdot crash in 3... 2... 1...)

LDAP, email imap/pop

Those were different products often bundled as part of a complete Netscape (later IPlanet) solution. Those are now sold as Sun Java System Directory Server Enterprise Edition and Sun Java System Messaging Server, respectively.

And this code isn't the dead version of Netscape Enterprise Server. It's the core to Sun Java System Web Server, yet another piece of the Sun Java Enterprise System.

Make sense? Next order of business, then. May I have a call for all those in favor of firing Sun's marketing department? (Slashdot crash in 3... 2... 1...)

This post is TOTALLY offtopic. Really you need to split these up and file them as bug reports over on launchpad. I'll post a couple of comments answers but I'm not going to follow up on any of this (even if you answer any questions I ask).

- switching from dual display to presentation (clone) and back totally messes up x config, I have to uninstall and reinstall nvidea drivers

Talk to NVIDIA (Linux web forum) about this. It's their code you're running and they are probably the only ones who are willing to fix it.

- in dual screen mode, nautilus opens on the first display. I have to open terminal and run nautilus& to lunch it on the second display

You can't drag it? I don't quite understand...

- in dual screen mode, keyboard keeps focus in the previous screen. I have to minimize/maximize a windows on the "new" screen to move keyboard focus

Are you using desktop effects? (Do windows fade and slide etc?) If so this sounds like a bug in compiz...

- RDP client crashes X windows in some cases (it does not close the drop down list of used servers... and bang)

Hmm. I'm really curious now as to whether you are using compiz. Regardless your best bet with this one would be to be to see if you can capture a backtrace of the crash with debug symbols and to file a bug report against the RDP client (I'm guessing you're using tsclient) in launchpad.

- oh and NO it's not AN ERROR if I close the RDP window. If I want to reconnect, I will, don't hide under my active windows and bring RDP windows back in 30 seconds. That's just plain stupid.

I guess file an enhancement request on tsclient in launchpad.

- java and window decorations don't play well together (popups without buttons etc.)

I really would like to know whether you are using compiz. If you are I have a feeling this was a known "bug" in the Java bug database for a long time but the fix is not yet in Ubuntu.

- How about opening a connection to a new server in a new tab, not in a new nautilus window?

Hmm probably best to file an enhancement request over on the GNOME bugzilla.

- Flash stops working. I just see a gray square where flash is supposed to be.

64 bit Firefox using 32 bit Flash via nspluginwrapper I'm guessing. There is a 64bit Linux Flash plugin that is in very early beta that MAY work better for you (I've heard mixed things mind). Also make sure you're using Flash 10 whatever route you are taking.

- Firefox is not very stable.

Might be because of extensions or plugins or you may have found a problem page or your memory might be faulty or Firefox might be buggy or... You are going to have to sit down and capture the issue in Firefox this then file a bug report in launchpad.

- Windows would become gray and unresponsive when there's a lot of disk activity.

You're using compiz aren't you? The greying is compiz telling you that the window HAS become unresponsive! As to why this is happening on I/O it probably varies from program to program. Too little information to many possibilities to say more.

- I've seen ubuntu crash on my much more times than I've seen BSOD on the same HW.

Quite possible. I've seen Linux stable on some computers and fla

The NetApp vs Sun lawsuit over ZFS isn't going the way NetApp would like it to ...

http://www.sun.com/lawsuit/zfs/index.jsp

To the contrary, NetApp may end up like SCO vs Novell, where the initial complainant ends up owing the respondent. Sun could very well end up both pwning AND owning NetApp.

As for the antivirus companies - I wish, but there will always be *some* "useful fools" around, and people whose financial self-interest aligns with enabling them to stay dumb and foolish.

According to a post on a Sun website

And, guess what, if you look on NetApp's website they disagree!

http://blogs.netapp.com/dave/2008/11/lawsuits-and-fo.html

Neither of these are likely to be good sources of information. It's quite possible that prior art will deal with all the patents in play by both companies.

Pete

The NetApp vs Sun lawsuit over ZFS isn't going the way NetApp would like it to ...

http://www.sun.com/lawsuit/zfs/index.jsp

To the contrary, NetApp may end up like SCO vs Novell, where the initial complainant ends up owing the respondent. Sun could very well end up both pwning AND owning NetApp.

As for the antivirus companies - I wish, but there will always be *some* "useful fools" around, and people whose financial self-interest aligns with enabling them to stay dumb and foolish.

And Ubuntu isn't ugly if your relative look is the Sun Java Desktop, hey look we manage to make Gnome look like crap!

ZFS has been optimized to take advantage of SSDs as ZFS intent log devices (whatever those are) in conjunction with regular drives. I think you may want to take a look at this for instance.

I haven't seen any specific optimizations for ZFS on standalone flash drives, but I would love to. Can you please provide any links?

PS: Frequent updates to Java caused by US daylight saving time are pathetic.

My first reaction was that many of these updates occurring are from other countries. Then I realized that these other countries might just be lagging in implementing their legislative changes to keep in step with specific US time zones.

Can anyone verify if most of these more recent java time updates are due to other countries aligning themselves with the US, or if they're just various countries doing their own thing?

Points of Interest
Java keeps it's time database aligned with the Olson time database.

However, if these updates remain frequent (as they are likely to do according to wikipedia) it sounds like Java needs a better mechanism for keeping time. Why does the VM keep time separately from the underlying OS anyways?

It sounds like a java connector to NTP is necessary so that running VMs can have their time databases updated on the fly (instead of having to bring down the VM and update).

If you have lots of data, I don't see how tapes are really going to do the daily backup jobs. You've been looking at the wrong tape drives. How does 1TB per cartridge and 120MB/sec transfer sound? How about 30 years archival life and 100,000 load/unload cycles? You don't get that with a disk drive! Your NAS is likely to have these on the server side, either in a tape library for primary storage or backing up the disk farm. Don't bet your business on non-removable media!

• The framework and getting it more modularized, so that various large projects making their own branded software will only use the components that they need. The situation is best described here, here and here.
• File format support and compatibility. This is mostly related to Office Open XML (known as MS Office 2007 format). That work is rather extensive, because so far there's some stuff that is yet to be done wrt pre-MS Office 2007 formats, while OOXML support needs continuous improvement and is still raw at places.
• Mac Aqua port. So far, OO.o had to be run through X11 on Mac OS X.

One of the best things framework-wise they did so far is getting the extensions system working. Michael Meeks is right about the number of committed developers; the extensions system should now make it easier for third party developers to create required functionality that can be quickly added, while taking some heat off the main developers. The extensions system also made it possible to ditch the bulky and inflexible way dictionaries were managed.

The Linux kernel
The benefit of running the latest 2.6.xx kernel instead of 2.4.xx is better overall security, resource management and better hardware support. The Linux 1.x tree probably doesn't support ext3 and other advanced stuff, because that depends on newer libraries, which in turn want a newer kernel to function. If you still want to run something on a very old machine, then perhaps give any of the *BSD's a try. That's how I see it.

I'll let you make up your own mind:

1. Kohei's story
2. Sun rebuttal by Mathias Bauer.

Sun has a history of not playing nicely with other projects, however. A real culture of "not invented here", or just plain arrogance. Makes me wonder what's going to happen to MySQL.

It's not very sexy, but it's fascinating and readable. I remember coming across it in Dillons bookshop, not knowing the name, and flicking through. Half an hour later, when I realised the time, I knew I had to buy it! Other books go into more exhausting detail (Knuth in particular), or cover a wider range (Knuth again!), or more modern ideas or languages. But Sedgewick is a great read, and I've been through it several times.

It covers all the basics (maths, searching, sorting, strings, graphs, and touches on FFTs and hardware and optimisation), and gives enough detail that you could go off and write some programs yourself. But more importantly, it explains them: how each algorithm works, what it's trying to achieve, how it behaves, and why. And it's because it explains the ideas so well that I'd recommend it. After every section I felt I'd learned something -- not because I had to, but for the sheer pleasure of understanding something new and interesting.

Other recommendations: Effective Java (a staggering amount of insight into the language), Thinking in Java (by someone who understands that language is more than just syntax), Deep C Secrets (again a pile of insight, interspersed with anecdotes and some rather off-the-wall diversions), Programming Pearls and More Programming Pearls (problem-solving in bite-sized chunks -- a little dated but still interesting). Plus I've already mentioned Knuth. K&R is well done, though narrow in scope. I find Design Patterns useful, but more for clarifying things I've already seen than for learning new things. I've never actually read The Mythical Man-Month, but people I respect mention it, so I'm sure it's well worth reading too!

Of course, times being what they are, especially in this field, a lot of interesting stuff is on-line. Some hat should go without saying hereabouts include the latest Jargon File, some of Eric Raymond's books, and more online documentation and archives than anyone but Google can cope with.

Other interesting articles include The Programmer's Stone, a guide to writing Unmaintainable Code, The Ten Commandments for C Programmers (annotated edition), Ken Thompson's Reflections on Trusting Trust, What Colour are your Bits?, and Guy Steele's Growing a Language.

Java SE6u10 was a major release and one of its most important improvements was... performance. You can read about that here, one of the many blogs. So excuse me for not being the slightest bit surprised that u10 outperforms u7.

The obvious 3 letter answer is ZFS, especially with the new time slider desktop GUI. But that isn't the entire answer. Linux is still ahead of OpenSolaris on number of packages, drivers and hacker niceties, but when it comes to long term API/ABI stability required for real businesses (who presumably intend to be around more than one Linux x.x.0 release), OpenSolaris wins. It is far less likely to force you to rewrite your business code and upgrade your entire application stack every 6 months.

Add the security, scalability advantages such as RBAC/Zones and observability advantages such as dtrace and it really should be on every developer's desktop even if only as a tool to help your Linux/Windows/BSD/OSX development.

Excellent point, u10 was the next "major" minor release after u07, check out the release notes for it here, they're... long.

http://java.sun.com/javase/6/webnotes/6u10.html

Well, saying "often" might be an exaggeration; the only major 64-bit compiler where a long is 32-bit is Visual C++. Every other 64-bit C compiler I've seen or heard of is LP64 (meaning a long is 64-bit) -- Linux (gcc), FreeBSD, Solaris, Mac OS X (also gcc), AIX, HP.

As for Java, the real problem is that you simply can't index an array with a long, so you're limited to 31-bit indices. It might seem crazy to have arrays with more than 2 billion entries today, but when we start to have hundreds of gigs of memory, it will be useful. I wonder if Java will ever change this.

Solaris isn't free, it is a 90 day trial. I went to setup a file server using Solaris and quit after reading the fine print.

Uh. Complete and utter FUD. From the horse's mouth:

You can use the Solaris 10 Operating System at home or at work -- without paying a license fee. Download the Solaris 10 OS today - FREE -- when you register your system (as part of the download or by going through the registration portion of the download) you will receive an Entitlement Document, which grants you unlimited rights to use Solaris registered machines. Sun offers this no-cost licensing program for all use - even commercial use, even on multi-processor machines.

I suspect that when that time comes around someone will implement a JVM with a larger primitive than Java's long (think 64 bit int), but in the meantime use this:

http://java.sun.com/javase/6/docs/api/java/math/BigInteger.html

3. Link my_java_path/lib/amd64/libnpjp2.so into your Firefox plugins directory (forget where it is)

I followed the installation instructions but that didn't work. But symlinking libnpjp2.so did the trick. WTF?

By the way, the plugins directory usually is ~/.mozilla/plugins.

Yeah really. Even if Java browser plugins still had much of a user base, what's the point of running them 64-bit? Tiny applications that run inside browsers are not to going to benefit from the extra power of the x64 world.

The web actually is a decent way to deliver Java applications. Provide your users a Java Web Start link, and with one click they can download the application code and runtime (both kept up to date automatically) that they need to run the app. And of course, you can use a 64-bit runtime.

That said, I'm afraid this was inevitable. I used to work in the Java SE group at Sun, and all the time I was there, the demand for a 64-bit browser plugin was incessant. It was inevitable that Sun would give in on this, even though it means them spending money they can't spare for no real benefit to anybody.

(BTW, your sig and my sig need to get together and have a talk.)

The biggest reason of all is interop. A piece of Java code that runs in 32 bit mode successfully will wrap around and work exactly the same on the 64 bit platform. Perl will work differently. if a piece of Java calls a piece of identical Java and one is on 32 bit and the other 64 bit then they will work properly, Perl will behave erratically.

Basically its the difference between a language that has been designed for longevity (Java) and one that just defaults to what ever is around (Perl).

Defaulting to what the processor has is the opposite of future proofing as it ensures that your current code WON'T WORK PROPERLY IN THE FUTURE. Sorry to shout but it really is quite important. The Java code will work the same on 32 bit and 64 bit versions while the Perl will work differently, thus it will not be future proof.

To really future proof your code what you need to do is plan for those things and assign your file size to be a long and guess what Java returns a long.

Perl and Design go together in the same way as Illinois and Probity.
 

BigDecimal b1 = new BigDecimal("100.04");
BigDecimal b2 = new BigDecimal("0.33");
BigDecimal result = b1.multiply(b2);

BigDecimal b1 = new BigDecimal("100.04");
BigDecimal b2 = new BigDecimal("0.33");
BigDecimal result = b1.multiply(b2);

P/E ratios for a company with flat revenue/profit growth are generally between 8 and 10. What this means is that a company that isn't growing is worth approximately 10 times what its annual profit is.

What you're not accounting for is the rapid growth, and expected future growth that Sun was counting on. Given the massive number of websites and/or large enterprises that use MySQL, and how quickly MySQL has matured into something which is beginning to resemble a real RDBMS, I think it's safe to assume that MySQL is going to continue to grow rapidly, vigorously chipping away at both Oracle and Microsoft. In addition, I believe that Sun correctly analyzed the largest problem faced by MySQL AB, the difficulty in picking up service contracts with large enterprise customers. Sun correctly surmised that while MySQL AB would have difficulty selling enterprise service contracts to Fortune 500's, Sun Microsystems wouldn't encounter the same difficulties. After all, they sell them hardware and enterprise service contracts already. Indeed, Jonathan Schwartz talks about exactly this here, where he describes selling MySQL services to a large enterprise client.

The other side of the story is the JAMS (Java, Apache, MySQL, and Solaris) stack, and the synergy created through the acquisition. Sun is now in the perfect position to start offering totally unified hardware and software support solutions. They designed and created Java, MySQL, Solaris, and the hardware in that equation, making them a very attractive option for the buyer. I believe that by being able to package and offer all of the software, hardware, and services together, offering them much less expensively than the competition by leveraging the open source community, Sun will easily be able to drive revenue. In fact, I'd bet that within 5-10 years, this acquisition could be driving a billion dollars of new revenue (that includes systems and services contracts they wouldn't have otherwise sold) a year to Sun. Should that happen, they'll have gotten a bargain on the acquisition.

Finally, there is one additional issue, which is the decline of enterprise systems in recent years. Sun has been attempting to divest themselves from their systems business for some time now, in an effort to establish other revenue streams. The MySQL acquisition was the perfect maneuver to jump start the systems business, while also broadening the horizons of the services business. Look at it as kind of a way to stay relevant with a changing landscape.

I guess what I'm getting at is that a company that has 200% revenue and profit growth today (just guessing Sun can achieve that), and a P/E ratio of 100 can still be an attractive investment, given that the ratio with sustained growth will effectively be 50 in one year, 25 in the next, and 12.5 in the third. It's a long term investment predicated on future growth potential, and in this case the additional benefits of having the product as part of Sun's larger portfolio.

So the proof that the newly released JavaFX will fail is that you haven't been using it for building applications?

A high percentage of developers code on linux systems, and if you want that code to run on windows, you're primarily limited to java or browser-based applications (although GTK is starting to look appealing). Deploying java applet and webstart apps is a nightmare, but javafx is being trumpeted by Sun as a solution to this -- for windows and mac only. Note that you need to download javafx just to view the demos, so even though it was downloaded by a lot of windows/mac users doesn't mean that a high percentage of those downloads were by people wanting to develop javafx apps. So the problem isn't that the grandparent poster doesn't use javafx, it's that if you use linux, you CAN'T use javafx.

And it appears that that will be the case for quite awhile, because Sun has been purging comments from their blog post about javafx support on linux and solaris (all comments from December 6 and 7th are now missing, along with some others), and the editor of the java.net site says that Sun has "better things to do" than release a linux or solaris version of javafx.

That may not be "proof that JavaFX will fail," but it certainly doesn't help foster its adoption.

Sun can still turn things around if they release a 64-bit linux port of javafx. The 64-bit plugin technology is related to javafx, so maybe if and when Sun ever releases a linux version of javafx, it will be for both 32-bit and 64-bit systems. But I'm not going to hold my breath.

This one: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4802695 more: http://www.linuxforums.org/forum/redhat-fedora-linux-help/50082-64-bit-java-plugin.html

Also have a look at that blog post, by a Sun employee, on the SUn blog :

http://blogs.sun.com/mrbenchmark/entry/scaling_mysql_on_a_256

The comments are insightful.

Sun is the worlds largest open source company both in terms of size and contribution.

MySQL
OpenOffice
Java
VirtualBOx
Open Solaris

are all wholly Sun projects but they also contribute to numerous other open source projects.

Sun may not be perfect but, there are none better at the moment.

Photoshop CS3

Looking at the AppDB page, I'd suggest trying it on some distro other than Ubuntu. Although CS2 works better if that would be sufficient.

- Office 2007

I need those specific apps because those are the formats my peers and clients use.

Well, you can open .docx files as of OOo 3.0. Or maybe you could talk them into using Sun's ODF Plugin (It's a long shot, but I thought I'd throw that out there.)

- MSIE 6/7

IE6 runs, sure, but leaks memory like there's no tomorrow, so I have to kill -9 it after a few minutes lest I face a swap-spiral of doom.

IEsforLinux? Although it seems a little dead...

It's impossible for guarantee 100% storage integrity, just like it's impossible to guarantee 100% uptime. What you want to ask is what risk of data loss you are willing to take.

This page compares some of the options in terms of Mean Time To Data Loss (MTTDL). For the amount of space you're looking at (~500gb), a three-way mirror is probably sufficient to last for your lifetime.

But there's always the risk of fat-fingering "rm -rf" or having the building catch fire, so maybe you want to have two synchronized sets of mirrors, stored in different physical locations. Only you can decide if that's too paranoid for you (or not paranoid enough).

its more like the (c)2003 sun demo http://www.sun.com/software/looking_glass/media/k5_media.jsp#lg1 *years* before leopard.

As expected, it seems that Apple has the lead.

I agree with your post for the most part but Apple isn't leading here:
http://bumptop.com/
http://www.sun.com/software/looking_glass/

They may "lead" in bringing something like this to the market quicker (like they did with desktop composition) but they didn't invent this stuff. Certainly not patent worthy.

This clearly shows that the patent system is broken. Sun have been working on a 3D Desktop since the early 2000s.

More info: http://www.sun.com/software/looking_glass/