Thanks for the followup, I found a couple of plasma-wayland packages (I forget if they were through apt or the software center, and i don’t know what the difference is) and tried them out. One of them I’m not sure what it added, but the other did seem to create the necessary file for my partner’s launcher to use plasma wayland. I don’t know if it’s a mint thing, but we always had to do a full reboot between using wayland and x11 window managers; if you just log out and choose the other, stuff would be borked.

It did really take off about 5 years ago.

I would go a step further and say that any time one of these MAC systems has to resort to user interaction to do its job, it’s a straight up failure case: the system simply didn’t have enough information to do its job, ended up doing no better than a blanket “block everything” config, and is asking the user to do 100% of the heavy lifting of determining what should happen.

So, when I hear

If someone is lazy or not knowledgeable enough to make the right decision…No automated system can protect [them].

I hear: “every access control system is fundamentally broken”. Which is fine, maybe that’s true, there’s a reason social engineering is so useful. So then all these systems should prioritize streamlining that failure case as much as possible: Tell the user what is accessing what, when, how, and then make it trivial to temporarily (with well defined limits), permanently, (or even volatile-y using CoW/containerization/overlay fs) grant or deny access as quickly and easily as possible.

Every other system you’re comparing SELinux, AFAIK, handles this case better, which is why users tend to prefer them.

For the record, I’m not arguing that SELinux is bad at the actual access control part, I’m only answering why people don’t like using it, which is how it handles the failure case part. Now it’s been a while since I’ve used SELinux and I’ve never used setroubleshooter, but if you tell me it actually streamlines all of this to be smoother than every other tool, then I’ll install it tonight!

How do you know when you’re letting through a valid access, an unnecessary one that could be a vulnerability, and an actively malicious one?

I don’t think anyone is saying throw out all access control, they’re just saying SELinux adds too much unproductive friction for everyday usage. You said it takes 15m to troubleshoot. But that’s not a one time thing, that’s 15m that scales with the amount of new programs and updates you’re running. And 90% of people aren’t even going to be able to tell they’re looking at a malicious access if they’re in the habit of always working around blocks that show up.

Ah that’s fair, I didn’t look closely

Is this running in your rc (i.e. every single time you open a terminal)? Even if it’s safe, I’d be annoyed by any delay.

So, when you say crippled kernel, do you actually mean you tweaked the kernel params/build to the point that it failed to boot? Or do you just mean you messed up some package config to the point that the normal boot sequence didn’t get you to a place you knew how to recover from and need to reinstall from scratch?

I think I’m past the point where I need to do a full reinstall to recover from my mistakes. As long as I get a shell, I can usually undo whatever I did. I have btrfs+timeshift also set up, but I’ve never had to use it.

In the modern parlance, i believe that counts as an OEM but the more accurate term that no one uses is probably a VAR

As i understand it, the OEM business has razor thin margins as it is. This seems like an aggressively unsustainable business practice, to the point that it’s making me wonder what their game is…

No, it doesn’t matter if the book is at a library or on my friend’s bookshelf, copyright law is literally the right to copy the thing. So if I make an illegal copy, I’m breaking copyright law. The “ToS” I’ve “agreed” to is the law of the country I’m in.

I’d venture to guess this isn’t the first time Linus has had to deal with devs who have ideological disagreements and one quits. It’s not also his job to keep that from happening. What he said is true, there’s a process they have for maintaining Linux, and it doesn’t involve flame wars on social media…it involves flame wars over email 😅.

But seriously, if a devs are going to get upset at each other and rage quit, it’s not Linus’ job to play mediator.

Is it using wayland? I think we were able to install KDE through the software manager, but only the X version.

If you had asked me Q1 a month ago, I would have said yes (and in general, it is a yes, with enough effort). But i run endeavour (arch) and my partner runs mint (which ships with the Cinnamon WM), and a few weeks ago I recommended that she try out KDE Plasma for its wayland support. Turns out, this is not something the mint community supports, you can’t just install it through their software manager, and the mint forums will all tell you to switch to another distro that supports KDE. Meanwhile, on arch, I expect to be able to install it through pacman, choose it from SDDM, and I’m done. Maybe tweak something in my .config, but it’s all downhill from there.

Just a datapoint. Some distros (and their communities) seem to be more receptive to experimentation than others, which can make trying new things easier/harder.

I would recommend fedora, debian, or endeavour + KDE/gnome. Good luck!

Wow, I’m impressed you actually got that working. Sounds like quite a hack.

Ooo, the MR it links to is 10mo old and still open.

Ahh, I always wondered what “pressure-vessel” was. Thanks for the resources.

Ah, I guess the HDR support in Wayland is still exposed via an “experimental” interface. But it looks like a handful of Wayland compositors support it, including wlroots which a bunch of smaller compositors are based off of.

Does it? What containerization does it use? I thought it was similar to wine, just a process pointed at a windows exe, and an environment to make the app think it’s running in a windows filesystem.

Doesn’t valve already use gamescope (Wayland compositor) with HDR support? And KDE?

Yeah, so the best beginner resource (especially for old hardware) is honestly this old blog series A Trip Through the Graphics Pipeline. But importantly, it was written before modern dx12/vulkan were around, so it will use dx9 terminogy. Also, it’s possible that certain aspects of the vulkan api aren’t possible to faithfully implement to spec with older hardware (while still maintaining reasonable performance, or possibly at all).

From there, it’s probably best to try and implement a backend for your GPU into the radv mesa driver, so probably go take a look at how other GPUs are done.

You will need to become familiar with the AMD GPU programming docs, here.

I’m not going to be one of the naysayers here who says you shouldn’t even try to do this, but as an ex-graphics driver dev, I think you will find pretty quickly that you have your work cut out for you. It would probably be easier to implement a Vulkan-on-OGL translation layer.

Both GPU hardware and drivers are developed by teams of professionals, each of which is hyper specialized in a few components, because none have the time or ability to be familiar with everything about all components (at least, not while also being effective). I’m not saying you can’t do it, and I’m not saying you wouldn’t learn a LOT doing it, but I am saying that by the time you finish, you could have worked a minimum wage job and purchased a dozen 5090s 😉.

Edit: and oh right, then there’s reading through the Vulkan spec, which, if it’s your first graphics API, will take months, if not years to digest.