Thoughts on Ubuntu maintaining Jessie's kernel ~ discuss

[Linadian]

http://m.infoworld.com/d/open-source-so ... ver-235552

The kernel is written mostly by companies.

I suspect a very significant part of the security auditing / patching is done by companies too.

Sometimes a distro / company decide they need to support a kernel for longer than it's officially supported for, to backports fixes. Others will decide to collaborate, or import the work.

There is nothing mysterious or novel about this. Usually it's RedHat, this time it's Ubuntu. Debian have never been in the business of writing the kernel - mostly, they package things and develop packaging tools.

If you want a sense of how controversial this really is (ignoring hysterical rants on user forums), check the mailing lists. Find a Debian Developer (someone who's actually qualified to have an opinion - and remember, many of them are no fans of Ubuntu) who thinks this is in any way an erosion of Debian's independence.

Assuming you are talking about 'generic' kernels, there is still some degree of 'filtering' going on, it's not like some corporation slaps some code in a kernel, then it gets auto-posted on kernel.org, again, anybody correct me if I'm wrong here. That being said, I still don't have an answer to the question, "Will average Schmoes have access to the same 'updated' kernels for examination at the same time Debian devs get them?". Here's another question, will there be and where would we find any change logs? The previous version can be compared to the most recent 'release', and if the changes match the log exactly.

[confuseling]

The process will almost certainly be exactly the same as it always was. You can find changelogs in the PTS, and source through apt among other places. Bear in mind I hardly use Stable, but I believe Debian Developers will cherry pick patches from the temporary upstream, apply their own patches where needed, then put the new kernels in proposed-updates. Security patches, which bypass that, will still be reviewed by the security team (and some of that isn't done in public until it's finished for obvious reasons; it never was).

[Linadian]

The process will almost certainly be exactly the same as it always was. You can find changelogs in the PTS, and source through apt among other places. Bear in mind I hardly use Stable, but I believe Debian Developers will cherry pick patches from the temporary upstream, apply their own patches where needed, then put the new kernels in proposed-updates. Security patches, which bypass that, will still be reviewed by the security team (and some of that isn't done in public until it's finished for obvious reasons; it never was).

Thank you ever so much for such a thorough peek (seriously, not kidding). Taking some of the mystery out of all this may put more people at ease. But then again, how many average Schmoes (will) wander in here and to this exact thread? People only see the 'face' of this PR announcement.

The length of support is still an issue, I don't see how 1 year kernel support (from approximate end of freeze to end of stated/quoted approximate Ubuntu kernel support) will cover a possibly a 2 year Debian stable OS release, the math not working is just a tiny bit obvious. Something smells a little fishy and it isn't my cat's food, lol.

[confuseling]

I haven't looked at the dates, but going from what you've said, if it comes down to it, they'll support it themselves.

The point is this way they get a year of 'free' upstream support before they have to take over. Doesn't completely eliminate the work even during that year, but it can only help (I'm sure they'll need to cherry pick and perhaps apply their own patches, because of differences between Ubuntu and Debian. But then it's probably easier than using RedHat, since they're more similar and share some infrastructure and developers).

[kmathern]

From this message https://lists.debian.org/debian-kernel/ ... 00413.html it sounds like Ben Hutchings will pickup support for the 3.16 kernel in April 2016.

Q: Will Linux 3.16 get long term support from upstream?
A: The Linux 3.16-stable branch will *not* be maintained as a longterm
branch at kernel.org. However, the Ubuntu kernel team will continue to
maintain that branch, following the same rules for acceptance and
review, until around April 2016. I can continue maintenance from then
until the end of regular support for 'jessie'.

That is also around the time that Squeeze LTS support ends.

[vbrummond]

This is getting blown out of proportion. There are no "cracks forming" because they decided to support a certain version of the kernel. I also don't understand where the init system comes into this. I'd like to see some hard data and not duf rants.

[Linadian]

From this message https://lists.debian.org/debian-kernel/ ... 00413.html it sounds like Ben Hutchings will pickup support for the 3.16 kernel in April 2016.

Q: Will Linux 3.16 get long term support from upstream?
A: The Linux 3.16-stable branch will *not* be maintained as a longterm
branch at kernel.org. However, the Ubuntu kernel team will continue to
maintain that branch, following the same rules for acceptance and
review, until around April 2016. I can continue maintenance from then
until the end of regular support for 'jessie'.

That is also around the time that Squeeze LTS support ends.

Thank you, that clears up the date(s) issue(s). But it still doesn't instill a whole lot of confidence, so for the hypothetical 2nd half of Jessie's life, Ben will be the only kernel 'guardian'?

I fit in to a few categories, PC hardware enthusiast, anti-monopoly OSes (that includes that pretentious/overpriced 'fruit' corp), tinkerer, etc, but I by no means have any mission critical systems (I have a dedicated HDD for file storage, separate from my dual SSD Raid 0, it's even readable by a an MS machine if such an emergency arose), so all of this really won't affect me that much, I don't care who patches the kernel, as long as it works and it has no spyware in it. But rest assured, the first whiff of malfeasance of any kind, I'll be running for the hills (another distro), probably to the relief of some, lol.

All that being said, there are people that do depend on Debian's (infrastructure) stability and longevity much more than I do, they'll be watching this 'development' (no pun intended, heh) more closely than simpleton tinkerers like me.

I'm going to quietly back away from this convo now and let the pros duke it out.

[Gyokuro]

The process which patches get merged from upstream is open due the Ubuntu's kernel maintainer send the patches for further review to stable@vger.kernel.org, linux-kernel@vger.kernel.org and Ubuntu's kernel-team@lists.ubuntu.com so there is nothing secret in it. I think the biggest problem is that people do not trust that much said distributor but I think as long patches get reviewed from the kernel.org community they should be ok. To maintaine a kernel over such a long period is quite a task and it would be interesting how much time the current Debian kernel maintainer for Wheezy need to filter out all patches and prepare a new kernel release.

[hakerdefo]

This is getting blown out of proportion. There are no "cracks forming" because they decided to support a certain version of the kernel. I also don't understand where the init system comes into this. I'd like to see some hard data and not duf rants.

Two very very critical components, kernel and init system, of the next Debian stable will be under the influence of Canonical and Red Hat. These are hard facts.
A tale of a big corporation, manipulation and Linux kernel,
Red Hat's "obfuscated" kernel source
Cheers!!!

[dilberts_left_nut]

Two very very critical components, kernel and init system, of the next Debian stable will be under the influence of Canonical and Red Hat. These are ...

FUD.

RedHat wrote a good portion of the software in Debian and also a lot of kernel code - that doesn't give them any more "control" or even "influence" than any other upstream.
A distro such as Debian is about packaging and integration - not writing code.

As for the "buntu" kernel, of course Debian is 'in control' of the Debian kernel packages and what patches are included or not, it will simply be based on a version that Canonical is doing the major backporting grunt work on, rather than the upstream LTS that would normally be the case if the timing wasn't shite.

A tale of a big corporation, manipulation and Linux kernel,
Red Hat's "obfuscated" kernel source

That's for the $(kernels+patches) shipped with RHEL and has nothing to do with the code from kernel.org or Debian.

[hakerdefo]

Slackware, Gentoo and Debian are fundamentally different distributions but the following is still an interesting comparison,
Slackware = 7 member strong development team
Gentoo = Around 175 active developers
Debian = Around 1500 active developers
And who out of these three relies on outsiders to maintain the kernel and develop init system?
There is something wrong with the way in which Debian project has been handled recently. Decision makers at the top are busy in-fighting and promoting their own agendas and ignoring the voice of majority of Debian users (for example systemd). The direction in which the Debian project is being lead doesn't bide well for the future.
According to W3techs figures Debian is used by 30.7% of all the websites who use Linux. Next is Ubuntu with 24.8%, CentOS with 19.8% and Red Hat with 4.9%. There are plenty of gainers in Debian's fall if and when it happens. I sincerely wish it never happens.
Enough conspiracy theories for the day
Cheers!!!

[vbrummond]

Edit: Ah, I didn't see Dilberts reply above which basically says the same thing.

Two very very critical components, kernel and init system, of the next Debian stable will be under the influence of Canonical and Red Hat.

Debian is made almost entirely up by software not made by Debian.

These are hard facts.

The word you are looking for is drama.

A tale of a big corporation, manipulation and Linux kernel,
Red Hat's "obfuscated" kernel source

Code obfuscation is not relevant to this issue. The kernel source comes from kernel.org, not redhat.com.

[confuseling]

1) Debian never developed an init system, and often imports kernel work done by other people. Feel absolutely free to dislike that, but don't pretend it's a change in direction.

2) Most Debian users use Debian because of its high maintenance standards - only qualified people get to make decisions. We didn't get to vote on the init system, and that's unambiguously a good thing. We don't vote on how bridges are built, or when surgery is necessary either.

[mor]

Decision makers at the top are busy in-fighting and promoting their own agendas and ignoring the voice of majority of Debian users (for example systemd).

(Emphasis added)

I am not challenging the validity of the statement, I personally wouldn't know what to say about it, but I can't help wondering if are you saying it as a speculation or if you have actual evidence to support it (I'm primarily interested in the underlined part)?

Bye

[hakerdefo]

Decision makers at the top are busy in-fighting and promoting their own agendas and ignoring the voice of majority of Debian users (for example systemd).

(Emphasis added)

I am not challenging the validity of the statement, I personally wouldn't know what to say about it, but I can't help wondering if are you saying it as a speculation or if you have actual evidence to support it (I'm primarily interested in the underlined part)?

Bye

Debian technical committee in-fighting evidence,
Debian Tech Committee Falling Further Into Disarray
If you search the three most visited forums by Debian users, Debian User Forums debian forums Linux Questions, for 'systemd' related threads you'll find that majority of people posting there are not happy with systemd as default init for Debian. While this is not a scientific evidence but it is still good enough to judge the mood of the users.
P.S. A couple of unscientific polls,
: systemd vs. upstart, or else?
Which init system are you using in Debian?
Cheers!!!

[Gyokuro]

The title is about Jessie's kernel not the Init system but in case that much users are against systemd what should be used instead so that the same people which are whining about systemd are happy again? The problem is the alternatives are not better as the elected one.

[vbrummond]

While this is not a scientific evidence but it is still good enough to judge the mood of the users.

That does not make it a wrong decision. People will always complain about everything, no matter what, whether they understand it or not. The developers voted on the issue.

[confuseling]

Further, it really isn't enough to judge the mood of anything other than a noisy minority, as you tacitly acknowledge by pointing out that it's not scientific. What proportion of users ever post on forums? Of those, what proportion engage in arguments, instead of just posting the occasional question? These people are anything but representative.

I strongly suspect if you did an actual poll, the winning answer would be something along the lines of "I don't really care, as long as my server works and is easy to administrate"...

[dasein]

It's impossible to argue with the clinically delusional.

(Just sayin')

[Linadian]

Ima gunna chime in on systemd, I really don't care what they use, as long as;
1) it's not buggy
2) it's not insecure
3) it's not annoying (as in goofy or stupid to use, I know, poor choice of words but let's face it, some things are)
4) It's COMPATIBLE, I tend to like cross-platform, I consider that a good thing for the Linux world
5) Although I'm not a maintainer, easy to maintain would be good, who needs more headaches?

Wikipedia always has some interesting takes, check out the chart below the 'Controversy' section.

Here is freedesktop.org's systemd page.

Edit: Another nifty chart, scroll down a bit.