Real world applicationof Arch linux for the Desktop

binarydepth · 2024-01-02 14:04:32

So, anyone else found issues with Arch's "bleeding edge" nature? Not always, keeping up with the latest versions hasn't been all sunshine and roses. I am trying to setup Android and Qt creator together and the versions seems to be troubling, causing compatibility headaches and workflow interruptions. No tutorials I can find other than installing with the Qt.io installer.

That got me thinking: what if we had both bleeding-edge and LTS versions of critical applications in the repositories? Imagine having a stable foundation for work while still dipping your toes in the latest features when you feel adventurous.

Would this be a game-changer for anyone else? Or am I just to new?

Maybe we can brainstorm some ways to keep Arch awesome and user-friendly for everyone.

dogknowsnx · 2024-01-02 14:32:15

Apart from the fact that there are "testing" repos already - who do you think is going to maintain all those packages?

schard · 2024-01-02 14:34:04

Well I am using Arch Linux at work right now and have been since 2014.
I never felt that my workflow was interrupted due to issues with the provided software packages.
Then again, I always read the breaking package news, pacman's messages and know how to browse the Wiki.
Also you may be confusing "rolling release" which Arch is with "bleeding edge" which Arch imho is not.

seth · 2024-01-02 14:49:43

LTS versions of critical applications

1. What is a "critical application"? QtCreator?? Android Studio??? Critical to whom?
2. Everything is subjectively critical to someone who critically relies on it
3. There're plenty of distros w/ LTS versions of everything, eg. Debian (stable) or RedHat

MAYBL8 · 2024-01-02 14:51:08

Also you can downgrade a package or packages and prevent them from updating.
https://wiki.archlinux.org/title/Downgrading_packages

Scimmia · 2024-01-02 14:58:37

MAYBL8 wrote:

Also you can downgrade a package or packages and prevent them from updating.
https://wiki.archlinux.org/title/Downgrading_packages

Which is a partial update, things WILL stop working at some point, and depending on just what you downgrade, could make the entire system unusable. This is a temporary troubleshooting step, not a solution to anything.

MAYBL8 · 2024-01-02 15:08:53

There is also this:

Read before upgrading the system

Before upgrading, users are expected to visit the Arch Linux home page to check the latest news, or alternatively subscribe to the RSS feed or the arch-announce mailing list. When updates require out-of-the-ordinary user intervention (more than what can be handled simply by following the instructions given by pacman), an appropriate news post will be made.

Before upgrading fundamental software (such as the kernel, xorg, systemd, or glibc) to a new version, look over the appropriate forum to see if there have been any reported problems.

Users must equally be aware that upgrading packages can raise unexpected problems that could need immediate intervention; therefore, it is discouraged to upgrade a stable system shortly before it is required for carrying out an important task. Instead, wait to upgrade until there is enough time available to resolve any post-upgrade issues.
Tip: You could use a pacman hook like informantAUR which prevents you from updating if there is fresh Arch News that you have not read since the last update ran.

Taken from here:
https://wiki.archlinux.org/title/System_maintenance

binarydepth · 2024-01-02 15:14:18

MAYBL8 wrote:

Also you can downgrade a package or packages and prevent them from updating.
https://wiki.archlinux.org/title/Downgrading_packages

True. I will try that approach.

binarydepth · 2024-01-02 15:16:27

dogknowsnx wrote:

Apart from the fact that there are "testing" repos already - who do you think is going to maintain all those packages?

Aren't LTS packages just past versions? Is easy as repackaging. I could learn Arch packaging and bundle the package with an LTS naming. I think those are already compiled. But on the other hand as mentioned before I can just downgrade the version myself.

seth · 2024-01-02 15:17:13

@MAYBL8 and how exactly do you think this justifies systematic partial updates?
Cause it doesn't. It's an elaborate caveat emptor.

@binarydeath
No you won't. You'll read Scimmias response.
"LTS" isn't "older version", there're binary dependencies etc. and if eg. glib2 updates and (yet again) falls ABI incompatible, everything depending on it has to be recompiled (and updated) against the new version. If that wasn't the case, you could happily pick random versions of any package and mix and match them as you like.
But in the - errhemm - "real world", that's gonna lead to a disaster.

Also what makes you believe the older version would be any more stable than the new version

Last edited by seth (2024-01-02 15:20:46)

MAYBL8 · 2024-01-02 15:24:07

@Seth
First you are much more knowledgeable on Arch than I am so I would take your advice over my own any day.
But what I was thinking is that if it just has to do with one or 2 packages to downgrade . That would be maintainable as long as there aren't too many dependencies involved.
I guess if it was that critical to keep a package at a certain version just never update that arch and install another version on your system that you update.

dogknowsnx · 2024-01-02 15:25:41

binarydepth wrote:

Aren't LTS packages just past versions?

If there were any LTS packages, they'd have to be leaf packages (which might change in the future) - if you want to go ahead taking @MAYBL8 advice then godspeed in dependency hell... (and I will stop taking your interest in a discussion on the matter seriously).

d.ALT · 2024-01-02 15:26:03

binarydepth wrote:

Is easy as repackaging. I could learn Arch packaging and bundle the package with an LTS naming

Welcome to dependencies hell

seth · 2024-01-02 15:40:27

MAYBL8 wrote:

But what I was thinking is that if it just has to do with one or 2 packages to downgrade . That would be maintainable as long as there aren't too many dependencies involved.

You can, in theory, up- or downgrade packages in isolation.

BUT (big butt): that requires understanding and oversight of what you're doing, ie. estimating the impact (misversioning a leaf package will at worst break the leaf package, misversioning ncurses will break everything), the involved dependencies (does the misversioned package depend on any library version that is not/no longer provided by the system - as that'll break your package for pretty much sure) and a times even version behavior (eg. when g_slice got dropped from glib2, the API remained, but the behavior exposed broken clients which all had to be fixed; downgrading such client against the newer glib2 might not get you a symbol resolution error, but you're now facing the buggy behavior because the new glib2 doesn't behave like the old one)

IOW: you're running a package management against the judgement of the maintainers and probably in your head (or on paper - certinaly not in the pacman database)

So in reality, this is a viable approch to deal with an immediate problem, esp. when some grumpy graybeard told you so. But you cannot realistically use random versions of plenty-a-packages over a longer period.

Head_on_a_Stick · 2024-01-02 16:15:44

@OP: have you tried NixOS? That seems to offer what you want.

merlock · 2024-01-03 02:52:17

I don't know anything about them, but wouldn't this be a 'good' use case for a flatpak?

Trilby · 2024-01-03 03:09:44

As noted, downgrading a single package (or subset of packages) via the archive is unsupported and likely to result in problems. However, downgrading the entire system to a specific archive date - or more practically just picking a date to point the repo Servers to in order to hold packages as that date - is safe and practical (within reason and under certain circumstances).

This, in fact, would be the sane way of achieving what you seem to be calling "LTS" packages. However, LTS is not old packages but it is older versions of software in new packages with relevant security patches.

Debian stable doesn't get fewer updates than their edge / testing / whatever. In fact, in many cases, stable or LTS distros will get more updates. They just will not get many updates to new (major) versions of software: instead fixes are back-ported to the older version.

Systematically using old packages without back-ported security patches is not called "LTS", it's called "stupid".

(As for "good" use of flatpak: Ceterum censeo Flatpak esse delendam)

Another aside: WTF is up with the title of this thread? I have used almost exclusively arch linux on desktops / laptops for well over a decade. Have I note been in the "real world" that whole time?

Last edited by Trilby (2024-01-03 04:50:17)

dnim · 2024-01-03 03:32:13

You can achieve the same by simply not updating often. Does it work right now? Then don't update, it will keep working, and there's your LTS. That will do you a lot better than partial upgrades.

Arch wouldn't be so user-centric if it wasn't a rolling release. Think about it, you're not getting the unstable bleeding edge, you're getting (ideally) recent stable releases of software when you do a system update. That's the whole point.

Last edited by dnim (2024-01-03 03:32:56)

binarydepth · 2024-01-03 06:18:39

Thank you very much all for all the replies. Yeah, I have been riding high on latest updates for long time. I totally forgot about libs/dependencies. Ok this is my only idea behind "real world" I have been doing AI Prompt Art as a hobby and Python getting updated breaks the setup and I need to compile my own thing because I have old GPU RX 590 which is no longer supported by AMD and industry support seems to not be the scope of Arch. We are all here in the FOSS world, yes you can min/max with AUR but in the overall trade of things it goes their own way apart from the industry.

Flatpaks and AppImage is the perfect solution it seems for apps and I do use them, but I can't do the same for Stable Diffusion with RX 590. So I am in the need to pace down on updates so I can learn to use software from resources that have a hard time catching up such as Youtube and paid Courses. So as a regular savvy user starting to learn a skill after learning to install Arch I encounter this clash of how things work. The work to install Arch to then you are out of the loop. As of now I am uninstalling Discover that is the app that nags me to update when it is not the best thing always (if it ain't broken don't fix it).

Sorry I had a hard time expressing the issue, I hope it clear now with my specific use case.

seth · 2024-01-03 07:56:54

I have been doing AI Prompt Art as a hobby and Python getting updated breaks the setup and I need to compile my own thing because I have old GPU RX 590 which is no longer supported by AMD

IOW this is a massive https://en.wikipedia.org/wiki/XY_problem
Where's your thread about the python issue?

industry support seems to not be the scope of Arch

AI Prompt Art as a hobby

You're producing AI porn on an industrial scale?
I'm not the one to judge, but dude… you can get blind from that

binarydepth · 2024-01-03 08:07:31

seth wrote:

I have been doing AI Prompt Art as a hobby and Python getting updated breaks the setup and I need to compile my own thing because I have old GPU RX 590 which is no longer supported by AMD
IOW this is a massive https://en.wikipedia.org/wiki/XY_problem
Where's your thread about the python issue?
industry support seems to not be the scope of Arch
AI Prompt Art as a hobby
You're producing AI porn on an industrial scale?
I'm not the one to judge, but dude… you can get blind from that

No it is not about the Python issue, it is about the tendency of breaking form the software that is not Free or "too old" for Arch. The case of EdrawSoft was a thing I encountered where the libraries where upgrade just a tad into the program not running. This fast pace on Arch makes developers not target Arch it in the whole generality. We can make a poll and see what people are actually doing with Arch apart from servers which the scope of this post. I intend to do some Qt apps and then delve into Unreal some CLI programs and scripts may go into the mix in the future. So putting things on the specific, do you think Arch is the distro for me? Also, taking into account that I want to keep doing the AI prompt as a hobby. You can see what I do on DeviantArt

seth · 2024-01-03 08:36:35

tendency of breaking form the software that is not Free or "too old" for Arch

Is it "for arch" or just because it's using some python2 bitrot?
It's hard to comment on the issue if it's not even clear what it is specifically.

Generally speaking, rolling release distros are implicitly moving targets, binary-only releases will mandate frequent updates from the vendors, but they'll have to keep on w/ software developments anyway.
Incompatible upstream changes will hit them sooner or later no matter what. Sooner w/ arch, later w/ debian stable.

That being said: valve uses arch as basis for SteamOS…

icar · 2024-01-03 09:04:30

If Python upgrades break your setup, don't use the system Python for that program and take a look at https://github.com/pyenv/pyenv

dnim · 2024-01-03 14:54:50

binarydepth wrote:

Yeah, I have been riding high on latest updates for long time. I totally forgot about libs/dependencies. Ok this is my only idea behind "real world" I have been doing AI Prompt Art as a hobby and Python getting updated breaks the setup
......
Sorry I had a hard time expressing the issue, I hope it clear now with my specific use case.

You could always run your AI tools from within a Python venv. Then you will always have the correct interpreter and module versions.

System wide python is for system packages. Both automatic1111 and comfyui work fine on updated Arch and if you followed instructions then you'll have everything inside a venv.

Reading material on Python virtual environments, you'll be using this a lot if you play with AI regularly.

Trilby · 2024-01-03 15:59:23

seth wrote:

Incompatible upstream changes will hit them sooner or later no matter what. Sooner w/ arch, later w/ debian stable.

But the result is very different from the end user's perspective. There is certainly a lot of software out there that is distributed as closed binaries only, and the producers of that software will generally keep it sufficiently updated to run on debian. So yes, library changes will catch up with that software producer in either case, but the time between when it "catches up" to them and when they respond could be close to zero for Debian, and effectively infinite for arch.

Closed-source software with versioned library dependencies is a fully valid argument for needing "stable" libraries ... it's probably the only argument for it, and it may not be sufficient and / or convincing, but it is a valid point in favor of it.

Last edited by Trilby (2024-01-03 16:02:09)

Arch Linux

#1 2024-01-02 14:04:32

Real world applicationof Arch linux for the Desktop

#2 2024-01-02 14:32:15

Re: Real world applicationof Arch linux for the Desktop

#3 2024-01-02 14:34:04

Re: Real world applicationof Arch linux for the Desktop

#4 2024-01-02 14:49:43

Re: Real world applicationof Arch linux for the Desktop

#5 2024-01-02 14:51:08

Re: Real world applicationof Arch linux for the Desktop

#6 2024-01-02 14:58:37

Re: Real world applicationof Arch linux for the Desktop

#7 2024-01-02 15:08:53

Re: Real world applicationof Arch linux for the Desktop

#8 2024-01-02 15:14:18

Re: Real world applicationof Arch linux for the Desktop

#9 2024-01-02 15:16:27

Re: Real world applicationof Arch linux for the Desktop

#10 2024-01-02 15:17:13

Re: Real world applicationof Arch linux for the Desktop

#11 2024-01-02 15:24:07

Re: Real world applicationof Arch linux for the Desktop

#12 2024-01-02 15:25:41

Re: Real world applicationof Arch linux for the Desktop

#13 2024-01-02 15:26:03

Re: Real world applicationof Arch linux for the Desktop

#14 2024-01-02 15:40:27

Re: Real world applicationof Arch linux for the Desktop

#15 2024-01-02 16:15:44

Re: Real world applicationof Arch linux for the Desktop

#16 2024-01-03 02:52:17

Re: Real world applicationof Arch linux for the Desktop

#17 2024-01-03 03:09:44

Re: Real world applicationof Arch linux for the Desktop

#18 2024-01-03 03:32:13

Re: Real world applicationof Arch linux for the Desktop

#19 2024-01-03 06:18:39

Re: Real world applicationof Arch linux for the Desktop

#20 2024-01-03 07:56:54

Re: Real world applicationof Arch linux for the Desktop

#21 2024-01-03 08:07:31

Re: Real world applicationof Arch linux for the Desktop

#22 2024-01-03 08:36:35

Re: Real world applicationof Arch linux for the Desktop

#23 2024-01-03 09:04:30

Re: Real world applicationof Arch linux for the Desktop

#24 2024-01-03 14:54:50

Re: Real world applicationof Arch linux for the Desktop

#25 2024-01-03 15:59:23

Re: Real world applicationof Arch linux for the Desktop

Board footer