devbox
podman
devbox | podman | |
---|---|---|
50 | 361 | |
7,751 | 22,164 | |
3.8% | 2.0% | |
9.7 | 10.0 | |
1 day ago | 6 days ago | |
Go | Go | |
Apache License 2.0 | Apache License 2.0 |
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.
devbox
-
Show HN: Brioche – A new Nix-like package manager
There's also [devbox](https://github.com/jetify-com/devbox).
Tried a lot of them, and after a while I found the nix the package manager requires too many workarounds. Things don't just work. For example, installing alacritty requires an OpenGL wrapper. Neovim can't find libraries to build some plugins. Basically, anything GUI had issues.
In the end, `cargo install`, `go install` and download a release archive from github are simpler to script for most of the tools I use.
-
Elixir and Machine Learning in 2024 so far: MLIR, Arrow, structured LLM, etc.
Yeah, the LSP situation remains a sore point, which is deeply unfortunate. One of the big reasons I like Gleam! Luckily, there are new contenders popping up to hopefully solve the issues with elixir-ls: try https://github.com/elixir-tools/next-ls or https://github.com/lexical-lsp/lexical. They might give a better experience.
> By the way, the official Elixir website recommends using Homebrew to install it. But almost everyone in the Github issues and comments says ASDF is the way to go.
The Elixir website is right. Just use Homebrew until you find a real need for asdf or similar tools. It's far simpler.
asdf (or mise[0]) is merely a way to manage different runtime versions between various projects, you would use it the same way as one might use rbenv/rvm, nvm/n, or even Docker/nix, and so on. You don't need it until you have several ongoing projects requiring different runtime versions. If you reach that point, great! It'll be worth the effort then, and it isn't difficult.
Personally, I just use Homebrew elixir for easy ad-hoc access to iex/livebook. If I truly need reproducible environments, devbox[1] (a sort of nix wrapper) is nice and extremely straightforward.
Tl;dr: Just use Homebrew. If your requirements expand beyond that, you'll have far more challenging problems to deal with.
[0] https://mise.jdx.dev/dev-tools/comparison-to-asdf.html
[1] https://www.jetify.com/devbox
-
How I use Devbox in my Elm projects
Before I went on my Christmas vacation last year I wrote an article on how I use Nix in my Elm projects. At the time, I was pleased with my set up. However, not even a month would go by before my satisfaction was questioned. In early January, Carlo Ascani asked a question, on the Elm Discourse, about his Umbra project. I decided to explore his project and I soon discovered two files, devbox.json and devbox.lock, I had never seen before. This piqued my curiosity and I had to learn more. I followed the link to the Devbox website and feverishly read the docs. I... was... hooked. I was pleasantly surprised by its simplicity and it seemed to fit my use cases really well.
-
Show HN: Flox 1.0 – Open-source dev env as code with Nix
How does Flox compare to Devbox? https://github.com/jetpack-io/devbox
- Instant, easy, and predictable development environments on any machine
-
PackagingCon – a conference only for software package management
I've spent the last year managing all my packages with Devbox (https://github.com/jetpack-io/devbox).
Local dev, cloud dev, CI, production – all with the same config file. Fingers crossed my talk submission for PackagingCon gets accepted. It'd be awesome to share this new way of working with a wider audience.
-
NixOS and My Descent into Insanity
> Now to figure out what a "flake" is…
Flake is a worthwhile addition to Nix that is worth learning. But like anything Nixian, it's not straightforward.
Have you checked out any of the tools that aim to simplify Nix experience? We built Devbox (https://github.com/jetpack-io/devbox) with this in mind.
-
TySON: a native go library that lets you use TypeScript as an embedded configuration language without depending on Node or V8
Also devbox ( https://github.com/jetpack-io/devbox ) which is what this is for does not work on windows because of its Nix dependency.
-
Simplifying preview environments for everyone
For these reasons, I believe most developer environments should prioritize developer experience over fidelity. Tools like Containerized development environments and cloud emulators can strike the right balance and there’s no surprise that we see increased activity around devcontainers, and similar solutions.
-
Codespaces but open-source, client-only, and unopinionated
Local first, cloud optional is the only way (IMHO) we're going to get people off their local laptop development setups.
We need to support local dev environments first, with the exact same config a developer can then move to the cloud.
See https://github.com/jetpack-io/devbox for how this can be achieved and https://www.mikenikles.com/blog/dev-environments-in-the-clou... for my thoughts after 3 years of working in this space.
podman
- Root your Docker host in 10 seconds for fun and profit
- Show HN: Pico: An open-source Ngrok alternative built for production traffic
-
How I ended up using Colima for Docker on Apple Silicon
A lot of well-known Docker alternatives emerged at this point, the most commonly recommended of which must be Podman (along with Podman Desktop). This is what I use on my Windows machines, and this was the first solution that I tried on the Macbook as well.
-
Podman 5.0 has been released
Example of why: https://github.com/containers/podman/issues/5102#issuecommen...
-
Exploring 5 Docker Alternatives: Containerization Choices for 2024
Podman
- Podman 5.0.0: final release candidate
-
A Gentle Introduction to Containerization and Docker
Even though we will focus on Docker for this article, I wanted to mention that there are more container creation and management tools such as Podman, Rkt, and so on.
-
A Journey to Find an Ultimate Development Environment
By using containerization, the application will always have the same configuration that is used in the development environment and production environment. There is no more "It works on my machine". Some examples of containerization technologies are Docker and Podman.
-
Anatomy of Docker
Podman Documentation. Podman is a daemonless container engine for developing, managing, and running OCI Containers on your Linux System.
-
Exploring Podman: A More Secure Docker Alternative
AFAIK podman either already supports pods in quadlet container files, or will in the near future. https://github.com/containers/podman/pull/20762
What are some alternatives?
devenv - Fast, Declarative, Reproducible, and Composable Developer Environments
Portainer - Making Docker and Kubernetes management easy.
devpod - Codespaces but open-source, client-only and unopinionated: Works with any IDE and lets you use any cloud, kubernetes or just localhost docker.
lima - Linux virtual machines, with a focus on running containers
Home Manager using Nix - Manage a user environment using Nix [maintainer=@rycee]
kaniko - Build Container Images In Kubernetes
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
rancher - Complete container management platform
asdf - Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more
containerd - An open and reliable container runtime
nix - Nix, the purely functional package manager
nerdctl - contaiNERD CTL - Docker-compatible CLI for containerd, with support for Compose, Rootless, eStargz, OCIcrypt, IPFS, ...