my OS install process probably shouldn't be "write a shell script to do every step and each time it fails simply rewrite, blow away the drive and do it again instead of undoing any steps
but man its so much simpler
reality is the battlefield
- she/they (pl)
- breadthcharge.net/
the first line goes in Cohost embeds
🐥 I am not embroiled in any legal battle
🐦 other than battles that are legal 🎮
I speak to the universe and it speaks back, in it's own way.
mastodon
email: contact at breadthcharge dot net
I live on the northeast coast of the US.
'non-functional programmer'. 'far left'.
conceptual midwife.
https://cohost.org/NireBryce/post/4929459-here-s-my-five-minut
If you can see the "show contact info" dropdown below, I follow you. If you want me to, ask and I'll think about it.
You must log in to comment.
in reply to @NireBryce's post:
i like the promise of a system that allows you to describe the end state and let it figure out how to get there from whatever the current state is, but in practice they always seem cumbersome and flakey 🫠
nixos isn't very flaky anymore, outside of having a feature called "flakes".
but it doesn't figure out how to get there, it just re-configures the entire itself from the ground up to match the config files you made.
i tried Nix (package manager) a few months ago and had a really bad experience, but i was also thinking of like Terraform
in screen drawing libraries (text, graphical, animation, but i hit it from the TUI/ANSI angle) there is the concept of differential drawing (i forget the proper term, it is not double/triple buffering but it is related to it) where you take the buffer of what is displayed in the current frame and the buffer that contains what you want to display next and diff them, then you can minimize the number of drawing calls to get to the next state
it seems like this should be possible for any other data structure (including a file system) but i recognize that it is just a hard thing to do well
which is why a lot of TUI apps just always do full redraws, and you do not have to worry that the external state has changed from your buffer cache of it
so i get why Nix does it too!
nix the package manager's uses are kinda obfuscated by the fact that the state of the art for two years has been languishing as as "experimental feature" the manual doesn't mention, and the manual recommending you imperatively install things. nix the package manager and nix the language being named the same also makes it more confusing than it needs to be.
the closer thing to nixOS would be to use home-manager (or the fleek frontend if you aren't managing that many applications) to manage your user's installed software, dotfiles, shells, etc.
(nix can also make dev environments through the same mechanism}
nixOS is like being able to describe your entire system in what's basically a JSON (with comments) file if you squint hard enough, but, of course, with that power comes needing to know how to describe those things.
but basically it means that instead of accumulating my fixes in random places in my system, I can just have my entire system in my dotfiles repo, including anything like additions to etc/hosts, fstab, /proc/acpi/wakeup, etc
and can keep all common programs, dotfiles, fixes, theming, etc consistent across machines at the expense of a long build the first time, and then a series of short builds as things change, not usually requiring reboots after the first. though i use home manager for user stuff so I can have shorter build times instead of building the entire system
nix's documentation failure is a deal breaker, it triggers some kind of overly vigorous response from me, when the situation improves i will try it out again
i have kept my configurations in a git repo since 2010 with its own install scripts, so setting up a new computer is just a git clone and a ./install to have it running in seconds - it is huge for me, so i am always on the lookout for something that can do that job better
i also have a little tool which i have been developing which handles that work in a generic case and can do it with zero prep on the remote except ssh access, and i would be happy to replace it if there was something similarly small that required little to no setup on the local and remote sides
so i hope that nix and friends continue to develop!
if that's your workflow you can probably switch pretty easily, the secret is to, instead of reading the manual, use github code search to harvest from configs like you're trying to extremely customize a .zshrc or .vimrc, and pretend the unhelpful error messages are c error messages (ie: the problem is probably on the line above the one indicated).
you only really need to know the types of data structures ({} is overloaded and is either brackets or a key:value, [ ] is a list but sometimes the separators are weird, double single quotes is a multi line string except if it's ''$, which confusingly is the escape for $ so it does shell substitution instead of nix substitution) , and learnXinYminutes has a pretty good summary there.
and the source code of the modules is, not documented but... half way to self documenting, "mkOption" declares config options, which come with descriptions and what data structure they expect etc. you can also search options from the nixpkgs package search website, its a different tab.
anyway nix sucks until it doesn't, but then it really doesn't, and the major pitfall is all the docs focus on it being language and complicated config stuff, but in the end so much of it is just like, installing too many vim plugins in terms of workflow, not writing your own modules. (and once you're using it for sysadmin stuff, writing modules comes easier because you can finally understand the manual, having all the context it doesn't give you)