

Ask News.YC: Opinions on Linux distros, Helma, Java Frameworks - Shooter

I've predominantly used Solaris/BSD on projects in the past (and then had Linux administrators take over if/when we had to deploy to Linux.)  I now have a project that will require that I deploy on Linux initially, and I wanted to solicit input on which distro is best for server deployment.  I'm looking for SERVER strengths, not desktop strengths.  The only firm requirement is Glibc 2.3.  We will be deploying to both x86-64 and PPC-64 if that is an issue.  We use Python, Erlang, and Lisp for MOST projects, and I know Debian is popular in those communities.  Any recommendations?<p>Also, we have an upcoming project that will require that we use Java for a portion of it.  I have always been able to avoid using Java in web apps, but this project has to tie into a bank's existing infrastructure. We're looking at Seam, Rife, and Wicket.  (Relative) flexibility is important to us.  (Relative) elegance is important to us.  Any recommendations?<p>Finally, I was curious if anyone has used Helma?
======
aaroniba
We use Helma for our (unlaunched) YC startup, and we love it.

It's faster than rails, and IMO nicer to develop with. Having all the Java
libraries without having to code in Java is sweet. The ORM is really well-
designed and the built-in object cache is super fast. The template system has
its quirks, but once you get used to it, is also really sweet.

It's a shame helma wasn't documented or evangelized as well as rails was. I
think it's a better framework that just didn't catch on because it wasn't
marketed well.

~~~
michaelneale
Well when you launch, PLEASE make heaps of noise about Helma - I think it
would be great for both you and helma to do this (kind of like rails was for
37S in a way). It really does sound sweet.

------
kashif
Debian Etch for Server, ubuntu or kubuntu for desktop.

In my experience, any RPM based system is a strict no-no - like Red Hat,
CentOS.

~~~
breck
Ubuntu is solid. Haven't tried Debian Etch or kubuntu yet. I would recommend
Fedora 7 for desktop as well. I have had success with RH and CentOS.

My suggestion: get VMWare Player and play with a bunch of them for fun. Kind
of inefficient, but it's cool if you like that sort of thing.

------
midnightmonster
I've deployed one production Helma site <http://preachingtheword.net/> for a
client. I have been a PHP developer for many years, but I have switched to
Helma for all new work. (I spend a lot of time maintaining and repairing other
people's PHP sites, and my current new projects are relatively large, so
that's why there's only the one so far.)

I care about the Java-ness of Helma principally b/c it lets me leverage a
gazillion existing libs if I need to. But my experience programming Java
itself is limited to writing a client/server othello game just to explore, and
I have no legacy Java systems to integrate with, so I'm useless on that score.
I was already a very competent JavaScript hacker (and love the language)
before I started with Helma, but only in the browser till now.

preachingtheword.net probably took me longer with Helma than it would have
with PHP, but I'm pretty sure that's all down to first project vs. years of
experience and my own framework. Of course I haven't actually written the same
site in PHP, so it's hard to be sure, but I believe my LOC are way down and I
know that my mental grasp of the project at all levels is better.

I'm only just getting into the ORM--I actually did preachingtheword.net
entirely with the built-in object DB. My feeling so far is that the ORM is not
particularly interesting--it's more the mapping of objects to URLs that's
unusual and brilliant (different from and better than the one in my PHP
framework and in other frameworks I've seen). For the ORM, I think SQLAlchemy
is more powerful and flexible in useful ways, but Helma 1.7 (under
development) is planned to have some new power and flexibility in that regard.
(Still.not as powerful as SQLAlchemy... maybe time to port?)

If you use the ORM all the time you are, of course, protected from SQL
injection and Helma does some smart things with caching and lazy-ish
retrieval, but if you need to run arbitrary queries the provided DB lib is
woefully underpowered with no support for parameterized queries or retrieving
results any way other than all at once. I plan on doing something about that
myself in the course of this next project. (The DB lib, similar to most Helma
libs, is a JavaScript wrapper around JDBC, so the power is there, but it's
been over-simplified away.)

I think the templating system in Helma ("skins") is insightful but doesn't go
far enough and makes some wrong decisions. I'm not using it in my projects in
favor of using E4X throughout, which gives me XML as a native data type in a
way not possible in any other language. E4X itself is a sometimes-frustrating
mixture of brilliance and madness, but one thing it gets 100% right is the
basics of templating: Among other things, you get perfect, no-thinking
protection from XSS and other HTML screw-up attacks automatically just by
doing the most obvious and reasonable thing. To me, that's extremely valuable.

E4X is just the biggest of many cool recent JavaScript features that you can't
use in the browser b/c on Firefox supports them, but you can use them in
Helma.

------
davidw
Sounds like a bit of a mess trying to deploy lots of different components to
different architectures. Debian sounds pretty good. I like Ubuntu because I
run it on both the server and desktop, so it's easy to have the same
environment everywhere.

~~~
Zak
Ubuntu also has a more predictable release schedule than most distributions -
especially Debian. I have yet to try the server version. How does it compare
to Debian? Unfortunately, Ubuntu server doesn't support PowerPC, which the OP
says is a requirement.

~~~
irrelative
In my experience, Ubuntu server has been very similar to my Debian server work
(I love apt package management). I'm currently using Dapper on the server
since it's going to be maintained for a very long time.

Ubuntu has a more predictable release schedule, but I wouldn't recommend
pushing the limit on upgrading your server. Unless you've got a lot of spare
time you'll want to use a fairly mainstream distro. When a nasty problem comes
up (and it will, trust me), you want access to lots of forums that show
solutions to related issues.

Some general advice (not really directed towards the parent): Just because you
know how to run something like Gentoo doesn't mean you necessarily should in a
production setting. Once you have a successful company you can worry about the
benefits of compiling your filesystem from scratch. Pick an OS you're familiar
with and run with it -- anything else is most likely premature optimization.

------
tmm1
I'm a big Gentoo fan, and if you've used BSD's ports you'll like Gentoo's
portage

~~~
qaexl
I'm also a big Gentoo fan.

I never used BSDs much, though I imagine you would be familiar with the
following:

\- With Gentoo you would be able to setup masks for a specific version of
glibc and compile everything against it, stage the binaries and distribute
them en mass to the other systems. This would allow you to stay with a
specific version of a library and less dependent on the whims of the distro
staff.

\- You also have the option of using a cluster of compilers to compile the
packages, though you may not want your production machines to be a part of the
cluster.

\- You have control over the CPU optimization flags.

\- You have control over package features. This is the equivalent of turning
them on or off with ./configure --enable-xxxx, but it is abstracted away into
USE flags.

\- Each package is downloaded from upstream, sometimes with Gentoo-specific
patches applied to them. In otherwords, you have access to pristine sources as
the authors intended.

\- You can also define an "overlay" so you can write your own custom ebuilds,
should you have specific patches you want to apply to any or all of the
packages

\- You can use the overlay to do an internal release of your proprietary
software using Portage. You can define package dependencies with your
proprietary software.

It is a lot more work than setting up a Debian or an Ubuntu box, but you also
get more control.

------
staunch
CentOS is a great option. It's simple, reliable, and theres lots of
documentation written for it. By far the most popular option for hosting these
days. I recommend it to others. Debian is just fine too, but not my preferred
flavor. When I'm building large clusters of machines I use one build "master"
machine (Gentoo based) that produces the binaries, libraries, and kernel that
the other identical machines run.

------
schmoe
I prefer CentOS (<http://www.centos.org>) as a server OS. It is well tested,
secure, and reasonably up to date. CentOS is very nice for the sysadmin:
configuration is well thought out, handy utilities like "service" and
"chkconfig", automatic security updates, etc. Plus if you need support,
upgrading to RHEL is trivial.

Unfortunately I don't think CentOS is built for PPC.

------
Zak
Have you considered tying in your app by writing an API in Java and your app
in a different language? Have you considered using another language running on
the JVM?

~~~
Shooter
Yes, I've considered both. In fact, that's what we have always gotten away
with in the past.

Unfortunately, part of this project is tying into a bank's existing
infrastructure. And because of the sensitive nature of the 'components' we are
tying into, they are requiring that that specific portion of the app be
written in Java (in part so that their in-house programmers can go over the
code with a fine-tooth comb.)

------
tedchoward
I've been using CentOS for my linux server os. I'm a little partial to
ThinWire (thinwire.com) for a Java web framwork. Never used Helma, looks
interesting.

------
falsestprophet
I think that something with BSD-style ports is crucial.

