5 ms·
I think Debian is the sweet spot for release cadence--stable is supported for ~3 years, and there is a new stable released ~2 years. This cycle avoids the RHEL
by candiddevmike 6y ago
I think Debian is the sweet spot for release cadence--stable is supported for ~3 years, and there is a new stable released ~2 years. This cycle avoids the RHEL issue of a "rolling turd of backport fixes"/trying to figure out WTF version you're really running for packages, and the Ubuntu issue of not knowing exactly what's coming in the next release (users can easily deploy Debian Testing to validate the next version). Finally, the breadth of Debian's packages are outstanding, and Debian's backports repo gives you an easy, "blessed" way to use newer package versions without impacting your existing system.
- sm4rk0 6y agoNot advocating for Ubuntu, but there's also "devel" "release" where you can see the current state of next release. How's Debian Testing different from that? Edit: it's "devel" not "develop"
- bayindirh 6y agoDebian Testing comes in two flavors. Rolling and non-rolling. You can either always stay in the rolling state for Desktop and non-critical application or, get to the bandwagon early and end-up with stable release eventually. To keep on rolling, you can use the keywords (stable, testing, unstable) in sources or use release names to stop rolling when something releases (buster, stretch, etc.). The nice thing about using release names is the annealing effect during development. First major version bumps stop (feature freeze). Then minor version bumps stop (RC state / full freeze). Then one day you read that Debian is released. Congrats! A last apt-get and you've arrived in stable.
- type0 6y agoWhile I like this structure, it is confusing at first and can be hard to explain to stubborn managers.
- sm4rk0 6y agoIsn't that the same as Ubuntu devel? You can always stay on devel, or switch to a stable release when (or preferably few days before) it's released.
- bayindirh 6y agoI don't know. I started using Debian 15+ years ago and never switched to another distro :) Had to reinstall my 8 year old installation to switch to 64 bit, and never reinstalled the new one.
- dsr_ 6y agoThese days there's a crossgrader that can switch from 32-bit to 64-bit -- and apparently, if you're feeling lucky and know what you're doing, from amd64 to arm64, assuming you're going to take the disks and move them to a new system.
- hiq 6y agoYou probably meant "Debian* comes in two flavors", but as you explained yourself, there are actually three: * stable (non-rolling) * testing (rolling) * unstable (rolling) What's interesting is that close to a freeze, "testing" is quite stable already, so pinning to its name (so bullseye as of now) allows you to keep this rolling state until it converges to the next stable.
- yaantc 6y agoI understand he meant something different: that you can use Testing in two different ways: 1) by explicitly referring to "testing" in your apt configuration. Then it's rolling forever. 2) by referring to the current "testing", so for example "bullseye". Then you're temporarily on testing, rolling for a while until the day bullseye becomes the new stable, and then you're on stable too. I often do this a bit ahead of a new stable on my personal laptop, to check what's coming with the new stable. I guess it's probably quite common.
- bayindirh 6y agoYep. That's what I tried to say. :)
- bayindirh 6y agoDebian comes in five suites actually: oldstable, stable, testing, unstable, experimental. There's oldoldstable but it's practically dead but, it's there. You can manage these suites in two different modes: rolling (suite based) or non-rolling (codename based)[1]. As you also noted, testing has a sinusoidal rolling speed. It starts rolling slowly when a stable is released. Then rolling gets faster. Then slows down (feature freeze) and stops (RC/Full freeze). Then that version becomes stable. Testing separates and whole cycle starts again. Testing never becomes unusable. Unstable has this risk. Instead testing is always tried to be kept in a semi-rc state. Any breaking bugs is a barrier for unstable to testing migration. As a result, testing can be used as a desktop system without any big drawbacks. [1]: Since unstable is always codenamed sid and experimental has no codename, they always roll. Similarly since stable is rolled from release to release, it doesn't quite roll but backports and volatile allows it to creep forward in a controlled manner.
- Qerub 6y agoDebian testing doesn't get timely security updates so it's inappropriate to use on production servers. Source: https://www.debian.org/security/faq#testing https://www.debian.org/security/faq#testing
- bayindirh 6y agoI know. However, back then testing also was getting security fixes with 24h deadline but, since Debian got much bigger, it became unfeasible and abandoned, no biggie. I always deploy current stable to any production server and I keep my desktop systems in rolling testing.
- hiq 6y agoUbuntu is based on Debian unstable, and if https://en.wikipedia.org/wiki/Ubuntu#Background https://en.wikipedia.org/wiki/Ubuntu#Background is still up to date, they freeze packages from Debian unstable before releasing, which looks pretty similar to Debian Testing getting packages from Unstable that have not proved too buggy. So you basically have this ordering more or less in terms of stability and how dated the packages are: From older (and more tested) to newer (and less tested): Debian Stable | Ubuntu | Ubuntu devel <-> Debian Testing | Debian Unstable Ubuntu devel <-> Debian Testing meaning that their orders depend on their respective phases, e.g. Debian Testing will soon freeze (prior to the next stable release) so in that time Ubuntu devel will probably be more up-to-date by virtue of being based on unstable. The rest of the time there's automatic migration from Unstable to Testing provided no blocking bug is discovered, so I'd expect packages in Debian Testing to be more recent. Honestly I think the main differences are the default experience, but if you know which packages you want to use, Debian and Ubuntu should be pretty similar.
- bayindirh 6y agoDebian also has single reboot, guaranteed stable-to-stable update. We use CentOS at the office for obvious reasons but, my personal servers are always Debian since 2005 or so. Had no problems whatsoever. Debian Testing is also a great, semi-rolling desktop distro. May be not the latest and greatest but, it's very very dependable.
- stephenr 6y agoWhat exactly are the "obvious" reasons (to you/your office) to use CentOS?
- bayindirh 6y agoI'm an HPC administrator. Scientific computation and HPC ecosystem is built upon RedHat infrastructure. First ScientificLinux, then CentOS. To be able to run scientific software and project related middleware with ease, you need a RH-Style distro. That distro is CentOS. (a little more insight is here: https://news.ycombinator.com/item?id=25349371 https://news.ycombinator.com/item?id=25349371)
- stephenr 6y ago... What do you mean by "RedHat Infrastructure"? What kind of packages are available for RHEL but not for say, Debian?
- bayindirh 6y agoNothing sinister. It's not about availability of packages. It's more like people develop and verify on RedHat based distros (because ScientificLinux was RedHat based). Some examples: - Software is released RPM first. - Software certification done on RedHat and CentOS (compile / verification). - Library versions present in RedHat and CentOS are used in development. - Documentation is written RedHat first. You can do everything on Debian. Possibly something would be hardcoded and you need to work around or re-compile it. Or, it works without hiccup but, developers can't provide support since they didn't test on Debian. Scientific software is a very different beast. Its accuracy and precision sometimes depend on the mood of a newborn butterfly in Zanzibar. I develop such software so, I know a little bit about the peculiarities. Since RedHat also has paid support, RH based distributions are considered more sound and mature, because if something breaks, RedHat can fix. It's no different for Debian but, RedHat was able to fly an engineer for NEC Corp. to reproduce and fix a GCC bug on-site. System in question was Itanium based IIRC.
- throw0101a 6y ago> I think Debian is the sweet spot for release cadence--stable is supported for ~3 years, and there is a new stable released ~2 years. Security fixes are for 5 years.
- bayindirh 6y agoAlso there is voluntary long term support by external parties (The LTS team) IIRC.
- pabs3 6y agoThe eLTS is done by paid developers, just like the LTS and you cannot use the eLTS without paying Freexian by sponsoring the both the eLTS and LTS efforts. https://wiki.debian.org/LTS/Extended https://wiki.debian.org/LTS/Extended https://deb.freexian.com/extended-lts/ https://deb.freexian.com/extended-lts/
- bayindirh 6y agoI meant that providing eLTS is voluntary. Of course it doesn't mean it's free to get this support.
- zozbot234 6y agoThat's including volunteer LTS support, which only applies to an unspecified subset of packages. Full support is ~3 years, per parent comment.
- pabs3 6y agoThe LTS team mostly consists of developers paid by Freexian, who are funded by various large and small companies. https://wiki.debian.org/LTS/Team https://wiki.debian.org/LTS/Team https://wiki.debian.org/LTS/Funding https://wiki.debian.org/LTS/Funding https://www.freexian.com/services/debian-lts.html https://www.freexian.com/services/debian-lts.html The LTS project supports most packages and the unsupported subset is specified, with the debian-security-support tool able to report unsupported packages that are installed: https://salsa.debian.org/debian/debian-security-support/-/blob/master/security-support-ended.deb9 https://salsa.debian.org/debian/debian-security-support/-/bl... https://packages.debian.org/stable/debian-security-support https://packages.debian.org/stable/debian-security-support