Slashdot Mirror
Linux Kernel 4.11 Officially Released (softpedia.com)
prisoninmate quotes Softpedia: Linux kernel 4.11 has been in development for the past two months, since very early March, when the first Release Candidate arrived for public testing. Eight RCs later, we're now able to download and compile the final release of Linux 4.11 on our favorite GNU/Linux distributions and enjoy its new features. Prominent ones include scalable swapping for SSDs, a brand new perf ftrace tool, support for OPAL drives, support for the SMC-R (Shared Memory Communications-RDMA) protocol, journalling support for MD RAID5, all new statx() system call to replace stat(2), and persistent scrollback buffers for VGA consoles... The Linux 4.11 kernel also introduces initial support for Intel Gemini Lake chips, which is an Atom-based, low-cost computer processor family developed using Intel's 14-nanometer technology, and better power management for AMD Radeon GPUs when the AMDGPU open-source graphics driver is used.
VMWare Workstation/Player 12.5.5 also needs some love.
VirtualBox has already been made compatible. Thanks, Oracle for keeping it up to date.
Lastly, a human readable changelog is always where you expect to find it: https://kernelnewbies.org/Linux_4.11.
A big THANK YOU for all the hard work to all contributors.
I cannot imagine using a system built on top of anything else than Linux. ;-)
The worldwide supercomputers and HPC clusters tend to agree with me
"Eight RCs later"?? Methinks they need to stay in beta a wee bit longer next time.
Welcome another round of API/ABI breakage: even the latest beta NVIDIA drivers 381.09 are not compatible with this kernel.
Meanwhile, opensource drivers, that are part of the kernel all work.
Intel's opensource driver :
- development paid by Intel themselves
- works with Intel's own opensource openGL driver)
IT WORKS
AMD's opensource driver :
- development paid, among other, by AMD themselves (but also by Valve)
- works with both the opensource driver (whose developement was among other paid by AMD, and is considered the future official driver)
- and the closed source AMDGPU-PRO (that AMD is putting, until the opensource catches up (openCL and Vulkan not up to par yet *) and for the few professional CAD workstation users that needs some weird feature that AMD is never bothering to port to Mesa)
IT WORKS.
Only NVIDIA persist in doing things their way (because it enables them to simply cross-compile** their Windows drivers to Linux, even if that breaks most facilities used by everybody else - see Optimus, etc.).
And only collaborates once in a bluemoon with the Nouveau developpers when it helps their agenda with Tegra mobile GPUs (where Linux support is a must).
(And because of that, even the opensource Nouveau that had to be developped from scratch by unrelated 3rd parties - is problematic)
INSERT LINUS' "FUCK YOU NVIDIA" PIC
So stop blaming Linux dev's for Nvidia's wrong doings.
Everyone else plays nicely with Linux and it works.
Only Nvidia decide to fuck up everything and go against everyone else and you see the end result.
---
* : OpenCL is in the process of getting ported by AMD on their ROCm opensource computing platform. Once that is done, AMD will officially have a good quality opensource OpenCL.
Vulkan: has a closed source implementation inside AMDGPU-PRO that AMD has promised they'll opensource (but they're VERY LATE with the legal review necessary to release the code). Meanwhile a couple of opensource developpers have released RADV which works with most Vulkan games (including through Wine), but isn't complete (still misses tons of extensions that aren't widespread in game) and isn't very performant yet (well of course, it's a very recent addition) (AMD has considered putting priority to opensourcing of those bits of AMDGPU-PRO's Vulkan that could also help RADV developpers the most. But again, they're really behind with these opensourcing efforts.)
** - AMD decided to go the other way around : they wrote an entirely new abstraction layer (called DAL / DC) to be both usable under Windows and Linux and for closed source and Mesa drivers.
Problem : that layer has been written by veteran *windows* developpers at AMD, not AMD's usual opensource inhouse crew.
And it shows.
It makes Linus' eyes bleed.
So currently it's not yet in vanilla kernel, it's still being reworked into something more acceptable.
Once it's done, the last few missing features (e.g.: HDMI, Freesync, etc.) should also work with maintstream kernel on Radeon GPUs.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Kudos to Manuel for fixing this thing that's annoyed me for a good twenty years.
Impressive how small the feature patch is!
I'll be setting vgacon.scrollback_persistent=1 on my bare-metal x86 machines.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Different AC here. That probably wasn't a joke. At least, I don't read it as a joke.
It's actually a very serious issue. When I deploy a Linux system, I need to have at least some assurance, however small, that what's being deployed is reasonably robust.
Back before systemd, I could do that by using Debian. It was very robust. Changes were small and incremental, and problems were caught quickly because of this, the rare times they even happened at all. Since separate, independent packages handled much of the core functionality, it was easy to skip an update or two if it was suspected it might cause problems. And because separate, independent packages were used, a problem with one package usually didn't affect others too seriously, if at all.
Systemd changed the equation. It changes much quicker, and includes fare more sweeping changes. Routine updates to Debian that would have gone off without a hitch before started going haywire for me once systemd was introduced. With systemd touching so much, it became very difficult just to determine what might break. An update affecting systemd could break everything from logging through to networking through to logins through to all of the other things that an init system handles.
I ran into so many problems with systemd that I was left with no choice: Linux had to go. I switched the workstations and servers I manage over to FreeBSD, and haven't looked back. As far as I'm concerned, Linux is dead. Even if systemd were removed today, I'd have little incentive to move back to Linux. FreeBSD offers the best part of Linux, without the drawbacks.
The real question here should be, "Why are they hooking directly into the kernel?", which leads to a followup question, "Why doesn't the Linux kernel offer a proper API for this functionality?"
I don't know the specifics of this situation, but I very much doubt that these driver writers are interfacing with the kernel in such a fragile way because they want to. No developer would want to develop that way. So the most likely reason why they're doing it that way is because they're forced to, due to the Linux kernel not offering a proper, stable interface supporting what the driver needs.
It doesn't matter what kernel we're talking about, it's hard to blame the driver developers if they're forced to work around a kernel that isn't providing them the functionality they need to properly support their hardware.
The typical /. user these days is a Trump-voting UX whore. You can't tell if their limp-wristedness is coming from frustrated interior-designer personalities, or carpal tunnel consequent to masturbating over disadvantaging the poor and unhealthy.
Comment removed based on user account deletion
Only the latest generation of AMD card is somewhat useful - and it benchmarks well below any nVidia card.
...for a smaller power budget and cheaper price.
AMD simply doesn't produce cards in the ultra-high-range category.
For years, the nVidia driver has had the odd quibble
Like Optimus not working at all on dual GPUs.
Like modesetting completely getting fucked-up on some laptops (including a few of mines).
Like display not surviving suspend/resume cycles on some laptops (including a few of mines).
(Note: all the above boil down to : Nvidia decided to not play nice with the kernel facilities that everybody else accepted to use, like DMA-BUF and KMS respectively).
AMD's drivers over that same timeframe have been horrible.
AMD's *closed source* driver (the old one : fglrx/catalyst) used to be horrible.
AMD also had provided documentation to opensource developpers (I think it started not long after acquiring ATI)
(And later on even had opensource developers on their payroll)
This enabled things like r600 and radeonsi drivers.
Which did work nicely (in my experience: even on the Radeon HD 3800 and 4600 I used to have back then).
To the point that r600 got quickly declared their official driver and fglrx phased out for that generation of hardware (VLIW, pre-GCN)
Don't whitewash the history of how things rolled out due to the latest 6 months of development work by AMD....
Don't demonize AMD based on their sole (old) closed source driver, while they have been putting (successfully) lots of exemplar efforts behind opensource for nearly a decade.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]