[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

my little rant...

On Sat, 11 Nov 2017 08:05:56 +0100, Xen wrote:
>But I also feel the Kernel itself is rushing ahead too fast.

Upstream https://www.kernel.org/ currently supports:
longterm: 	4.9.61
longterm: 	4.4.97
longterm: 	4.1.46
longterm: 	3.16.49
longterm: 	3.2.94

Let alone that until a few month ago RHEL, so much likely the free as in beer CentOS as well still supported Linux 2.x.y.

"6.9, also termed Update 9, March 21, 2017; 7 months ago (kernel 2.6.32-696)" - https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_6

>Rolling releases is not a very good idea but anyway. I think it causes 
>library dependency creep.

That depends on the purpose of the rolling release.

"Debian Unstable (also known by its codename "Sid") is not strictly a release, but rather a rolling development version" - https://wiki.debian.org/DebianUnstable

A rolling "development version" isn't the same as a rolling "release".

Arch Linux is a real rolling release and it doesn't suffer from soname issues. Arch Linux has got a testing repository and software gets pushed to the "regular" repositories after a process that ensures that there will be no soname and some other issues. It only requires that users never do partial upgrades and that they need to care about local build packages. 

>You can't really put structural changes to a system in a rolling
>release anyway, can you?

Wrong, structural changes happen especially when using a rolling release. When using a rolling release it's wise to subscribe to an announcement list and/or to read the news on the homepage, since a structural change does force the user to step in, by running commands mentioned by the announcements and the homepage news.