toolbox
zap
Our great sponsors
toolbox | zap | |
---|---|---|
109 | 17 | |
2,235 | 481 | |
3.4% | - | |
9.1 | 4.1 | |
14 days ago | 7 months ago | |
Shell | Go | |
Apache License 2.0 | MIT License |
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.
toolbox
-
ChromeOS is Linux with Google’s desktop environment
The team has both made a ton of effort switching off their proprietary Skia based rendering tech and adopting standard Wayland, and has put forward huge effort to making running incredibly well integrated real Linux containers just work.
The headline is true. ChromeOS is Linux with Google’s desktop environment. But it obfuscates the details. It's a damned by omission statement. It has some really good sauce to help you not notice often, but it's not at all a Linux desktop environment one can regularly use. You can do a lot of Linux desktop-y things but only through well crafted special unique wrapped processes that mostly but not fully help mock & emulate a regular Linux desktop. Even though it now runs Wayland, the apps you want to run will have atypical intermediates up the wazoo.
And no one else uses any of this tech. ChromiumOs has so much interesting container tech, does such an interesting job making containers think they have a regular Linux / FreeDesktop environment. It's far far far far deeper virtualization than for example https://github.com/containers/toolbox . But you know what? Google has made zero effort to get these pieces adopted elsewhere. It's open source but not intended for use outside Chromium/ChromeOS. I respect & think ChromeOS is a quite viable Linux, and it's so much closer to the metal & more interesting, amazing tech, but my gods Microsoft has gone 300x further to establish wsl2 as a sustainable community effort folks could use & target, in a way that ChromiumOS has done nothing about.
It's sad how Google has transformed from a company that appreciated & worked with ecosystems, that drove things collectively forward, into an individual player that does their own things & delivers from on high. ChromiumOS is such an incredible effort, but it's so internernally drive & focused, and it's hard to believe in such a wildcat effort, even though it's so so good. It keeps coming into better alignment with Linux Desktop actual, but via shims and emulations that no one else cares about or which seems marketed elsewhere. And that inward focus makes the whole effort both so exceptional & promising, but suspect. Such a different nearby but alternative & separately governed universe. ChromiumOS/ChromeOS do excellent at faking being a Linux desktop, and wonderfully have increasingly drawn more strength from that universe, but are still wholly their own very distinct very separate very controller other space. In many ways that's great, secure, good, and miraculously transparently done. But it's still hard to really trust, being such a weird alien impostor, faking so much for end user apps, and there's tension in believing ChromeOS will keep straddling the rift in pro-user manifestations forever.
-
Introduction to Immutable Linux Systems
I'm really, really happy with my current setup of Fedora immutable + toolbox [0]. This tool lets you create containers that are fully integrated with the system, so you have acces to the entire Fedora repos, can run graphical apps, etc. while still having everything inside a container in your home directory. That means no Flatpak required. Highly recommended.
-
Codespaces but open-source, client-only, and unopinionated
Seems like toolbox is also in this space; https://github.com/containers/toolbox
- What’s the safest way to compile apps from source in a binary-based distribution like Fedora?
-
Silverblue: Nvidia drivers in toolbox?
I'd probably try running it on the host system first. If you want to use your nvidia gpu inside toolbox, you would indeed need to install the drivers in the container: https://github.com/containers/toolbox/issues/116
-
Seamlessly run other Linux distributions inside your terminal
How is it different from Toolbox? (https://github.com/containers/toolbox)
Quoting the README:
It implements the same concepts introduced by https://github.com/containers/toolbox but in a simplified way using POSIX sh and aiming at broader compatibility.
-
Devs using SilverBlue, how to use your IDE?
### fix vscode not opening links in toolbox https://github.com/containers/toolbox/issues/291 ``` sudo dnf install flatpak-xdg-utils sudo ln -s /usr/bin/flatpak-xdg-open /usr/bin/xdg-open
-
20 Years of Nix
> What’s the escape hatch to bring those into the dev environment?
One thing you can do is try the Nix package manager on your Linux or macOS system. -- If it's not in nix, you can just do it the way you did things before.
If you want to try NixOS:
1. Writing a package is only necessary for sharing code.. you can still just have Python, setup a virtual env, & run the program as you would.
2. You could use a tool like Podman or Docker, to run stuff in containers. I've heard stuff like https://github.com/containers/toolbox helps this.
(Among other solutions).
-
Debian and immutable OS
Containers, containers everywhere! That is really the whole concept and benefit of an immutable OS. Your underlying OS and libraries become an image you can boot, update, and roll back if needed. Since your system is read only you will run all of your apps as Flatpaks or inside of a toolbox container. The benefit of all of this is additional security and stability. If a new package breaks your system, just rollback to an old one. It's hard to compromise your system too if it is immutable. It is sort of neat to think that conceptually I should never have to worry about borking my system again. But here is where I run into some issues for a typical home Linux user...
zap
- Working on an app to "install" and manage AppImages
-
Lamenting What AppImage Could Have Been
On the run, but I assume you've seen this: https://zap.srev.in/ / https://github.com/srevinsaju/zap
-
appimage-builder 1.0.0 was released, a tool for packing applications along with all of its dependencies using the system package manager to obtain binaries and resolve dependencies.
That said, there is Zap.
-
Interesting Benchmarks of Flatpak vs. Snap vs. AppImage
If you can download and install software from the web (which you also can do with debs and rpms btw), you can create a package manager to automate that from the terminal. You either trust a project or you don't, and if your don't the package format makes no difference.
There's also zap
-
It's time to fork some good projects
NOTE: I don't know when and if to add new AppImages from the main catalog, also because a part of them is mostly broken and out of control. The AppImage packages compiled and managed by "AM"/AppMan are new AppImages that use scripts that also allow constant updating and recompilation from scratch, as if they were installed from AUR, using more reliable sources (official repositories for Debian and derivatives) . If you are interested more to the applications made available officially from the official AppImage.GitHub.io catalog, I suggest you to use Zap, Bread or the aforementioned Appimagedl. All these amazing utilities can be quickly installed via "AM" or AppMan.
- AppImage and centralized repositories: my point of view
-
"AM" and AppMan - that's why they don't include support for AppImageHub and similar sites
The preferred sources for downloading packages in AppImage format via "AM" / AppMan are GitHub and Sourceforge, however, writing installation scripts that are compatible with one or more programs is a difficult task. Just think that many developers add multiple versions of the same product in the same tag (I have to include also commands to find the exact name of the latest version to avoid the download of other packages), or include more complex links that require an equally complex function to obtain the latest version of a program, and this slows down the loading of these programs on the "AM" repository I manage. I have therefore included excellent AppImage package managers such as "Bread" and "Zap" among the downloadable programs, but also "AppimagePool" and "bauh" are available among the graphics applications (not counting a "Pacstall" AppImage versionI made). These tools should compensate the lack of support for certain sources that I have not included in the "AM" repository.
-
A collective intelligence test?
You have zap, still a CLI tool, but integrates perfectly with launcher menus and useful to manage AppImages.
What are some alternatives?
distrobox - Use any linux distribution inside your terminal. Enable both backward and forward compatibility with software and freedom to use whatever distribution you’re more comfortable with. Mirror available at: https://gitlab.com/89luca89/distrobox
podman - Podman: A tool for managing OCI containers and pods.
batect - (NOT MAINTAINED) Build And Testing Environments as Code Tool
zsh-in-docker - Install Zsh, Oh-My-Zsh and plugins inside a Docker container with one line!
AppImageUpdate - AppImageUpdate lets you update AppImages in a decentral way using information embedded in the AppImage itself.
cockpit-podman - Cockpit UI for podman containers
nerdctl - contaiNERD CTL - Docker-compatible CLI for containerd, with support for Compose, Rootless, eStargz, OCIcrypt, IPFS, ...
box86 - Box86 - Linux Userspace x86 Emulator with a twist, targeted at ARM Linux devices
asciinema - Platform for hosting and sharing terminal session recordings
com.valvesoftware.Steam
docker-tramp.el - TRAMP integration for docker containers
AppImageLauncher - Helper application for Linux distributions serving as a kind of "entry point" for running and integrating AppImages