2015-10-31
One advantage of System V is that it was available
I mentioned recently that even though I have a negative view of System V, it made its own contributions to Unix. There are a number of technical contributions, but one of the under-appreciated things it did was simply that System V was available.
The reason that Unix vendor after Unix vendor used System V is in large part because AT&T made it available for licensing. My understanding is that it was even licensed on relatively generous terms; it didn't cost particularly much money to get a source license with binary redistribution rights, and AT&T mostly let you do whatever you wanted with the result without many restrictions. The results of this is that from the mid to late 1980s onwards, Unix versions flourished everywhere, from the small to the large. We probably would not have the broad Unix ecology we do today if AT&T had tried to be more restrictive.
This is all the more noteworthy because AT&T itself was in the business of selling Unix machines for much of this time, and they weren't particularly successful machines either. AT&T undercut its own Unix server business by selling AT&T Unix licenses to direct competitors who then generally offered better products with it.
(Although I don't know for sure, I don't believe that AT&T required things like per-system royalties in its commercial Unix licenses.)
Now, I don't know how much money AT&T earned from its Unix licensing business. But either way, AT&T made an unusual decision to let its server hardware business suffer when it might well have been able to give it a hand, a decision that many companies have decided differently. The result of AT&T's decision here drastically helped Unix spread, especially in the basic server market that became the bread and butter of many Unix vendors.
So, regardless of what I feel about System V at a technical level, I have to respect it simply for being available, for being out there in the world and introducing a great many people to Unix.
In practice, anything involving the JVM is often a heavyweight thing
Last week I asked on Twitter if anyone had a good replacement for swish-e for indexing and searching some HTML pages. Several people suggested Apache Solr; my immediate reaction was that this sounded too heavyweight for what we wanted. It was then asserted that Solr is not that heavy if you disable enough things. I had a number of reactions to that, but my instant one was 'nothing involving the JVM is lightweight'. Today I want to talk about that.
I don't call JVM-based things 'heavyweight' because Java itself can
easily eat up lots of memory (although that's certainly a potential
issue). What makes the JVM heavy for us is that we don't already
run any JVM-based services and that all too often, Java is not like
other languages.
With languages like Python, Perl, Ruby, or even PHP, as a sysadmin
you can generally be pretty indifferent to the language the system
is written in. You install the system (ideally through a package
manager), you get some binaries and maybe some crontab jobs, and
you run the binaries. You're done. With Java, my impression and to
some extent my experience is that you also have to administer and
manage a JVM. A Java system is not run some programs and forget;
it's putting .jars in the right place, it's loading certificates
into JVM trust stores, it's configuring JVM parameters, and so on
and so forth. There is a whole level of extra things to learn and
things to do that you take on in order to maintain the JVM environment
for the system you actually want to run.
(One way to put it is that a JVM seems to often be a system inside your normal system. You get to maintain your normal system and you also get to learn how to maintain the JVM system as well.)
All of this makes any JVM-based system a heavyweight one, because adopting it means not just learning the system but also learning how to manage a probably-complex JVM environment. If we were already running JVM based things it would be a different issue, of course, because we'd probably already have this expertise (and the JVM way might even work better for us), but as it stands we don't.
(Similar issues probably hold for any Node-based system, partly because of Node itself and partly because Node has its own very popular package management system that we'd probably have to learn and wrangle in order to run any Node-based thing.)
It's probably possible to design JVM-using systems that are not 'JVM-based' in this way and that encapsulate all of the complexity inside themselves. But I suspect that something labeled on its website as 'enterprise' has not been designed to operate this way.
(I've mostly talked about the JVM instead of Java specifically because I suspect most of these issues also apply to any other JVM-based language, such as Scala, Clojure, and so on.)