111–120 of 141 posts
Earlier quoted context omitted.
I agree with most of this, my biggest issue is how hard it is for me to recall any moderately complex shell syntax (or the slightly different Makefile syntax). LLMs largely solve that for me.
I would RTFM so I actually learn something instead of using """AI""" regurgitation.
but if you don't, and the tldr command isn't available, then good freakin luck.
Or, you could use NixOS and just declare your systems in some text files, git commit; git push. You build script becomes: while true; do git pull nixos-rebuild switch sleep x done That's it. You can even do it remotely and push the new desired state to remote machines (and still build on the target machine, no cross compile required). I've completely removed Ansible as a result and no more python version mismatches,…
Sounds interesting. Let's say the software is a web backend. Can you deploy it like this with zero downtime? So that the new version starts, new traffic goes to it, and the old version handles its active requests to completion and then shuts off.
But if you could have the server into 'lame duck mode' (no new connections accepted, but existing ones can finish) / gracefull shutdown and that's a blocking call (or you could poll if it's still up etc), then you could script that before the 'nixos-rebuild switch' call. Maybe sending SIGINT to the service does that already?
Or, you could use NixOS and just declare your systems in some text files, git commit; git push. You build script becomes: while true; do git pull nixos-rebuild switch sleep x done That's it. You can even do it remotely and push the new desired state to remote machines (and still build on the target machine, no cross compile required). I've completely removed Ansible as a result and no more python version mismatches,…
Instead of saying: while true You can instead say: while : There is actually a /bin/true, which could involve the fork of a new process for each iteration of the loop. The form that I have shown you is guaranteed not to fork.
Or, you could use NixOS and just declare your systems in some text files, git commit; git push. You build script becomes: while true; do git pull nixos-rebuild switch sleep x done That's it. You can even do it remotely and push the new desired state to remote machines (and still build on the target machine, no cross compile required). I've completely removed Ansible as a result and no more python version mismatches,…
My current deployment method for most of my personal hosts is: nixos-rebuild switch --target-host x.example.com (I still have a few Arch hosts using Ansible, but will migrate them in future)
There's also https://github.com/zhaofengli/colmena which may be of interest to folks.
Earlier quoted context omitted.
I've never been in a situation where I had to care. Bash is everywhere, it's a de facto standard of its own. Even a lot of buildroot and Alpine based Linux deployments, which don't come with bash by default, usually have bash added to them.
It’s not everywhere though, FreeBSD for example doesn’t use it.
Earlier quoted context omitted.
i have encountered messes of shell scripts that were difficult to maintain; in my first sysadmin job in 01996 i inherited a version control system written as a bunch of csh scripts, built on top of rcs but they were messy not because they lacked 'abstractions' but because they had far too many i think shell scripts are significantly more bug-prone per line than programs in most other programming languages, but if the…
If it was in RCS, then you could directly move the archives under a CVSROOT and use them natively. CVS had been out since Brian Berliner's version of 1989. I actually moved a PVCS archive into RCS->CVS this way, and I'm still using it.
Earlier quoted context omitted.
OK, and I wouldn't have used either Ansible or bash. I would have used picolisp, which is clearly superior for this task due to the flexibility that comes with the deep POSIX integration. When I think about excellent software Ansible isn't the first that comes to mind either. Clearly it's different for you, and the person who wrote the TFA doesn't agree with me either.
Let's take a step back from names for a second - I feel we're getting a little distracted by that. My gripe isn't with the tech, or even the solution. It's perfectly fine. I know I'm being overly critical, but I think they opened themselves to some judgement by making a post! I would do something very similar. Sure, the tool wouldn't have the exact same name, but the mechanism would be ~the same~ very similar. If the…
Ansible has surprised me way more often than bash has. The latter is upfront about being weird and a little bit insane, Ansible tries to have a better image. In my experience that is true also for Puppet and some other similar tools, which I'd never use without payment, at least until I can afford personal medium iron somewhere and need to provision and handle hundreds of more or less ephemeral virtual machines.
In part because I enjoy having pets rather than herds in my personal projects, but also because when using the shell or POSIX there's very little overhead, like venv and python libs and so on that will inevitably irritate me a few times a year even if I rarely use them directly.
Earlier quoted context omitted.
python is a particularly bad choice for things that are not supposed to break; the python maintainers have adopted a new policy of intentionally breaking new things every release. recent casualties include asyncore, distutils, and imp https://docs.python.org/3/whatsnew/3.12.html#removed there are people who foolishly depend on python for things that need to work. i hope that at some point they band together behind a…
Perhaps don't upgrade your Python willy-nilly? That seems like a sane solution to this problem.
debian's versioning system for packages doesn't really contemplate needing to install old versions of a package because the maintainers are deliberately breaking new versions of it, so in 'bookworm' debian 12.5, the only cpython available to install is python 3.11. so if you want to 'not upgrade python' you are going to have to take on the maintenance burden of the old versions yourself; debian isn't going to help
some other package managers handle this kind of situation better (nix is notably excellent at it) but that doesn't really help with the maintenance burden of keeping up with security fixes
Earlier quoted context omitted.
The bash man page is my bible. It's dense and long but it always has the answers, you just gotta know where to look.
When people mention `bash` it's immediately a code smell. In order to write portable shell scripts, it must be only POSIX `sh`. If the need ever arises for a more complex data structure, typically I jump into AWK since it's also POSIX compliant. Here's a note from the Ubuntu recommendation: https://wiki.ubuntu.com/DashAsBinSh
Earlier quoted context omitted.
Instead of saying: while true You can instead say: while : There is actually a /bin/true, which could involve the fork of a new process for each iteration of the loop. The form that I have shown you is guaranteed not to fork.
Thank you sir!
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
Most of the familiar userland utilities are at that website, accessible as a (somewhat crude) Apache index:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/
Any POSIX-compliant system is required to implement the functionality described there.