toolbox
cockpit-podman
Our great sponsors
toolbox | cockpit-podman | |
---|---|---|
109 | 4 | |
2,264 | 387 | |
3.2% | 4.4% | |
9.1 | 9.5 | |
15 days ago | 4 days ago | |
Shell | JavaScript | |
Apache License 2.0 | 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.
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...
cockpit-podman
-
Monitoring and visibility of rootless containers running by different users on single server
Hey, I have homelab NUC server where I run different services as rootless podman pods and containers running by dedicated users, eg. nextcloud pod running by nextcloud user, gitea by gitea, znc by znc and more. Next step was trying to monitor these services. First trey was using cockpit-podman feature, but in UI I see only containers of my user and rootfull which both was empty. I cannot switch to another user because the're not capable for login to cockpit. Now I'm testing prometheus and podman-exporter which seems ok, but again I see containers only if I run prometheus-podman-exporter service as user who run another podman container (e.g. as nextcloud user). Of course I can run this service parallel as dedicated user with another port and add them as target to prometheus scrape config but from obvious reason I want to avoid that. Is it more gentle way to monitor my pods? I know that those namespaces are one of the main feature of Podman but I don't consider this before my deploys :)
- Cockpit Project
-
Front end ...gui for podman.
Cockpit has a podman module (cockpit-podman)
-
Podman: A tool for managing OCI containers and pods
Tested podman to replace docker (the cli) on a mac yesterday Most of it works fine. They have an easy way to setup a vm now with `podman machine`: https://podman.io/getting-started/installation#macos
If you want the management GUI, install cockpit: https://github.com/cockpit-project/cockpit-podman
Try podman, you'll be impressed.
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
traefik - The Cloud Native Application Proxy
podman - Podman: A tool for managing OCI containers and pods.
podman-compose - a script to run docker-compose.yml using podman
machine
opentelemetry-collector-contrib - Contrib repository for the OpenTelemetry Collector
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!
gns3-server - GNS3 server
singularity - Singularity has been renamed to Apptainer as part of us moving the project to the Linux Foundation. This repo has been persisted as a snapshot right before the changes.
Podman Desktop - Podman Desktop - A graphical tool for developing on containers and Kubernetes
kind - Kubernetes IN Docker - local clusters for testing Kubernetes