Where else in your organization do you use open source or might you use it? Any desktop Linux plans?
I run rdesktop into Terminal Server, which gets me into the regular Office stack, which is great. It works fine. We keep on thinking about, for instance, our customer service reps. They run an internal tool thats called Genie, and its all Java-based, so we keep kicking around the idea of starting up a project to run a Linux distro desktop.
Im a fan of KnoppixI think it could just run off a CD. There are so many compelling reasons to do so from a security defense perspective. You try to send an attack on a Knoppix system and youre attacking RAM, not a hard drive. So thats something we keep kicking around. Id say theres a very high likelihood we kick something off in 2006 in that regard.
The savings for desktop Linux probably wouldnt be as dramatic as they were for the data center. What other motivations would lead you to adopt desktop Linux?
No, the economy of scale isnt there. But its good organizationally, because we run a common technology stack, and the technical community at E-Trade can build up better, more detailed knowledge about one system. We have to know how to defend a Linux deployment on the Internet, for instance, and we have to know how to defend a Microsoft deployment on the desktop.
Some of those defenses are common between the two, and it just seems to make sense that if Im committed to the Linux server strategy in my production system, for our customers, it would make a lot of senseorganizationally, technicallyto use the same defense strategy for my associates.
Youre running Red Hat AS. Are you happy with it? Have you thought of moving to another distro? Maybe a non-commercial one?
All the time. One thing I do like is what Red Hat does from a distro point of view: They establish a distro (and when I say distro, I mean a set of packages that are thought to be compatible), and then the open-source guys will keep moving along, and they frequently will backport bug fixes from the top of tree back into their more stable base of packages.
All the Linux distros do a very good job at this style of taking something that, almost by definition, has a change rate thats almost too high for an enterprise to deal with and kind of cherry-picking and going back into a set of packages that are somewhat frozen. Youre not doing functional improvement on that distro, youre doing defect fixes.
So it seems to be a good way to balance the change rate and stabilitykind of a happy go-between. Weve tested SUSE, and its great. Weve tested Red Hat, and its great.
Are you using the Apache that Red Hat is shipping as part of the distro? What pieces are you customizing, and where are you sticking with the distro makers packages?
There is a feature that wasnt supported in the Red Hat distro that my application needed, so Im now creating my own Apache package, immediately.
We have a package management and deployment methodology that predates RPM. In 1999, we were buying lots and lots of Sun hardware, to keep up with the dramatic ramp-up in business. As soon as the boxes came off of the dock, we already had the configuration ready, so the machine would be plugged in, go through a stress test to make sure it didnt do out-of-box failure, and then we would push the application stack to it and the configuration to it, put it in the load balancer, and itd be trading.
This methodology is still consistent today on the Linux stack.
When you go to smaller packages of code, you have to get the dependency chaining right. Your organization has to be able to assert, I depend on our ID tool 1.2.whatever, right? And then somebody else, maybe in QA or maybe ops, This version of our ID tool doesnt work right; you need a different version.
And so you need a community process for defining the distromeaning, the set of packages that are thought to work togetherwhich is exactly what Gentoo does, a community process for establishing a distro.
The development process.