Keep on hacking
Wow, that is one unstable code base!
Linux overlord Linus Torvalds has loosed the first release candidate for version 4.8 of the Linux Kernel. “This seems to be building up to be one of the bigger releases lately,” Torvalds wrote on the Kernel Mailing List, but rates the update “fairly regular, with about 60% of the non-documentation diffs being drivers (gpu, …
Unstable? compared to what? Windows 10? What were you comparing it to?
As most of the updates were documentation that is clearly not ..... code.
As for forthcoming Surface support. We'll probably get it just as Microsoft announce
1) They have locked down the UEFI so that only Windows will boot
OR
2) They are stopping production of all Surface devices.
OR
3) They are dropping the Windows kernel and adoping Linux with the Windows 10 GUI.
Which is more likely?
"As for forthcoming Surface support. We'll probably get it just as Microsoft announce [...] they are stopping production of all Surface devices."
Microsoft has already announced that Surface 3 will be EOL'd at the end of this year. By then it will be a 2-year-old Atom Soc design already and you just can't sell old computers for full price unless you're Apple. :-)
JJ being a twat, again.
Compared to what, dufus? Letting alone that a recent compare point's Anniversary Edition is making the news for instability. The article is all about relative weights of what's being changed. Ie x% drivers. Not how much % of the code base is being changed in absolute terms.
Are you really that dense? That you can't comprehend a short article in your native language? I mean it's one thing to be partisan. Or a troll. But a dim partisan troll?
This just shows what a heap Linux is. It doesn't have a proper modular device driver system. It just grows including support for every nasty and not so nasty processor and chipset that comes out.
It is also why combining parts from Google and Android device manufacturer is so problematic. The kernel and device support cannot be be separated.
I am well aware of kernel modules and written a few but they typically aren't very deep within the kernel don't help at all when the kernel itself has such an unstable ABI. Only last week I had to fiddle with some userland code, in fact the Python 3.5 socket module that broke because of a change in a minor kernel revision.
Only last week I had to fiddle with some userland code, in fact the Python 3.5 socket module that broke because of a change in a minor kernel revision.
Please elaborate, best with a link to Linux Kernel Mailing List archive. Linux have very strong rules for not breaking user code with kernel changes. Linus is know to personally jump into these kinds of issues, and has some very strong language reserved especially for the guilty developers.
>The "unstable" ABI is there for a very good reason; to piss off people like you.
Doesn't piss me off really as I don't have to support proprietary device drivers for a living (the only annoyance really is the whole NVIDIA dkms build thing but not much trouble once setup) More than likely having to use that shitty cram everything in the one userland process that can't go down (what could go wrong?) before I get to use this kernel version in the future bothers me a lot more.
Actually the devs probably aren't near as pissed about the ongoing maintenance required as those who have to pay their salary. But then again I don't own a hardware company so rather indifferent personally to device drivers these days (will admit Linux is far ahead of the BSDs especially for laptops though).
Depending on what you call "proper modular device driver system". Almost all device drivers are built as separate binaries, so it has one if that's what you are asking for. The ones which are under GPL usually sit in the single source tree of the upstream kernel, because that makes maintenance easier.
There can be drivers under GPL which are nevertheless not submitted (or accepted) into upstream, and there can be also drivers which are not under GPL, in both cases we are obviously talking about separate projects, meaning their development would not be reflected in kernel.
It seems you are referring to number of changes in drivers in the upstream kernel to imply on the availability of the drivers outside of it. Which makes no sense to me.
"It doesn't have a proper modular device driver system."
Unlike Windows that doesn't support backward compatibility with device drivers, and changes "modular device drivers" at the drop of a hat, forcing OEMs to do the work of conversion all the time.
"It just grows including support for every nasty and not so nasty processor and chipset that comes out."
Unlike Windows that only runs on ONE processor and a little bit on ONE ARM processor architecture.
>Unlike Windows that doesn't support backward compatibility with device drivers,
Honestly Linux is on the one extreme of very frequent ABI changes (dkms somewhat alieviates this but often requires keeping kernel source around). This means binary wise your driver on Linux has a very short shelf life (but if the source code is maintained and available can be built from source every version). The other extreme I understand is Solaris where a device driver binary often can work 4 or 5 OS versions (15 years) later. Of course Solaris doesn't have to support near as much hardware. And going back to your point about windows drivers, source is not even an option so ABI changes are the kiss of death unless new drivers are released by the manufacturer.
> Secure Boot has already taken care of that.
Ahem! http://www.theregister.co.uk/2016/08/10/microsoft_secure_boot_ms16_100/