Hacker News Reader

Comment by geoffroy | Hacker News Reader

I'm not an expert about Linux server-side distros. I'm using Ubuntu Server, I haven't seen any cons for now. Any hint ?

Debian is more conservative with changes - if you want your systems to be rock-solid, go with Debian. The downside is that it's so stable that packages are usually outdated, but in many cases there are more recent backports which you can cherry-pick.

In my experience, Debian's security team responds to new CVEs faster than Ubuntu's, but this is purely subjective.

Also the users are a bit more, um accurate, in their answers; so if you run into problems, you may be in better hands if you reach out ( so long as people in help places aren't being hostile twats ).

Absolutely, I've found the debian community to be one of the best out there as far as support goes.

I've found them to be a highly mixed bag in IRC.

One issue I've found is support for old releases. Ubuntu only has a 5 year support life cycle, where as CentOS / RHEL have a 10 year support life cycle. For most people this isn't an issue, but in the enterprise it definitely is.

I recently had to move a bunch of Ruby 1.8 applications (where it didn't make financial sense to upgrade them) to new servers. They wouldn't even run on Ubuntu 10.04, where as CentOS 5.5 is still receiving security updates.

But Ruby 1.8 is EOL. I also got some customers running Rails 3.0 with 1.8.7. I told them they have to rely on good luck not to be hacked and they also made the financial decision not to upgrade so they are running an unsupported language version on maybe an unsupported OS (can't remember which OS they're using).

Assuming they are using RHEL/CentOS 6.

You can get supported ruby 1.9.3 on RHEL6 or CentOS6 https://www.softwarecollections.org/en/scls/rhscl/ruby193/ or https://wiki.centos.org/AdditionalResources/Repositories/SCL

Unless they are unwilling to upgrade their rails and using the ruby version as an excuse :) Best of luck to you!

Software Collections aren't "supported" in the same fashion that core RedHat packages are (i.e timely security fixes, backported if needs be, for the lifetime of the OS release).

From the ruby193 SCL page you linked to:

"Community Project: Maintained by upstream communities of developers. The software is cared for, but the developers make no commitments to update the repositories in a timely manner."

Yeah, if they are in CentOS land it will be a bit touch and go (as usual).

But if you have a redhat subscription they are fully supported. I should have pointed that out in my first comment though, thanks for bringing it up :)

"All Red Hat Software Collections components are fully supported under Red Hat Enterprise Linux subscription terms of service. Components are functionally complete and intended for production use. " [0]

[0] <https://access.redhat.com/products/Red_Hat_Enterprise_Linux/...

Yes, it's not the best situation but is a lot better than it was before. Originally there were about 10 Rails 1 / 2 applications on a pair of machines running Ubuntu 6 and Ruby 1.8.4, with most services open to the world. These machines were being retired so the apps need to be moved off - a few apps were shutdown as they were no longer used, and the remaining each got their own VMs.

The apps were upgraded where possible but most of them had dependencies that would only run on Ruby 1.8 and have long since been abandoned. We considered rewriting them, but they are only used internally and are most likely going to be shutdown in the next year or so. At least the OS doesn't have any known security issues and is now properly behind a firewall, so that's something.

One of the issues with Ruby 1.8 is that it only compiles against OpenSSL 0.9.x. To compile it from scratch means you need to downgrade that (and a few other deps), which is about as painful as you can imagine. CentOS 5.5 still comes with that and is supported until 2017, where as you would need Ubuntu 8 or lower. I was thinking of creating a LTS version of Ruby 1.8 (a la Rails LTS), but I don't think the need is really there. Businesses who are running Ruby 1.8 have either weighed the risks or simply don't care :/

Ruby 1.9 is EOL.

Yup, but RedHat commit to backporting security fixes for the duration of the release (so 30/11/2020 for RHEL6)... Not sure that this is the case for software available via any of the collections.

edit: SCL's aren't supported by RedHat

They are. As I pointed out in my other comment:

[0] <https://access.redhat.com/products/Red_Hat_Enterprise_Linux/...

If you really, really must have the latest and greatest of some package, you can always use the IUS Community's RPM repos for RHEL/CentOS (it's run my Rackspace for their servers).[1]

But, we're talking about enterprise here, no young hip startups. Enterprise wants stability over everything else, young hip startups want the new shiny.

There are huge amount of Java 1.3, 1.4, and 1.5 applications still running in Enterprise all around the world with zero issues. Most of the time it doesn't make financial sense to re-build or spend time debugging an upgrade just to have the latest runtime.

"If it ain't broke, don't fix it".

[1] https://iuscommunity.org/pages/About.html

I understand to run Java 1.5, or better Java 1.6 but not 1.3 and 1.4 that's aweful. But I know that's a fact since I've used Apache Fop and they try to have a compatibility up to Java 1.3. For me I've writing all my software with the latest Java, but I don't care which os (even RHEL 5/6 would work, if they could get java 8 to run) Supporting everything down needs have so many more Lines of Code and is rareley harder to maintain / code. Especially Option Types and Java 9 + Java 10 brings your Java Code to a further level, I also don't get it why somebody would code a new project via J2EE if there are so many great servers like wildfly and netty.

Well, a Java 1.3 application isn't going to be a new application - usually a legacy application which has a lot of custom libraries built specifically for that version of Java, and would require significant effort to bring the codebase up to date in terms of running on a modern platform. At my company, one of our most used internal applications runs on 1.3 - it's an application which allows user-made plugins, however we don't have the source for the main application, which means we're stuck maintaining a 1.3 system.

As an aside, J2EE is quite good and very prevalent in enterprise, JBoss, GlassFish, Tomcat, etc...

I can understand why enterprises need 10 year support for their server OS, but I would assume many of the third-party software running on that OS will not have a 10 year support period. This is not ideal from a security perspective.

Yep, I've still got plenty of RHEL 5 and 6 boxes running production public-facing services. I'll upgrade them probably within the next six months or so but it's simply not a priority at this point (even for the 5.x machines).

Five year support might be too short for some people. If so there's Red Hat Enterprise Linux (and its community rebuilds like CentOS), and SUSE Enterprise Linux.

A paid RHEL subscription will even give you security updates for point releases, in case your needs preclude from upgrading even to backwards compatible versions (e.g. You can use RHEL 6.4 even now, instead of 6.6 or 7.0)

I seriously believe that Ubuntu is not the best decision. SUSE and Redhat have much better support and services.

More people know Ubuntu and is why they use it.

Seconded, the support lifetime of Ubuntu makes it woefully inadequate for use in an enterprise environment. I get that the hip startup scene wants the latest and greatest, but I work in the medical industry and rock-solid stability and availability are more important than anything else - we still have a couple Windows Server 2003 R2 and Windows XP systems that we haven't finished decommissioning yet, along with a couple SQL Server 2005 installations.

When we made our first major Linux deployment this year there's no way I would have picked anything but RHEL/CentOS, we have critical services running on these systems that will be in use for a long time, and playing the upgrade dance in 5 years even (shorter than it sounds) is not an appealing thought.

This is something not to be neglected: having a patched and backported LTS is not negligible in the enterprise.

Honestly, Ubuntu doesn't even try to focus on your type of usage you've defined.

Given your companies pattern of doing its first deployment of Linux this year, and needing a very long support cycle - I think it's fair to say that you're looking for the equivalent of a traditional UNIX. Slow moving, with lots of stability and strong guarantees on backward compatibility. Red Hat and SUSE focus on that type of "enterprise computing" - they've grown on doing 'UNIX replacement'.

Ubuntu is aimed more at the (as you put it) "hip start-up scene" or at least the area in the technical spectrum that is about new technologies, concepts such as continuous deployment and cloud computing.

The funny thing is most enterprises have a bit of both those types of computing. Some slow-moving "eggs in one basket" services, but also the need for fast-moving innovative areas. So there's room for more than just one sort of distribution.

If you have an unattended server, there's an open bug since 12.04 that hasn't yet been fixed, that might make it get stuck in grub, forcing you to connect a keyboard to make it start. (Yes, it bit me with embedded hardware stored in a closet on a pole 20 feet high in the air)

http://serverfault.com/questions/243343/headless-ubuntu-serv...

The fix is in 12.04-proposed, but was never released, never applied to 14.04 and 15.04 last time I checked. Which is quite ridiculous, IMHO. (Can't find the Launchpad entry right now)

I second that this is pretty annoying. The problem is that Ubuntu's grub.cfg is configured to wait forever until the user manually chooses a new boot option if the last booting failed. However, sometimes a temporary error can happen during the booting process, and this will make the server hang after the next reboot. This is probably not what server users want.

In addition, I think this behavior is not ideal for desktop users either, because (1) spurious errors can also happen in desktop and in that case waiting a few seconds is better than waiting indefinitely, and (2) it is not uncommon to use Wake-on-LAN nowadays.

But I'm not sure this problem is unique to Ubuntu, as Ubuntu shares much of its codebase with Debian. Does anybody know this is also problematic in other distributions?

It looks like this will be fixed in 15.10: http://www.phoronix.com/scan.php?page=news_item&px=ubuntu-15...

When I checked (in 2013), Ubuntu had this problem, and Debian did not.

Ubuntu shares a lot with debian, but grub configuration is one thing that Ubuntu appear to be doing on their own.

That bug was fixed in all releases last july. This was the bug:

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1443735

Thanks. I guess it didn't modify my /etc/default/grub (which I would have noticed) because I already added it myself.

The problem was found (and a fix committed to proposed) in june 2012, but only applied (in -updates) in july 2015. I find that weird, to say the least.

This was such a thorn in my side back in the day. So many unnecessary trips down to the server room to kick over someone's box that was hung.

Ubuntu 14.04 was one of the last distros to use upstart, which is pretty close to dead.

As .service files become normal in the RHEL & Fedora/Debian world, and 14.04 LTS long life cycle runs, upstart is going to look increasingly out of date.

Atm (assuming LTS) you'll have to use upstart, which sucks. Terrible selinux support also.

> Terrible selinux support also.

Ubuntu focuses on AppArmor instead.

Sure. I just prefer selinux (along with most of the MAC using world), so this is a negative for me.

> so this is a negative for me.

Exactly. For you. This isn't a con of the actual system.

Is there an init system which doesn't suck?

Yep: http://core.suckless.org/sinit

Well, it certainly sucks less

Seriously though, I've found that most things from the suckless guys are pretty great. st is a perfect terminal; surf would be perfect if it had an ad blocker.

It almost seems as if they are recreating Acme (plan9 editor).

Why would a web browser need an ad blocker? Do that in your HTTP proxy or DNS server. I recommend Polipo or Privoxy as I've had success integrating them with EasyList.

> Why would a web browser need an ad blocker? Do that in your HTTP proxy or DNS server.

In order to be able to perform URL-level blocking without a proxy; and in order to be able to perform context-sensitive blocking and CSS blocking at all.

Reply on news.ycombinator.com