KubeRoot

The wiki tells you what you need on arch, and what you need it for. Those packages also don’t seem to have kernel-specific or dkms versions, so seems like they’re not kernel modules.

Mind you, the setup is clearly not monolithic, with different components for different purposes, including alternative options. On top of that, each distro will make different choices - Arch provides the components as packages and puts the responsibility of installing the right ones on you. Some features might be built into kernel drivers, like working video output, but Vulkan support clearly wants a dedicated driver.

Here’s what you need for Arch, for more context: https://wiki.archlinux.org/title/AMDGPU

There’s nothing special about it. Linux distros are one of the options, alongside windows and osx as desktop systems.

What there are are preferences, morals, affordability. Linux is generally free, has different approaches to how the system is structured, how software is installed, how much access to the system you have, and how much responsibility for setting it up you have.

This will also vary from distro to distro, but generally software is installed from the distribution’s repositories, not downloading files from various websites - and instead of having some different scheme for updating every program on your computer, you use a single command (or button in an app) to update your system and all your software. This is one of the main things I love about Linux - you get to update your stuff when you want, all at once.

I think on mutable distros, or at least arch, you can run a command to reinstall all installed packages, which will verify integrity of the package files (signatures) and then ensure the files in the filesystem match package files? And I think it takes minutes at most, at least for typical setups.

I do think it’s also possible to just verify integrity of all files installed from a package, but I don’t remember if it required an external utility, pretty sure it’s on the arch wiki under pacman/tips and tricks

Oh, just ask an Arch user about Manjaro.

I also recommend rEFInd for the bootloader if you don’t want to set anything up (and risk messing up). You don’t need to configure your boot entries, it scans for boot options and shows them with a graphical interface, so your Linux and Windows should just show up.

The issue is, when doing sudo, you have to put in the password when doing sudo. In this case, you put in your password, some flag is set, the computer does a full reset, and then after it reads the flag and decides to bypass the password system. That sounds like just a step away of figuring out how to set this flag without a password to bypass logging in.

I think an issue is, this sets up your computer to have a way to bypass putting your password in on boot. If you don’t care about security too much and don’t have things like secure boot and encryption, then that’s bypassable anyways… But otherwise, I’d be concerned about introducing systems that specifically bypass security.

Why does every distro need yet another package manager?

I think most package managers - the ones actually part of a distro - are old. It’s not a question of why they all use different package managers, it’s a matter of them having developed them long ago before any single one matured.

That said, there are other considerations, which is also where new ones come from - different distros will have different approaches to package formats, dependency management, tracking of installed packages and system files, some might be implemented in a specific language due to the distro’s ideology, some might work in a different way (like NixOS), and there’s probably a whole bunch that just want a different interface.

You wouldn’t ask why Linux has a different way of viewing installed programs from Windows, and in the same vein packages are not a universal aspect of Linux, so each distro has to make its own choices.

Also I like pacman, some people complain about the commands being obscure, but I feel like they’re structured in a much more logical way. Don’t confuse it with yay though, pacman doesn’t build packages, and yay is specifically a wrapper around pacman that has different commands, while adding the ability to interact with the AUR.

The 8 dependencies must be an optional dependency for some other package you already have installed. That said, that kind of stuff is the main reason I want to try NixOS - any time I install something, configure something, etc. I’m risking forgetting about it and getting tripped up over it down the line, with no good way to check.

I think I saw a video mentioning they are illegal in some places, showing just why they’re so dangerous

Man, and here I put too much effort writing a reply to a troll 😔

Does windows come preinstalled and preconfigured with more potentially vulnerable software on open ports?

I personally don’t value an antivirus that much, since it can only protect you from known threats, and even then, it only matters when you’re already getting compromised - but fair point for Windows, I suspect most distros come without antivirus preinstalled and preconfigured.

A firewall, on the other hand, only has value if you already have insecure services listening on your system - and I’m pretty sure on Windows those services aren’t gonna be blocked by the default settings. All that said though… Most Linux distros come with a firewall, something like iptables or firewalld, though not sure which ones would have it preconfigured for blocking connections by default.

So while I would dispute both of those points as not being that notable, I feel like other arguments in favor of Linux still stand, like reduced surface area, simpler kernel code, open and auditable source.

One big issue with Linux security for consumers (which I have to assume is what you’re talking about, since on the server side a sysadmin will want to configure any antivirus and firewall anyways) could be that different distributions will have different configurations - both for security and for preference-based things like desktop environments. This does unfortunately mean that users could find themselves installing less secure distros without realizing it, choosing them for their looks/usage patterns.

Question, how is Linux more insecure out of the box?

Windows 10. The reason I switched was pretty funny - I had previously bought a cheap SSD and moved my install over to it, and installed Arch on my HDD hoping to experiment with it.

I never really did that, but one day before Christmas my computer booted straight to Arch to my confusion, and after a while I figured out my SSD failed. I ended up installing gnome to have something to use in the meanwhile, since I wasn’t gonna be buying a new SSD in the next few days, but then I just decided to stick with Linux. As I learned more about it I realised I was barely missing anything, and I preferred Linux for what I had.

I think you’re actually agreeing with me here. I was disputing the claim that software should be made available in “a native package format”, and my counterpoint is that devs shouldn’t be packaging things for distros, and instead providing source code with build instructions, alongside whatever builds they can comfortably provide - primarily flatpak and appimage, in my example.

I don’t use flatpak, and I prefer to use packages with my distro’s package manager, but I definitely can’t expect every package to be available in that format. Flatpak and appimage, to my knowledge, are designed to be distro-agnostic and easily distributed by the software developer, so they’re probably the best options - flatpak better for long-term use, appimage usable for quickly trying out software or one-off utilities.

As for tar.gz, these days software tends to be made available on GitHub and similar platforms, where you can fetch the source from git by commit, and releases also have autogenerated source downloads. Makefiles/automake isn’t a reasonable expectation these days, with a plethora of languages and build toolchains, but good, clear instructions are definitely something to include.

The responsibility to figure out the dependencies and packaging for distros, and then maintain those going forwards, should not be placed on the developer. If a developer wants to do that, then that’s fine - but if a developer just wants to provide source with solid build instructions, and then provide a flatpak, maybe an appimage, then that’s also perfectly fine.

In a sense, developers shouldn’t even be trusted to manage packaging for distributions - it’s usually not their area of expertise, maintainers of specific distributions will usually know better.

And reinstalling the packages, moving over all the configs, setting up the partitions and moving the data over? (Not in this order, of course)

Cloning a drive would just require you to plug both the old and new to the same machine, boot up (probably from a live image to avoid issues), running a command and waiting until it finishes. Then maybe fixing up the fstab and reinstalling the bootloader, but those are things you need to do to install the system anyways.

I think the reason you’d want to reinstall is to save time, or get a clean slate without any past config mistakes you’ve already forgotten about, which I’ve done for that very reason, especially since it was still my first, and less experienced, install.

I do have my screen set to sRGB, and it is possible it’s simply incorrect in SDR - when I enable HDR, everything looks greenish IIRC. As for color profiles, I think there might’ve been a built-in profile that was automatically enabled in the settings? It’s possible I’m looking at horrible colors and not realizing, but at least I’m not doing things like a friend, who “optimized” his colors to improve gaming performance, and keeps complaining about colors being weird 😅

Color management is annoying, since you need a correct reference to verify anything, and I never looked into that.

As for the monitors, I specifically meant good screens, not screens with good HDR - I feel like if you go for a good screen these days, it’ll likely have some HDR support, letting people simply try it out with little effort on Windows.

I use Wayland exclusively, and I’m on up to date Arch. I’m talking about issues like screenshare issues with software, XDG desktop portal screenshare randomly breaking, steam notifications started positioning wrongly, steam’s search stopped working (not 100% sure if those two are Wayland)…

I also tried running a game in game scope with HDR enabled, experimenting with options and env cars I found online, but it just didn’t work. It was a sample size of one, but it was one game I wanted to play with friends, so I gave up in favor of just playing.

I also don’t use MPV - I tried testing HDR with it, and it probably worked fine, but I don’t have the right media to test it. (Side note: I should try mpv more seriously, but I haven’t needed a video player much in general)

An extra annoyance is the fact that the LDR colors are quite off with HDR enabled on Plasma. I suspect this is the fault of the display or configuration, but it’s still something I’d have to spend time researching and fixing, only to barely get any use out of it.

I haven’t tried setting up steam itself in gamescope, but wouldn’t it be limited to one window then? Could try it just to experience an HDR game, but otherwise it’s a bit of a deal breaker.

You might be right about it being for enthusiasts in the first place, but I feel like there’s a lot of people who will just pay up for a good screen that includes HDR, and on Windows I’d imagine you can just turn it on and start getting HDR from various sources - something that will surely become possible on Linux, but will take a while longer.

All that said, I’m not saying this to shit on Wayland or the developers’ work on HDR. Not long ago HDR was something that just wasn’t possible, and people were whining it’ll take another 10 years at this rate. I’m excited to see the next update on this, as well as stable wider adoption, but that’s the thing - that’s something I’m anticipating, not something I’m gonna be using now.