Linux 4.17-rc1 Kernel Released: A Ton Of New Functionality While Shedding Old Code

[rene]

The nice thing about an open source kernel is that some enthusiasts can (and probably will) maintain out-of-tree kernel patches for those older platforms.
Those archs just won't be in the mainline kernel anymore.

Your comment sounds really arrogant. Do you even contribute code? Also: never say never.

[dungeon]

Linus started kernel for i386, and 5+ years ago they decided to drop that too as "it required extra work involved in continuing support not outweighing the resulting benefits"... blah, blah.

We could copy/paste that for any old arch, obsolescence will be for any arch sooner or later, even for plain x86_64 as Intel currently care only really about Haswell or newer

[-MacNuke-]

why not? I love security and bug fixes.

Linux is not a preservation project for obscure and outdated hardware. If nobody wants to maintain it then it gets removed. The developers can't care for every hardware somebody has somewhere just for fun. If you care that much -> get involved and help. You simply can't assume that someone else fixes your problems until you die.

[rene]

Linus started kernel for i386, and 5+ years ago they decided to drop that too as "it required extra work involved in continuing support not outweighing the resulting benefits"... blah, blah.

We could copy/paste that for any old arch, obsolescence will be for any arch sooner or later, even for plain x86_64 as Intel currently care only really about Haswell or newer

when in reality i386 support boils down to just some thousands lines of code, … i386 is simple, all the modern shit however is complicated and buggy like hell ;-) https://www.youtube.com/watch?v=afwIZDtrRj4

[Djhg2000]

Colors are way off for me when testing 4.17rc1 on Debian Sid and R9 Fury. Everything is very dark. I've seen the same problem before when trying amd-staging-drm-next. Also, ROCm OpenCL still not working but I think it needs updated userspace bits before it will work on upstream kernel so I was kinda expecting that not to work.

I think it's related to the new color management code. For me it happens on Wayland but not on X.Org (which AFAIK still uses the legacy pathways for color compensation), so I guess the code simply isn't ready yet. Would be great if bridgman could enlighten us about this.

I use both Raven Ridge (GPU works great so far with 4.17-rc1) and Polaris on Debian Sid, I have upgraded to Mesa 18.0 from Experimental though so I can play with DXVK.

[randomsalad]

A little bit bitrot is easer to fix and get working again than something entirely gone.

But it's not gone. It's not available for Linux 4.17+ because there's noone to maintain it, but the code for those archs as it existed as of 4.16 is still there, and probably always will be there so long as there are copies of the Linux git repo. And literally anyone can bring that code back into the kernel if they so wish; The only requirement is that you or someone else takes the time needed to maintain the code.

[rene]

But it's not gone. It's not available for Linux 4.17+ because there's noone to maintain it, but the code for those archs as it existed as of 4.16 is still there, and probably always will be there so long as there are copies of the Linux git repo. And literally anyone can bring that code back into the kernel if they so wish; The only requirement is that you or someone else takes the time needed to maintain the code.

I already explained that bringing code back later is much more work, because all the api changes you do not know about needs to be figured out, while they could usually be simply and naturally be done by some substitution while the author of the API changes is doing it. Here, I dedicat today's video to you and all the other code deleters: https://www.youtube.com/watch?v=XYsKct4T2xk

[rene]

The nice thing about an open source kernel is that some enthusiasts can (and probably will) maintain out-of-tree kernel patches for those older platforms.
Those archs just won't be in the mainline kernel anymore.

yeah, look how well that works, and how many runs Linux on a mips64, ip30, Octane: https://t2sde.org/packages/linux-ip30

[FireBurn]

it is not as easy after a year or two, and hundreds of renames and shuffled API arguments. When someone changes something they knew what they were doing and they can sed -i s/// easily, after a year or two, and someone who has not done the hundred changes in between this is a really tedious task. Getting my Sgi Octane booted with a modern Linux kernel took me the better half of my free afternoon, weekend and night time of December: https://www.youtube.com/watch?v=AU_RV8uoTIo

It's a tedious task doing this in the first place, with nothing to test it on - which is why they're removing it. Keep using a stable kernel or get a maintainer to keep the code up to date and tested regularly

[baka0815]

Your comment sounds really arrogant. Do you even contribute code? Also: never say never.

I'm sorry if I hurt your feelings somehow, that wasn't my intention.
However I don't understand what you want to say with "never say never" - that doesn't fit with my comment.

it is not as easy after a year or two, and hundreds of renames and shuffled API arguments.

That's exactly the point of removing code.
All those renames would need to keep track of the old code, making sure that you don't break stuff.
That may be architecture none of the (active) devs uses, so no one can check if the code still works.

If the codes would have (enough) active maintainers, it wouldn't get thrown out so easily.