
Thanks!
Again thanks to all who code and work to improve the kernel. Cheers!
As anticipated last week, version 4.12 of the Linux kernel landed Sunday amid a storm of … well, placidity, as it happens. Linus Torvald's release announcement is suitably low-key for something he expected to land without fuss. “Things were quite calm this week, so I really didn't have any real reason to delay the 4.12 release …
Sanders rolls his eyes.
Mate go inform yourself a bit more.
Nothing stops anybody from distributing drivers that are not in the kernel.
Drivers are distributed with the kernel because they are maintained along the kernel as the internal ABI of Linux changes from kernel to kernel. (yes, done on purpose)
Also the drivers in Linux usually cover "entire device families".
What John said. Learn how it works before commenting.
AC said that they thought it was crazy that linux ABI version changes per kernel release, John's comment suggests they do this, and indeed it's deliberate??
They didn't say you couldn't distribute separate drivers, merely that it'd be nice if you had a stable and well defines and versioned ABI. (Well, that's how I read it anyway). This isn't a bad thing, and one of Linux's major weaknesses.
After all, Linux is the worlds most common kernel (as the underpining kernel for android) , I guess they must have got something right.
Linux has done many things right, you may argue that not getting sued by AT&T helped a bit. :) As did not being Hurd.
However, if you take any lessons from Linux, don't let it's driver model be one of them.
Google is attempting to address this in Android with it's project Treble. It may eventually end up going further than that....
"Drivers are distributed with the kernel because they are maintained along the kernel "
That's part of the issue being raised above. Drivers should ideally be distributed and maintained separately!
As an example if I get a new Linux kernel I have to test not just the kernel works, but also that all the new drivers work too. That's far from ideal. I should be able to by default change them separately so that I can isolate where a problem lies more easily.
If the internal ABI changes then it should be a matter of simplicity to check if a driver was built to a compatible version... If the ABI / ELF build really changes that much and that frequently then that's going to break loads of other stuff too - such as drivers that don't ship with the kernel... And if that's deliberate then it's extra sucky.
You can avoid a lot of the driver clutter by using the Linux-libre kernel. Linux-libre strips out all the proprietary driver blobs from the kernel, and is used as a primary or alternate kernel by a wide number of distributions, including Debian, Arch, Gentoo, and Slackware. My personal favorite is Parabola - an FSF-approved variant of Arch Linux - which only uses the Linux-libre kernel. FSF-approved Ubuntu variant Trisquel is also based on Linux-libre.
Linux-libre is supported by a strong community, which usually puts out its blob-free kernel within just a few hours of Linus's release of a new kernel version (including point releases).
Why should Linux pander to the needs of closed-driver distributors. A moving-target API works (better than) fine with drivers that are being actively maintained (especially, but not exclusively, in-tree). If you want to rely on crufty, buggy, insecure, un-maintained, closed (and/all of) drivers, well, there are others OSes for that already.
Linux (and the GNU around it) was explicitly designed to be open, and has no need to devote limited resources to catering to the whims of the closed.
Why should Linux pander to the needs of closed-driver distributors.
It shouldn't. A well defined ABI isn't 'pandering to closed-driver distributors' it's just good software engineering. Just because Linux doesn't do it doesn't make it wrong. (The IOKit interface in OSX is available as part of Darwin for example).
A moving-target API works (better than) fine with drivers that are being actively maintained (especially, but not exclusively, in-tree).
Why does it? Why is it better than a proper ABI? (The in source drivers would still exist, they'd just conform to it).
Also there are some drivers that are essentially done, they make their old, possibly unmaintaned hardware work. Why should they require source code changes and the associated testing/qualification/packaging/documenting just because there's a new kernel version. If there's a breaking, unavoidable change, then yes. (Not all NT4 drivers work on 32bit Windows 10 quite understandably after all).
If you want to rely on crufty, buggy, insecure, un-maintained, closed (and/all of) drivers, well, there are others OSes for that already.
Just becaise a driver exists on Linux doesn't make it a paragon of well written clean code. Crufty insecure buggy drivers are the preserve of all OSs, as are well written ones. Also, just being 'open' doesn't make it amazing too. NetBSD has had a much better designed hardware interface layer for years now, and that is open. (Not GPL though).
Linux (and the GNU around it) was explicitly designed to be open, and has no need to devote limited resources to catering to the whims of the closed.
But what does that have anything to do with the poor driver ABI? It would save some of the limited resources surely? You can be idealistically superior but if no one uses you then you'll have very little hardware to drive. Look at the mess with Android and it's poor security updates, a modular, well defined and versioned ABI would at least allow Google to push out Linux updates to devices that supported it (which would be checkable at update time). It's not a coincidence there are efforts afoot to improve this situation.
Maybe I'm wrong, I've probably just spent too much time messing around trying to get various DVB devices to play nice together. It just seems mental to me that the manufacturer supplied drivers rebuild the entire DVB subsystem; at least it's their fault for being closed source and not Linux's for being poorly designed in this regard.
". A moving-target API works (better than) fine with drivers that are being actively maintained"
So with Linux my printer driver might stop working as soon as the manufacturer stops selling that model and bothering to update the driver?! No wonder no one uses on desktops...
"So with Linux my printer driver might stop working as soon as the manufacturer stops selling that model and bothering to update the driver?! No wonder no one uses on desktops..."
Maybe you should stop doing your IT purchasing in the supermarket/superstore stationary/IT section?
And if the driver is open, anyone can update it (which generally just means it being recompiled along with all the others - the API moves about a bit as the kernel goes through various optimisations over time, but it doesn't generally run away from you and hide.)
"I've got a great idea. Don't ship any drivers with Windows"
The above is not suggesting that you don't ship drivers as part of an OS distribution. Just that it's not great to tie them directly into kernel updates...
Quite.
A PC here became terminally ill recently. It was possible to take the hard drive out and stick it in another PC - different CPU (different maker of CPU!), obviously different motherboard, different graphics card, different expansion cards - and have it boot up Linux without a problem, ready for work in 30 seconds.
Try that with a Windows hard drive.
"Try that with a Windows hard drive."
It's easy. All you need to do is change the SATA driver from the manufacturer specific optimised one to the Microsoft generic one before you remove and swap the HDD... Everything else will auto configure if the drivers are present or you can install them if not.
SATA might well work. Things like the network chipset driver, the graphics driver, and much else will not. You can be stuck with the need to update a PC that has no network connection (the network driver) and will only boot into 800x600 (the graphics defaulting to VESA SVGA). Good luck.
Amazon Review:
Its been 17 years since I started using Linux and I have to say it hasn't whitened my teeth, my dog still has fleas and my shit still stinks.
That said my PC is faster, more reliable and generally more pleasurable to use. Which is a bonus.
If you use this product don't expect it to do what it isn't designed for like I did. You'll be left confused.
Would recommend to a friend with caveats above.
5/5
damn straight. I run win10, server 2012r2, mint 18.x branch and centos 6.7/7.x here.
really tired of rebooting after the multitude of critical updates pushed onto the nix systems every 3 days.
least with windows you don't have to waste 30 minutes rebooting after every few updates apply more updates rinse and repeat.......
This post has been deleted by its author
Ryzen features were mostly added in the 4.10.X series (and I believe support for AM4 audio chipsets came in 4.11.X). I'm running Fedora 26 beta on my Ryzen system because of that and it works fine. Distros running pre-4.10 kernels (e.g. LTS versions such as CentOS 7) might have problems, even trying to be installed on Ryzen.
from, I've read any from ubuntu version 16.10 and older has issues with ryzen. That includes Ubuntu 16.04.2 LTS. With the last two version of ubuntu I've had issues on AMD chips. I'm still having issues with the latest version of ubuntu on my Ryzen system. It does not all ways boot into it and when it goes to sleep it does not wake up. So I don't know why that AC was down voted.
GF runs Windows 10. Hates updates because they invariably demand a reboot at the worst possible time - and yeah we've done everything possible to schedule them for a sensible time.
Her other fear, from long experience, is that every update will "break" something, which is why she delayed replacing her XP box until the hardware died. (Having spent the last year beating Win10 almost into submission, I tend to think she was right.)
Meanwhile I picked up nice used laptop last week. I did no research, just downloaded a distro to a USB stick and had a fully working linux install in about 25 minutes. Including disabling CapsLock and letting updates install. I let my other machine update whenever it asks, and can't recall ever having a problem.
What does Linus know that seems to be so beyond Microsoft?
"GF runs Windows 10. Hates updates because they invariably demand a reboot at the worst possible time "
Windows 10 lets you defer updates repeatedly - it doesn't "demand" a reboot - it just tells you one is needed.
"- and yeah we've done everything possible to schedule them for a sensible time."
The Windows 10 update settings allow you to chose an up to 18 hour window each day when it won't try to install updates. Unless you work in a Redbull factory that should be enough!
"and had a fully working linux install in about 25 minutes"
Installing a clean build of Windows 10 from scratch onto a used Dell laptop from a USB 3 key took me 14 minutes today for the x64 version.
Just a month ago I tested 6 different kernels (4.4- 4.10) with my quite new laptop. In each case at least one hardware competent did not work properly, from the lit keyboard to power management to wi-fi. And the newest kernel was not the one I decided to stick with.
The kernel should get stable at some point and stable means as few code changes as possible. 4.12 had over a million of LOC added, is there any other software piece which changes that much at that frequently?
@Korn - "Just a month ago I tested 6 different kernels (4.4- 4.10) with my quite new laptop. In each case at least one hardware competent did not work properly, from the lit keyboard to power management to wi-fi. And the newest kernel was not the one I decided to stick with."
Vendors need to write drivers for your gear. No kernel on earth - not from MS, not from Apple, not BSD - is going to run all your gear perfectly without proper drivers. There's only so much you can stuff into a single kernel.
All of them were official distro kernels, all updates done via the package manager, no manual hacks.
I did investigate a few issues more deeply and they were genuine bugs i.e. reported problems found in the kernel code. As I said, if each kernel release means thousands of code changes, such things will happen.
@korn - "I did investigate a few issues more deeply and they were genuine bugs i.e. reported problems found in the kernel code. As I said, if each kernel release means thousands of code changes, such things will happen."
Fair enough, you did your due diligence. We've all run into regressions and bugs if we've worked with Linux long enough. I still have to wonder if the vendors aren't at least partially to blame - a lot of that code change in each new kernel is from the vendors making changes to their own previous submissions. With so many proprietary driver blobs, it's very hard to tell what changes they've made from one time period to the next.
@Andy
>Fair enough, you did your due diligence.
Notice how he never mentioned what the regressions are? They might not even be in the kernel.. they might be in out of tree drivers. Exactly zero details on something that he thinks is a major issue.
>a lot of that code change in each new kernel is from the vendors making
>changes to their own previous submissions.
I would like to see stats to prove that.
>With so many proprietary driver blobs,
So not things that are in the kernel. And how many blobs do you really have aside from firmware? Maybe one for a GPU?
>it's very hard to tell what changes they've made from one time period to the next.
Git has tools built into it to help you work out exactly what commit broke something. Linus only merges patch sets that have a clear set of commits to show how things changed so those tools are useful. If you know one version works and the next doesn't you have the complete history of changes broken up into bitesize pieces to work from.
"Notice how he never mentioned what the regressions are..."
See my first post: keyboard, wifi, etc. And from my perspective as a customer, I do not care what causes the issues. I switch to kernel 4.4, things work OK, I switch to 4.8, they don't. Back to 4.4, again OK.
ETC.
Did you try reporting the problems you are having somewhere that someone that can help you visits. I.e. the forums for the distro you're using, the bug tracker for the distro you're using or maybe the LKML?
>4.12 had over a million of LOC added, is there any other software piece which
>changes that much at that frequently?
I would suspect that Windows has similar levels of change between major releases. The difference with Linux is you can if you really want back out patches until you find the one that broke something for you. If you can't do the legwork to track down the issue yourself you need to make your issue known to people that can.
"Did you try reporting the problems you are having somewhere..."
Some of them I did. But most were related to my laptop brand, and testers would need the exact same model (or line) to reproduce them and fix.
"I would suspect that Windows has similar levels of change between major releases."
True, but there is a new Linux kernel version every 5-6 weeks now! MS handles it differently.
My grub lists over 15 kernels now, I can use whichever I want but this won't work for Linux newbies.
"Some of them I did. But most were related to my laptop brand,
and testers would need the exact same model (or line) to reproduce them and fix."
Probably not actually. If you can tell people which versions work and which don't it's very possible someone can find the roughly what patch or patch series caused the change.
I suspect your issue is that you went onto a forum and said something vague like "why kernel have regression. My compooter no work no more!" and no one could help you because you left out any details of the actual issue.
"True, but there is a new Linux kernel version every 5-6 weeks now! MS handles it differently."
Unless you run gentoo or similar it's very unlikely you have anything that's close to mainline on the day it drops. Many distros use LTS kernels that are updated much less frequently.
"My grub lists over 15 kernels now, I can use whichever I want"
So open an issue on the bug tracker for your distro's kernel package and report that XYZ stopped working between kernel x.x.x and x.x.x. It's very likely that if it's a real regression it's already in their bug tracker.
"but this won't work for Linux newbies"
Did you pay for the distro you use or a support contract? You got a very nice kernel and set of software for (probably) absolutely nothing. It doesn't come with free lifetime hand holding. Most distros have support communities that go out of their way to help people but no one has unlimited time to waste on people that don't help themselves.