• 1 Post
  • 203 Comments
Joined 6 months ago
cake
Cake day: May 2nd, 2026

help-circle






  • I have a git repo with all my docker files, config, notes, etc. I have a main overview file covering the overall system and then a directory for each machine. I edit things on my local machine, then scp and ssh to the various remotes. Once I’m happy with my changes, I commit and push to my Forgejo install on my NAS in case my main computer fails. Secrets, passwords, and keys are in my Vaultwarden.

    I don’t use AI for it, but a local model could probably give me the commands to do whatever I wanted based on the repo.






  • Like all projects, you should think about needs, budget, and time. You’ve got a good list of what you want to run which is a good start. Budget is next, particularly considering the price of hardware these days.

    FWIW, I run Jellyfin, Navidrome, the entire arr stack, Forgejo, Paperless, mealio, and Immich on a NAS with 24GB RAM and have never needed more. 8GB would have been a bit tight but probably doable. 16 will be plenty for you.


  • From TFA, emphasis mine:

    What veans is for#

    Coding agents keep their own to-do lists. Claude Code has TodoWrite, other tools have their own scratch files, and either way that list lives inside a single session and disappears when the session ends. You can’t see it while the agent is working, your teammates can’t see it at all, and nothing survives to the next session.

    veans replaces that ephemeral list with real tasks in a Vikunja project. The agent claims a task before it starts, moves it along as it works, and leaves it in review when it’s done. The result is that the agent’s work is visible in the same place you already track everything else: you can watch a task move across the board in real time, comment on it, reprioritize it, or pick up where the agent left off. When the session ends, the trail is still there.

    veans itself is built for machines, not people . Everything prints JSON, so it’s made to be consumed by an agent or a script. The human side of the workflow happens in Vikunja.

    What Taskwarrior lets you do is something like this for people:

    task add priority:high due:thursday depends:32 something I need to do  
    task ready   # shows all of my tasks that aren't waiting on something or depending on something  
    task project:home-repairs export > home-repairs.json # export my entire home repair project to a json file to process into a gantt chart, budget (since I can add a price tag to each task) and whatever else  
    

    but then I can also have a script that looks like:

    # taskfile.sh  
    infile="$1"  
    proj ="$2"  
    
    while IFS= read -r line; do  
        [ -z "$line" ] && continue  
        [[ "$line" =~ ^[[:space:]]*# ]] && continue  
        echo "Adding task: $line"  
        if [ -n "$proj" ]; then  
            task add "$line" "$proj"  
        else  
            task add "$line"  
        fi  
    done < "$input_file"  
    

    which lets me have preset task lists for various things, like:

    taskfile.sh ~/tasks/packing-list.txt proj:work-trip  
    taskfile.sh ~/tasks/xmas-list.txt proj:xmas-presents  
    

  • Thats an administration cli, not a daily use cli.

    And, I mean things like being able to take tasks, pipe them through whatever tooling you like, pipe them back in, sync them from any other task system, etc. TaskWarrior has a fully customizable priority and urgency system, tagging, dependency management, and status system. I also like that TaskWarrior is usable completely offline and then can be resynced whenever you feel like it.

    Vikunja is great and probably the right choice for most people. But if you do significant project planning for yourself AND want to be able to deal with you todo list programmatically, the only other thing close is orgmode.





  • Oh it’s gotten so weird and depressing for me too. Like a lot of people I played with the free demo of GH Copilot when it came out in 2021. I was… not impressed for the most part. Its python suggestions were usually not any better than the standard Python analyzers, though every once in a while it would pop up a surprisingly decent function. Its C and C++ were either hilariously terrible or more likely just non-existent unless I was writing a textbook algorithm for some reason. Then it might be okish, maybe.

    That fall, the company I was working for laid off my entire department, so I spent a few months looking for a job and ended up in management for a few years. The only code I wrote was a few hundred lines of Python to help me manage Jira tickets and I didn’t bother setting up Copilot. I’m not sure if the company was paying for it. A couple engineers mentioned that they used it to do a couple of refactors, but nothing much seemed to happen with it.

    Then, right about a year ago I changed jobs to go back to IC engineering at a company that had a strict no-AI code policy. In February I had a crazy work trip where I had three days to bring up some hardware that I had never touched before and script a demo for it. I pulled it off, after a couple of 3AM coding sessions in my hotel room. The C parts were straightforward, but the demo script was a damn mess of some of the worst Python I had written in a long time, due to the time pressure and the fact that I was writing it at 3AM.

    Oh, but also in February the company softened its stance and was allowing AI coding assistance in some very limited ways as long as it fit into whatever our GH budget was. I knew that I would probably never touch the Python again as the real version was in process by someone else in Rust, but just in case I wanted it cleaned up. I figured it would take me a day or so after a good nights sleep to do it the right way. In the airport I asked copilot CLI to refactor my script, as a test, not expecting much.

    Five minutes later it had refactored it into something much cleaner, properly using properties, and other such niceties. It wasn’t perfect, there was a sign error in one equation, and there was still some minor cleanup to do but damn. It was good enough that if I was the reviewer I would have thought it was a good first pass and only had a few nits.

    Since then we’ve all been given a decent LLM budget and told to use it as much as we want. I’m not being told I have to use it, but almost everyone is except for a few of us grey beards. And reviewing the code is terrible, because there is too much of it and it doesn’t matter, I’m not actually teaching or working with anyone, just talking to someone who is talking to an LLM.

    Due to some health issues that intermittently leaves me with too much brain-fog to really write code but clear enough to talk about my general knowledge and explain what I want to do, I’m tempted to use them to keep up. And when I do it’s so disheartening. They have the judgement of a very junior engineer, but with perfect syntax in every language and documentation level knowledge of almost every subject. But they’re just so damn fast at it. Previously, if I gave the kinds of instructions to a junior engineer, I’d expect to hear back from them in a day or three, with a passable first attempt and some interesting ideas to talk about. Now I hear back in five minutes with too much code and no reason to talk with them other than to give a few instructions to clean it up.


  • Eh, there are distros where you will never need to touch a command line if you don’t want to. In fact, most modern mainstream ones are that way: Mint, Fedora, Ubuntu, etc.

    Though I don’t understand the fear of the command line. My grandmother owned two computers in her life and both of them were command line only. She was not a researcher at a university, a professional programmer or anything like that, just a normal person with a high school education.

    She just wasn’t afraid to read the manual and try things. I still remember the spiral-bound manual with post-its covered in her nurses shorthand.

    She used them to run the books for the family business, first an Apple ][, then a PC running DOS. She also used them to write letters and the church newsletter, practice Bridge, organize her family genealogy work, and things like that.