

deleted by creator
deleted by creator
Don’t get mint if you’ll get a remotely capable laptop or plan to game on it. Its so called ‘modern’ desktop environment (wich still defaults to the old X window system) feels awful to use imo and while the ‘retro’ ones are better there’s no point in using them on a new laptop. Choose a distro that ships with KDE, GNOME, or a wlroots based desktop environment.
I’ve also had driver issues with it that didn’t happen with Ubuntu or arch.
Pretty much every distro has a caveman compatible installer.
What has nothing to do with systemd? You open the link and before the introduction it says the current release isn’t fit for general use because they couldn’t add systemd yet. If they picked something with systemd they wouldn’t need to spend so much effort on it
It always puzzles me why they chose the one distro without systemd to base this on and are now trying to add it themselves.
Also I have thoughts about this:
Move sudo to community
At present, sudo is in the main repository, which requires us to provide security support for 2 years. Upstream sudo does not provide an “LTS” lifecycle, so this requires either performing security upgrades during the maintenance lifecycle, or backporting security fixes by hand.
Benefit to Alpine
Prior to the creation of the security team, there was an unofficial preference to push doas as the preferred pivot tool for Alpine. This reinforces that messaging. Additionally, we do not have to support sudo for a 2 year lifecycle, since there are no LTS branches for it.
How often does sudo have security vulnerabilities that it’s worth moving to a lesser used tool whose vulnerabilities are less likely to be discovered against your security team’s wishes? What do all the other distros do?
Kind of unrelated, why does c sometimes fail to print if it hits a breakpoint right after a print while debugging? Or if it segfaults right after too iirc
They literally said the issue was an unintentional bug and then fixed it. How is that damage control?
Will it not use it even after the ram fills up? I wouldn’t want the compressed part be prioritised anyways
Do you need a swappiness over 1 if you don’t have another swap device?
Isn’t this already a thing on Wayland?
Guessing from how this change required 3+ implementations before it became official according to the gitlab page, maybe it’s a chicken and egg situation. Hdr is a lot of work so maybe people don’t want to implement an unfinalized version that might change
Wow the icon saga is finished!?
If anyone wants to throw away a couple hours, there was SO much discussion (and initially drama) over it: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/269
Gpu brand shouldn’t be a factor, just buy whatever’s better value.
I’ve used nvidia on Wayland for a year and the issues are greatly exaggerated, and if you have a cpu with an igpu you can plug your monitor(s) into the motherboard to get around wayland-related ones (there’s probably some latency impact for games but I can’t tell).
Currently the problems (that I know of) with nvidia drivers are that colors get muted if you enable hdr, steam’s web interfaces appear corrupted or flicker unless you resize them, there is no memory spillover to ram, and the nvidia ‘x server’ settings app doesn’t support wayland.
And keep in mind that issues tend to get resolved over time. When I first built my PC the nvidia gpu would cause xwayland apps to flicker and didn’t support nigth light or transparent panels in kde. The amd igpu would turn the screen pure white if I changed windowing related kde settings. These don’t happen anymore.
This worked. Apparently I had all the usb devices connected to the same controller and it seems linux initialises them controller by controller. Thanks
I did try messing with the hook order but it’s already as early as it can be.
How would bios change how linux loads usb devices?
It works fine in bios and bootloader. This only happens during boot
I had thought it was about the color profile because with hdr disabled from system settings, enabling the built in color profile desaturates colors quite a bit and does some kind of perceived brightness to luminosity mapping that desaturates bright / dark hdr content even more. Although I don’t think that’s the cause of my problems anymore.
Thanks to your tip about kscreen-doctor, I could try different combinations of hdr / wcg / edid and see how the colors look with different combinations:
I think there must be something wrong with my screen since the hdr reduces saturation more than anything else. Anyways, thanks for the good work
Edit: Tried this with an amd gpu. hdr+wcg works as expected without muted colors. hdr without wcg still significantly desaturates colors, so I guess that’s a monitor bug. Now to figure out gpu passthrough… (Edit 2: It seems to just work??)
Side note, when I turn off hdr only from kscreendoctor the display stays in hdr mode until it turns off and on again, that didn’t happen with nvidia
Edit 3: Found something weirder… Hdr colors are muted on nvidia gpu and seems vibrant with the amd igpu. If I plug the monitor to the motherboard (amd), enable hdr, then unplug and plug it into the nvidia gpu, the colors are still vibrant??? I can disable and enable hdr again and again and they aren’t affected. They’re even fine when hdr is enabled without wcg??? But if I fully turn off the monitor and back on they once again become muted with hdr. Weird ass behavior
Weston implementation seems still in progress:
https://gitlab.freedesktop.org/wayland/weston/-/issues/467
Anyways, proton 10 when