Ask News.YC: Opinions on Linux distros, Helma, Java Frameworks
19 comments
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.
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.
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.
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.
In my experience, any RPM based system is a strict no-no - like Red Hat, CentOS.
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.
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.
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.
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.
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.
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.
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.
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.
I'm a big Gentoo fan, and if you've used BSD's ports you'll like Gentoo's portage
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.
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.
Another benefit of Gentoo is the wealth of knowledge you'll find at http://gentoo-wiki.com and http://forums.gentoo.org . Additionally, the portage system makes everything rather easy to do, once you get the hang of how it all works. Is a certain version of a library causing a problem in a program? Just mask that specific version and run a single command to re-install to a different version of the library and update all programs that depend on it.
I started with FreeBSD and switched to Linux when I couldn't get proper drivers. I didn't like Ubuntu or Debian, but I've been quite happy with Gentoo, and I'm getting ready to put it on my third computer.
I started with FreeBSD and switched to Linux when I couldn't get proper drivers. I didn't like Ubuntu or Debian, but I've been quite happy with Gentoo, and I'm getting ready to put it on my third computer.
The author didn't specify how large his project was. If it involves a lot of servers then Gentoo's ability to basically "make your own distro" could prove very useful. You can't get much more flexible than that. Since the OP is coming from a BSD background that is an advantage for Gentoo as well.
On the other hand if the project just involves a small number of servers than Gentoo will likely prove more hassle than it is worth. In that case the conventional wisdom would be Debian. (or RHEL if you want to pay someone for support).
On the other hand if the project just involves a small number of servers than Gentoo will likely prove more hassle than it is worth. In that case the conventional wisdom would be Debian. (or RHEL if you want to pay someone for support).
Seconding this option. Gentoo is the way to go if you are used to BSD.
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.
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?
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.)
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.)
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.
I think that something with BSD-style ports is crucial.
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.
Unfortunately I don't think CentOS is built for PPC.
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?
Finally, I was curious if anyone has used Helma?