> I've noticed with untyped code that at some point HOFs start becoming hard to write because the layers of abstraction get confusing […]
I have the same with Nix (from NixOS).
It’s a really nice idea to have a functional language that compiles to a working linux installation, but those abstract functions can get really complicated, especially when I return to something I wrote six months ago.
Yes, very. ML and LLM has its specific uses, but every company is slapping “AI” onto everything and it’s so stupid. Have you heard about the AI rice cooker…?[1]
You might enjoy the talk Adam Conover had with Ed Zitron[2]; I found it quite cathartic.
Exactly! If you only look at the commute, you get ridiculous things like commuter trains, that only run in the morning in one direction and in the afternoon in the other.
In the Netherlands for example, lots of people go by car to Work, because that’s relatively far away; but then they’ll use their bike or transport for everything else. Stuff like groceries, dentist visits, meeting friends, going to the gym, etc. because all those things are within (their district of) the city.
I use colmena[1] to manage one nixos configuration for multiple machines:
- laptop
- desktop
- server
- rpi nas
I also wipe my entire rootfs every boot with a zfs snapshot rollback[2] using the impermanence module[3] to keep specific stateful data one one of two datasets with regular snapshots: one is backed up with zfs send, the other is just for cache between reboots.
It took a little puzzling to get started, because I didn’t know about the impermanence module at first, so I built my own hacky solution. But I really love this setup. And the way I don’t have cruft to clean.
Not OP, but I can highly recommend just using the programming language you already use to make key-value map to and then converting that to JSON. That way you only have 1 syntax to worry about. In my case that’s Python (using dictionaries and json.dumps)
You could also try for a templating framework (like jinja2) but then you have 3 syntaxes colliding: the programming language you call the templating engine with (e.g. Python for jinja2) the templating language itself (e.g. jinja2) and then JSON as well.
Do you have any references about what they got wrong and what the more traditional stories are?
I expected they took some liberties for storytelling purposes, but if it’s as egregious as you make it out to be, I’d love to hear the common versions of the stories.
> Requires=network.target tells systemd not to start this mastodon.target if the network.target hasn’t been reached successfully.
That’s not true, Wants=/Requires= do not specify any order between units, only that without them the unit cannot be marked as succesful. This way they can still be started in parallel.
If you really want it to happen after network is up, you should add a dependency of After= under the Requires=.
Also network-online.target might be a better choice but YMMV.
I haven't heard of RQ before, but on first glance they look pretty similar.
The main difference I see is that meesee workers are always setup as python programs, whereas RQ workers are separate programs. (calling a `rq` program insead of `python3 my_worker.py`)
Though looking at the docs tells me that RQ can do the latter as well.
Personally I prefer meesee[1], because setting up Celery or other big worker systems is always a lot of work, and they have more components than I usually need.
Meesee is an elegantly simple worker system (written in python) using redis as a backend, and it works really well if you don't need all those extra features that stuff like Celery give you.
You just need a redis instance and then you're good to go :)
I have the same with Nix (from NixOS).
It’s a really nice idea to have a functional language that compiles to a working linux installation, but those abstract functions can get really complicated, especially when I return to something I wrote six months ago.
It makes me really miss Rust’s type system…