Hacker News new | past | comments | ask | show | jobs | submit login

> I run fixed release distros on production servers/devices. It's important to be able to install a new package on a machine and not have a hundred dependencies need upgrade, break or conflict.

Isn't that an argument for rolling release? I don't see how this would support using fixed release distros.




Not when you have a few hundred servers. Then, you want consistency. Consistency between servers, between datacenters and between pre-production and production environments.

Now, you can get there with your own repos and a rolling distro. Or you can accept a test/upgrade cycle for a fixed release distro every half year or every year. I personally think the latter is less error prone.


That is what distros like Manjaro / Chakra are effectively. They just pick a date, grab all of Arch, test it for a few weeks, and push it to end users in batches.


I am unfamiliar with Manjaro and Chakra. My experience with Arch is limited to my Cubox-i. It's a nice distro, with an excellent community. I liken it to Gentoo in its glory days.

Having defined my limitation in the observation, I'd just like to point out that, when it comes to distribution stability, for large server deployments, there is safety in numbers. Should a problem occur in a "stable" package, the odds that you are the first one to find the error are smaller with popular server distros (RHEL, Centos, Debian) than with less popular distributions. It's not a statement regarding the intrinsic quality of the distribution. It is a statement regarding the overall quality of the distribution + installed base.

All in all, for a distribution to dislodge entrenched players, for this use case, it will have to be an order of magnitude more stable.


Using a fixed release only requires that you apply the update once every few years, so you can plan for it. You can do it at a quiet time when you are available to fix any problems. With a rolling release you have no idea if something is going to break at an inconvenient time.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: