- Joined
- Jul 3, 2021
No. I recommend reading the full write up even if you don’t have any servers. This is a disaster.
The Linux Thread - The Autist's OS of Choice
- Thread starter tehpope
- Start date
- Joined
- Mar 30, 2023
I read it but I didn't fully understand it, but I'll try that tempfix when I get home
- Joined
- Apr 1, 2024
Just hearing about the exploit. Assuming you guys are talking about the one that essentially let's you get privilege escalation. I don't think that was a nothing burger exploit for any system. But it does require you to take advantage of some other exploit first to really be bad. Like if there was some other thing that allowed RCE, then it would be really bad, because then they could be basically guaranteed privilege escalation, and its over after that. Especially with how trivial it is to take advantage of this once you have access to a machine.
Either way thankfully we found out about it in a disclosure, and not by seeing a huge hack.
Either way thankfully we found out about it in a disclosure, and not by seeing a huge hack.
- Joined
- Sep 5, 2019
Having an issue on Kubuntu 26.04 where I can't install install fitgirl repacks. It happens when using both Lutris and Heroic so it seems to be system specific.
- Joined
- Aug 31, 2024
Its because normal wine doesn't support the decompression algorithm FitGirl uses for some reason.
Try a kron3ek build, these worked for me before.
- Joined
- May 12, 2017
Wine is still really hit/miss, quality has demonstrably improved despite the constant chasing of a moving target, but part of me can't help but feel melancholic over how the interfaces for Wine applications now look like they're ripped straight from Windows XP instead of looking like a Windows 9x monstrosity. Not because Wine itself is getting demonstrably better, rather it reminds me of the inexorable passage of time and my powerlessness to reverse it all.
Orcinus Orca
kiwifarms.net
- Joined
- Oct 8, 2025
My BIOS does not support Legacy Boot. I'll try those distros you mentioned.
- Joined
- Dec 16, 2019
It's actually up there with "really bad" because it lets you escape shared hosting and docker containers in ways you shouldn't be able. And apparently at least Gentoo (lol) wasn't told at all: https://www.openwall.com/lists/oss-security/2026/04/30/10 https://archive.is/LxyUO
HN is variously pissed about that and/or about the company that found it obviously using fucktons of AI.
https://news.ycombinator.com/item?id=47965108 https://archive.is/gFbII
- Joined
- May 14, 2024
Artix chads continue winning. Ching chong back doors in systemd? Not my problem. AI discovered TLA back doors? Updated to 6.19.14 last weekend before the disclosure. And as if I would ever give anyone else shell access on my machines. Now all we need is the Russian back door in wayland and Xorg because free desktop is compromised and I'll get my hat trick.
If you aren't using Artix + Xlibre + Not-systemd, what are you even doing at this point?
- Joined
- May 12, 2017
Waiting for XLibre to have a proper Devuan implementation. I love Artix, I love XLibre, but I fucking hate the AUR. Not because it's a "bad" thing, rather its constant susceptibility to DDOS attacks, outdated or otherwise orphaned PKGBUILDs (i.e. something's GitHub was updated 3 days ago, AUR was last updated like 3 months ago, and the PKGBUILD's borked in a nontrivial way), and I fucking hate AUR "helpers" like yay. I'm more than willing to give Devuan a fair shake, but to that end? They've been sleeping on XLibre's first party support since June while Artix had it more or less from the beginning. The third party rebuild repositories are also hideously variable in quality. It's just less hassle right now to run mainline Xorg instead of bothering to do the swapover to XLibre with third party repos because so many of them just end up dying out and merging into something else. That happened to Debian's third-party XLibre repo and the same happened to Fedora's COPR repo too.
- Joined
- May 14, 2024
Can you elaborate on why? I'm genuinely curious.
I've said this before but IMHO the AUR is the missing piece for linux. Where as on windows you download cpu-z.exe or whatever other utilities that aren't in windows in the debian world that doesn't exist. You get the packages the distro maintainers have and that's it. More than comes with windows, yes, but not enough and not up to date. Using the AUR (and I use yay lol) I can yay -S llamacpp-cuda-bin and bam, done. Or the git version if I need to add build flags for myself. (I could go on)
Plus it's not like using the AUR is required. You could just check stuff out and makepkg -si manually if you wanted to. But even ignoring all that the packages in the arch/artix repos are going to be more up to date than Debian. As far as DDOS and outdated/orphaned packages both of those things can happen to official repos too. I guess Debians hosting is probably more resilient but that seems like a reach?
- Joined
- Jun 26, 2025
Oh so these were researchers finding the exploit and patching it? I'm just catching up on this and haven't read it yet.
- Joined
- Mar 30, 2023
Ironically Xlibre is one of the best examples of why. Before the team could add it to the AUR some rando took over setting up Xlibre on the AUR, then proceeded to break the packaging and be really slow on updating. When the team tried to set up their own packaging on the AUR it got removed for being a duplicate, and it took quite a bit of work to sort something out with the squatter.
I'd much rather do the "curl -fsS https://dl.mysite.com/install.sh | sh" thing which adds a fully supported repository to the list.
- Joined
- Jan 22, 2018
Italian Linux Man is just reading off an AI-generated prompt, since his own accent is too thick and would butcher most of those words.
But usually puts out decent content.
- Joined
- May 14, 2024
I think it's obvious that was politically motivated. Please direct your attention to the Arch logo change today or Xlibre page removal from the arch wiki. And while the AUR eventually was fixed debian is not supporting Xlibre right now for the same political reasons. So... this is/you are retarded.
>exploit disclosed yesterday that allows privilege escalation from any script for any kernel in the last 8 years
>yeah I'd rather curl random scripts than have even the barest of quality control
Last edited:
- Joined
- Apr 1, 2024
lol intel never ceases to amaze me.
Yes from my understanding it was found by some white hat hacker, and disclosed to the kernel team. Then later publicly disclosed. It was a bug in this kernel module. algif_aead
It basically allows you to get root pretty much instantly as soon as you gain access to a machine. So if you happened to know of some remote code execution exploit that was in some common piece of software people use, or find some other way to run a command on a machine, at that point you are able to run the script/program that takes advantage of the bug, and boom, you have a root shell. As far as bugs go, being able to reliably and easily get root access is pretty bad. The only thing that would have been worse is if this hack itself let the machine be accessed remotely.
- Joined
- May 12, 2017
It ain't complicated: the AUR is a blessing and a curse. For you, it's a blessing. I ain't taking that away from ya in the slightest. More power to you for enjoying it. For me, the AUR is a constant point of contention that I'd rather not deal with if I can afford to. I don't like using AUR helper tools because the AUR to me is more of a liability than an asset. The AUR isn't the same thing as the developer maintaining an official binary package repository that you can properly integrate into Pacman, and I vastly prefer the latter to the former.
I don't give an iota about compile time flags, tracking the latest git commit, or any of that nonsense. I just want the binary there so I can use the damn software right then and there. If that's an officially maintained repository for my distro by the developers in question, that's my go-to. AppImages and Flatpaks are also acceptable. What I ultimately give a shit about is using the damn software.
When I built my new PC on Cyber Monday, Linux Mint didn't work well with my RX 9070 XT. I know they have HWE-enabled kernels now (i.e. as of April 2026), but that's far too little and much too late for me. I considered Artix because I really loved using it on bare metal off a portable hard disk, but the AUR was effectively a non-starter for me. I prefer a GTK environment, Cinnamon is my go-to, MATE and Xfce are also acceptable, and I need a functional X11 implementation. Above all else, I need a reasonably recent Linux kernel and accompanying Mesa stack.
- Mainline Debian variants are non-starters because their kernels and Mesa stacks are hideously outdated
- Arch and variants are non-starters because of the AUR.
- Non-LTS Ubuntu and related spins are non-starters because of Wayland and the
sudo-rs/uutils nonsense- That leaves only Xorg-forward Fedora spins as my next best option.
As fate would have it? Fedora 43 (and now 44) Cinnamon is basically "good enough." It's well and truly "the lazy man's bleeding edge Linux distro." RPM Fusion is quasi-official, AppImages cover my vidya gaem console emulators, Steam works as intended because everything's systemd-forward anyway, Xorg is better than Wayland even without XLibre niceties, and basically all my software's basically reasonably current thanks to both Fedora's official repositories being vast compounded by the quasi-official RPM Fusion. Most importantly: the Linux kernel and Mesa are 100% up-to-date. Fedora 44 even enables
ntsync in the kernel OOTB and that's like super good for gaming or whatever.There is a COPR repository for XLibre on Fedora, but the question still stands: why would I fiddle with XLibre as a matter of principle when Xorg is the more pragmatic option, and it still gives me my Dark Souls and 3DS retro vidya experience all the same? I'm not happy that I'm basically using Fedora because my arbitrary criteria of selection rendered everything else non-starters. As it stands, my setup is "good enough" despite not being ideal in the slightest. I can live with that, you'll probably think ill of me, but whatever.
- Joined
- May 5, 2022
Oh hey that's Sam, I talk to him a lot in regards to debugging shit! He was pissed as fuck the other day because the work involved. Gentoo had to (is still) backporting the patches from ~23 versions of the kernel (gentoo-sources. some significantly less), 20 times from sources (17 sources, 3 binaries).
Did I mention the kernel dev lead is a Japanese (probably tranny) masquerading as a 12 year old Gyaru Idol? They're a senior dev engineer that works on the Japanese version of SUSE/Red Hat called Miracle Linux.
Profile picture:
Namesake:
Yes. It says age 12 on the wiki.
Namesake:
Yes. It says age 12 on the wiki.
- Joined
- May 14, 2024
@Dread First
I have some quibbles that I'll mention later but they're not really important.
I guess my real question is why does having the option to use the AUR make Artix a non-starter for you? If you don't want to deal with the AUR it's not required so I don't understand your hangup. Do you think the software selection in the official repos isn't broad enough without it?
And as a sort-of follow up are you aware that Artix has Xlibre in their official packages (completely replaced Xorg afaik) as opposed to the AUR?
I have some quibbles that I'll mention later but they're not really important.
I guess my real question is why does having the option to use the AUR make Artix a non-starter for you? If you don't want to deal with the AUR it's not required so I don't understand your hangup. Do you think the software selection in the official repos isn't broad enough without it?
And as a sort-of follow up are you aware that Artix has Xlibre in their official packages (completely replaced Xorg afaik) as opposed to the AUR?
-I would call the AUR quasi-official. Is there really that much of a difference between it and the RPM fusion repo? (geuine question)
-There are a lot of AUR packages that are pre-compiled. I always pick those over the ones that need to be compiled unless I have to change something which isn't often. Waste of time to compile them otherwise.
-There are a lot of AUR packages that are maintained by the people that are making the package itself. Less 'randos doing this' and more 'this is how the X team distributes X on arch'. Like if I'm looking at a github project and the installation instructions for arch are "we're on the AUR" that seems pretty official? I guess you need to check individual packages?
-There are a lot of AUR packages that are pre-compiled. I always pick those over the ones that need to be compiled unless I have to change something which isn't often. Waste of time to compile them otherwise.
-There are a lot of AUR packages that are maintained by the people that are making the package itself. Less 'randos doing this' and more 'this is how the X team distributes X on arch'. Like if I'm looking at a github project and the installation instructions for arch are "we're on the AUR" that seems pretty official? I guess you need to check individual packages?
- Joined
- May 12, 2017
That's on me for not stating it outright: for my specific use case, enough stuff that I normally use is relegated to the AUR for it to be a non-trivial issue. It absolutely is a problem for me that the software selection in Arch's repositories (core, extra, community, multilib) and all downstream variants is sparse. The AUR explicitly exists for the community to plug up the gaps that Arch developers and package maintainers either can't or won't take care of.
a) The AUR is not quasi-official the way that RPM Fusion is. RPM Fusion is operationally and organisationally distinct from Red Hat and its assorted projects, but the overwhelming majority of RPM Fusion's staff consists of paid Fedora developers who (allegedly) maintain RPM Fusion in their spare time. It's becoming more and more "official" with time, given how Workstation and now KDE enable the RPM Fusion repos for Steam, the NVIDIA binary driver, and Google Chrome in the new Anaconda Web UI installer.
Conversely, the ArchWiki explicitly states that the AUR is 100% a caveat emptor sort of affair. You use those PKGBUILDs at your own risk, regardless of whether or not the developer of $insert_project_here is officially maintaining that PKGBUILD. That's why you need
yay: because Pacman intentionally lacks any sort of direct ability to interface with the AUR.b) I don't care if there are pre-compiled AUR packages or if the developers of whatever project are officially maintaining the PKGBUILD; I would rather have a proper repository set up with Pacman rather than relying on PKGBUILDS from the AUR where I must specifically either utilise an AUR helper tool or manually keep track of with
makepkg -si.Yes, I'm 100% aware of it. I've known since like July 2025. A few months back they even changed their testing ISOs to use XLibre by default instead of Xorg. That was a huge reason why I gave Artix a shot on a portable hard disk. It was excellent, except for the part where software I wanna use is gated behind outdated PKGBUILDs on the AUR. My disdain for Artix despite my praises is predicated squarely on the fact that it's an Arch variant, and thus shares that hidden dependency on the AUR and its inherently unreliable nature.