Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have written a number of C++ server side daemons for my website, using my Ubuntu 9.10 dev machine.

The C++ apps I mentioned above are "GUI-less" daemons (and libraries used by the daemons).

I am now about to host my website and need to decide whether to go with Debian server or Ubuntu server.

In a nutshell, here is the situation:

  • I developed on Ubuntu desktop because I preferred the more friendly GUI
  • I would like to deploy on Debian Server because of the (perceived?) robustness of the Debian server over Ubuntu server (I may be totally wrong here - and in fact, this is really what this question is all about)
  • If Debian server is indeed more robust than Ubuntu server, then I have no choice but to go with Debian server - BUT, will my Ubuntu developed C++ apps run on the server? (or do I need to recompile them on the server? (I'd HATE to have to do this, because I want to keep the server machine clean and light - no GUI, no dev tools etc). This last question is really about binary compatability between Ubuntu and Debian.

I want the server to be robust, secure and stable, and simply act as a server (i.e. LAMP and very little else - no GUI etc). Given that requirement, and the fact that I need to run my C++ apps (developed on Ubuntu 9.10),

I need advice on which OS to choose for the server. Ideally, any advice will be backed with a reason. I am particularly interested in hearing from people who have been in an identical situation, or done something similar.

share|improve this question

migrated from stackoverflow.com May 5 '10 at 4:42

This question came from our site for professional and enthusiast programmers.

8 Answers 8

Also, there seems to be a new "patch" every few weeks - which I would not like on a server (I want to leave the server well alone, and let it get on with its business of serving pages).

You're doing it wrong.

Debian stable has an excellent security policy, and if they offer a security update it means that they fixed some package that has a security flaw. You don't really have the option of not updating it, or you'll get hacked sooner or later.

Of course you could write a script that calls the updates and upgrades automatically every day, but you'd better pay personally attention to your server.

I dont want to be grappling with the learning curve associated with a new OS

ubuntu is just a modified debian for desktop use: likely you won't have any problem.

share|improve this answer
    
@Loris: The patches I was referring to are to do with Ubuntu, not debian –  skyeagle May 4 '10 at 9:29
1  
then you definitely want debian stable: they update on regular basis only security, and you get other updates only a few times a year. –  Lohoris May 4 '10 at 9:44
1  
No learning curve when switching from Ubuntu to Debian. It's pretty much the same thing. –  Antoine Benkemoun May 5 '10 at 7:45

My experience with Ubuntu and Debian would lead me to Debian on the server - they have far more of a focus on stable, solid releases and more of a history in the server space, and my experiences with Ubuntu have been pretty uneven.

That said, that's just my personal experience; I know there are people running server farms on Ubuntu, so it's not out of the question.

If you do chose Ubuntu, be sure to pick an LTS (Long Term Release), so you get bugfix/security support for 3-5 years, instead of 18 months in the regular Ubuntu releases.

Finally, Florian is quite correct that you're best off having a local environment that mirrors your production environment; the best way to achieve that is probably a Xen/KVM/etc guest with whatever your server is built with.

share|improve this answer
    
Rodger: What's a Xen/KVM/etc guest? –  skyeagle May 4 '10 at 9:50

Just an alternative to consider - run a small virtual machine in your Ubuntu host that runs a Debian server. The purpose of this is to generate Debian packages. You can pollute this VM with as many developer packages as you need and all the build tools necessary. Then, use the command line just to compile and build your package for deployment. Not the most elegant solution, but it should allow you to do 90% of your development on Ubuntu and deploy a binary package that definitely works on Debian.

share|improve this answer
2  
you're kidding, right? –  Lohoris May 4 '10 at 15:39
    
Nothing wrong with having a test machine to ensure that the app works in Debian before deployment. We cannot assume that a binary will work in Debian just because it works in Ubuntu. They may have different library dependencies. –  sybreon May 5 '10 at 1:10
    
This is the right way to go. Use Debian for compiling binaries and deploy them on the server. Use a vm, chroot, pbuilder, whatever suits you. –  ptman May 5 '10 at 6:31
    
What are you talking about, lol? Why should he bother creating a virtual machine to compile it, when he can compile directly on the target?!? –  Lohoris May 6 '10 at 17:10
    
he/she does not want to clutter his server with dev tools and stuff as stated in the OP. –  sybreon May 8 '10 at 7:54

In my experience it is better to have a server that does nothing but serve. By this I mean avoid desktop user interfaces on servers. You can do all you need with the command line, if you can't the app is not meant for the web server. This will increase stability and virtually nullify downtime, whilst also maintaining separation of dev/pub. Ensure that the apps you write are command line compatible and you should be golden for the daemons. If the app absolutely must have a UI, make the UI web based.

share|improve this answer

If I understand correctly, you mainly use the computer through the graphical UI, and I can guess you might be a bit lost in front of a command line only computer. It is true that the UI changes, but keep in mind that both use GNOME and are not so different. But it is true that Debian is more rough.

Regarding updates, Debian also has regular updates on its stable release, almost daily. As for binary compatibility, the best is to recompile your software for the target system you aim to deploy to, even if it should work as is, as long as the versions you use have about the same age.

With this in mind, I have about the same feeling that ubuntu may be a better route for you.

share|improve this answer

As Ubuntu is based on Debian the differences aren't that big (except for the GUI - but you won't use a GUI for you server, right?). If you can work on the command line with Ubuntu you can do the same on Debian.

On both Debian and Ubuntu you'll get only important updates, like security fixes, for the stables releases, so for the same software you should expect amount the same amount of updates on Debian.

Using the same system for development as you have on the server helps to avoid a lot of problems.

share|improve this answer

Ubuntu is Debian. Most things developed on Ubuntu should 'just work' on Debian. If you want stability you may want to look into Ubuntu's LTS (Long Term Server) which is designed to provide a longer period of stability than the regular six month release cycle that the regular Ubuntu Desktop release provides. Or you may want to look into Debian Stable. Currently Debian Stable is version 5.0 but a new Debian Stable will likely be released this year.

Debian Stable is very stable. It gets tested extensively for roughly two years before release and there are minimal updates to it - only security patches and the most critical changes. It has a reputation in the industry as being an extremely stable Linux.

share|improve this answer

There is no need to recompile your app for Debian if it was developed on Ubuntu. You are compiling for the Linux Platform, not a specific distribution. With that said, that is not a guarantee that you don't have dependencies in your app that you would have to ensure are installed on your production server.

My recommendation is to continue to develop in whatever way is comfortable for you, however you should have a test machine. For this purpose Virtual Machines are a great solution. For ease, I would recommend VirtualBox, but Xen, KVM, or VMware could all serve your purposes.

The important thing to note is that you should ensure that your test server (the VM) is as close in configuration to your production box as possible. What I recommend is either automating your build process, scripting your installs and configs, or (the hard way) taking detailed notes of the changes that you make on one server and reproducing them on the other.

Once you have them almost ready to start testing and deploying your app, take a snapshot of the VM. This is a feature of most virtualization platforms that allows you to roll back to a certain state. (In this case, your pre-app-deployed state.) Then test your app. If it works, deploy it. If it continues to work in production, get rid of the snapshot and that is your new "live" image. (You can keep your snapshots, but if you are going to be upgrading your app in production, you should be upgrading it in test...) If it works in test but not in prod, you will have to find the specific fix for prod. Once you do that, you will need to replicate your changes back to your test box and resume the testing cycle.

Yes, it's work. But it's the right way.

-Waldo

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.