The Linux Thread - The Autist's OS of Choice

[SchizoDaemon]

launch Synaptic

That was your mistake. Never trust any of these GUI package managers.

 

[Pluciferous]

That was your mistake. Never trust any of these GUI package managers.

You’re telling me that running a program that Debian packages and supports is my mistake?

You sound like Steve Jobs telling people they’re holding the iPhone 4 wrong.

 

[Betonhaus]

That was your mistake. Never trust any of these GUI package managers.

mintupdate is pretty rock solid and doesn't do this shit

 

[SchizoDaemon]

You’re telling me that running a program that Debian packages and supports is my mistake?

Yes. This is like one of the first lessons I learned when using Linux. Do not trust any of the GUI tools for system administration.

I also don't want to use Git/SVN/Mercurial via a GUI either, for similar reasons. Many of the GUI Git clients used to use this Java Git client that would occasionally hose your repo.

If you fuck something up on the command line, at least you know what actually happened because you typed it.

There are deeper-seated architectural/philosophical reasons that only spergs like me care about why this is the case, but I won't elaborate on those here.

You sound like Steve Jobs telling people they’re holding the iPhone 4 wrong.

Not really. If you keep on using something that is broken/poorly designed and expecting it to work well after you've learnt of its problems, at some point it does become your fault.

I appreciate in some cases there are no alternatives, but this isn't the case here.

mintupdate is pretty rock solid and doesn't do this shit

I wouldn't touch this either. None of them can be trusted.

 

[Curry Teafag]

You’re telling me that running a program that Debian packages and supports is my mistake?

Is Synaptic even still a thing? My Proxmox doesn't have it. There, I only use Discover, apt, or the admin web page.

 

[Dead Lion]

Is Synaptic even still a thing? My Proxmox doesn't have it. There, I only use Discover, apt, or the admin web page.

Debian 12 used to ship it with MATE.

You know it's bad when GNOME software is better.

 

[DavidS877]

Problems come with Debian when you do stupid shit with the package manager (which they tell you not to do), or it is because it is an "open source thing that isn't really open source, and they only really have a build for Ubuntu and some stupid dependency on an ancient version or a super new version of libstdc++" and it is impossible to build yourself because they decided to use some bespoke build system instead of just using CMake / Make / Scons etc.

How I learned to stop worrying and love the podman.
Oh, your crap only runs on Ubuntu 20.04...
FROM ubuntu:20.04
Sure, waste of fucking space but I don't have to deal with packaging shit or finding a working package.

I even finally broke down and added registry.daveshouseofhorrors.in as a real host on my domain(not my real domain) so I can just push and pull local images. One part registry container, one part apache proxy rules, one part letsencrypt SNI cert.

Is Synaptic even still a thing? My Proxmox doesn't have it. There, I only use Discover, apt, or the admin web page.

I just use "aptitude" like a normal person. And when I hit dependency-hell I quit and try again.

 

[Curry Teafag]

Debian 12 used to ship it with MATE.

You know it's bad when GNOME software is better.

I just use "aptitude" like a normal person.

I have neither of those because I installed KDE on my Proxmox box. KDE comes with Discover, and that thing works just fine.

 

[SchizoDaemon]

How I learned to stop worrying and love the podman.
Oh, your crap only runs on Ubuntu 20.04...
FROM ubuntu:20.04
Sure, waste of fucking space but I don't have to deal with packaging shit or finding a working package.

Docker / Podman can't be used for a number of things I was trying to do.

Also fuck Ubuntu.

I just use "aptitude" like a normal person. And when I hit dependency-hell I quit and try again.

You could fuck around with all this crap or spend a few minutes reading the man page and never touch that

 

[DavidS877]

Docker / Podman can't be used for a number of things I was trying to do.

I'm curious what kinds of things, as about the only thing they can't do is be part of the kernel or the early boot process. You can pass through sockets, devices, volumes, to do pretty much everything else. I think there's even some dumb project to run an entire desktop environment in a container.

You could fuck around with all this crap or spend a few minutes reading the man page and never touch that

I'm not sure what the man page has to do with trying to switch from native Linux CUDA packages(old) to the Nvidia repo and trying to suss out how to get them installed without breaking the planet. Which does work fine, but you're better off starting that way instead of trying to do it after the fact. Then I realized just doing that shit in a container is a better option, sadly I'm still too lazy to container up my personal ComfyUI build so I need the system CUDA libraries for now.

 

[SchizoDaemon]

I'm curious what kinds of things, as about the only thing they can't do is be part of the kernel or the early boot process. You can pass through sockets, devices, volumes, to do pretty much everything else. I think there's even some dumb project to run an entire desktop environment in a container.

I am aware of what Podman and Docker can do. I work with them pretty regularly. However, there are weird limitations with rootless Docker (and I guess Podman). I ran into this while trying to run the IBM Granite models on Ollama, where it wouldn't see the AMD GPU properly. Even with the proper switches on rootless Docker (Podman IIRC requires similar switches), models were still running on the CPU.

Specific issues were things like ROCm + the AMD proprietary driver. Their packages just straight up didn't work properly with Debian Testing (which is now 13) at the time. I know it's all included in the distro now, but at the time it wasn't.

There is other stuff like trying to compile anything large with Rust. All the Rust tooling works fine (using Rustup works fine). However, some Rust packages use things such as just which is kind of like make IIRC.

I'm not sure what the man page has to do with trying to switch from native Linux CUDA packages(old) to the Nvidia repo and trying to suss out how to get them installed without breaking the planet.

I incorrectly assumed you were talking about the GUI version of aptitude, and you were following on from the previous convo about Synaptic.

I just use it apt for pretty much everything, even dpkg when I fuck it up. I kind of forget aptitude exists.

 

[DavidS877]

Ollama, where it wouldn't see the AMD GPU properly. Even with the proper switches on rootless Docker (Podman IIRC requires similar switches), models were still running on the CPU.

I can't speak to Ollama, but llama.cpp works fine with my AMD eGPU in a podman container. Not 100% sure if it was the proprietary driver or not. Will have to check that when I re-assbmble that system as parts have been re-allocated for other uses. All my Intel and Nvidia GPUs also have been working fine in podman, Intel vllm and Llama.cpp, Nvidia just Llama.cpp not tested vllm. Once I realized I needed host networking for decent RPC performance. (Oh Noes! My Security!)

 

[⠠⠠⠅⠑⠋⠋⠁⠇⠎ ⠠⠠⠊⠎ ⠠⠠⠁ ⠠⠠⠋⠁⠛]

That’s an almost perfect use case for a Flatpak…just saying.

It isn't a _terrible_ case for an AppImage. There is never a good use case for Flatpak.

I just use "aptitude" like a normal person. And when I hit dependency-hell I quit and try again.

What is this 'dependency-hell'? I remember dependency-hell when I was installing Debian packages on a 486 by downloading packages on another computer and copying every dependency I needed to install software I actually wanted over by floppy disk. I'm not sure how one has 'dependency-hell' when you can just run a command and it install things.

(Except for every time you have to deal with Python packaging and look up how to make venvs work, of course)

 

[DavidS877]

What is this 'dependency-hell'?

As I implied earlier. Things like "Hmm, I need the Nvidia CUDA libraries instead of the Debian ones." and instead of doing the smart thing and just wiping all the libraries and starting over I tried to "upgrade", which tends to make the dependency resolver very angry, until I wiped all the libraries and started fresh. Can also happen when you decide to use a package from backports with 37 other packages that depend on the exact version in the main repo.

In "normal" use it's things like "Why the hell does it keep upgrading Libre Office" oh, I'll just remove it, ok, why is it going to remove my entire desktop environment, right, dependency on xfce-desktop, fuckers.

 

[SchizoDaemon]

As I implied earlier. Things like "Hmm, I need the Nvidia CUDA libraries instead of the Debian ones." and instead of doing the smart thing and just wiping all the libraries and starting over I tried to "upgrade", which tends to make the dependency resolver very angry, until I wiped all the libraries and started fresh. Can also happen when you decide to use a package from backports with 37 other packages that depend on the exact version in the main repo.

Backports can be a pain. I am very selective about what I use from there.

In "normal" use it's things like "Why the hell does it keep upgrading Libre Office" oh, I'll just remove it, ok, why is it going to remove my entire desktop environment, right, dependency on xfce-desktop, fuckers.

It can do that on some packages, but it tends to be a core package or something related to the core desktop. It is better than it was back in Debian 10.

The most annoying thing is that it always wants to install gnome-games whenever you install a different desktop through tasksel

What is this 'dependency-hell'? I remember dependency-hell when I was installing Debian packages on a 486 by downloading packages on another computer and copying every dependency I needed to install software I actually wanted over by floppy disk. I'm not sure how one has 'dependency-hell' when you can just run a command and it install things.

You can update package-a in debian-backports, and then it breaks apt because package-b has a version constraint on package-a that is older than the backports version, even though they are both compatible.
I don't install anything from backports unless it is something like the kernel image, PipeWire or something like that e.g., I was running kernel 6.18 in Debian 13, so I get better game performance on AMD CPUs.

Often I install a lot of stuff to ~/bin which is mapped and added to yours .profile by default in Debian.
The other scenario is some developer has some software you want to build from source, and it uses about 10 layers of dependencies, and the dependencies are in some obscure Debian repo.

I ended up doing with Debian is what I have to do in Enterprise Linux distros (ancient RHEL / CentOS versions), basically building a bunch of stuff from source or downloading it tar.gz and copy it into ~/bin , /opt or /usr/local/bin
Then it doesn't touch the rest of the system. So I have a clear separation between the core-OS packages and the third-party ones.
Often I don't care about what version of GNOME, Cinnamon, X or whatever; so older packages for the core OS are perfectly fine 95% of the time.

Except for every time you have to deal with Python packaging and look up how to make venvs work, of course)

Anything that uses TensorFlow with AMD, you end up having to fix the broken mess of dependencies in the venv. Python stuff is a mess because a lot of stuff is either built by academics, scientists or postgrads who make very specific assumptions about what you are running e.g. you are using Ubuntu and no other Linux distros exist.