Here’s what you need for Arch, for more context: https://wiki.archlinux.org/title/AMDGPU
Here’s what you need for Arch, for more context: https://wiki.archlinux.org/title/AMDGPU
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
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.
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 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 removed 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.
Pretty sure HDR is “working” in the sense that KDE went ahead and implemented unfinished specs, so that the very few apps that also went ahead with it can do HDR, but only on Wayland which breaks other things that are behind, and also often requires very recent versions and specific obscure parameters to be passed to enable HDR support?
Yeah, it’s a great step forwards and great for enthusiasts, but unless I’m very behind on the state of HDR myself, it’s still something I’d consider “coming soon” and not proclaim it’s just “working for me”. It certainly feels like a “year from now” kind of thing - something to anticipate, not try to force just yet.
I don’t think that’s a good point, since they make their own immutable images, so they can use whatever versions of software they want, and you don’t normally get to update them with the rolling release
Considering the word fornication, I’m not surprised fornix sounds sexual
Could’ve stopped at 1 😔
Applications disappearing from the launcher because you changed the greeter sounds very weird… And that’s kinda what I mean. You had to give up on using this software, and instead go for an alternative, because of an issue that shouldn’t even be related.
Granted, a lot of people are probably fine with it, and it sounds like an annoying issue to debug… But it still rubs me the wrong way.
You do raise a good point about replacing software - even just in my example I neglected to mention myself switching to pipewire a couple times and figuring out how they work. Interoperability between software is valuable and knowing you can always switch out one part of your system for an alternative is indeed a useful skill - I sometimes see people complaining about things like Linux’s clipboard, or archive manager, being bad, something like that, without realizing that’s just one option you can use.
Depends on the issue, but many issues come from misconfiguration - fixing the issue can help you understand your system, what went wrong and why, and not only fix that issue ans help you fix further issues, but also reveal things you didn’t know about the software. I find it valuable to know how things work, so I can understand what I’m using, what I need, and what I can do with it.
As an example, messing around with pulseaudio and pipewire I understood a bit more about how it works. I found out I could enable the built-in echo cancel module and get rid of virtually all of my echo when using speakers and microphone. I then later also knew how to configure multiple virtual streams, so I can separate games and voice chat from my browser, so when I record clips when playing with friends, I can have those separate. And then also configured RNNoise for systemwide noise suppression for that bit more audio clarity.
I could find instructions on how to do each of those without understanding them, but when I wanted to ensure noise suppression happens after echo cancellation, I knew what to mess with to set that up.
I understand it’s not for everybody, it’s not feasible for most people - but I see the system as a complex machine you need to operate, and while having simple controls is a good idea, understanding how the machine is built can help not just with complete breakages, but also with avoiding smaller inconveniences that come from using it in unintended ways
To me that’s part of the ideology I associate with Arch. If you actually use -h
in pacman, I find that the help is presented in a nice and contextual way. You only need a few commands on a daily basis, and most of the other things you might need are easy to figure out when you need them.
In regard to -S
being confusing, I think it’s basically making the external operations map to how the software works internally. I feel like learning what the software is doing, rather than expecting the software to hide away the details, is also part of it. When you want to do more complex operations, or when something breaks, you’ll have a better understanding of what happened.
I wouldn’t mind a better interface, I’m not claiming it’s the best it can be or even close to it, but I wouldn’t want the improvement to come at the cost of obscuring how the software works. I don’t want the commands categorized just by convenience rather than logic, or magic buttons that automatically perform a sequence of hidden operations. I want something I can learn, understand, commands I can dissect into their components, not something I’m expected to use in the 10 ways provided and hope it does what I need.
I see this in the same way as people tend to use git - some GUIs will offer convenient buttons with their own made up names, and when git throws an unexpected error, the user will have no idea what the error means, or what the software did to get there.
People often complain that git doesn’t make sense. They might have a point in terms of it being unintuitive… But I find that with a general understanding how it’s built and what the commands do, the complaints are often people trying to force the issue using the wrong tool for the job.
And, honestly, sorry for the rant. In the end it’s just my opinion, I don’t want to force it on anybody, I just started writing and kept finding things I wanted to elaborate on. If you’re reading this, I hope you have a good day!
I’m a bit confused, the information isn’t very clear, but I think this might not apply to typical consumer hardware, but rather specialized CPUs and GPUs?
From my experience, it seems like the video quality really sucks the moment you try to stream anything more complex, like a 3D game - no indication on my side, but a friend complained and I got the same result checking the stream on a second device. Frame rate drops to 2fps or worse, with bad quality on each frame.
I remember reading an issue on vesktop about it, but sounds like it might just come down to missing HW acceleration in electron for the relevant APIs? Though if you have any suggestions and/or better results, I’d love to hear about it.
Most likely… Unless the “destruction” was switching your MOBO between Legacy BIOS and UEFI, in which case you could break booting into both in one swoop ;D
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.