dietlibc VS Vagrant

- Dietlibc: https://www.fefe.de/dietlibc/

The commercial success of a product totally depends on the business model you come up with, whatever be its opensource (or not) license.

Corporates have a vested interest in promoting the propaganda that only a non-xGPL opensource license can be commercialised successfully simply because they cannot freely steal the source code of a competing xGPL licensed software.

The real value of an FSF license, like the AGPL, is that it was designed to protect the copyright holders, and its users, "right to repair". And thus, it cannot be closed source by anyone (apart from the original copyright holders) once released under the said license (even if future versions are closed source, the old version under xPL remain opensource perpetually). Other open source license (that are less stringent) are prioritised to increase developer contribution. Source code under such license can be closed-source even from the original copyright holder.

But again, commercial success totally depends on the business model you come up with, irrespective of your license. The right license and the right business model will empower each other. Or cripple your business.

Stefan Tomanek - Creator of dietlibc, a libc optimized for small size - https://github.com/stefan-tomanek (The dietlibc project itself doesn't have an official GitHub repository, but you can find it at https://www.fefe.de/dietlibc/)

There are definitely some nice alternatives to glibc out there. He mentions Cosmopolitan Libc. I've used musl, uclibc, and dietlibc/libowfat in the past.

Maybe you should include the math part of a libc statically with your code. glibc is one option, or dietlibc if you want it to be as small as possible.

I agree that the implementation of printf is complex, but the interface is not. Hence calling it should not introduce bloat. Glibc adds a bunch of constructors and tables and such, whereas linking with dietlibc will probably lead to a smaller executable.

Vagrant

Take a look at Vagrant! https://www.vagrantup.com/ In my admittedly limited understanding I believe it offers closer to a nix like reproducable rather than repeatable deployments.

on the off chance one hasn't been tracking it, there were several "we don't need your stinking BuSL" projects when this drama first started:

https://github.com/opentofu#why-opentofu (Terraform)

https://github.com/openbao/openbao#readme (Vault)

and I know of several attempts at Vagrant <https://github.com/hashicorp/vagrant/forks> but I don't believe one of them has caught traction yet

There are also some who have talked about an "open Nomad" but since I don't play in that space I can't speak to it

It sounds like you're using Nix as a sort of configuration management solution. CM just isn't worth it for managing a single desktop IMO. It triples the effort for whenever you need to add or remove a package, as you must now add that also to your nix configuration. You're supposed to be able to make that back up in time saved restoring to the next machine, but inevitably the next machine will be different enough that you'll have to edit it all anyway. In the end I just got tired of trying to manage my own machine with infrastructure as code (though in fairness I was using puppet at the time not nix).

I keep a git repository with all my dot files in it[1]. This seems to work the best. It has a Windows folder as well, and I copy that out whenever I need to set up Windows.

A lot of people like using WSL but I hate how it hogs on my memory. Hyper-V is a terrible virtualization engine for consumer-grade use cases because it can't thin provision RAM. If I need to use docker, I will spin up a small Linux VM using vagrant[3] with Virtualbox[4] and put Docker on there. Vagrant is an extremely underrated tool in my opinion, particularly in a Windows context.

I use scoop for packages. Typically I will scoop install msys2 and then pin it so that it doesn't get blown away by the next upgrade.

Then I basically do all of my development inside of msys2. I can get most things running in there without virtualization. In my case that means sbcl and roswell for common lisp, senpai for irc, and tmux and nvim for sanity. Msys2 uses the pacman package manager and this is good enough.

All In all, I set up my Windows machine affresh after a while of not using it and it took me about 3 hours. Most of that time was just getting through upgrades though, I felt like it was pretty fast.

1: https://git.sr.ht/~skin/dotfiles

2: https://www.msys2.org/

3: https://www.vagrantup.com/

4: https://www.virtualbox.org/

Tools like Docker and Vagrant can be used to allow local environments to mimic production environments.

There's an open issue [1]. A scripting interface has since been added [2], and updated [3], so there's progress.

[1] https://github.com/hashicorp/vagrant/issues/12518

Someone should fork and maintain Vagrant with an MPL open source license:

https://github.com/hashicorp/vagrant

https://github.com/hashicorp/vagrant/blob/v2.3.7/CHANGELOG.m... ?

The changelog lists both improvements and bug fixes and there's even apparently some effort to port it away from ruby: https://github.com/hashicorp/vagrant/blob/v2.3.7/internal/cl...