my little rant...

[Xen]

Ralf Mardorf schreef op 11-11-2017 10:18:
> 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

So?

> 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".

Then I didn't mention it.


> 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.

So then they are mini discrete releases, nothing continuous.

Also your use of "soname" is really annoying.

> Wrong, structural changes happen especially when using a rolling
> release.

No, they just happen more frequently. Or rather, you are turning this 
"rolling release" into "more incremental steps" which is fundamentally 
no different from "one big step" -- you are just changing the step size.

> 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.

Well the whole point of what I wrote was about stability.

I can upgrade Debian 8 to Debian 9 too.



I just have to deal with the fact that:

- owncloud is gone
- dokuwiki is gone
- PHP is updated from 5 to 7, so if I want to keep above, I must upgrade 
them manually
- PostgreSQL has a binary non-compatible database format upgrade that 
requires running some rather difficult or at first non-intuitive 
commands
- I also have to upgrade LXC to version 2, which is not the worst, but 
still, requires time.


I guess that in a Arch model of mini releases I would have had time to 
do this step by step.

Personally I don't like constantly having to maintain my system.

This constantly having to maintain is what I called "nervousness".

You can compare that to the Let's Encrypt digital certificates that for 
no reason whatsoever, give no-name people monthly certificate renewal 
that requires all infrastructure to keep working, otherwise you are 
obviously "screwed".

And the only reason they do this is because the more people constantly 
use their service, the more "popular" they are etc. etc.

There is almost no benefit and only detriment to this frequent 
certificate renewal.

The unlikely event that someone hacks your server or device, then steals 
your certificate and private key, then puts effort into using that 
certificate against your users who now need to be subjected to a man in 
the middle attack in order to be vulnerable to this.

Does not coincide with the target audience of users who are too cheap 
(or too small) to acquire a commercial certificate.

But now you have something more to worry about: does the renewal keep 
working?



This is what I call "nervousness".

Maybe there was good reason to maintain older kernels, I don't know.

I just think the pace had been picked up with regards to kernel 4.

Grek KH earlier commented that the pace was constantly increasing in 
kernel development.

The growth is, in a certain sense, exponential.

The number of lines of code contributed keeps growing every month.

This is not, in a general sense, a very good thing.