The issue with those numbers is that they don’t account for people having multiple devices. My PC, Laptop, and Steam Deck all download apps from flathub, so I’m likely counted multiple times. On the other hand most people only use one device, so the actual numbers probably don’t doffer much. It’s an estimate anyway.
Edit: I’m not surprised the amount of people using flatpak/flathub increased so much. It’s my preferred method of installing proprietary software and works on any distro, even unconventional ones like NixOS or Alpine. Sandboxing continues to get better, be it isolation or usability.
You may be interested in reading this post about the process of packaging Steam.
tl;dr: It’s mostly an annoyance reserved for packagers to deal with. Dynamically linked executables can be patched in a fairly universal fashion to work without FHS, so that’s the go-to approach. If the executable is statically linked, the package may have to ship a source patch instead. If the executable is statically linked & close-source, the packagers are forced to resort to simulating an FHS environment via chroot.
I would say it’s actually easier in many cases. Nix has really fantastic packaging tooling. You do have to learn a bit of the nix language, however (not become an expert).
The issue comes when trying to build from source. In most other distros, ou just follow the readme. In nix, you have to package it.
If I am packaging software for gentoo, all I have to do is translate the build instructions from the project’s documentation to gentoo’s package recipe. In nix, it seems that it is not that simple and you’ll have to do some exploration. Am I wrong?
It’s just that most (if not all) build system in the source code package would assume some level of FHS compliance.
For example, they would install:
executables under /bin /usr/bin
libraries under /lib or /usr/lib
sysconfigs under /etc
manpages under /usr/share/man
and so on…
These build systems would include options to change these, but you’d then have to change all these values to adapt to nix structure. While it’s all been done by the nix package maintainers, you’d have to do all that if you’re to come up with a new package.
In the FHS compliant distros, the maintainers wouldn’t need to change anything since these values are already set to the values they want (there are actually minor details they’d change, but that’s another topic).
If I am packaging software for gentoo, all I have to do is translate the build instructions from the project’s documentation to gentoo’s package recipe.
It’s the same for Nixpkgs.
In nix, it seems that it is not that simple and you’ll have to do some exploration. Am I wrong?
In well behaved build systems, it’s likely easier to package than most other distros. If it’s not as well behaved you will have to do some “exploration” and the complexity can get quite out of control if the build system is exceptionally terrible.
Here is the package for the GNU hello program which uses a well-behaved build system:
If you ignore the optional passthru.tests, this is very simple. You provide metadata, sources etc. to the generic mkDerivation function and that’s it. The most complex non-standard thing this derivation does is enable the build system’s tests.
You don’t even need to run the provided build instructions because Nixpkgs’ stdenv abstracts those away. If it finds a makefile, it’ll automatically run make and make install with the correct flags for instance. Same for other standard build systems; if you pass cmake into nativeBuildInputs, it’ll attempt to build, install, check etc. using cmake’s standardised interfaces.
If the build system is poorly behaved however (like for instance Anki’s), you will have to get into the weeds and do some rather advanced things:
If your use cases (a.k.a. requirements) are met by your current distro, never switch.
If you are satisfied with stability, availability of support, quick availability of security patches, never switch.
This is particularly important when you are using your Linux desktop as your daily driver.
Most you can do is to check what additional features other distros are offering (rolling release, hardened/zen kernel, x86-64-v2/3 support, file system type, user base, availability of packages, package formats, overall documentation etc.), validate if you really need those features.
If you are interested or just curious to test those features, install that distro on a VM (QEMU/KVM) to try it out first safely. Use it on VM for a while, make yourself comfortable with it. Once you are satisfied with it, only then switch.
USB block devices containing mountable filesystems (on Desktop systems) can generally have those filesystems mounted and files written to them by regular users; But the block device itself stays only root writeable.
On windows I think you need a HDMI dummy plug as others mentioned here before but Linux has to have a way to run headless. You can run Linux in Qemu without a connected display. If you find anything on why it’s not booting please let me know!
My own classic was fiddling with the nvidia PRIME config to try and get rid of some very mildly irritating screen tearing. No graphics output at all. Now this is fixable of course, but it’s a pig.
And I’d decided to do this 2 hours before an incredibly important progress review meeting for my PhD.
Got it back with about 10 mins to spare and decided just to leave the driver config alone after that.
Bonus round
Also a friend managed to bork his ubuntu 16 laptop by trying to switch from unity to gnome and ending up with sort of neither. That was reinstall territory right there.
I have a stupid one, but far from funny… I’ve been using and building computers for a very long time so I’m far from a noob, but I’m still quite cautious, bordering on paranoid, so I like to unplug all other drives when re/installing an OS just to avoid stupid mistakes. I go through the installer on the livecd, there’s only one drive to choose from so I don’t think much about it, select that it should erase everything, I set up the new partition structure, and start the process. After about a minute I begin wondering “why is it taking so long?”, and “what is that ticking noise? SSDs shouldn’t be making any sounds when written to”, when I realize that I had unplugged the wrong drives and that I was currently overwriting my main storage drive. Of course I had backups of the most important things like photos and code, though not really synced for a couple of months so I lost some stuff permanently.
I use flatpak for virtually everything because sandboxing your applications from each other and from your private data is a great idea to improve your system security. This helps prevent one compromised app from taking actions that affect the rest of your system.
For example, I have the VLC flatpak and used flatseal to revoke internet access because I only use it to play files. If a file tries to exploit VLC, it will not be able to upload any data or communicate with the attacker’s servers. I revoke any permissions my apps don’t actually need.
There are a few exceptions though. I run development and administrative tools directly because I do actually want unrestricted access to the system for these apps.
linux
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.