generally most modern UIs are moving away from those reactive patterns (React, Svelte, etc) just cuz the composition can be optimized (Kotlin compiler plugin, shadow-DOM, etc), and a lot of people—myself included—find that declarative design easier to reason about. and yeah i guess i outed myself as an Android dev, but i can’t in good conscience recommend the node based Android XML UI lol (although that’s a different SDK).
anyway, not to yuck your yum. i played around with JavaFX back in the day but never made anything to speak of. i’ll have to check out more of your blog!
i mean, how many realistically? how many systems are out there using non-LTS releases that would actually run into these edge cases? and auto-updating them in production without triggering the bug first? or maybe i’m a naive corpo
honestly, i 100% do not miss GUIs that hopefully do what you want them to do or have options grayed out or don’t include all the available options etc etc
i do get burnout, and i suffer many of the same symptoms. but i have a solution that works for me: NixOS
ok it does sound like i gave you more homework, but hear me out:
with NixOS and flakes you have a commit history for your lab services, all centralized in one place.
this can include as much documentation as you want: inline comments, commit messages, living documents in your repository, whatever
even services that only provide a Docker based solution can be encapsulated and run by Nix, including using an alternate runtime like podman or containerd
(this one will hammer me with downvotes but i genuinely do think that:) you can use an LLM agent like GitHub Copilot to get you started, learn the Nix language and ecosystem, and create Nix modules for things that need to be wrapped. i’ve been a software engineer for 15 years; i’ve got nothing to prove when it comes to making a working system. what i want is a working system.
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.
sorry it’s been a minute. i drank the emacs KoolAid because of posts like this years ago and happily switched back to Neovim after they added Lua config support
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.
generally speaking, i think it’s good practice to find several recipes and compare and contrast them. you’ll find opinions and get a sense for what the writer’s priorities are (quick, fewer dishes, what they usually have in the pantry, etc) and can figure out which writer has similar priorities to you. or just synthesize a recipe from those sources. this does require some technical know-how, but i think this is a good skill to have.
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.
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.
yeah i get that.
generally most modern UIs are moving away from those reactive patterns (React, Svelte, etc) just cuz the composition can be optimized (Kotlin compiler plugin, shadow-DOM, etc), and a lot of people—myself included—find that declarative design easier to reason about. and yeah i guess i outed myself as an Android dev, but i can’t in good conscience recommend the node based Android XML UI lol (although that’s a different SDK).
anyway, not to yuck your yum. i played around with JavaFX back in the day but never made anything to speak of. i’ll have to check out more of your blog!