distrobox
flatpak
Our great sponsors
distrobox | flatpak | |
---|---|---|
401 | 431 | |
8,758 | 4,013 | |
- | 1.3% | |
9.7 | 9.0 | |
3 days ago | 4 days ago | |
Shell | C | |
GNU General Public License v3.0 only | GNU Lesser General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
distrobox
-
Tools for Linux Distro Hoppers
Distrobox is a tool that enables us to try Linux distro CLI, including their package manager. This requires a containerization tool (e.g., Docker). In Windows, this can be achieved using WSL (Windows Subsystem for Linux)
-
Fedora Atomic Desktops
I use containerized versions of things, ubuntu and chainguard images mostly.
You can always create containers with init if that's how you want to do that though. Some distros publish images that come that way: https://github.com/89luca89/distrobox/blob/main/docs/useful_...
-
Battery consumption of using remote development with WSL2?
Btw #3: Depending on what the user is trying to accomplish, e.g. maybe to make WSL(2) itself more of a "subsystem" than a "container engine", using something like Distrobox or nsbox.dev can be a good idea (along with Docker or Podman in Distrobox's case; the other one uses systemd-nspawn).
- Clang now makes binaries an original Pi B+ can't run
-
An independent package manager that every hacker deserves
I've been using Linuxbrew for few months last year, it was always hit-or-miss whether some tool will work or if it will be macOS only recipe.
Then I started using aarch64 CPUs, and Linuxbrew still doesn't work on those. Bummer.
So while I'd love to see a package manager that spans all Linux distros, Homebrew is not it, at least for now. Nix may be it, but it has its own interesting issues at times.
I recently used distrobox to run Arch Linux container on Fedora host and it was a good experience. I did not try exposing the CLIs from there to the host OS but it sounds possible https://github.com/89luca89/distrobox/blob/main/docs/usage/d... . I don't want to daily-drive Arch again, but it's a great project to install fresh versions of various CLI tools from.
- Flathub – The Linux App Store
- FLaNK Stack Weekly 09 Oct 2023
-
NixOS and Flakes Book: An unofficial book for beginners (free)
I use NixOS as a daily driver. (My previous Linux of choice had been Arch).
I'd describe Nix as 95% wonderful, 5% hugely painful.
I learned Nix by using it on macOS/Linux before trying NixOS. I was concerned that NixOS would be very difficult to use.
It was easier to use NixOS than I expected; the main problems I ran into were when a tool would helpfully download some kind of binary, but since NixOS doesn't put its shared libraries where other Linuxes do, these programs wouldn't work. -- Though, for a popular-enough tool, most likely someone else already has a Nix package written that helps out.
There are other "escape hatches". e.g. I think something like distrobox could be used if native-on-NixOS stuff has problems. https://github.com/89luca89/distrobox
Nix can otherwise be difficult if you need to write some Nix code. There are several concepts in Nix which are foreign enough to how things have been done before; e.g. when building a package, it won't have access to $HOME; but, recent language tooling will often want access to $HOME. -- If something goes wrong, you may often need a wider and deeper understanding compared to if something goes wrong on a more typical Linux distribution.
For as difficult as it is, the trade-offs Nix makes are essentially "I'm going to put in a lot of effort now, so that I don't have to put in effort some time later". (This favours Nix when "effort later" is multiplied many times).
Overall, as a choice for "I need this to work right now", I'd recommend against NixOS (especially for someone who doesn't know Nix).
-
Toolship: A (More) Secure Workstation
I'm running silverblue but running my containers through distrobox. Both toolbox and distrobox are running on podman under the hood, so it's the same technology as far as I understand. However, distrobox has some interesting features relevant to this idea of development isolation. One is that it has an assemble feature[1] built-in. Where you can feed it a recipe file and it will build or rebuild containers accordingly. The other is that it allows setting a custom home directory for the container, among other host/container isolating options[2].
Perfomance wise my containers take a couple MiB of rams and no perceptible CPU usage when not in use. At least as far as I can tell.
[1] https://github.com/89luca89/distrobox/blob/main/docs/usage/d...
[2] https://github.com/89luca89/distrobox/blob/main/docs/usage/d...
- i386 in Ubuntu Won't Die
flatpak
-
Tools for Linux Distro Hoppers
Hopping from one distro to another with a different package manager might require some time to adapt. Using a package manager that can be installed on most distro is one way to help you get to work faster. Flatpak is one of them; other alternative are Snap, Nix or Homebrew. Flatpak is a good starter, and if you have a bunch of free time, I suggest trying Nix.
-
Podman Desktop 1.6 released: Even more Kubernetes and Containers features
No, it looks like you have to do it on an application basis.
- how strong is the steam (runtime) sandbox for games?
-
Been thinking of switching to linux but I am a noob
Flatpak
- FLaNK Stack Weekly for 20 Nov 2023
-
Flathub – The Linux App Store
> CLI tools do not implement auto-complete themselves. What you are seeing are auto-complete scripts for your shell that make network connections.
nit: This is incorrect. Robust auto-complete scripts call the actual program to provide completions.
That is what Flatpak does. It is Flatpak itself that makes the network connections.
https://github.com/flatpak/flatpak/blob/main/completion/flat...
Not that it would make any differencen if it was implemented in Bash seeing as the Bash script is also provided by Flatpak.
-
Meduza co-founder's phone infected with Pegasus
Not really. Even with modern technologies, the Linux desktop technology stack is very, very far behind when it comes to security.
The Linux kernel itself is a very weak foundation security-wise, the only way Android and ChromeOS get away with it is by using a very small feature set and restricting everything else as much as possible with seccomp, SELinux and heavy sandboxing.
The Linux desktop userland doesn't have meaningful hardening features compared to other platforms (even Windows is ahead, sadly). For example, practically all distros use glibc's memory allocator which has both poor performance and security [1] and their toolchain is based on gcc, with no support for modern compiler security features such as CFI (with the sole exception of Chimera Linux). Not to mention the permission model is completely outdated, like in that xkcd cartoon. Flatpak only mitigates this partially, because the Flatpak sandbox is very weak. The people working on Flatpak are doing their best, but from reading some GitHub issues, it's clear they are badly overworked and not experts on security at all. The person responsible for Flatpak's seccomp sandbox has admitted it isn't even his main responsibility and he doesn't have much knowledge about seccomp and is learning along the way [2]. The Flatpak seccomp filter is based on denylist instead of allowlist, and many dangerous syscalls can't be blocked because many applications rely on it (e.g. Firefox needs ptrace for the crash reporter). You also have to be very careful and use Flatseal (which is not officially supported) to deny permissions such as /home filesystem access, because it lets Flatpak apps override their own permissions by design [3]. And dangerous kernel components like io_uring are exposed [4], while Google disables them on their systems for their exploitation potential.
Here is a more detailed article examining the lack of security of Linux phones in case you're interested: https://madaidans-insecurities.github.io/linux-phones.html
If you want a FOSS-based secure phone, GrapheneOS is the best option.
[1] Check this comment by GrapheneOS founder for some technical details and how it compares to hardened allocators such as Android's Scudo or Graphene's hardened_malloc: https://github.com/NixOS/nixpkgs/issues/90147#issuecomment-6...
[2] https://github.com/flatpak/flatpak/issues/4466#issuecomment-...
-
The technical merits of Wayland are mostly irrelevant
Sensitive features like screenshots, input methods, screen locking and whatnot are behind extensions (or portals). I'm not familiar with the state of GNOME/KDE/Flatpak, but at least on the wlroots side of things it is true that currently these extensions are enabled and accessible by any process that can talk to the Wayland socket (breaking those security benefits, as you say). This is changing with protocols such as security-context that allow a sandbox engine like Flatpak (or your custom scripts) to restrict what features apps can use. (so your browser can't register an input method, or some random app can't lock the screen)
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
-
Modern CSV version 2 is now available
It shouldn't be too complicated to create a package from the provided tarball.
[1]: https://flatpak.org/
- Flutter 3 on Devuan 4: 始め方
What are some alternatives?
toolbox - Tool for interactive command line environments on Linux
steam-runtime - A runtime environment for Steam applications
firejail - Linux namespaces and seccomp-bpf sandbox
wsl-distrod - Distrod is a meta-distro for WSL 2 which installs Ubuntu, Arch, Debian, Gentoo, etc. with systemd in a minute for you. Distrod also has built-in auto-start feature on Windows startup and port forwarding ability.
Autodesk-Fusion-360-for-Linux - This is a project, where I give you a way to use Autodesk Fusion 360 on Linux!
docker-android - Android in docker solution with noVNC supported and video recording
rustdesk - An open-source remote desktop, and alternative to TeamViewer.
toolbox-vscode - Toolbox Visual Studio Code integration
nix - Nix, the purely functional package manager
toolbox - The Docker Toolbox
vscode-dev-containers - NOTE: Most of the contents of this repository have been migrated to the new devcontainers GitHub org (https://github.com/devcontainers). See https://github.com/devcontainers/template-starter and https://github.com/devcontainers/feature-starter for information on creating your own!
dockerfiles - Various Dockerfiles I use on the desktop and on servers.