a-splunking we will go
is just out, and I thought I'd give it a go. I've just finished downloading the thing on to one of our servers. It is now 23:47 and the download took a whole 3 minutes.
I'm doing the "look mom, no wires" installation kind, no manual, no nothing, just to see how it goes.
we start off by chmod a+x splunk-2.0.1-linux-installer.bin , and then ./splunk-2.0.1-linux-installer.bin
Licenses... oh well... let's just say "yes", shall we?
The defaults are pretty sensible for a test install. The only thing I changed was where it asked me how much free space to leave on the device.
It seems to be installed and running, and the whole process took less than 10 minutes, download included.
I'll let you know in the morning how fun it is to use.
The Decaffeinated Penguin - thoughts on Java and Linux
James Governor commented on Java and Linux
, and it stirred up a few thoughts.
I remember only too well how the Java/Linux relationship started. It started when Sun wouldn't make a JRE, let alone a JDK for Linux.
So the Open Source movement, as always, routed around them. Some went on to develop things like Kaffe, an open source Java runtime. But it was always a work-in-progress, sometimes slow, sometimes a bit buggy. But it gave most people the impression, in those earlier days, that Linux wasn't really the platform for Java.
Where does that lead you? Windows. You see, the problem with Solaris is that most developers don't have a Solaris box sitting on their desktop, or under their desk. Solaris boxes are kept by systems administrators, and tend to be used primarily for "enterprisey" projects, which doesn't really include installing a new language and environment and fiddling around with it to see what you can do with it. So the kind of machine the average developer has unfettered access to is, of course, Windows or Linux. Of course today you can run Solaris x86, but not when all this was happening. A couple of years ago Solaris x86 was something of a non-supported product, always rumored to be discontinued with a hardware compatibility list that could fit on the back of a business card.
And since they had no option, developers went on to install Java on Windows, and to develop on Windows, and to deploy on Windows. Sun did that, by merely not supporting Linux early enough.
Now Sun comes talking about Java and Linux. Well, they're a bit late, and they'll have to run a bit to catch the train. Without Linux, the Java community has pretty much settled on Windows ou Unix. And without Java, the Linux community has pretty much settled on whatever other language they choose, Perl, Python, Ruby, PHP, C.
Making developers turn to Java on Linux is probably going to take something more than just hype. You can make it as god as any other platform, it still won't be a reason to switch. You have to make it run better on Linux than it does on Windows, aim for better integration with the kernel API, aim for speed, aim for integration of the Java toolset with other GNU/Linux tools.
Jaime Cardoso was commenting, on an unrelated matter
, that the "if you build it, they will come" motto wasn't really true. Actually, I think he's wrong, I still believe that if you build it, they will indeed come, if:
- if they aren't diverted into something else that has better promotion than you
- if they aren't already somewhere else
Java on Linux suffers from both these problems. The Java developer community isn't all made of fresh-out-of-college junior programmers. Some of the people in the community have been around as long as I have (does anyone still remember Duke?) and were hurt by the no-Java-on-Linux decision Sun made early on. So going back isn't really "the thing we have been hoping for all our lives". We were hurt, and moved on. So we are already somewhere else.
As for the new programmers, Java has a lot to compete against. Windows on one side, with C# and .NET and flashy McDonalds Certified Food Specialist titles that look good to a 19-year-old. Python and PHP and Ruby on the other side, with the save-the-world-in-4-lines-of-code-and-get-a-free-model-train approach.
So where does that really leave Java? What is the competitive advantage of Java nowadays, other than being taught at schools?
The "write once, run anywhere" ideal will not suffice. Portability is nice, but most client Java solutions have problems whenever they touch the graphics subsystem - slow, have to be "tuned" for different platforms, etc., and most server-side solutions aren't just designed to go around running "anywhere". And you can still run PHP or Perl pretty much as "anywhere" that you can run Java - I know, different languages, different features sets, different approaches. But still I don't see programmers flocking to Java and away from Ruby and friends.
Mobile devices come to mind. But where does MIDP come into the Linux equation, if anywhere?
So let me know if I'm wrong, but Sun's current "Java on Linux" drive is just too little, too late.
In reply to a post on James Governor's blog, I ended up writing what would seem to be a "defense" of Web Services versus more "pragmatic" approaches such as REST. I'm transcribing the full comment here, but allow me to clarify:
I've gone to the point of believing that a bad standard is better than no standard. Choice is good, but I'd like to see convergence just for a couple of years, and then see choice again, and evolution in standards. Right now, I just wish things would interoperate without needing two completely separate interfaces, one to deal with WS-*, another to deal with REST - and sometimes yet a third and a fourth to deal with still some other interfaces.
The post is as follows:
Disclaimer: most of my work life was spent in banking and insurance. YMMV in other industries, I've been involved in some areospace projects, sattelite data collection and such, and in a number of telco gigs, and REST does seem more appropriate in those environments. But today I'm writing from a financial services point of view.
Even for read interfaces there are - more often than not - security requirements. Not everyone can read all data, not all servers can consume all interfaces, some people have access to aggregate figures but not to individual items. And with this need for control - be it real or just perceived by the users, but, after all, they're your customers, most people don't just code for fun - there comes a need to make control centralized and enforcable. It just doesn't make sense to have every single application, every single service, every single datasore implement their own versions of access control, permissions, data visibility, and auditing.
I agree that WS-* is something of a mess. It was designed by commitee, it was design with no regard for practicality, I know all the excuses. But the same problems have existed in all call interfaces that came before, and most of the time it was even worse. Having a bandwagon join behind WS-* would, at least, have the benefit of doing what CORBA could not do, defining a worldwide call-interface standard.
But, as I've said so many times, the "good" thing about standards is that there are always (at least) two (thinks ASCII and EBCDIC, 220 and 110 volts), and human kind has again fulfilled this promise. Even before WS-* was fully deployed and understood, a number of "smart" fellows decided they could always "cut some corners" and came up with REST. Of course it's potentially slower. Of course it's more complicated. If I think about solving only MY problems I can always come up with something faster and easier.
But it doesn't cover a lot of people's needs - needs that have driven WS-* to be - at least partly - as not-simple and not-fast and not-easy as it is. And it's because of those people that REST can not be a universal solution - unless people start grafting other features upon REST, and end up having another WS-*, which they will always claim is better, because it's their WS-*, not someone else's.
Some of us have been around long enough to see all this happen before. Me, i'm still an optimist at heart. I really had hopes that WS-* could be "the one to rule them all". Not that I like it, but I was willing to concede personal liking to standardisation. Apparently, a lot of people didn't agree. Another chance missed - history, again, repeats itself.
Too many things, too little time, and a bit of the flu prevented me from posting in the last few days.
In these days, Johathan Schwartz suceeded Scott McNealy as CEO of Sun.
from a geek
point of view, it's a step in the right direction, I'm not sure how it will turn out from a market point of view. It still sounds solid, I mean, it's not like they're turning the company over to Bill Joy or something (not that I don't admire Bill Joy, it's just that there's always a risk capital in putting too much power in the hands of editor frontmen...)
In other news, Apple is interested in porting ZFS to MacOS X
. Probably the best move they could ever do in the filesystem arena, combining what is starting to become the world's most interesting operating system with the worlds definitely most interesting filesystem implementation. These are good times to live in.
Yet in other news, we have three totally unrelated events, some of which may interest you in participating:
DARPA is issuing the call for the 3rd Grand Challenge
; this time, the robots invade the cities :)
Closer to home, Red Bull (the soft-drink manufacturer) is hosting the 2nd Flug Tag
in Lisbon, Portugal. If you can't afford a DARPA robot-car, build a plane and crash it into the sea ;)
If you are not of the building inclination, and would rather sit on a sofa, the Vodafone Best Seat Sofa Race
may just be the thing for you. They provide you with the sofa, you just have to talk two friends into pushing you around, and off you go.
There are your options, now don't complain you have nothing fun to do this summer.