fpm is not a complete solution. It just creates a package from your files, however you need to build them in the environment of the distribution where it is supposed to work, with the same versions of dependencies. OBS is the best solution I know, but with it you need to write packaging scripts compatible with each distro you are targeting. It is quite time consuming and requires a good knowledge of native packaging tools.
You can also use any CI system that is able to execute builds in containers with your target distros. This requires a bit more scripting (just a bit), but modern CIs are easier to setup than OBS in case you need your own instance. This also allows you to use your favorite VCS and workflow you are comfortable with.
Pro tip: configure a font that doesn’t show open circles for unused braille characters to have a higher priority than your current font to get better-looking graphs.
On my system, braille characters are provided by DejaVu Serif, and it was as easy as just installing the font.
I think they mean the variable width of the graph’s columns. If you watch it as the graph moves, there are gaps at every 2 columns.
I don’t understand though the thing about font priorities.
And also, would that just change all fonts? Unless you mod the font to only have the braille characters…
No, you’ve got it set up right. Many people will have graphs where each character rectangle has open circles for the unused braile dots in the character block.
Linux only package manager that works across distros. It supports sandboxing via bubblewrap, but be cautious because by default most programs in Flathub are not as sandboxed as they should. You can host your own repository but it is heavily centralized towards Flathub, controlled by Red Hat, IBM.
Flatpak uses OSTree to distribute and deploy data. The repositories it uses are OSTree repositories and can be manipulated with the ostree utility. Installed runtimes and applications are OSTree checkouts.
AppImage
You’re basically packaging your program and every single dependency up to the C library. Linux only.
An AppImage is basically a self-mounting disk image that contains an application and everything the application needs to run on the target systems
Canonical’s take at flatpaks. They are quite similar, but snaps use AppArmor instead of bubblewrap and the server is proprietary, so an inferior option and should be avoided. The only “advantage” is that it’s used by default in Ubuntu.
Nix/Guix
multi distro package manager with reproducible builds support, more akin to a traditional package manager (eg apt)
Snappy and Flatpak talk about how they make library versions work better together and blabla and how they solve a lot of issues but that’s just a praetext, the real elephant in the room is that they are a big wink to proprietary software, they were designed for that, they just can’t say it so they focus on other things in their PR statements.
How Nix and Guix work is that they are traditional “package managers” as such the user or the distributor must have access to the source code to compile it into a package, the interesting difference is that it is capable of keeping library versions apart and will automatically share libraries if they are exactly the same. But packaging still occurs downstream, not upstream.
Snappy and Flatpak allow packaging to occur completely upstream at the developers side, which means they no longer have to cough up source code to whomever who will package. Which leads to an inferior solution to the user with far higher memory and storage consumption.
this one is something in between Nix and traditional package managers. It’s main advantage is that it works in other UNIX-like OSs, like FreeBSD, NetBSD, IllumOS as well as in Linux. The only not Linux specific option in this list (other than docker, which is not a package manager but a container)
Docker
I wouldn’t recommend this one, since it requires packaging a whole OS that creates a lot of overhead. And it can be tricky to use with GUI programs.
Overall, I think that Nix/Guix present the most advantages, with Pkgsrc being a less known close second and Flatpak being in the third position due to it’s relative popularity and overall advantages over snaps and docker. Docker might be decent option if it’s a program designed for servers, tho.
I’d also recommend that you add your program to the AUR, because even if it only works on Arch and Arch based distros, it’s incredibly easy to do and maintain as long as the building of your program doesn’t change drastically between versions.
I believe Pkgsrc compiles the program at install, so it’s native. But it’s been a long time since I used it, you might need to look into it.
And you’ll have a hard time finding a “native” package format, because distros have different libraries versions: arch libraries will be much more updated than Debian’s, so things might break trying to execute programs depending on those libraries. That’s why Flatpak, AppImages, Nix, etc bring their own libraries, because if they don’t, things will break.
They are native in the sense that they are Linux executables, but it’s true that they bring their own dependencies, but as I said, that’s necessary for cross distro support.
Nix allows you to download a binary of a proprietary package because every input is hashed. You may need to patch it to work with the correct paths, but these tools already exist.
I wonder if they consulted Plasma devs about it. Sure they said that they aim to make Wayland ready for Plasma 6, but it didn't sound like it was an actual plan for 6.0. After all they got their hands full with Qt 6 porting, and there are still major roadblocks with completing Wayland support, while 6.0 is about to have its alpha release already.
Knowing Fedora devs however, I suspect they didn't. They switched to Plasma Wayland by default several Fedora releases ago, when it was in no way ready. I guess I will switch to a different distro when this time comes.
Yeah, as usual the opinionated crew are making something that one may even like feel like it’s forced down everyone’s throat (see: systemd, snap…) and making everything worse. I don’t see how any Linux desktop distro worth its salt can get by ignoring 90% of the PC GPU market share and essentially forcing them into an inferior desktop experience for pure ideology’s sake, and I LIKE Wayland. I even put up with all its quirks in a particularly quirky implementation (KWin). But this ain’t it if you want users to use your OS.
electron is a framework, and a shitty one if I might say so, it’s cross platform but it’s not a way to package for multiple distros. You still need to package the electron program in either the native package manager (apt, pacman, etc) or a distro-agnostic one (flatpak, appimage, snap).
but it is not an option. It’s not a tool for packaging programs.
Building an electron program is no different than building it in GTK or QT in the sense that they are just the GUI toolkit and they do not do packaging.
It’s a framework for programs to have their GUI wrapped inside a browser, so they are cross platform.
But electron doesn’t create packages. You can package an electron program using Flatpak, snap, apt, AppImage, pacman, or whatever.
I use btop, iotop, jnettop, and radeontop. I rarely need any individual piece of information any of them but they make for an incredible spread of blinkenlights.
hollywood is an installable app which when run takes over your machine with a fullscreen terminal and multiple panels with lots of dyanamic data to look like a hacking scene from a Hollywood film. :)
linux
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.