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, Interesting) by Anonymous Coward on Monday February 10 2020, @08:29PM (5 children)
You need to try configuring (not even necessarily building the end result) just to see how big of a clusterfuck the configuration menus have become. Lots of shit that is x86 or embedded processor only leaks into the configuration menus for unrelated systems. Various features that should be possible to disable for your specific platform can't be (permanent enabled checkbox). The amount of new configurable but not really configurable hardware Kconfigs in each new minor release of the kernel has become insane. And since the distro maintainers only ever use it was a make all modules config, none of the KConfig shit gets properly tested for non-all module usecases.
ARM is a secondclass citizen, and every other arch is 3rd or worse class.
(Score: 2) by DannyB on Monday February 10 2020, @08:32PM (1 child)
That sounds like the menuconfig system is not maintained with the modules it configures? Or at least its dependency graph is not maintained. Too bad.
Complexity might really be the measure of "kernel is too big" rather than how much disk or memory size it uses.
The lower I set my standards the more accomplishments I have.
(Score: 0) by Anonymous Coward on Monday February 10 2020, @10:08PM
Spot on. Complexity defines how well the idea is actualized. The other two are only measures of the medium.
(Score: 2) by Azuma Hazuki on Tuesday February 11 2020, @04:30AM (2 children)
You're not kidding. I used Gentoo back when starting Linux in 2004, but for a long time (2009-late 2019) have just been too hardware-constrained for it. I remember running it on an Inspiron 500m (Pentium-M "Banias" 1.3 GHz single core, 512 MB RAM) and having very little trouble finding everything necessary to run.
Flash forward to about 3 months ago when I got an amazing deal on a Thinkpad E495 (8GB memory, 256GB NVMe SSD, Ryzen 7 3700U 4C/8T). Granted, I now run LVM-on-LUKS, which is a more complex setup and required an initramfs, but for the life of me I cannot start from a clean "make allnoconfig" file and find everything I need. It compiles fine but sits there forever at "loading initial ramdisk...". Thankfully, booting an Arch liveUSB and running "make localmodconfig" gets a (mostly) working base which I can trim down and modify. But I still have no idea what I did wrong with the from-scratch attempt :/
As you said, entire categories of stuff just...fail to appear completely unless obscure other options are chosen. No warning is given about this.
I am "that girl" your mother warned you about...
(Score: 2) by The Mighty Buzzard on Tuesday February 11 2020, @03:17PM
It's still pretty easy if you're building for a headless VM or the like. Once you start doing it for actual hardware, especially on a desktop that you never know WTF you're going to want to attach to it a month from now, it gets a wee bit more difficult. Such are the perils of hardware advancement and variety.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Wednesday February 12 2020, @03:13AM
Probably passing "quiet" as a kernel parameter or turned down the configured log level, you selected the wrong CPU architecture, you mismatched the microcode, you didn't generate the ramdisk properly by configuring mkinitrd and running it, or a mismatch in compression algorithms for the initrd. In my experience, those are the five most common reasons that pops up. Well, other than not having enough memory/disk space, which seems unlikely here.