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

FWIW I'm running my personal VPS with Arch, with services that only I use. As many people know the good thing with Arch is that what you gey is the bare minimum to have a shell running, so anything that is not necessary for the system to be up is something I installed; I know what is on the system.

I do upgrade my packages from time to time. It's almost always happened smoothly. The few times problems happened were due to 2 reasons:

- the software itself has a buggy upgrade procedure. I probably would have had the same issue with any other distribution, assuming they would contain the latest version

- it's an Arch-specific upgrade issue, but I have so few packets that this happens at most twice a year and it's always documented on the front page of the arch wiki

I have to admit that since it's only my own server, there is no pressure for services to stay up. In practice in the years I've used this setup I've never had an issue because a package was too recent and buggy; it was always a misconfiguration from my part.

I very much like the process of steadily keeping up to date bit by bit, instead of stagnating on a stable base and doing a big bang update every few years. I also like the fact that I don't need to know which version of which release am I going to get, it's always the latest one and it's the one that upstream released.




Like Jay says https://www.youtube.com/watch?v=ytfohob38vM It really depends on what do you want to run on and including also how often you plan to upgrade dependencies. But being honest, Arch upgrades are transparent. For example I never got crashes or similar issues upgrading from Arch OS/Kernel dependencies in my daily basis desktop. The issues that I have only faced were with few dependencies coming from the AUR channel that I have installed on demand. So it's not a "crazy" idea to consider to give a try ArchLinux for server-side stuff. Not in 2020.

> I very much like the process of steadily keeping up to date bit by bit, instead of stagnating on a stable base and doing a big bang update every few years. I also like the fact that I don't need to know which version of which release am I going to get, it's always the latest one and it's the one that upstream released.

Yeah, that's also the motivation of this thread from my side. In fact, moving between majors for example has also "risks" to tackle (E.g CentOS 6 to 7 to 8). You know, things that you need to take time to evaluate and test. But in the other hand, having rolling release upgrades makes that headache disappears.

So IMO I believe the Arch rolling release approach will be the next way to upgrade our software on a non-distant future. It's time to try out and test ArchLinux on hot places like servers.


Interestingly, the rolling release approach is already the way companies like Facebook or Google are releasing their services: when all tests pass it goes on master, and whatever is on master goes to prod. There are no releases, no backporting, no humongous release notes, etc... In a sense I like the idea that my server acts the same way, because the server is there to provide a service the same way Google provides a search service.


Same. But for me there has been one particular recurring kind of breakage. Python version upgrades (most recently 3.8 -> 3.9) invalidate all manually installed packages and virtualenvs. Mitigated by using Arch packages for Python packages instead...




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

Search: