5 ms·
It still baffles me why people choose Ubuntu for a server. Canonical has a history of doing weird things: how many times have they diverged from upstream with
by stephenr 9y ago
It still baffles me why people choose Ubuntu for a server.
Canonical has a history of doing weird things: how many times have they diverged from upstream with some in-house solution that never quite works out.
The 6 monthly releases aren't realistic for business, who use LTS, at which point you may as well use Debian and back ports/vendor repos for software you need more updated versions of.
- matt4077 9y agoI used to use Debian, and Gentoo before that. I still remember spending days trying to get a somewhat recent version of php to compile on these systems. Around the time I tried Ubuntu, I started encountering problems less and less. Maybe I got better, maybe all distributions got better, or maybe Ubuntu is more robust. I just don't feel any pain that would motivate me to try other distributions. Ubuntu also seems to be the de-facto standard, and anything with install instructions will first cover Ubuntu.
- gargravarr 9y agoDebian has the problem that its packages are older, so if you need specific versions of PHP or other runtimes, you are much better off using Ubuntu. It's worth noting that Debian can be made to support PPAs as well, but all this is native to Ubuntu. I can't deny the Ubuntu community is extensive and there are in-depth articles covering setup of just about anything on Ubuntu. Fortunately, owing to the Debian basis, it's fairly easy to convert the same tutorials to run on Debian.
- philamonster 9y agohttps://www.dotdeb.org/ https://www.dotdeb.org/ usually handles needs for more common late release packages in Debian.
- ubernostrum 9y agoThe main issue is trying to use the distro packages for dependencies of the things you'll actually use the server for. Over in the Python world I'd be perfectly happy to use Debian. I'd just use it only to provide an operating system; then I'd compile the version of Python I want, and use virtualenvs and pip for managing the actual application code and dependencies.
- aoeusnth1 9y agoAgreed. Package managers are OK for a lay user, but if you actually want to run code in production you're better off with a reproducible and isolated environment you created yourself.
- stephenr 9y agoUpdated php builds are available from https://deb.sury.org https://deb.sury.org - they're available for both Debian and Ubuntu. The operator of that repo is also a Debian maintainer, so they follow the same practices. For nodejs you're better off using a vendor like nodesource regardless of your distro.
- snuxoll 9y ago> Debian has the problem that its packages are older, so if you need specific versions of PHP or other runtimes, you are much better off using Ubuntu. I really wish other distributions would steal the idea of software collections from Red Hat. Having newer runtimes and database engines available out-of-band is a great idea, especially considering SCL packages live in an isolated root and won't interfere with the base system.
- stephenr 9y ago> out-of-band I'm not sure I know what you mean by out-of-band ? Installed via something other than rpms? Installed from non-official rpm repos? It sounds like you just need packages built that allow for parallel installs of other versions of the same runtime/etc. The PHP packages for 5.6 onwards on Debian are built such that they can be installed side-by-side. Building on this basis, dotdeb.org and deb.sury.org have offered back ported versions of PHP built for stable, oldstable etc. From Buster (testing) it appears there will be multiple versions in the main repo (Buster currently has 7.0 and 7.1 packages)
- snuxoll 9y ago> Installed via something other than rpms? Installed from non-official rpm repos? Software Collections aren't part of the main repositories, they're an optional repository that can be enabled and have different guidelines for updates and new packages than the core repositories do. They're effectively divorced from the normal scrutiny and stability concerns that every package in the core RHEL repos has to go through, newer packages get pushed out faster as a result. > It sounds like you just need packages built that allow for parallel installs of other versions of the same runtime/etc. That's precisely what Software Collections do, they go one step further and isolate each runtime and require it be manually enabled for use (rhscl enable python3.5 `command goes here`) - there's no potential for the core system to be affected and you can layer different collections together if needed.
- stephenr 9y agoThe first part sounds like it's solved by a combination of the $release-backports repo, and vendor repos. The second part sounds interesting - sounds vaguely like using a chroot, so the 'target' just knows to run python, not which specific version its going to run, for instance?
- henpa 9y agoWhich Linux distribution would you suggest for a server?
- gargravarr 9y agoDebian or CentOS. Both have extensive packages and long-lasting support for them.
- jmnicolas 9y agoCentOS has the advantage of being 'convertible' in a Red Hat so you can get paid support if needs be.
- stephenr 9y agoI've never quite understood this for anyone but the biggest companies. The vast majority of businesses aren't ever going to buy a red hat (or canonical) support contract. They're going to hire a Linux sysadmin to help them.
- snuxoll 9y agoA sysadmin isn't going to be troubleshooting kernel panics that suddenly started happening on a production system, or why a new version of libfoo without a soname bump is causing service xyz to segfault. Commercial support has it's advantages, and it is why I do plan on switching all of our CentOS VM's to RHEL in the coming year (especially since we've chosen to adopt OpenShift after a PoC with the upstream release). Honestly, why would we NOT, it's ~$2000/yr per physical machine to have knowledge that engineers are available should something go wrong in a mission-critical deployment.
- stephenr 9y ago> A sysadmin isn't going to be troubleshooting kernel panics I would expect a sysadmin to do very basic troubleshooting, and if it's not a very quick fix, organise a new machine. The sort of companies that will need to fix the issue on that box, rather than just replacing it, are the kind of companies that will buy a Red Hat support contract. For most companies, it's probably not worth it.
- wiredfool 9y agoUntil recently, Ubuntu had a much better story around long term support releases than Debian did. Debian averaged 3 years of support, Ubuntu offered 5. That has changed with Debian's support of LTS in one of the recent distros.
- gargravarr 9y agoDebian also had a reasonably inconsistent release cycle. Now they've settled on 2 years, it's much more viable to use plain Debian rather than Ubuntu. Ubuntu has always been about user-friendliness. I've never found the extraneous bits necessary for admin'ing a server from bash.
- gargravarr 9y agoThe worst part of LTS is that it only applies to the OS itself. Security updates for applications actually running on it (e.g. Apache) expire after a considerably shorter period of time. We found this out after an internal vote between Ubuntu and CentOS. We'd have picked the latter if we'd known. You can run `ubuntu-support-status` to determine what packages are currently supported.
- manaskarekar 9y agoThat's a nice command to know although it gave me the following: Support status summary of 'acomputer': You have 12 packages (0.8%) supported until January 2017 (9m) I guess the dates are hardcoded when the distribution was launched. (I'm on 16.04). Still a good over all indicator I suppose.
- soneil 9y agoI don't believe it's hardcoded, it's provided in the package list from the repo. eg, "apt-cache show apache2 | grep ^Supported".
- rlpb 9y agoEssentially, that is hardcoded. The package list (ie. apt cache) does not change after release. It cannot, because of mirror expectations and of course because it ends up on the images. Updates go through a separate updates pocket. Essentially the "Supported" field cannot be updated for all packages without issuing an update for all packages, which would require all users to download all packages again to get the new versions of each of them.
- rlpb 9y agoThis is not accurate. Apache is supported for security updates for the entire LTS period in all current stable LTS releases, for example. If "ubuntu-support-status" is telling you otherwise, that's a bug. Packages in main are security supported by Canonical. Packages in universe are security supported by anyone who wants to contribute acceptable fixes.
- gldalmaso 9y agoThere are people who need to operate linux servers without great familiarity with any of them, Ubuntu just seems to have a much greater available knowledge base. You can just basically search for "how to do x in ubuntu xx.xx" and get very helpful results, including solutions for Ubuntu desktop that are relevant to the server version. Results may vary immensely with "how to do x in y", y being any other distro.
- TeMPOraL 9y agoBecause it works out of the box. Ubuntu is a great system for people who want to use Linux to do their work, as opposed to working on Linux. I.e. developers, not sysadmins.
- sk1pper 9y agoI don't really think 6 month releases are viable on desktop either. Stability is important there, too, if you care about getting work done.
- reacweb 9y agoI use ubuntu for my hosting server in the cloud because I use ubuntu on the 2 desktops and 1 laptop of my house.
- stephenr 9y agoWhy? I would assume they serve at least slightly different purposes/roles, no?