• 1 Post
  • 11 Comments
Joined 3 years ago
cake
Cake day: March 3rd, 2024

help-circle

  • three, maybe four things:

    1. as mentioned: Obsidian. i pay for Sync cuz i like the product and want them to succeed and want reliable offsite backups and conflict resolution. use a ton of links and tags. i’ve been into using DataView to make tables of IoT devices, services, todo items, etc based on tags and other YAML frontmatter.
    2. chezmoi. manages my dotfiles so my machines are consistent. i have scripts that are heavily commented that show how to access MQTT, how to read and parse logs from journald, how to inspect my network, etc. i do think of them as code as documentation, even if they’re also just convenient.
    3. NixOS. this has been my code as config as documentation silver bullet. i use it as a replacement for Docker, k8s, Ansible, etc as it contains definitions for my machines and all the services and configuration they run, including any package dependencies and user configurations. no more statting an assortment of files to figure out the state of the system. it’s in flake.nix
    4. honorable mention to git and whatever git hosting provider is not on your network. track your work over time, and you’ll thank yourself when things go wrong.

    some things are resistant to documentation and have a lot of stateful components (HomeAssitant is my biggest problem child from an infra perspective), but mainly being in that graph mindset of “how would i find a path here if i forgot where this was” helps a lot


  • it’s not stupid. i have pretty successfully done some NixOS work flying basically blind with an LLM guiding the way.

    1. ask follow up questions. “can you show me in the docs where this is defined”, “why did you add this line here”, etc

    2. you’re going to have to understand this config eventually. the LLM will start to get confused if you’re trying to squash a weird bug and you’re just chastising it. it will always tell you you’re right even when you aren’t.

    3. document everything with comments and in git

    4. Caddy is better :P



  • ok i’m not saying do this

    i recently setup an API proxy, C&C server, Grafana and Prometheus, and Discord bot. now i can send pings via Grafana or with a simple request (provided it’s authed via VPN or proxy) and have my Discord bot use a local LLM on my network to deliver the alert to a Discord channel in the voice of Ultron.






  • i worked in Android development for years. i used Kotlin and Jetpack Compose in alpha. their docs weren’t perfect but they existed. in my experience good documentation evolves with the project and isn’t tacked on as an afterthought.

    otherwise i get you point and really don’t know enough about the drama to pick a side. i just want my software to work 🤷‍♂️

    ETA: honestly documentation as a first class primitive in Nix is a selling point. if only that consistency could be applied to high level docs


  • chrash0@lemmy.worldtoNix / NixOS@programming.dev•*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    21
    arrow-down
    1
    ·
    2 years ago

    The Nix project has long intended to release version 3.0 when flakes 4 are stable. With Determinate Nix 3.0, we’ve fulfilled that promise

    i noticed this language recently as well. i’m glad Nix upstream is defending themselves, but honestly, the place where Nix “3rd party” tooling shines is in documentation. i swear to god the #1 things holding back Nix adoption is piss poor documentation. and i love the idea of Nix to be clear, but if the official docs are years out of date for installing popular user space software like CUDA and the Rust toolchain, for which the docs are either far out of date or using solutions that are not standard or otherwise clunky, then it’s silly to recommend for my work. and also to be clear, i could pull string and make this happen at my company—we’ve done it for Rust—, but i will not stick my neck out for this kind of tribalism.

    on one hand tho, Determinate Systems provided clear install instructions for flakes (which is an important feature, for a lot of maintainers for sure) and did make it clear what the differences were (some of which were clearly better defaults), even if the verbiage is a bit aggressive. i honestly don’t know what it will take. i’m slowly but surely becoming competent in the ecosystem, but i get the vibe from forum posts (which i’m forced to read in lieu of docs) that there’s this “why don’t you already get this” from the already established community. and maintainers act like there’s no reason for these “soft forks” to exist. Nix is not straightforward, and, no, the language isn’t simple enough to learn in an hour. adoption requires good docs