So this is a struggle that the linux community has been going through for a few years now, and the crux of the issue is this: Most software licenses do not allow you to compile their software with your own for free. This is a problem in situations where software you want to use is expecting another piece of code to be available, such as an audio middleware like pulseAudio for example. The way this has traditionally been solved on linux systems is through the package manager, which would install these dependencies separately, and the distro maintainer would have a list of supported software that worked with the whole system and they would be updated automatically.
But a few things have changed:
- As more people adopt linux, if they find software that isn't available through their package manager they will try to get it from the source. If the developer does not have a build for your distro tested and available, there is a good chance it won't work. These leads to complaints and undue support requests.
- Containerization hit the scene. Containerization allows software to be run in it's own evironment, possibly locked off (sandboxed) from the rest of the operating system. This is good, especially for corporate uses since you can use outdated software without the risk of the whole machine/server/network being compromised (in theory)
So developers are looking for ways to make software work on any distro without a whole lot of extra work, businesses want software that doesn't cost a lot to secure, and lawyers want to make sure their software is not compiled as someone else's code. That's where things like flatpak, appimage, and snap come into play. These are all containers that package the program with its dependencies in a virtual environment. They are, in a way, vying for dominance right now. But the downside is, of course, having multiple copies of the same software on one machine and software updates are more confusing.
dependency management is a really tough problem. on windows and OS X the norm is to just ship a big blob of dependencies as part of the application package. applications may share the same java or .net (etc) runtimes but that's about it. so you'll have maybe 500 copies of SDL2 on your system but it's all abstracted behind pretty visuals so who cares.
on linux, distro maintainers usually ship those packages and dependencies separately and take care of screwing all the garden hose together, but they can't really do this for every single application out there and they especially can't do this with prohibitive proprietary software licenses. so for the rest you'll either get things like appimage and flatpak which do the bundling like on windows and os x (and sometimes also do some fancy process isolation shit for Xtra Security), or a github repo with some build instructions. sometimes you get third party repositories that you can point your package manager at, like PPAs for debian/ubuntu/etc or the AUR for arch linux and those usually work great but they're not always up to date.
in any case, even with all this shit, I'll never go back to the experience of running shady self-extracting binary packages that try to install ask toolbar and mcafee antivirius
I’ll never go back to the experience of running shady self-extracting binary packages that try to install ask toolbar and mcafee antivirius
I've genuinely forgotten how much of a thing that is on windows, my god.
Most software wouldn't even use the same version of a library anyways. On Windows, you end up having 50 different versions of the C++ redistributable blah blah blah because every application uses a different minor version number. Would have been better to just statically compile that stuff in...
I find it really weird that nerds are worried about extra disk and memory space being taken up by multiple copies of a library as if that's the most pressing issue worth sacrificing everything else for. It provides such little benefit. How many applications running at any given moment on a computer even use the same library? And chances are, if programs were just statically compiled, they would be smaller anyways because all of the unused library code would be compiled out. 90% of software library code is just feature bloat.
there's more to it than just disk space. imagine if another critical openssl vulnerability pops up. would you rather rely on one team of distro maintainers or 500 teams of projects, a big chunk of which may be dead? also, statically linking glibc is highly discouraged, so that's another major hurdle.
I still think it would be ideal but yeah.
And when u try to read about it, the documentation assumes so much knowledge and familiarity with Linux :'(
It's true. There's a basically undocumented set of skills that you have to pick up first before the docs are useful. But also you can't pick up the skills, sometimes, without using the docs.
IMO this is one reasom to start with, or just test, a linux distro that has you do a bunch of low-level stuff manually. To install gentoo, you have to use the command line and call the various magical incantations to make the right things happen. Through repetition, and sometimes the documentation, you'll pick up what is happening.
You can always go back to a more automated distro, but you'll have the skills to put out the little fires that pop up here and there.
There's also a course out there somewhere called something like, "the missing semester of cs" that covers a bunch of common nerd skills that mostly applies to linux. Highly recommend it.
The beauty of linux and open source is that you can rewrite the documentation. Doc writers are badly needed because coders hate writing documentation - you'll fit right in.
Writing documentation is literally a job that non-coders can do.
Anyone can write documentation until they have a question they don't know the answer to. And Linux land is full of stuff people don't have an answer to. There are literally system calls that have no documentation whatsoever. There are probably system calls barely anyone knows exist.
Perfect is the enemy of good. Pick up a github project and get to work. Be the change you want to see.
Perfect is the enemy of good. Pick up a github project and get to work. Be the change you want to see.
How does someone with no understanding of the code start documenting the code exactly?
It's kind of a recurring thing in Linux, that there's always that one thing that's kind of fucked. If nothing is fucked, Canonical (the Ubuntu people) will pick something that's merely not very good, and "fix" it by pushing out a new solution that's not ready yet, thus transitioning it to a fucked state. This unites the entire Linux community around fixing that feature, and over a few years they eventually settle on a good solution and the cycle begins anew. The thing does actually get fixed during that though.
It's package management's turn now. It was audio when I switched to Linux, then Gnome 3, then I think there was a scheduling thing that I missed somewhere in there. I assume it was printers at some point, because of how eerily well they work now.
So give it another couple years and there'll be a good solution, and we'll all be complaining about something else instead.
who says pipewire is broken buggy shit? it's been flawless and a marked improvement over pulseaudio for me since Fedora switched to it by default, with the exception of one short-lived bad release.
I actually haven't had trouble with Pulseaudio since like 2010. But I don't do anything super in-depth audiowise, so maybe it's worse if you're trying to use a DAW or something.
f nothing is fucked, Canonical (the Ubuntu people) will pick something that’s merely not very good, and “fix” it by pushing out a new solution that’s not ready yet, thus transitioning it to a fucked state
Red Hat is a worse offender - they're the shitheads that resulted in pulseaudio and systemd, among others. The former started being somewhat usable barely a few years ago (and even then, not always); the latter is still in the "fucked up state" phase.
I hugely disagree with systemd being in a "fucked up state." I actually will now avoid some community run distros (Void, MX, etc) because they don't use systemd. I find systemd unit files intuitive to understand and pretty easy to write, and even easier to use.
I agree with the user friendliness aspect for sure. But systemd still sucks right now. A few examples; do you use full disk encryption / LUKS ? its passphrase request module is 1. vastly different than the initramfs one, and less secure; 2. given to presenting you the prompt for different volumes in random order; its LUKS closure module screws up about 50% of the time, having to timeout after 1:30 for each volume it failed for.
When I started using Linux in the 90s, something that was extremely common was a minor issue (due to BIOS compatibility IIRC) where Linux wouldn't be able to shut down the computer; it'd end up with a console saying "you can now cut power" - much like Windows 95 at the time. This disappeared more than a decade ago; and yet for the first time in more than 10 years, due to systemd, this is now again the case on 2 out of 3 laptops I own.
Some other issues are due to the automated systemd scripts generations for services that didn't support it natively yet, mind you (uwsgi under debian comes to mind); but a lot aren't. Moreover, systemd means loss of compatibility with legacy hardware, and a lot of embedded stuff; the RAM usage of that thing is awful for a simple init system. It has a lot of feature creep, too; and binary format for logs, while it's a more minor issue, can be a pain in the ass on - again - legacy or exotic systems.
Finally, I'm having a hard time trusting such a new, needlessly complex software at such a critical position in a system security-wise. Feedback on security issues from the dev team on their tracker didn't always inspire confidence, either.
Ultimately I'm sure eventually it'll mostly be OK, of course, just like pulseaudio; and I wholly agree about the easiness of the syntax. But I am absolutely convinced you could've implemented something far far cleaner, simpler, and just as user friendly without all the bullshit on top of it. For me ultimately it's far removed from the unix philosophy: it is over engineered, makes it harder to integrate with other tools, and reminds one more of proprietary software than free software in the way it was designed.
I do use LUKS on my laptop, but not my desktop. I guess I don't encounter those situations because I just use the default encrypted setup the Fedora installer gives me on one hard drive and one volume. Nor have I seen messages from any computer I've used Linux on telling me to shut down the computer because it couldn't handle it itself.
My impression of systemd is very different than yours. I think it's a godsend unifying group of technologies that harmonizes different distros, just as the kernel itself puts everything under the "Linux" umbrella. I can take common unit files, concepts, and ideas and share them from Arch to Debian to Fedora and others as well. Things like binary logs don't trouble me because tooling exists to decode them, just as cat and zcat exist to print text and compressed text files.
You could move sysvinit files from distro to distro, mostly, too, mind you; that being said perhaps I'm just an old curmudgeon stuck in their habits.
True.
You know what's a bit funny to me? I actually just had an experience recently where I was rewriting a docker-compose file as a script to work with podman and for the containers to reside properly in a pod. If you don't know, podman doesn't officially support the compose files, they have more natural support for kubernetes kubes which looks pointlessly complicated... Anyway, so I went from the declarative config file (docker-compose.yml) to my own little handwritten mishmash.sh to create the more podman-centric script and I felt like it was a reverse of my experience of going from sysvinit to systemd.
it means that you turn modules on and off and configure the whole system from a single git repo. it's declarative in that you don't write scripts, just provide the features you want turned on or turned off. I've been using it for years and at least as a professional it's much better. idk about as a layperson. there's a steep learning curve the second you have to like write a custom package or something. if you're a developer, I'd try it out as an env manager for code projects first - it's one of the most useful features the package manager provides.
I think 99% of the programs I use are updated through the package manager, flatpak has such large install size that I only use it if there's no other option
You are free now. It has both upsides and downsides. But I’ll take freedom and privacy with some mild inconveniences any day.
Used to be that everything would run through the package manager, but yeah that's changed due to reasons started elsewhere in the thread
Linux is basically this comic about everything until tides shift and all buy one standard get abandoned (or a big project makes the decision for everyone else).
PS distro package managers + flatpak is the best don't @ me about snaps.
I hate that shit too. I can't decide whether I hate having to check my distro every time I come across a solution that says to install a .deb, flatpak, etc.; or the programs and applications are all in folders with intuitive names more
my order of preference goes
distro repos
flatpak
appimage
build from sourceIt's janky. I can't raise or lower the volume on my system if there's a right click menu open :cat-confused:
Just close the right click menu.
You have to roll with the punches, here. I can’t use my Bluetooth headphones when on Linux. It’s a mild inconvenience, but I have a 3.5mm cable for it anyways so it’s a small price to pay for freedom and privacy and security.
can’t raise or lower the volume on my system if there’s a right click menu open
can’t use my Bluetooth headphones when on Linux
You have to roll with the punches
Very good OS you've got going there, average users will definitely want to adopt it.
Also, how tf does the first one even happen?
It sounded like their volume wouldn't turn down at all while a right click menu was open. Which means keyboard shortcuts wouldn't work either.
Otherwise, they wouldn't even have had a problem because clicking to change volume necessarily gets rid of the right click menu anyway.
