The Linux Thread - The Autist's OS of Choice

Dread First said:
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.
Click to expand...
I see. In that case I guess there's nothing much for it. Out of curiosity (and if it isn't too much of a power level) can you tell me some of the software that's missing?
 
use case guy jar.png
Ebassi cum jar on page 1000
 
Rust Troony said:
Its because normal wine doesn't support the decompression algorithm FitGirl uses for some reason.

Try a kron3ek build, these worked for me before.
Click to expand...
I think Proton GE/Wine GE builds work with it fine. Even Proton might.

Ferryman said:
The whole "X keylogger" thing makes me schizo paranoid. Not that it ever happens, I know it doesn't, but just knowing that it could happen rubs me the wrong way. Once I can stuff everything into its own namespace, we're balling.
Click to expand...
Wouldn't xnamespaces break certain clipboard applications, or is that a different problem? Like sharing clipboard contents across VNC, or xclip, or virtual desktop sharing.
 
Controlled Demolition said:
Wouldn't xnamespaces break certain clipboard applications, or is that a different problem? Like sharing clipboard contents across VNC, or xclip, or virtual desktop sharing.
Click to expand...
You can set some apps to have access to all Xnamespaces. Otherwise it would be exactly like the garbage Wayland solution that everyone hates.
 
Betonhaus said:
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.
Click to expand...
Also fuck whoever is in charge of putting Krita in the AUR. They have replaced the current working version with the beta so most functions like scripts or adding text are broken.
 
Controlled Demolition said:
I think Proton GE/Wine GE builds work with it fine. Even Proton might.


Wouldn't xnamespaces break certain clipboard applications, or is that a different problem? Like sharing clipboard contents across VNC, or xclip, or virtual desktop sharing.
Click to expand...
What @Betonhaus said, the way they work is you can create as many individual namespaces as you'd like that either run as "root" or "user" levels of privilege. Each namespace is its own little container that can't talk to other namespaces or the root namespace, but you can group several programs inside of the same namespace if you do want them to read each others' inputs, or put them in root if you want them to read everything. Something like a clipboard manager would thus sit in the root namespace, but something like a browser or some other untrustworthy proprietary app, say, Spotify, Discord, Slack, Teams etc., would sit in its own isolated namespace. If you want screen sharing for example, you'd just assign a keybind that launches the screenshare app with root privileges temporarily while sharing your screen, then another that boots it in a namespace when you're done. It is essentially a parallel to what Wayland tires to do if it was done right, with granular per-app permissions that don't require the abomination that is portals to work. For desktop forwarding, you'd just run it as root. You can also assign even more granular privileges to each namespace, like network connection or keyboard inputs.

I tired to rig a proof of concept last week where I had aliases and keybindings for each app to either run in the default root namespace or its own isolated one, but xnamespaces still throws a known bug, so it still hasn't been patched to work. SonicDE was supposed to integrate namespaces somehow but I haven't had the chance to look at their source code to see if they have a fix.
 
Dread First said:
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.
Click to expand...
This is me as well, and why I've found Gentoo much less irritating than Arch-likes. If AUR integrated into pacman how overlays integrate into portage, I'd be much happier. I mean, in my world, I was using an AUR package for FFmpeg because I don't get features I need otherwise. On Gentoo, it's all just USE flags, and if I'm going to be building and maintaining by hand anyhow, there's no reason not to be using Debian packages, which are better supported.
 
SCV said:
I see. In that case I guess there's nothing much for it. Out of curiosity (and if it isn't too much of a power level) can you tell me some of the software that's missing?
Click to expand...

There were several packages, but the most egregious example I can think of: ProtonVPN. It's explicitly a community-maintained PKGBUILD in the AUR, whereas Debian/Ubuntu and Fedora have dedicated, official repositories. The ProtonVPN team themselves outright stated that official support for Arch is in progress... but they've had that notice up there for at least four years at this point.

1777659825968.png

Fact of the matter is that when the AUR exists, there's no impetus for software developers to maintain an official repository that cleanly integrates into Pacman. Why go through all the hard work when you can just find a turbosped from the Arch community to do the hard work for you? ungoogled-chromium is lucky enough to have both binary and source packages available in the AUR... but again: why the fuck isn't there a proper Arch Linux repository that cleanly integrates this shit into Pacman? A web browser is the last thing I wanna faff around with updating by using yay or makepkg -si. The same is doubly true for Brave Browser and LibreWolf.

Meanwhile: Fedora has all this shit and more available with minimal, if any, friction whatsoever. Plus I'm using X11 via Xorg on Cinnamon, which is my preferred desktop environment anyway, and I have the pseudo-rolling release cadence that pushes out the latest Linux kernel and Mesa stack. On Fedora Cinnamon, Fedora's GNOME repo works perfectly. There's an officially supported COPR repo for ungoogled-chromium. Brave, LibreWolf, Vivaldi, and all other manner of web browser already have RPM repositories up and running. I'm also tracking the latest wine-staging from the official WineHQ repositories for shits and giggles. All this shit is relegated the AUR in one form or another.

Fedora is Red Hat slop, I will concede... but again: the Cinnamon spin is "good enough" triumphs the alleged platonic ideal in my specific situation.
 
I was curious how much of what you mentioned was in a repo vs. the AUR. Do note I've enable the arch repos via the official artix-archlinux-support package.

For browsers the artix repos have ungoogled-chromium and librewolf, the arch repos have vivaldi, and I'll give you brave however it appears that the brave team is running their AUR repo and that's their official way to install brave on arch (they even recommend yay, lol).
1777663095067.png1777663119268.png

Beyond that wine staging is in the artix repos and they have a cinnamon ISO.
1777663551843.png

I will concede that the protonVPN app situation does look like a mess with a couple randos making UIs that interface with the CLI so if you need that to switch countries that's an issue. And I wouldn't touch GNOME anything with a 10-ft pole but if you need something from there that is another problem.

I have two big complaints about proton. First of all if you are using base wireguard and try to torrent in any significant amount it will kill your connection. My resarch indicates this is because there's some kind of rate-limit-trip on incoming UDP connections so once the DHT traffic gets above that it just dies. Doesn't disconnect just stops passing all traffic without telling you until you reconnect.

Supposedly that doesn't happ if you're using the app but that leads into my other complaint. If they support wireguard it should, you know, work but also they seem to be trying to nudge people to use the app. Why? I don't know. It could just be trying to get better retention or it could be more sinister. But I will tell you if I were the NSA or whoever and wanted to unmask someone I sure would prefer them to have the app. Because then I can just hand proton a court order (that they can't talk about) and force them to compromise my targets machine. There's no facility for that with just wireguard.

Of course switching countries is going to be annoying with just bare wireguard so the app does provide some value. But treating wireguard as second class is suspicious to me.

I don't really understand the friction complaint when the difference is pacman -S brave or yay -S brave. Yay will even run pacman automatically for regular repos when you do a full system upgrade. I do "yay --sudoloop --noconfirm" then reboot and that's it. All my shit is updated. I use repos before the AUR and my AUR packages are -bin versions where possible so it doesn't take very long. Protip for my AUR enjoyers: You need to install ccache if you haven't. Really speeds up subsequent compliations of shit.
 
Last edited:
SchizoDaemon said:
Building an AUR package should take them an afternoon.
Click to expand...

Yeah, that's another sticking point I have against the AUR. The Arch Build System basically gives everyone the freedom to design their own bespoke tooling, turn it into a package, and some insufferable faggot the opportunity to say "hey guys, I made this super cool ricing package" before it quietly goes unmaintained, then orphaned, and then well and truly abandoned. Not to mention that maintaining a custom package in Arch Linux more generally is a fucking painful experience. You do it once for the thrill of it, and then you abandon the custom package in favour of the standard upstream binary once you get sick of maintaining it.

***

@SCV you're not telling me anything I'm unaware of, JFYI. I've lived with Artix through the Cinnamon ISO for a month. I even did the post hoc Xorg -> XLibre swapover before the testing ISOs started shipping with XLibre. I have tons of praises for Artix, and my distaste is purely because of the consequences that being a downstream Arch variant entails. Search through my post history for Artix if you're curious; I believe the time range is somewhere between August and October 2025. I will, however, answer your question as below.

SCV said:
I don't really understand the friction complaint when the difference is pacman -S brave or yay -S brave. Yay will even runs pacman automatically for regular repos when you do a full system upgrade. I do "yay --sudoloop --noconfirm" then reboot and that's it. All my shit is updated. I use repos before the AUR and my AUR packages are -bin versions where possible so it doesn't take very long. Protip for my AUR enjoyers: You need to install ccache if you haven't. Really speeds up subsequent compliations of shit.
Click to expand...

yay is, in itself, an AUR package that serves as a wrapper over Pacman. My nonexistent ideal would be for a toggle in /etc/pacman.conf that allows for Pacman to directly pull $insert_PKGBUILD_here from the AUR. As stated previously, the AUR is explicitly a "use at your own risk" affair. I do not like using the AUR as a matter of principle because the onus falls on me to manually keep track of shit. I'm a Linux boomer: you ask me to do more than sudo dnf --refresh update -y or pacman -Syu alongside flatpak update, and I start hemming and hawing about that extra step, regardless of how inconsequential it is. Even if yay is capable of updating itself, there's something kinda crappy and fairly unrelaxed about using an AUR package to keep track of all your other AUR packages.

Circling back to Fedora Cinnamon here: the update process for me is stupidly simple. I just run the below script that chains dnf and flatpak and my shit's up-to-date no matter what. That also includes the COPR repo for ungoogled-chromium, official third-party repos for ProtonVPN, Brave, Vivaldi, Mullvad Browser, LibreWolf, WineHQ, etc, and everything else from both Fedora's official repos and RPM Fusion (free+nonfree).

Code: 
#!/usr/bin/env bash
set -eu

dnf_updater() {
    sudo dnf --refresh update -y
}

flatpak_updater() {
    flatpak update -y
}

main() {
    dnf_updater
    flatpak_updater
}

main

You can tweak this script to use yay if you so choose. I personally refuse to because I loathe the AUR wholesale.
 
Last edited:
Looks like Mesa is possibly deprecating support for older hardware, again

I hope it isn't a mess like Amber was where it conflicted with a regular Mesa install...

Mike Blumenkrantz of Valve's Linux graphics team has ignited a discussion over potentially shifting some of Mesa's older GPU drivers into a new legacy Git branch in order to better support the more modern OpenGL and Vulkan drivers without having to worry about breaking the legacy drivers and to allow for better cleaning of the Mesa codebase. Among the drivers that could be impacted are the ATI/AMD R300 and R600 drivers and many smaller drivers.

Back in 2021 various old Mesa "classic" non-Gallium3D drivers were punted off into a Mesa "Amber" branch to ease Mesa development burdens. Back in 2021 that shift to the Mesa Amber branch included Radeon R100/R200 drivers, the original Nouveau code, the Intel i915 and i965 classic drivers, and others.

Now we have a discussion over potentially creating an "Amber2" branch to effectively retire more of the older drivers that are rarely seeing any new development activity but complicating modern Mesa development efforts when it comes to cleaning up the codebase, addressing continuous integration (CI) breakage on the older platforms, and similar constraints.

Mike Blumenkrantz was motivated to start this Amber2 discussion given the less-maintained drivers more frequently hitting CI issues these days and causing pain points. Among the drivers proposed for splitting off into this new legacy Git branch include virgl / svga / i915g / lima / r300 / r600 / nv30 / nv50 and potentially others. For instance, some have suggested even moving the Nouveau NVC0 off to this branch with Zink + NVK being viewed as the future there with NVC0 being hardly maintained.

The biggest point of contention may be the Radeon R600g driver for moving to Amber2. There are a few hobbyist developers still working on code there and the like as well as users.

This new discussion also raised the matter of whether Mesa's original "Amber" branch was a failure or not. Mesa's Amber branch hasn't seen any activity since January 2023, or less than one year after the code was ultimately branched. No Mesa Amber releases were cut either since 2022. And the Mesa Amber packages aren't widely available by Linux distributions. At the same time that frozen state has ensured those drivers don't inadvertently break with newer Mesa changes but it also shows that there is limited interest/resources in advancing those older drivers given the lack of activity.

No decisions have been made yet but some Mesa developers are clearly interested in at least branching off some of the drivers rarely seeing any modern code activity.

(Link) (Archive)
 
You must log in or register to reply here.
Back
Top Bottom