Alt account of @Badabinski

Just a sweaty nerd interested in software, home automation, emotional issues, and polite discourse about all of the above.

  • 0 Posts
  • 42 Comments
Joined 2 years ago
cake
Cake day: June 9th, 2024

help-circle



  • You may have a bit of a hard time finding something that’s completely FLOSS that’s not on the older side (the sar visualizer being a Java desktop application being a consequence of that age). There are various ways to dump resource usage into a time series database like Prometheus (Apache2), InfluxDB (Apache2/MIT), or VictoriaMetrics (Apache2) and then visualize it with a frontend (Grafana, APGL). The database is going to be the tricky part. All of the time series DBs I’m aware of are permissively licensed. Grafana may be a good fit for you, however. It’s written in Go so it’s relatively light, although it obviously requires a browser to interact with.



  • Was this done according to proper clean-room design principles? If so, then imo the GPL is still working as intended. The company had to spend a fuckton of money and time getting one engineer to read the source and describe what was done to other engineers, and then ensure that one engineer never ever worked on the project again.

    If they didn’t do that then they violated the GPL and someone should report them to the SFLC.








  • Badabinski@kbin.earthtoLinux@lemmy.ml*Permanently Deleted*
    link
    fedilink
    arrow-up
    12
    arrow-down
    1
    ·
    4 months ago

    I wrote and maintained a lot of sysvinit scripts and I fucking hated them. I wrote Upstart scripts and I fucking hated them. I wrote OpenRC scripts and I fucking hated them. Any init system that relies on one of the worst languages in common use nowadays can fuck right off. Systemd units are well documented, consistent, and reliable.

    From my 30 seconds of looking, I actually like nitro a bit more than OpenRC or Upstart. It does seem like it’d struggle with daemons the way sysvinit scripts used to. Like, you have to write a process supervisor to track when your daemonized process dies so that it can then die and tell nitro (which is, ofc, a process supervisor), and it looks like the logging might be trickier in that case too. I fucking hate services that background themselves, but they do exist and systemd does a great job at handling those. It also doesn’t do any form of dependency management AFAICT, which is a more serious flaw.

    Nitro seems like a good option for some use cases (although I cannot conceive why you’d want to run a service manager in a container when docker and k8s have robust service management built into them), but it’s never touching the disk on any of the tens of thousands of boxes I help administrate. systemd is just too good.