Are you building a C/C++ project that should run on BSD, Gnu/Linux and other platforms? Then maybe use autotools. All distro tooling will easily be able to handle it.

Are you just building some small project that will never make it into a distro, maybe just use something simpler. Or even just a plain makefile.

Things are suspicious but you still spread gossip and maybe lies.

Nobody knows who responded here. Don’t spread rumors.

https://lemmy.world/post/9437525

My version of this with a bit more detail

Yeah, very nice. It will be tough to bootstrap since you need a critical mass of people who ideally live close together so that it’s cheap and quick enough to deliver the items in question.

I’ll give it a try. Nothing to loose.

Why a gantt chart for a road trip though. There are not that many parallel things you usually do, no?

Not sure I really understand the issue here. Is it about installing or modifying parts of existing config files? I try to use config.d facilities as much as possible for this problem.

Not sure I understand your criticism. Debs definitely help compared to how I was doing things before. Adding some form of parameters (eg. the hostname used by some web application) to the package is necessary and I’d rather have in the form of debconf than having to edit a config after installation.

Do you have an alternative?

What about using standard shell or bash? I know they are not easy to use correctly, but at least they won’t break every few years.

Makes sense. I imagine the push model of Ansible had a lot to do with the speed issues? I can imagine how a solid .deb would be much more performant.

It’s part of the problem, but the other part is that you have to re-do the package building all the time. Alternatively you fiddle with tags and only run part of your roles (which is a hassle anyways because ansible does not really have good abstractions that help encapsulation).

Professional sysadmin here who has been trying to create ansible roles and playbooks to re-create all his VMs.

I have spent a lot of time “packaging” custom web applications (and other stuff) for ubuntu systems and building complex configurations for a system of interacting hosts. Once I had finished writing a role to deploy or update one of those applications, I often found it very hard to use them for maintenance. The biggest problem being that I couldn’t remember how to invoke the roles or playbooks to get my desired outcome and what state my systems were in. Another problem with ansible for my usecase is it’s slowness. Installing a rather complex package might take minutes on one host.

All in all, I found that I had been doing things the wrong way. Off course, it’s nice having all the procedures documented somehow, but if you don’t remember what state your machines are in and what tags and roles to apply, it wont be of practical help in your day to day work. My workload is maintaing a bunch of VMs with mostly different sets of packages and config installed, so ansible doesn’t play out it strengths of being able to execute things on multiple machines in parallel.

I’m now switching over to a model where I only use ansible to manage installation and configuration tying machines together and where I use debian packaging for, well, packaging. Although it’s pretty tough to get into, once you have taken the first hurdles, things fall into place easily. You can do so many things with debian packaging, including installation of custom systemd service units, depend on other packages, distribute customized config files, install custom management scripts. There is even a way to ask questions during installation in an interactive and non interactive way (debconf). Since you target your package for a specific OS and version, you can rely on files being in their usual places (FHS), which makes configuration easy. The nice thing about this model is that I can now use the tools I’ve been using since ages, to install, update, uninstall, inspect and configure things. On top of that, I could easily distribute our weird to install software to third parties now instead of relying on a broken and long installation procedure.

Sometimes we should just stop reinventing the wheel and just try to understand what previous generations have built (.deb, sql, unix, etc). Sure, the old ways are bad in many ways but they often get the work done.

This being said, I’m happy for people to work on things like nix, guix, ansible etc. They are just not the right tool for my set of skills and problems.

Uhh, very nice. I didn’t know about xdg-ninja.

Afaik guix is very similar to nixos in that respect. The store where applications are installed is called /gnu there.

Thanks for the input. Things are complicated: https://askubuntu.com/a/135679 . Apparently it originally meant “user” but then slowly was used for system stuff. So people invented backcronyms.

I unfortunately did it in whimsical.com which is great but also closed if you don’t pay. https://whimsical.com/fhs-L6iL5t8kBtCFzAQywZyP4X is the best I can do.

The better you understand it the less it seems bad.

Added a black background version.

The legend is a bit broken. Will fix it maybe.

As for the rest, yes, the FHS can be confusing. It’s from a time where mostly professional admins would deal with it and requirements were pretty different from today’s end-user systems. If you want to understand more, I urge you to read the spec. It’s highly readable! https://refspecs.linuxfoundation.org/FHS_3.0/fhs.html

You could invert the colors in GIMP or similar.

There is a lot of work being done on reproducible builds in the guix project and other distros. The idea being that you can be sure that a binary package is bit for bit the same, whoever builds it and on whatever system. This would be the first time you have complete traceability of what goes into your binaries.

On guix, you can for example install substitutes of packages which you could also build manually. Since the build environment and the dependencies are very tightly controlled, you have mathematical proof that the substitute is equivalent to the package built by the maintainer. You can thus be sure that no evil third party injected malware into the substitute binary, unless ot was done at source code level and the package maintainer has put it there (by accident).