Slashdot Mirror

There are plenty of real world case studies that prove your personal experience to not be the general case for Java:

http://www.sun.com/customers/index.xml?soln=31a8487e-0f60-11da-99bc-080020a9ed93&page=1&sort=date&asc=false

This case study is particularly relevant:

http://www.sun.com/customers/servers/transact_tools.xml

This page is rather out of date, but shows that Java was performing well even in 2003:

http://www.artima.com/weblogs/viewpost.jsp?thread=8142

Java has become the number one most prominent language in business with good reason. It's flexible, and can cater to pretty much anything you throw at it if you understand the tools and technologies available, and which ones are suited to your particular problem. Garbage collection really just comes down to having an understanding of the way the garbage collector works and being able to develop with that in mind. See here for an example discussion of just that from back in 2003:

http://java.sys-con.com/node/37613

here's a slightly more recent (but still relatively dated in technology terms) article:

http://articles.techrepublic.com.com/5100-10878_11-6108296.html

The problem Java and .NET seem to face is people approaching the language, from say a C++ background and not understanding what's different about it and how it works to be able to implement a solution in it to an equivalent level of their C++ application. This does not mean experienced Java/.NET programmers cannot do just that though- they can, and do. Again, it's really a question of competence in a particular skillset rather than inherent flaws in a particular technology.

Sorry, but it's not a monopoly as long as I can buy one of these, one of these, or even one of these.

Terminal Services

This is the most outrageous of your claims. Linux, Solaris, *BSD all come up trumps in this. You've got X11, NX, VNC, and the most advanced thin client solution at the moment, Sun Ray.

Why does everyone like VNC? I use it but only when I have to its slow as a turd it seems slower running VNC with 8 colours than Terminal Services running with 16K colours across slow networks.

Active Directory

You can't be serious on this one. LDAP + Kerberos can easily take on that role plus some.

Exchange

Email is easy enough to offer but shared address books and calendaring may give Exchange the edge. No harm in deploying Exchange on the back-end and using Evolution or Thunderbird or web based Exchange on the front-end.

Terminal Services

This is the most outrageous of your claims. Linux, Solaris, *BSD all come up trumps in this. You've got X11, NX, VNC, and the most advanced thin client solution at the moment, Sun Ray.

I asked to verify I understood correctly, and he indicated that it was a quick implemented feature based on metadata copies, so basically not to expect much out of it. It's possible he was wrong or there was a miscommunication though.

Looking more at the documentation though seems to indicate that the only time this would happen is if the other drive(s) do not have the space available for the copies, in which case multiple copies will be written to the same drive.
http://blogs.sun.com/relling/entry/zfs_copies_and_data_protection

..and the sooner people learn that, the better. Studying ZFS' design reveals a great deal about what RAID simply cannot achieve.

As others have mentioned, this is something that is discussed on the ZFS mailing lists frequently.

For more info there, check out the digest for zfs-discuss@opensolaris.org

and, in particular, check out Richard Elling's blog

(Disclaimer: I work for Sun, but not in the ZFS group)

The fundamental problem here isn't the RAID concept, is that the throughput and access times of spinning rust haven't changed much in 30 years. Fundamentally, today's hard drive is no more than 100 times as fast (both in throughput and latency) than a 1980s one, while it holds well over 1 million times more.

ZFS (and other advanced filesystems) will now do partial reconstruction of a failed drive (that is, they don't have to bit copy the entire drive, only the parts which are used), which helps. But there are still problems. ZFS's pathological case results in rebuild times of 2-3 WEEKS for a 1TB drive in a RAID-Z (similar to RAID-5). It's all due to the horribly small throughput, maximum IOPs, and latency of the hard drive.

SSDs, on the other hand, are no where near the problem. They've got considerably more throughput than a hard drive, and, more importantly, THOUSANDS of times better IOPS. Frankly, more than any other reason, I expect the significant IOPS of the SSD to signal the death knell of HDs in the next decade. By 2020, expect HDs to be gone from everything, even in places where HDs still have better GB/$. The rebuild rates and maintenance of HDs simply can't compete with flash.

Note: IOPS = I/O Per Second, or the number of read/write operations (irregardless of size) which a disk can service. HDs top out around 350, consumer SSDs do under 10,000, and high-end SSDs can do up to 100,000.

-Erik

Well, I couldn't even get OSOL installed on the SPARC machines, so my experience on that side comes from my experiences on x86 boxes.

Well, have you've checked HCL in prior to installation? http://www.sun.com/bigadmin/hcl/ Because if you did and it won't work, then it is a bug and next your move should be reporting it. In my case I even installed it on incompatible hardware (it won't even boot at that time and hanged right I've inserted CD).

You also can subscribe to osol-help@opensolaris.org and ask these questions there. I think you just as everybody else, who comes from Linux world and treats Solaris as Linux. :-) That's understandable, but it is very different culture and philosophy to deal with. If you want get into it, better subscribe to mailing lists you need and look for BigAdmin docs in prior to work with.

As for me, Linux is not any stable: kernel panic was already a regular routine, unfortunately, in both big datacenters I worked in.

And now, they have stuff that provides a sensible approach to concurrency

Erm, if I read that article correctly, it means Apple finally discovered that cutting edge new technology, the "thread pool". Oh, and they hacked closures into Objective C. How is that not simply a ThreadPoolExector?

It happens on a lot of levels and with lots of software. It is IMO one of the key issues which might hinder OSS to be adopted in a more professional way. Do note that I'm not stating that this is the case for each and every open source application out there, but there are a lot..

I've experienced this same kind of situation myself.. I'm a fan of the Java language and utilize this both professionally and as a hobby. Do note that I'm not a full time programmer. I've started out with NetBeans version 4.1 and basically kept following the developments around the IDE, now a full platform. The somewhat counter part of NetBeans, Sun Studio, offered support for UML diagrams. And it didn't took the NB developers too long to port UML support into NetBeans. And I can tell from personal experience that they did a really nice job. It wasn't perfect, it was still rough on the edges so to speak, with a few bugs here and there. But as long as you were familiar with the product you could do a lot. And the same applied to NetBeans.

Now all went relatively well until version 6 of NetBeans was released. That version became quite controversial even though I'll be the first to admit that they have done a really fine job. They basically rewrote the entire thing in order to clean out the code. As a semi-professional developer I can recognize and admire the technical impact this must have had. Don't get me wrong here. But as an end user I was appalled to see that several big and important features were gone all of a sudden. No more support for Bean Patterns (an option which made it easier to add or remove fields from a JavaBean), no longer would it offer an overview for JavaDoc (a separate window which would immediately show you what methods and fields you commented, which ones weren't consistent with the actual method or field and which still needed to be commented), and so on.

SO although it also offered a lot of new features (more modular support, support for other languages, etc) one of the primary basics was slightly crippled. Naturally all of this was fixed eventually, right now I'm also a very happy NetBeans 6.7.1 user and it does everything I need. Everything but one thing...

With the full code rewrite many modules also needed to change in order to be compliant with the new standards. Many succeeded, and many didn't. One of those was the UML plugin. Ironically enough for me it was NetBeans / Studio One which somewhat aroused my interest for UML diagrams. And when NetBeans 6.5 got released it was this particular feature which got totally crippled. It was hardly possible to create any decent diagrams, and to make matters worse the plugin now suddenly stopped supporting some (for me) important diagram types (like deployment, sequence, object). And so I eventually stuck to NetBeans 6.1 because I really needed UML support.

Until I suddenly noticed an article on the UML plugin webpage which mentioned Visual Paradigm. Its a company which developes UML modelling software, and one of their key products is the so called Smart Development Environment. And in my opinion its brilliant! Commercial, but brilliant.

This is a plugin which can embed itself in all of the major (Java) IDE's currently available; From Microsofts Visual Studio .NET to IntelliJ IDEA right to Eclipse and naturally NetBeans. Although they do offer a free community license (free of charge with a few limitations when it comes to p

Mac Mini or Mac laptop. Now you have it all. Sun has a free one. http://www.sun.com/software/products/virtualbox/get.jsp
Duh!
qz

But MS exchange and the software ecosystem surrounding it is highly available, reliable, feature rich, painlessly scalable from a small operation up to hundreds of thousands or possibly even millions of users at a price point that almost any business can afford. Its one of microsofts best products, and there really isn't anything I have seen in any competitors that can meet, much less, beat Exchange at its game.

Sure shows that you have never had to admin an Exchange server or your either a Microsoft shill. The above is utter BS.

We run an Exchange cluster and also a Java Messaging system. It takes 2 guys about 30 man hours a week to maintain it. The Java Messaging system takes one guy and about 3 man hours a week to maintain it.

For 2000 users it takes 4 machines clustered together on Exchange and it could use more. We use two machines clustered together for Java Messaging for 4000 users and it runs just fine. Actually one server will handle the load. The other is just for fail over. Java Messaging is rated for the box we are running on to support 1 million users. Try that on just one Exchange box. citation

and yes you can use Outlook to connect to Java Messaging and it works fine. Most users don't even know they are not using Exchange.

painlessly scalable

Again you've never had to admin one of these have you. If you had you would know the pain.

up to hundreds of thousands or possibly even millions of users at a price point that almost any business can afford

Yea right.

OK Explain this. It takes 4 machines to handle 2000 users on Exchange. You buy 4 server licenses and 4 Exchange licenses from MS PLUS a user licenses for each user. (2000 user licenses) and pay two people to maintain it.

Java Messaging will handle more than 2000 users with less use of resources on one machine. The OS cost $0.00 the software cost $0.00 the user licenses cost $0.00 and only takes one person to maintain it.

Now which is at a price any business can afford?

reliable

This one word shows you have no clue and have never work on a large Exchange system.

You say you are a fan of open systems so lets talk about how any other OS's email clients have a hard time connecting to Exchange with their broken "Closed" protocols. Why MAPI? Why not be like everyone else and use IMAP w/ SSL or TLS? Every open protocol on the Internet MS has broken it and perverted it in some way so it only works with THEIR system. Exchange is a good example of this along with Kerbous5, and LDAP to mention a few more.

Its one of Microsofts best products,

I don't think so. Its one of the biggest piece of shit they ever made.

Who here runs Linux on anything with more than 16 cores?

My personal server. A debian based distro of Gnu/Linux is much easier for me to admin than Solaris. Massively multicore is the future. I wouldn't buy any new computer with less than 16 cores/hardware threads. Well, except for laptops and embedded systems.

Looks like a cheap downscale undersized version of a Sun X4500/X4540.

Or, if you also want software in appliance form, along with flash accelerator drives and support, the Sun Storage 7210 which holds 46 TB in its 4U chassis and is expandable to 142 TB.

Sun has been undercutting NetApp prices with these ZFS-based "Unified Storage" systems, especially since they don't charge for software features (NFS, CIFS, HTTP, replication, etc.) separately like NetApp does.

By the way, if you want to try the software, there's a VMware/VirtualBox VM image of the storage appliance. You can replace the simulated drives with real ones if you like.

Looks like a cheap downscale undersized version of a Sun X4500/X4540.

Or, if you also want software in appliance form, along with flash accelerator drives and support, the Sun Storage 7210 which holds 46 TB in its 4U chassis and is expandable to 142 TB.

Sun has been undercutting NetApp prices with these ZFS-based "Unified Storage" systems, especially since they don't charge for software features (NFS, CIFS, HTTP, replication, etc.) separately like NetApp does.

By the way, if you want to try the software, there's a VMware/VirtualBox VM image of the storage appliance. You can replace the simulated drives with real ones if you like.

The code you link to has a sign extension bug. You need to use the unsigned right shift, which moves zeros into the most significant bits:

http://java.sun.com/docs/books/tutorial/java/nutsandbolts/op3.html

Not much difference, it's just third iteration of in-CPU crypto accells. See details in presentation.

The T1 and T2 have different cryptographic capabilities. See page 5 of "Using the Cryptographic Accelerators" a description. I would imagine that they are including even more support.

Sounds a lot like Lights Out Management eh. Seen this in Sun and HP too.

At least this idea was previously published at Research Disclosure, a site intended as an inexpensive way to log prior art. It is the next logical step and I'm glad to see that companies are moving in that direction.

Convert all DOCX documents to DOC format to prevent some Microsoft Office update removing the XML features and thus shutting people out of their DOCX documents.

What does the judge think of this ODF plug-in converter for MS-Office? Does it violate the XML patent as well as Sun Office and OpenOffice.Org and IBM Lotus Symphony?

I build myself these little 4 port ethernet taps. All you need is a couple things from your local electrical supply shop and about 5 free minutes. http://www.sun.com/bigadmin/content/submitted/passive_ethernet_tap.html

Fixed the spelling (punctuation, actually) mistake. Thanks.

Regarding the name, I'll quote from my old home page. I'd just give the link, but I suspect this site will not remain in the air for much longer (most of it is quite out of date), so I'm quoting here:

Once upon a time, I had a simple, very easy to understand, name. My given name had three letters, as well as my family name. It was clear to anyone hearing my name how to spell it, and to anyone seeing my name written how to pronounce it.

Without anything actually happening to me, this all changed, suddenly and ruthlessly, one day towards the end of 1991. The trigger of the change was a (now almost dead) utility called "Internet Relay Chat" - IRC. The cause of the change was most of the world's inability to speak Hebrew. All of a sudden I found that both my given and my family name were seven letters long, and no-one knew how to spell either one, let alone pronounce them.

Trying to find acceptable alternatives, I turned to the fact that most names given in Hebrew have a meaning. In my case, "Shachar" means "dawn", "Shemesh" means "sun". Since Dawn is a female name, I went with "sun".

When the domain buying craze started, I found out that sun.com was already taken. While I had the fleeting idea of suing the sneaky bastards, I decided to let the case drop.

So now you understand the reason behind my /. user name....

I should point out that I stopped using "sun" as a nick name, mostly because I figured the Internet had enough of its Xenophobia gone to allow non "Latin friendly" names. I also figured most people today are adept enough in the complex art of "copy and paste" to handle it.

Then again, who knows? Maybe with Sun bought by Oracle, sun.com will be free again and I'll change my mind...

Shachar

Dynamic languages have more overhead to dispatch a method call.

That depends on how method dispatch is implemented in the virtual machine. JIT compilers can replace an expensive indirect call with a compare + direct call pair at all call-sites (Hotspot, for example, does this) which makes method dispatch overhead go away. Look up inline caching on Wikipedia or read the polymorphic inline caching (PIC) paper if you are interested in the details.

It's "direct hardware access" in the same sense as the 2D accelerated DrawRectangle() is "direct hardware access".

Oh, sorta like GDI? :)

We went through a few bad years when the .jpg libraries had buffer overflow vulnerabilities on platforms from Linux to Solaris, and on Windows, this was further compounded by GDI+ vulnerabilities.

The GDI+ vulnerability was particularly annoying; it wasn't specific to web browsers, but any JPEG viewer that used GDI was vulnerable. (Hey, make sure to update your copy of ACDSee or IrfanView before viewing that .JPG you downloaded off alt.binaries.goats.e.e.e, even though not a single packet traveled over port 80 in the process. Are you sure the guy who wrote some obscure shareware game where you could replace a bobblehead-doll target with a URL pointing to a pic of your favorite celebrity didn't use the wrong version of the library? Did he release a patch, or has he been out of business for 5 years...)

This has the potential to repeat that mistake: untrusted third-party content will be thrown at libraries (and drivers) that, up until now, had been written with at least the tacit assumption of console access being the normal use case.

Yes, I know OpenGL doesn't strictly require console access -- it works over a network in a way that DirectX never could, so there's some abstraction going on, and those extra layers of abstraction might provide a little bit of protection.

But the people who write the drivers for ATI(AMD) and NVIDIA - a market in which every frame per second counts - probably took the odd shortcut from time to time. Hell, even the people writing the drivers for Intel and VIA's integrated graphics chips took shortcuts for performance. 99% of the users will use the app from the console, and the remaining 1% running OpenGL apps over a network aren't plentiful enough for malware writers to develop exploits. OpenGL calls spawned from web content changes that balance.

Or they use a "real" switch that has port mirroring, or a passive ethernet tap.

In fairness, Office 2007 will...

* Export to PDF and XPS (Beginning in SP2). Also, using beerfree programs like CutePDF and the like, you can simulate OO.org's PDF exporting abilities in any Windows program.
* Import a plethora of formats that OO.org can't open. Go ahead - import a Microsoft Works file. I dare you.
* Export to ODF if you install the Sun ODF Plugin. There was an article here fairly recently about MS' native ODF plugin being extremely incompatible with OO.org's implementation of the standard, so I'd avoid that.
* Also allows you to easily install and manage extensions. In fact, Office made it so easy, it became a rather serious security breach. Office 2007 now requires you to assign a level of trust to your macros and plugins before you install them.
* Runs natively on... erm... Windows.
* Doesn't cost a penny if you don't mind violating numerous copyright and trademark laws.

On the other hand, once you look past Word and Excel and start looking at the rest of the office suite, you quickly find that Draw is a really poor substitute for Visio or Publisher, Base could diplomatically be thought of as a severely watered down version of Access, and what does OO.org use for e-mail? Oh right - it doesn't, which means there's no clean way to apply OO.org macros to e-mail documents.

Look, OO.org is a nice product. I use it for most things without complaint. For a lot of people, it matches up well enough. That said, don't fool yourself - OO.org isn't a drop in or feature-matched replacement for Office 2000, much less any version after that, unless you're just using the Home & Student version.

Beats the pants off of Microsoft Works, though. If there's one thing we can be thankful for, it's the OO.org may have single-handedly nuked that abomination from orbit.

I'd rephrase that. It eliminates the common cases where you'd need fsck on a conventional filesystem.

ZFS' design makes consistency failure extremely unlikely. I understand why they claim it doesn't need fsck ("always consistent on disk").

That's assuming that when you have a power outage, either you were using battery-backed RAID, or the disk was kind enough to commit the writes to the physical medium in the order the OS gave them. If you don't have battery-backed RAID, the only way you can have the faintest clue what's on the disk in the event of a power outage is to configure the OS or applications to flush data to the actual physical medium constantly, skipping the write buffers on the device. Which is incredibly slow. So nobody tends to do it very aggressively. If you don't take that step, you can't guarantee anything; a fsck is still required after a power outage. (Not to mention other types of hardware failure.) The only time you won't need fsck is after a mere OS crash; but you usually don't need a fsck then anyway, on journaled filesystems.

I'd rephrase that. It eliminates the common cases where you'd need fsck on a conventional filesystem.

ZFS' design makes consistency failure extremely unlikely. I understand why they claim it doesn't need fsck ("always consistent on disk"). There is controversy over whether there should be a scavenging tool. Some people want one for peace of mind.

But again, most cases of ZFS pool loss where some believe a scavenger may have saved them, may actually have been solved by more aggressive rollback (I believe work is being done on this).

Anyone interested in this issue should follow the ZFS mailing list.

- better package management

Take Nexenta's implementation of OpenSolaris, for example: the package manager is 'dpkg' and 'apt-get', just as with Debian Linux. There's also a Debian GNU/NetBSD port of Debian. If you want to keep Linux-style package management, you have good options.

BSD also has decent package management... NetBSD has pkgsrc, FreeBSD has ports, which allow you to very easily install software from source code, lots of software is available in this form that you'd have a hard time finding on Enterprise Linux distros.

Of course, binary packages are available as well.

- better hw support

If this is the most important thing to you, then perhaps you should stick with Windows server when using commodity processors, because Windows is what nearly all hardware vendors say their product is designed for.

Choose hardware your OS works on then; I never had the least bit problem doing that with BSD or Solaris; it's not as if hardware required to run Solaris or BSD is necessarily more expensive. Sun publishes a compatibility list OpenSolaris (HCL). FreeBSD/NetBSD work just fine on most commodity hardware.

In fact, NetBSD has been known to have ports for more platforms than others, it even runs on a fair number of processor architectures that Linux hasn't been ported to.

- Much larger community

If this is the most important thing to you, then you should run Windows, because Windows has the absolute largest community.

The Linux community having grown so much does not necessarily mean that the other OSes suck, or that Linux is magically better.

- better ISV support

This is only useful if you are actually running independent software. Most UNIX users are running common open source software, that they've installed from package repositories, or compiled themselves.

- Better availability of qualified Linux sysadmins

I'll agree there's better availability of Linux sysadmins, not necessarily that they are best-qualified, and this is a valid reason to choose Linux, but not a reason that other options suck.

A well-qualified sysadmin should be able to work in Linux, FreeBSD, Solaris, etc, once they have done some basic reading up on the differences and the OS of choice's documentation.

The administration of Solaris is pretty similar to the administration of BSD, which is also very similar to the administration of Linux.

Much of the software is the same. The main differences are in some system monitoring and diagnostic tools that OSes other than Linux have more of, and Linux users rarely use.

In fact, a major reason Linux sysads aren't automatically qualified Solaris sysads, is because Solaris provides tools that are a lot more useful for effective system administration.

Other OSes provide fault management, troubleshooting, diagnostic, and monitoring capabilities that Linux does not.

E.g. Linux has 'strace' that is very dangerous to use in practice (if you can help it, you don't trace or debug processes on production systems); Solaris has 'truss' or 'dtrace' that are fairly safe to use: you can transparently instrument a production system, whereas with Linux you cannot.

Solaris has 'fmadm' for fault management, plus 'smf' for service management, including fault-managed services and e.g. automatically restarting apache, and many kernel tools for tuning settings without rebooting; on Linux, there is no fault management, and if you want to tune things, you're probably going to need a kernel recompile.

Oh yeah, and on Linux, if you want to automatically re-start BIND or Apache should it crash, you will probably be hacking together a non-standard cron script, or installing some random third-party package and hacking together a script to make it happen.

"How about testing them on web services like digg, or on company mail servers instead of fake throughput and "feel" tests?"

I've been waiting for the same thing, unfortunately SLC flashed-based drives (the more expensive NAND flash with the higher lifespan) is still exceptionally expensive. But, the good news is major SAN vendors are already offering SSD options. Everyone from EMC to Sun Microsystems is starting to include SSD drives in their storage products. While it would be very unusual for us to get a peek into the storage systems of companies like digg, etc, hopefully they'll filter down far enough that we can get some realistic reviews soon. I'm definitely looking forward to it.

Sam, I mean this sincerely:

Microsoft has a long, long history of letting its mid-level managers and employees believe one thing, when the top managers intend something else, something very unfriendly and sneaky.

For example, Microsoft employees believed that they would be allowed to finish their work. But, in spite of strong opposition inside Microsoft, Windows Vista was released.

Other products released before they were finished:
Windows XP (Okay after SP2, a lot of grief before)
Windows ME
DOS 3.0

Since Microsoft has acted against the best interests of its customers in many ways in the past, people think that will happen this time.

I listened to this interview of you: Sam Ramji of Microsoft Tells all. It's obvious that you are intelligent and well-meaning. I would tend to trust anything you say if you have control over it. However, I think it is likely that you have no control. I'm guessing that it is likely that some vicious Microsoft top manager has some plan to cause trouble.

Why do I think that? Because sneaky behavior by Microsoft has cost me tens of thousands of dollars over the years.

Personally, I'd have to agree that ZFS is probably the way forwards for storage at the moment. I've not tried FUSE yet, although I have looked into Solaris and Nexenta, installing them on virtual machines for testing (I want to ensure my backup is stable, and want to put it through its paces before I setup what will be my next server).

Once you realize that ZFS can run Raid-Z in a system on chronically faulty hardware, and it still loses no data, then you understand that any other storage methods (bar possibly online backup) are second-class in comparison.

there are only 2 other major OS makers who are publicly traded, that are in competition to RH

HPQ HP-UX
ORCL Solaris
IBM AIX
NOVL SUSE

Looks like Red Hat has plenty of competition. Red Hat's business performance selling support services for their distribution of linux has been outstanding and their inclusion in the S&P 500 is well deserved.

Why has Sun Microsystems not done particularly well in the last few years? Why are they finding it necessary to sell themselves to Oracle? My theory is that the highly reliable hardware Sun Microsystems sells is no longer popular because it is far cheaper to use consumer-grade hardware with software that is fault-tolerant. The excellent 2008 book Planet Google describes Google's experiences on page 54: "For about $278,000 in 2003, [Google] could assemble a rack with 176 microprocessors, 176 gigabytes of memory, and 7 terabytes of disk space. This compared favorably to a $758,000 server sold by the manufacturer of a well-known brand, which had only eight multiprocessors, one-third the memory, and about the same amount of disk space."

Why would Oracle buy Sun? Possibly because there are difficulties in making Oracle database products work with the new fault-tolerant technology. For example, fault-tolerant technology may require performing all database modifications on 4 computers at the same time, and Oracle may not want to sell 4 licenses for one application at the same price as the 1 license used with the more expensive high-reliability equipment.

What are your ideas about the sale of Sun, and Oracle's interest? There are many people with far more knowledge about this than I have.

1) http://www.theserverside.com/news/thread.tss?thread_id=46887
2) http://weblogs.java.net/blog/alexwinston/archive/2005/04/strongly_types_1.html
3) http://www.developer.com/java/other/article.php/3300881 ?
4) http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html
5) http://java.sun.com/j2se/1.5.0/docs/guide/reflection/proxy.html ?

Absent? (Admittedly, I don't code in Java, but I got those links just by googling all your points.)

1) http://www.theserverside.com/news/thread.tss?thread_id=46887
2) http://weblogs.java.net/blog/alexwinston/archive/2005/04/strongly_types_1.html
3) http://www.developer.com/java/other/article.php/3300881 ?
4) http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html
5) http://java.sun.com/j2se/1.5.0/docs/guide/reflection/proxy.html ?

Absent? (Admittedly, I don't code in Java, but I got those links just by googling all your points.)

They mean the java.lang.OutOfMemoryError I am sure

Yech. It requires reading the file twice, and it's not even 100% reliable.

AFAIK it's not possible to do it in a 100% reliable fashion, but there are technical solutions where the file doesn't need to be read twice. Java, despite all of its flaws, handles this sort of thing pretty well, so I'll use that as an example.

In Java, there is a distinction between byte-based and character-based I/O. InputStream and OutputStream are byte-based I/O classes; Reader and Writer are character-based. Then you have classes like InputStreamReader that bridge the two worlds; an InputStreamReader is a reader that pulls bytes from an InputStream and passes them through a CharsetDecoder to converts them to the system's internal string representation (which is UTF-16).

So in Java, to read and validate the file in one pass, you just need to hook up your InputStream/InputStreamReader/CharsetDecoder pipeline so that the decoder throws an exception when the file does not conform to the encoding. This is one of various built-in strategies for CharsetDecoder; others are to ignore the invalid data and try to recover, or to insert some predefined character.

People coming from Perl or similar systems, when they see this for the first time, tend to think that this is much too complicated, especially when they notice all the associated extra classes like CoderResult and CodingErrorAction. It might be a bit more complicated than it needs to be, but certainly the best solution to reading characters from files is going to be more complex than what these people want.

Yech. It requires reading the file twice, and it's not even 100% reliable.

AFAIK it's not possible to do it in a 100% reliable fashion, but there are technical solutions where the file doesn't need to be read twice. Java, despite all of its flaws, handles this sort of thing pretty well, so I'll use that as an example.

In Java, there is a distinction between byte-based and character-based I/O. InputStream and OutputStream are byte-based I/O classes; Reader and Writer are character-based. Then you have classes like InputStreamReader that bridge the two worlds; an InputStreamReader is a reader that pulls bytes from an InputStream and passes them through a CharsetDecoder to converts them to the system's internal string representation (which is UTF-16).

So in Java, to read and validate the file in one pass, you just need to hook up your InputStream/InputStreamReader/CharsetDecoder pipeline so that the decoder throws an exception when the file does not conform to the encoding. This is one of various built-in strategies for CharsetDecoder; others are to ignore the invalid data and try to recover, or to insert some predefined character.

People coming from Perl or similar systems, when they see this for the first time, tend to think that this is much too complicated, especially when they notice all the associated extra classes like CoderResult and CodingErrorAction. It might be a bit more complicated than it needs to be, but certainly the best solution to reading characters from files is going to be more complex than what these people want.

Yech. It requires reading the file twice, and it's not even 100% reliable.

AFAIK it's not possible to do it in a 100% reliable fashion, but there are technical solutions where the file doesn't need to be read twice. Java, despite all of its flaws, handles this sort of thing pretty well, so I'll use that as an example.

In Java, there is a distinction between byte-based and character-based I/O. InputStream and OutputStream are byte-based I/O classes; Reader and Writer are character-based. Then you have classes like InputStreamReader that bridge the two worlds; an InputStreamReader is a reader that pulls bytes from an InputStream and passes them through a CharsetDecoder to converts them to the system's internal string representation (which is UTF-16).

So in Java, to read and validate the file in one pass, you just need to hook up your InputStream/InputStreamReader/CharsetDecoder pipeline so that the decoder throws an exception when the file does not conform to the encoding. This is one of various built-in strategies for CharsetDecoder; others are to ignore the invalid data and try to recover, or to insert some predefined character.

People coming from Perl or similar systems, when they see this for the first time, tend to think that this is much too complicated, especially when they notice all the associated extra classes like CoderResult and CodingErrorAction. It might be a bit more complicated than it needs to be, but certainly the best solution to reading characters from files is going to be more complex than what these people want.

Yech. It requires reading the file twice, and it's not even 100% reliable.

AFAIK it's not possible to do it in a 100% reliable fashion, but there are technical solutions where the file doesn't need to be read twice. Java, despite all of its flaws, handles this sort of thing pretty well, so I'll use that as an example.

In Java, there is a distinction between byte-based and character-based I/O. InputStream and OutputStream are byte-based I/O classes; Reader and Writer are character-based. Then you have classes like InputStreamReader that bridge the two worlds; an InputStreamReader is a reader that pulls bytes from an InputStream and passes them through a CharsetDecoder to converts them to the system's internal string representation (which is UTF-16).

So in Java, to read and validate the file in one pass, you just need to hook up your InputStream/InputStreamReader/CharsetDecoder pipeline so that the decoder throws an exception when the file does not conform to the encoding. This is one of various built-in strategies for CharsetDecoder; others are to ignore the invalid data and try to recover, or to insert some predefined character.

People coming from Perl or similar systems, when they see this for the first time, tend to think that this is much too complicated, especially when they notice all the associated extra classes like CoderResult and CodingErrorAction. It might be a bit more complicated than it needs to be, but certainly the best solution to reading characters from files is going to be more complex than what these people want.

Yech. It requires reading the file twice, and it's not even 100% reliable.

AFAIK it's not possible to do it in a 100% reliable fashion, but there are technical solutions where the file doesn't need to be read twice. Java, despite all of its flaws, handles this sort of thing pretty well, so I'll use that as an example.

In Java, there is a distinction between byte-based and character-based I/O. InputStream and OutputStream are byte-based I/O classes; Reader and Writer are character-based. Then you have classes like InputStreamReader that bridge the two worlds; an InputStreamReader is a reader that pulls bytes from an InputStream and passes them through a CharsetDecoder to converts them to the system's internal string representation (which is UTF-16).

So in Java, to read and validate the file in one pass, you just need to hook up your InputStream/InputStreamReader/CharsetDecoder pipeline so that the decoder throws an exception when the file does not conform to the encoding. This is one of various built-in strategies for CharsetDecoder; others are to ignore the invalid data and try to recover, or to insert some predefined character.

People coming from Perl or similar systems, when they see this for the first time, tend to think that this is much too complicated, especially when they notice all the associated extra classes like CoderResult and CodingErrorAction. It might be a bit more complicated than it needs to be, but certainly the best solution to reading characters from files is going to be more complex than what these people want.

Yech. It requires reading the file twice, and it's not even 100% reliable.

AFAIK it's not possible to do it in a 100% reliable fashion, but there are technical solutions where the file doesn't need to be read twice. Java, despite all of its flaws, handles this sort of thing pretty well, so I'll use that as an example.

In Java, there is a distinction between byte-based and character-based I/O. InputStream and OutputStream are byte-based I/O classes; Reader and Writer are character-based. Then you have classes like InputStreamReader that bridge the two worlds; an InputStreamReader is a reader that pulls bytes from an InputStream and passes them through a CharsetDecoder to converts them to the system's internal string representation (which is UTF-16).

So in Java, to read and validate the file in one pass, you just need to hook up your InputStream/InputStreamReader/CharsetDecoder pipeline so that the decoder throws an exception when the file does not conform to the encoding. This is one of various built-in strategies for CharsetDecoder; others are to ignore the invalid data and try to recover, or to insert some predefined character.

People coming from Perl or similar systems, when they see this for the first time, tend to think that this is much too complicated, especially when they notice all the associated extra classes like CoderResult and CodingErrorAction. It might be a bit more complicated than it needs to be, but certainly the best solution to reading characters from files is going to be more complex than what these people want.

Problem is those methods of dropping the weight, also increase the cost (TFA assesses both). In the case of 3.5" SATA HDDs, that weight/cost should include a storage system that renders all the data available at the same time. 140 Lbs for 48 Hard drives is reasonable.

Off the wall idea but how to store a petabyte for near very few kilos and it scales up. Place mirrors in space, from a satellite fire a laser for 10 light seconds of 1 PB of data into space at the mirror. When it comes back send it out again. While 1 PB goes out, the other PB comes back. Create as many steams you want. Near infinite storage. Only hitch is if the relay loop is broke, there goes the data as your not likely to catch up to it. Next issue is random access is 0 to 20 seconds. That is, use light in outer space.

Problem is those methods of dropping the weight, also increase the cost (TFA assesses both).

My problem with the assessment however, becomes even more glaringly obvious when you look at the micro SD proposal in the grandparent. If you are going to have a single SD card reader and plug these cards in as needed, the weight estimate is ok. If however all 1 PB of data must be immediately available to your software, the weight gos up dramatically.

In the case of 3.5" SATA HDDs, that weight/cost should include a storage system that renders all the data available at the same time. 140 Lbs for 48 Hard drives is reasonable.

Depending on your RAID Level, 1,500 Lbs per petabyte is closer to reality. 1,700 Lbs to 2,000 Lbs per petabyte if you add the rack to the equation.

BTW: Doing something sane, like RAID, instead of JBOD or RAID 0, will increase that mass somewhat.

Sun has committed only to not asserting patents against their own GPL implementation; any other implementation is fair game for their intellectual property lawyers.

Not true, as far as I can see: the Java SE licence says 'Sun also grants you a... license... to create and/or distribute an Independent Implementation of the Specification...'. From my reading of the legalese it seems that any compliant Java implementation is covered.

But remember that not only Sun owns software patents which cover your Java program, and not only Microsoft owns swpats covering your .NET program. A legal risk assessment is not merely an evilness competition between Microsoft and Sun!

Isn't ReadyBoost essentially a hybrid system?

Also I rememeber that one of the main disadvantages of Btrfs over ZFS was that I doesn't support using SSD to speed up overall access, while ZFS does.

Hybrid systems are rare, and it doesn't look like they will become more common.

You're probably right when we talk about desktop PCs and laptops. I'm sure the latter will be SSD only in 5-10 years time, and desktops are also losing terrain quickly against laptops.

But when we look at datacenter grade enterprise storage, hybrid systems are currently picking up fast. The advantage is that because of the fast 'flash memory cache' you can use SATA disks instead of the FC/SCSI drives, where the former are both much bigger and much cheaper. Instead of 300 146GB 15K FC disks, you only need 30 1.5 TB 7200 RPM SATA disks. For the same capacity this results in much lower power bills, less DC floor-space costs and much better performance.

If you say "There are some hybrid SAN's, but they're damn expensive.", have a look at what [shameless plug-on] Sun is doing, and yes, I work for Sun [plug-off]. But other storage vendors (NetApps, EMC, IBM, etc.) are starting to do similar things.

So the whole "storage-stack" gets more and more hybrid and integrated. It consists of the full gamut of DRAM, flash memory, hard drives and finally tape. Each of these have their own strength and are used best in combination.

I'd suggest that they are likely to grow to being an important part of computing, but no bigger than, for example, the large-server-and-Oracle part. (full disclosure: I'm a capacity planner, so most of my income comes from just that part).

The disadvantage is that my cost per transaction is greater than if I had a steady load and ran my own machine room. The fees I and the other customers pay a cloud service have to cover their whole machine room, whether it's it's busy or not, plus their profit.

So I see a natural evolution for a growing business. While they're small, they'll build a LAMP or Java stack on a small machine in the back room. If they grow slowly and steadily, they'll buy more, larger machines for the back room. If they grow without bound, they'll jump to LAMP-on-cloud or Java-on-a-cloud, with a few code changes as possible.

Once they have mastered that, they'll move back and forth, depending on the business growth rate. If they grow too fast, they'll do a lot in the cloud. If they grow slowly, they'll have a cloud presence, but try to process as much in their own machine room as they can, to improve the profit margins, using the cloud for overflow and to run during my machine-room upgrade.

Conclusion? common software between the cloud and the machine-room is important. Look for any standards developing in the LAMP/SAMP space, like the DMTF incubator at http://www.dmtf.org/about/cloud-incubator Look for Java offerings for business, like http://blogs.sun.com/cloud/entry/communityone_cloud_recap When you're there, specifically look for virtual machines that will run in the cloud. Finally, look for load-balancing mechanisms that will send your work to two different places, under your control, sometimes called "application distributors".

Don't assume open source is at a disadvantage: if you can run your stack on a free VM on a standard-conforming cloud, however commercial it might be, then your computing can remain free of the control of others.

--dave