This summary page is a nice reminder of what an awesome project Linux actually is.

If you recall the fact that this is a collaborative efforts of a distributed team of volunteers (although a big part of them backed by companies), it is simply amazing to look at the size and complexity of what came of this project.

Just wish that what is built on top was not such a tire fire of egos and misplaced priorities.

I assume you are trolling, but I still want to say that:

- Linux is built by developers, it is not built on top of personality traits.

- Developers must have a minimum of ego to be able to believe in the possibility of creating working code.

- The priorities have been good enough to make Linux a very successful project.

While I don't disagree with your point, your argument is a poor one. "must have a minimum of ego" is a requirement for any productive endeavor. Software development is not a special case.

"is not built on top of personality traits" is parsing the complaint too literally. It's unquestionable that the personality traits of those in charge turn many people off from wanting to contribute.

Finally, the fact of success is very weak evidence that any particular personality trait involved was necessary to that success. It's a fallacy of the successful to believe that their path was the only one that could be successful, but at least they have reasons for believing that to be true. It's silly for observers to fall into the same trap of false logic.

For a comment that talks about taking things too literally, I think you've pinned too many of those separate points together. There was no suggestion that, for example, Linux is successful because of the way Linus talks to developers. It could be despite it.

But I will say that a lot of the people complaining about it have absolutely zero experience developing at even a fraction the scale Linux works at. Thousands of large contributions from hundreds of developers every release. Keeping a handle on that demands a strict submission framework.

But sure, everybody and their mother has a go at Linus because after two decades hammering out these rules, he loses his shit when developers and companies submit crap that ignores the basic minimum requirements for submission. I don't think you can say that his curt approach has done more harm than good. I'm sure it does both, to different audiences.

Linux the kernel, yes. Linux the OS, only if you ignore anything beyond the server rack.

The original post is about Linux, the kernel.

And it is an excellent kernel, held back by the constant deck chair shuffling, and resultant breakages of APIs and workflows, that happens above it.

>It bumps the limits to 128 PiB of virtual address space and 4 PiB of physical address space. This "ought to be enough for anybody" ©.

The © in the quote is a nice touch.

dank humour ;)

It's a reference to a 1970s quote (probably mis-)attributed to Bill Gates: "640 kB ought to be enough for anybody". https://google.com/search?q=ought+to+be+enough+to+everybody

How is that dark?

typo .. I meant dank humor

I've been on 4.14 since last week when I built my new Ryzen system and realized for some reason lm_sensors wasn't working, apparently AMD hasn't realized full specs yet which is a little frustrating. Updated to 4.14 via the very awesome https://wiki.manjaro.org/index.php/Manjaro_Kernels tool and loaded nc6775 module and all is well.

It might be in 4.15: http://lkml.iu.edu/hypermail/linux/kernel/1711.1/03366.html

I've been running mainline kernels for years. Upgraded to 4.14 this morning using Ukuu on Cinnamon. As expected - no problems to report.

(Dell XPS 15 9560, Cinnamon 18.2)

> using Ukuu on Cinnamon

You probably meant to say "Ukuu on Ubuntu". I'd be disturbed if my desktop were involved in kernel space.

What is Ukuu?

According to Google, a GUI for installing newer kernels on Ubuntu.

I guess I should have just googled myself.

These release summaries KN publishes are awesome (and to be fair far from simple summaries!). I recall reading every one of them back in the days, only to learn about random stuff I've never heard about before. On the other hand, the ridiculous amount of "commit" links in the generated page... :-)

Anyone experience with switching from Radeon to AMDgpu driver? I am contemplating a switch here.

I am using an AMD APU A8-7600 with X11 and XFCE desktop. Am also using KMS for booting. Only very sometimes I paly a game. I do watch a lot of videos.

Any gotchas? Is it usable yet? And I am not misunderstanding things, right? :)

My desktop has an R9 Nano (using a GCN 1.2 aka Fiji core) from 2015. I've been using AMDGPU since Linux 4.5 and couldn't be happier. Everything that I do works as intended, from desktop compositing to Minecraft to Steam games (no AAA stuff, but e.g. Cities Skylines and Portal 2 work flawlessly).

(Haven't tested OpenCL, multi-monitor and HDMI audio, though.)

So IMO, if your GPU is supported by the AMDGPU driver, by all means give it a try.

> no AAA stuff, but e.g. Cities Skylines and Portal 2 work flawlessly

Do you get playable frame rates? Cities: Skylines pretty quickly falls to 20-30 fps even with a recent Nvidia card with closed Windows drivers, wondering how is the experience with AMDGPU.

Not sure how well the APU's are supported on amdgpu yet, however, I used the amdgpu driver with a RX560 and RX570, in both cases it was incredibly stable and a simple matter of telling the mkinitcpio config to use the amdgpu module and not the radeon module when building the initramfs.

KMS should be supported out of the box with amdgpu.

Thank you for your reply. I will give it a try then.

> This kind of feature is also appearing in various other operating systems.

How many other OSs are there in active development that have this feature?

I had no idea wtf you were referring to, so to save everyone else the wondering:

> Heterogeneous Memory Management for future GPUs

Good point. Copied first part, pasted second over, went away to work ;-)

I'm experiencing USB issues. New kernel won't recognize my external HDDs that I connect through the USB 3.0 hub.

Reboot once in case the update forgot to keep the DKMS files (Arch problem, usually, but sometimes apt messes this up too)

Check your BIOS settings.

If that doesn't help file a bug with your distro (more likely to be the problem) or consider informing someone working on the USB subsystem of a regression if it's truly a kernel problem.

I use Arch so you're onto something. I have rebooted but it does not help. I've tried the 4.9.x LTS kernel and it has no issues. It's definitely the new kernel issue.

What's the best place to file a bug?

You can file a bug in the ArchLinux bugtracker.