我用我的Ubuntu 9.10开发机器为我的网站编写了一些C ++服务器端守护进程。
我上面提到的C ++应用程序是“无GUI”的守护进程（和守护进程使用的库）。
我现在要主持我的网站，并需要决定是否要与Debian服务器或Ubuntu服务器。
简而言之，就是这样的情况：
我希望服务器健壮，安全和稳定，只是作为一个服务器（即灯和其他很less – 没有GUI等）。 鉴于这一要求，以及我需要运行我的C ++应用程序（在Ubuntu 9.10上开发）的事实，
我需要在服务器上select哪个操作系统的build议。 理想情况下，任何build议都会有理由支持。 我特别感兴趣的是听到处于相同情况或做过类似事情的人。
而且，每隔几周似乎就会出现一个新的“补丁” – 我不希望在服务器上使用服务器（我想让服务器保持良好的状态，并让服务器继续提供服务页面）。
你这样做是错的。
Debian stable具有出色的安全策略，如果他们提供安全更新，则意味着他们修复了一些存在安全漏洞的软件包。 你没有select不更新它，否则迟早会被黑客入侵。
当然，你可以编写一个脚本，每天自动调用更新和升级，但是你最好亲自关注你的服务器。
我不想要与新操作系统相关的学习曲线
ubuntu只是一个经过修改的debian桌面使用：可能你不会有任何问题。
我在Ubuntu和Debian上的经验将会使我转向服务器上的Debian–他们更关注于稳定，稳定的版本和更多的服务器空间历史，而我在Ubuntu方面的经验相当不平衡。
这就是说，这只是我个人的经验。 我知道有些人在Ubuntu上运行服务器场，所以这不是问题。
如果你selectUbuntu，一定要selectLTS（长期版本），所以你得到bug修复/安全支持3 – 5年，而不是在常规的Ubuntu版本18个月。
最后，Florian非常正确，您最好拥有一个能够反映您的生产环境的本地环境; 实现这一目标的最好方法可能是Xen / KVM / etc客户端，无论您的服务器是用什么内置的。
只需要考虑一个替代scheme – 在运行Debian服务器的Ubuntu主机上运行一个小型虚拟机 。 这样做的目的是生成Debian软件包。 您可以根据需要使用尽可能多的开发人员软件包和所有必要的构build工具来污染此VM。 然后，使用命令行来编译和构build您的软件包以进行部署。 不是最优雅的解决scheme，但它应该允许你在Ubuntu上进行90％的开发，并部署一个绝对可用于Debian的二进制包。
根据我的经验，最好是有一个服务器，只能服务。 我的意思是避免在服务器上的桌面用户界面。 如果您的应用程序不适用于Web服务器，则可以使用命令行完成所有需要的操作。 这将增加稳定性，并且实际上使停机时间无效，同时还保持dev / pub的分离。 确保您编写的应用程序与命令行兼容，并且应该是守护进程的黄金。 如果应用程序绝对必须有一个用户界面，使UI基于Web。
如果我理解正确，主要是通过graphics用户界面使用计算机，而且我猜测你可能会在一台只有命令行的计算机上丢失一点信息。 确实UI改变了，但是请记住，两者都使用GNOME并没有那么不同。 但是，Debian确实是比较粗糙的。
关于更新，Debian几乎每天都会定期更新其稳定版本。 至于二进制兼容性，最好的办法就是重新编译你的目标系统的软件，即使它的工作原理是一样的，只要你使用的版本年龄大致相同即可。
考虑到这一点，我有同样的感觉，Ubuntu的可能是一个更好的路线给你。
由于Ubuntu基于Debian，差异不是那么大（除了GUI – 但是不会为你的服务器使用GUI，对吧？）。 如果你可以使用Ubuntu的命令行，你可以在Debian上做同样的事情。
在Debian和Ubuntu上，你只会得到稳定版本的重要更新，比如安全修补程序，所以对于相同的软件，你应该在Debian上获得相同数量的更新。
在服务器上使用相同的开发系统有助于避免很多问题。
Ubuntu 是 Debian。 在Ubuntu上开发的大部分东西都应该在Debian上“正常工作”。 如果你想稳定性，你可能需要考虑一下Ubuntu的LTS（长期服务器），它提供比常规的Ubuntu桌面版本提供的常规六个月发布周期更长的稳定期。 或者你可能想看看Debian Stable。 目前Debian Stable是5.0版本，但是今年可能会发布一个新的Debian Stable。
Debian Stable非常稳定。 它在发布之前已经过了大概两年的testing，并且只有很less的更新 – 只有安全补丁和最关键的变化。 它在业界声誉是非常稳定的Linux。
如果Debian是在Ubuntu上开发的，则无需重新编译您的应用程序。 您正在编译Linux平台，而不是特定的发行版。 这就是说，这不是保证你的应用程序中没有依赖关系，你必须确保已经安装在生产服务器上。
我的build议是继续以任何舒适的方式发展，但是你应该有一台testing机器。 为此，虚拟机是一个很好的解决scheme。 为了方便起见，我会推荐VirtualBox，但Xen，KVM或VMware都可以满足您的需求。
重要的是要注意，你应该确保你的testing服务器（VM）在configuration上尽可能接近你的生产环境。 我推荐的是自动化你的构build过程，编写你的安装和configuration脚本，或者（很难）详细logging你在一个服务器上做出的改变，并在另一个服务器上重现它们。
一旦准备好开始testing和部署应用程序，请拍摄虚拟机快照。 这是大多数虚拟化平台的一个特性，允许您回滚到某个特定状态。 （在这种情况下，您的应用程序部署前的状态。）然后testing您的应用程序。 如果有效，请部署它。 如果它继续在生产中工作，摆脱快照，这是你的新的“活”的形象。 （你可以保留你的快照，但如果你要升级你的应用程序在生产中，你应该在testing中升级它…）如果它在testing但不在prod中工作，你将不得不find具体的修复刺。 一旦你这样做，你将需要复制你的变化回到你的testing框，并恢复testing周期。
是的，这是工作。 但是这是正确的。
-Waldo