Thoughts on Ubuntu maintaining Jessie's kernel ~ discuss

[Linadian]

This is carried on from a discussion in "Worrying trend" as suggested by vbrummond.

See this post, this post and this post for starters.

Edit: Admins: If this is in the wrong section, please move, thank you.

[vbrummond]

I was going to split the posts to here but it seems like they would be a bit out of context. For me, short answer, I would prefer the upstream LTS kernel but I am not really worried about using the 3.16 one, even if it means relying on Ubuntu. I'll have to take a look at the discussion about the issue on the mailing lists and post back what I think.

Edit: I think it starts here: https://lists.debian.org/debian-kernel/ ... 00008.html

[Randicus]

Unless I am mistaken, that is the discussion I linked to and quoted from in my rant thread. As I alluded to in the that thread, does it make sense for a major distribution to rely on one of its derivatives for maintenance of the kernel? Borrowing insignificant applications like Synaptic is one thing, but leaving the kernel in the hands of someone else? I do not believe such a short-term expedient would be beneficial in the long-term.

[Linadian]

Although it's comforting to know (now, I just found out) the Debian team would review changes to the kernel, I just don't see the practicality, judging by the lifespan of Squeeze and Wheezy, April 2016 is a bit short sighted for the length of support, which has been 2-3 years on average for each stable Debian release. Jessie goes in to freeze mode November 5 this year (2014), so if Jessie is officially released post freeze, let's say April 2015 for argument sake, that's only 1 solid year of support, unless Jessie is destined for a short lifespan on purpose.

Unless this is some sort of elaborate practical joke and somebody will set the record straight out of the blue (I'm having my doubts), the possibility of Canonical swallowing Debian is not going over well with some people.

Honestly, if there is no other higher LTS kernel available at the time of Jessie's official release and 3.14 is made available as an option, I would use 3.14 mostly for the longevity.

I know 3.14 likes my computer, I've had it installed (I'm currently using 3.2.x on purpose), where as some custom Canonical beta kernels hated my computer, this concerns me a little too.

Why do I get the feeling this move is to appease the Ubuntu development cycle as well? *adjusts tinfoil hat*

Just my 2/100 of a dollar.

[vbrummond]

Yeah, it seems this will only be supported as some kind of alternate kernel on Ubuntu? Though a part of the move is so that the RT patches will be available as well.

[hakerdefo]

How trustworthy and stable can an operating system remain when it's developers don't have much control over init system and kernel?
Cheers!!!

[confuseling]

Debian never did write the kernel or the init system though, did they? Nor, at a guess, many of the security patches they used.

As far as I can see the change here is the addition of the word 'Ubuntu'. Horrifying indeed.

If they don't contribute to the core stack, they get accused of freeloading. And if they do, they get accused of trying to take over.

Would it make more sense to you if Debian devs just did all the work again independently, on principle?

I mean cripes, what is it you actually want? If it's an operating system independent of any corporate interests then you're in the wrong place, have been for some time. Kernel fairies don't write the kernel. If it's an operating system with strong checks and balances in place that prevent undue influence by any one company (principally, the right to patch or fork whenever it disagrees with upstream, and a democratic process amongst its developers), then everything is still ticking along nicely.

[Randicus]

This is a quoting from something communicated to me.

I'm shocked that they can easily find people to maintain an absolute shitload of software in the Debian repositories, several different init systems, kFreeBSD and Hurd, yet have to get a 3rd party to maintain their kernel... it just confirms what I'd suspected all along about Debian - the project is just a sprawling directionless blob, with no one really prioritising and ensuring that the most important work/projects makes the top of the to do list.

I am only in partial agreement with the latter part, but in complete agreement with the first half.

Debian never did write the kernel or the init system though, did they?

Smoke and mirrors. You are ignoring the fact that if this happens, no guarantee, it would mean a "fairly significant part" (understatement intended for effect) of the system being out-sourced to a derivative. That alone should frighten people. Out-sourced to a derivative known for bugs, proprietary software and spyware should scare the Hell out them.

As far as I can see the change here is the addition of the word 'Ubuntu'. Horrifying indeed.

It would be disconcerting regardless of which distribution, but the word Ubuntu is the only thing you see? Really?

If they don't contribute to the core stack, they get accused of freeloading. And if they do, they get accused of trying to take over.

Maintaining an older version of the kernel for a distribution's own needs (long-term support) is contributing to the Linux world? No. Contributing to Debian? Possibly, but since when has Debian or any other major distro needed one of its derivatives to prop it up? The fact that developers are even discussing such a move shows that Comical's employees among them have gained some influence. If, again if it happens, it would be the official beginning of the merger. Until now it has been a slow takeover by infiltration. This would make it overt.

The looming spectre of systemd crap has already stimulated me to look at alternatives. If the kernel is handed over to Butnut, that would guarantee a change in distributions. Now let the Buntu apologetics continue.

[confuseling]

Debian have relied on RedHat's kernel support before, and the sky didn't fall in. Collaborative development is *the entire bloody point* of open source software.

Yes, the standard maintained by Ubuntu is not the same as that provided by RedHat or Debian (different focus, for one thing - their objective was *always* to be more updated and inclusive, ipso facto less stable and tested). But the developers working at the application level are largely not the same as those maintaining the kernel. Clue: many of the higher level Ubuntu devs are already DDs, meaning they've been through the same stringent evaluation as everyone else.

Show me evidence of Ubuntu kernel maintainers or developers introducing bugs at a higher rate than anyone else. Even better, show me evidence of Ubuntu developers introducing bugs that were passed upstream and not picked up by Debian review.

Or just keep posting childish rants about 'Comical' and 'Buntards', without any actual evidence that there's a problem...

[Linadian]

Debian never did write the kernel or the init system though, did they?

Smoke and mirrors. You are ignoring the fact that if this happens, no guarantee, it would mean a "fairly significant part" (understatement intended for effect) of the system being out-sourced to a derivative. That alone should frighten people. Out-sourced to a derivative known for bugs, proprietary software and spyware should scare the Hell out them.

Glad you said it (Randicus), I have a huge and warranted fear of the NSA, corporations have been known to 'co-operate' with authorities or have been infiltrated by them. I don't partake in any illegal activities but I do like my privacy. There is a right-wing agenda to push political activism off the internet and maintain it solely for commercial interests. The internet was originally created to share scholastic knowledge, not make a select few slime in suits more rich. There's nothing wrong with sharing code and bug fixes, it seems it's the control part people are having a problem with. So is Ubuntu going to release the updated kernels as GPL (as in available to anybody) before the Debian devs pour over them for official repo release? Or is this to be a behind the scenes interaction? Will average Schmoes have access to the same 'updated' kernels for examination at the same time Debian devs get them?

[confuseling]

Yeah, you're probably right.

Bring back the kernel fairies, all is forgiven.

[Linadian]

Yeah, you're probably right.

Bring back the kernel fairies, all is forgiven.

OK, I'll be the first to admit I'm no computer scientist or expert, but correct me if I'm wrong...on a normal average day, Debian would take the raw stable kernel from kernel.org, patch it up to run/'jive' with the rest of Debian, am I right? Have Debian's kernel maintainers suddenly turned in to lemmings and found the nearest cliff? Debian was around long before Ubuntu, people pick Debian for the stability and longevity, handing control of anything over to anybody else seems counterproductive. Is there cracks forming in Debian's foundation? Do I have to learn how to patch my own raw kernels from kernel.org now? If I have to start doing that, I might as well write my own distro. Some people, like me, dumped Ubuntu and its derivatives on purpose and chose Debian as a replacement, I hope the conflict of interest is becoming glaringly evident.

[reinob]

Borrowing insignificant applications like Synaptic is one thing, but leaving the kernel in the hands of someone else? I do not believe such a short-term expedient would be beneficial in the long-term.

It's not the end of the world. After all, you can always use your own kernel if you like, which obviously will not have either debian's or ubuntu's patches, but it's not like debian forces you to use this or that kernel.

Luckily kernel choice (and configuration) is still something that every Linux distribution has no problem with (after all, Linux is just the kernel). Unlike /sbin/init, where your options are limited to whatever the distribution decides to "package".

[reinob]

Do I have to learn how to patch my own raw kernels from kernel.org now? If I have to start doing that, I might as well write my own distro.

But why? what is so magical about debian's (or whoever's) patches?

I've used slackware, ubuntu and debian since like forever almost exclusively with my self-configured kernels straight off kernel.org. You can even free yourself from over-bloated initramfs's if you like.

If it's about security (as otherwise there's no point in patching old kernels) then you obviously have to trust whoever is patching your kernel. I see no reason to distrust ubuntu's kernel people compared to debian's. (and since debian decided to use systemd they have proved they're not "better" than the rest). Just use whatever works for you.

[confuseling]

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.

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