someone was asking for a GUI, so not going to be an ffmpeg expert. likely the LLM would recommend ffmpeg anyway. plus you would run YOLO (or maybe CLIP) locally; it has been running on Android phones since 2020 at least. a Jupyter notebook would also give a quick and dirty GUI to visualize and document the solution. plus “motion detection” is probably not the full story, and any video will probably have artifacting that means you’d have to tune the motion detection algorithm or end up with a bunch of garbage artifacts/false positives in the end. also, sounds like the user isn’t looking for something long-running like Frigate. if the user isn’t familiar with Python and wants to do something downstream like sort the outputs or whatever, an LLM would help with that.

sure, programmatically, it’s not a difficult problem, but like it or not it can be solved by someone without an advanced CS degree with an LLM precisely because the problem is easy. no easily ready solution exists, but that doesn’t mean it can’t be done. “just use ffmpeg” to someone like my dad who might have the know how to install Linux but isn’t a programmer isn’t exactly the simple advice it sounds like.

i’d vibe code something in Python for this tbh, but i have some expertise in this area already. you could even get some classification going with a YOLO model to help you narrow down the search. it won’t have a GUI unless you count Jupyter notebooks.

normally it’s for syncing across machines, but it is convenient for setting up new machines. i use chezmoi and Nix and some other tools to keep things in sync

i host my dotfiles on GitHub, but any cloud provider or self-hosted git instance will do. otherwise, rsync, scp, or a good old fashioned thumb drive

this feels like a breaking change akin to macOS changing the Command key to bringing up a start menu because it confuses Windows users. platforms have differences, and this one is actually so tiny and inconsequential it feels like any ameliorated confusion will be offset by confusion of people that rely on it and use it. is this really the barrier to adoption?

other commenters have hinted at this, but the main point of most of the good advice is this: don’t use the system Python install (ie the one from apt) for development. uv is my go to, but the idea behind *conda, pyenv, asdf, etc is the same. the underlying OS shouldn’t be an issue; you should be able to ship the code between OSs and build just fine, ideally.

nice. simple and modular i like. i deal with far too many “one stop shops” at work to bring that home

we use Jenkins + a bespoke wrapper at work. thats left a bad taste in my mouth enough to avoid Jenkins altogether

this is my experience as well. we have a bespoke wrapper around Jenkins, and the more we can test locally the less time we have to spend waiting for the system to fail. it’s one of the reasons i’ve adopted just to script things locally as if it was CI.

heck yeah this is the review i was looking for 💯

you’re right. i just expected it to be an increase 😅

i honestly didn’t look that close, obviously haha

but yeah, i’ve been kinda looking for a reason to de-Microsoft my stuff

good lead. it’s just the one project for now, and to my surprise it’s actually a dependency for the ollama-rs project, so i feel somewhat obligated to keep it stable.

yes, according to this morning’s email

i switched to Linux in 2013ish to get away from my gaming habit and go all in on programming and computer science. that may not work these days as all the games i play work on Linux ha

weird. i’d probably good around for drive checks personally, any test should be pretty definitive. how did you install Discord? the AUR? maybe a reinstall is in order.

i don’t think this is Node specific. if i were writing logs, i’d want to be pretty sure they get written, either by creating the directories necessary, putting them in a place i was pretty dang sure existed, and/or crashing as early as possible if the location didn’t exist, which makes me think it’s a weird Discord config error.

error is right here:

EROFS: read-only file system

this line is concerning:

At random times

this sounds like a drive failure. Discord’s logger can’t write to the filesystem; it’s reporting as read-only.

what’s the drive like where /opt lives?

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

in addition to what others have said, i’d say a lot of civil infrastructure—hospitals, clinics, government facilities, etc—are locked in either because of bad politics or weird vendor lock in. my dad ran his own dental clinic, and he had to run a Windows server because it was required by his software vendor that did everything from appointment reminders, to the web portal, to billing, to showing which of your teeth were missing, to integrating with scanners or other equipment. it was shit software that looked like Windows 3.1 well into the 2020s, but it did the job and 24hr support was reliable. just an anecdote, but as a software engineer i was fascinated by it.

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