I’ve been transitioning to Linux recently and have been forced to use github a lot when I hadn’t much before. Here is my assessment.
Every github project is named something like dbutils, Jason’s cool photo picker, or jibbly, and was forked from an abandoned project called EHT-sh (acronym meaning unknown) originally made by frederick lumberg, forked and owned by boops_snoops and actively maintained by Xxweeb-lord69xX.
There are either 3 lines of documentation and no releases page, or a 15 page long readme with weekly releases for the last 15 years and nothing in between. It is either for linux, windows, or both. If it’s for windows, they will not specify what platforms it runs on. If it’s for Linux, there’s a 50% chance there are no releases and 2 lines of commands showing how to build it (which doesn’t work on your distro), but don’t worry because your distro has it prepackaged 1 version out of date and it magically appears on flatpak only after you’ve installed it by other means. Everything is written in python2. It is illegal to release anything for Mac OS on github.
Wait until you install some package and then scratch your head not knowing how to run it.
Then think “I’ll figure it out later” but you never do. Only to be reminded of it a month later when you happen to see it scroll by in an apt-or-whatever package upgrade.
“Oh yeah, I forgot about that. I should check that thing out again” you think to yourself. But you never do. Repeat for eternity.
Helix Editor did this to me. They have so much documentation on their site about how to use the editor, how to extend it, theme it, etc., etc. What they didn’t seem to document, though, is that the binary is named hx, not helix :/
When I’m confused like that, I check https://packages.debian.org and open the file list for the package. That way I know what binaries are installed.
The fun part is that as a dev, you don’t really know that either. It’s just the file name of the executable. Anyone can rename that.
And even if it’s not renamed, you still don’t know, if your users need to call it with just hx or with ./hx or some other path.
Obviously, you should mention somewhere that the executable is likely called hx, but because that requires an explanation, there’s certainly a tendency to not mention it very often…
Congrats on expressing that in the most passive-agressive and gatekeepery way you could’ve. I’ve been using Linux for the better part of a decade now, and know my way around the usr dir - however things work a bit different on NixOS, whose package manager doesn’t involve installation steps beyond adding the word “helix” to my packages list. I’m not great at reading though, so I absolutely would’ve missed something as obvious as the Installation page 😅
As for your beliefs about postmodern Vim clones, what’s the point (and fun) in the freedom of choice Linux offers if I can’t install and try out the latest fun spin on an old fave from time to time?
If I install a package, I don’t even know what it installed and/or where.
I can’t believe Linux can’t even tell you what it installed where - even Windows can do that.
Interesting how we live in different bubbles ✌️
Yes the world of github and linux is vast and I am like a newborn baby. I hope to visit your bubble one day my friend.
your distro has it prepackaged 1 version out of date
found the ubuntu user :D
Just a small (or maybe big?) tip for you 🙂
If it’s for Linux, there’s a 50% chance there are no releases and 2 lines of commands showing how to build it (which doesn’t work on your distro), but don’t worry because your distro has it prepackaged 1 version out of date
There’s a tool called Distrobox.
You can install it (via CLI I think?), and then manage it the easiest graphically way via BoxBuddy (available in your Software Center), or just the terminal if you prefer it.
With it, you can screw all those “Doesn’t work on my distro” moments.
You’re on Linux Mint? No problems, here’s the AUR for you!
✨✨✨ BONUS: Your OS won’t break anymore randomly due to some AUR incompatibility, because everything is containerized! ✨✨✨
Even if you run Arch, use it to install AUR stuff. Or Debian/ Ubuntu, add PPAs only via Distrobox.
It’s absolutely no virtual machine. It basically only creates a small, lightweight container with all dependencies, but it runs on your host. Similar to Flatpaks.
You can also export the software, and then it’s just like you would have installed it natively!
Your distro choice doesn’t matter anymore. You now can run any software written only for Suse, an abandoned Debian version 10 years ago, Arch, Fedora, Void, whatever. It’s all the same.
I hope that was helpful :)
That’s great, but it should still be possible and well documented for people to run things natively. Some people want less bloat for technical reasons (maintaining a product with very little storage or memory). Tinycore Linux is my go-to example of the benefit of keeping things lightweight for a purpose.
When you’re maintaining a product that is based on linux, you’re surely qualified to port that thing to your platform yourself.
Open source developers are thanklessly giving away their work for free already, and for the many things where there’s just a github page it is just a one man show run in spare time. Don’t demand them to give away even more of their time to cater for whatever distro you’re using, just because you are not willing to invest the time to learn how linux works and also not willing to give a way a few megabytes for the dependencies they’re developing against.
All the discussions about things like distrobox and flatpak where linux novices express their dissatisfaction due to increased disk space are laughable. In the linux universe sole users have no power in deciding what goes, they do not pay anything and at worst pollute the bug tracker. Developers are what make up the linux universe, and what appeals to them is what is going to happen. Flatpak is a much more pleasant experience to develop for than a gazillion distros, hence this is where it is going, end of story. As a user either be happy with wherever the linux rollercoaster goes, or - if you want to see change- step up and contribute.
Why Linux will never be mainstream ^
No… It’s the users that are wrong and stupid.
Each to their own. Linux is, in my opinion, about choice. If one prefers everything to be ultra minimalist, native and lightweight, then that’s fine.
I personally just find to be Linux’ most overlooked strength is containerization. It’s one of the main reasons why most servers run Linux, because of things like Docker. On the desktop, containers are way underutilized, but that’s now slowly changing with things like Flatpak or Distrobox.
A distrobox container is technically more bloated than a native install, sure, that’s correct.
But, in my opinion, it’s like saying “Drawers and closets are bloat for my apartment. I throw everything on the floor.” Yeah, now you have less things in your room, but it looks like shit, you can’t find anything and you fall over your tubberware that’s mixed with your underwear and shampoo.
Having everything collected in a container only costs me a few hundred MBs and a small amount of RAM if needed. But, literally every PC has more than 50 GB hard drive space and 8 GB RAM. If your system slows down because of one container, then your PC is the problem, not distrobox.
That absolutely doesn’t mean we should stop optimizing software of efficiency. But it can help us to spend our time on more important stuff, like fixing bugs or adding new cool features.
I really love Flatpak because of that. Sure, it has some drawbacks, but as soon as more devs support Flatpak officially, and iron out some issues we currently have, like misconfigured permissions, they’re (imo) the best package format. Why should a distro maintainer have to apply every software change to their package format? That’s needlessly duplicated work.
