SoylentNews is people
SoylentNews
This kernel is simply huge: there is so many new and improved features with this particular release that it's mind-boggling. I'm having difficulty remembering such a time a kernel release was so large.
The quick summary of Linux 5.6 changes include: WireGuard, USB4, open-source NVIDIA RTX 2000 series support, AMD Pollock enablement, lots of new hardware support, a lot of file-system / storage work, multi-path TCP bits are finally going mainline, Year 2038 work beginning to wrap-up for 32-bit systems, the new AMD TEE driver for tapping the Secure Processor, the first signs of AMD Zen 3, better AMD Zen/Zen2 thermal and power reporting under Linux, at long last having an in-kernel SATA drive temperature for HWMON, and a lot of other kernel infrastructure improvements.
(Score: 2) by DannyB on Monday February 10 2020, @11:00PM (11 children)
It would seem to me that having all of the kernel modules available on disk has no significant penalty. It merely costs disk space. Nothing more. If you plug in a new hardware item, you already have a driver immediately ready to use. That's convenience. Or alternately, go through a Windows-like experience of "searching for driver . . ."
The lower I set my standards the more accomplishments I have.
(Score: 4, Insightful) by Runaway1956 on Tuesday February 11 2020, @01:37AM (5 children)
That "searching for driver" experience is vastly different on Linx, vs Windows. Mostly, the drivers are found via the package manager, whether it be RPM or APT or whatever. On Windows, if you don't have an installation disk, then you go to Google. Google doesn't mark the results with tags like "reputable source" or anything. Unless you know what you are doing, you can easily download a boatload of malware, and install it, instead of the driver you were searching for. Alternatively, you can find an outdated driver, which may or may not work for your particular hardware.
Both worlds have their problems, but I think Linux problems are a lot easier to solve reliably than Windows.
(Score: 0) by Anonymous Coward on Tuesday February 11 2020, @06:28AM (4 children)
I wish they would just compile statically. Give up on the dream of upgrading each package separately. Huge, static globs of binary for each program you use that I can run off a USB. That is actually my idea of perfection in software - it never breaks after upgrade. You can run off a USB stick. It never breaks(*).
(*) Shut up.
(Score: 2) by DannyB on Tuesday February 11 2020, @02:40PM (3 children)
Maybe another alternative . . .
Maybe it is time that Kernel developers consider the possibility of . . . OMG . . . having a standard kernel driver API. Not for all possible kernel modules, but for device drivers. It seems device drivers are the vast majority of kernel source code, or so I am under the impression. If necessary later, introduce a 2nd improved kernel driver API. Surely enough is understood about what kernel access a device driver needs after about 30 years?
Another idea, multiple standard interfaces for different kinds of drivers. Eg, filesystems. Direct memory access drivers. Video devices. Etc. A single driver could implement one or more of these interfaces.
The lower I set my standards the more accomplishments I have.
(Score: 0) by Anonymous Coward on Wednesday February 12 2020, @02:52AM (2 children)
from the executive summary of https://www.kernel.org/doc/html/v4.14/process/stable-api-nonsense.html [kernel.org]
(Score: 0) by Anonymous Coward on Wednesday February 12 2020, @02:56AM
Should have linked this version https://www.kernel.org/doc/html/latest/process/stable-api-nonsense.html [kernel.org] or https://www.kernel.org/doc/html/v5.6-rc1/process/stable-api-nonsense.html [kernel.org]
(Score: 2) by DannyB on Wednesday February 12 2020, @08:44PM
I can't, or don't, or shouldn't have a strong opinion on this. I don't write kernel modules. So I'll defer to those who do. Thanks for the info.
The lower I set my standards the more accomplishments I have.
(Score: 2, Informative) by The Mighty Buzzard on Tuesday February 11 2020, @04:20AM (3 children)
Having the necessary functionality for a specific module to even hook into does cause very significant overhead. Having a specific SATA driver, for instance, built as a module is not the same as not even having SATA support in the kernel. If you know you're never going to need any hardware but what you currently have, you can shrink the complete fuck out of the kernel.
My rights don't end where your fear begins.
(Score: 2) by DannyB on Tuesday February 11 2020, @02:45PM
That is another useful thing about the kernel, its adaptability for small devices with fixed hardware. Wristwatches. Cameras. RoKu, TiVo. Thermostats. And who knows what else.
The lower I set my standards the more accomplishments I have.
(Score: 2) by DannyB on Tuesday February 11 2020, @10:36PM (1 child)
That makes sense. Having support for the module in the kernel is a non-zero cost, in addition to disk cost of the module.
The lower I set my standards the more accomplishments I have.
(Score: 0) by Anonymous Coward on Wednesday February 12 2020, @02:45AM
Not to mention that some modules and CONFIGs are mutually exclusive.
(Score: 2) by RS3 on Tuesday February 11 2020, @06:42PM
In fact it's probably net zero. It's about the same size as a module or compiled into the kernel.
You could argue that the kernel usually resides in a separate partition than /lib, but either way, kernel modules are pretty small.