init crashed because it couldn’t load a shared library, but init isn’t allowed to be killed so the kernel panicked

• https://github.com/prometheus/node_exporter?tab=readme-ov-file#textfile-collector - which makes node exporter watch a specific directory for files that contain metrics, then re-export them back to the central Prometheus server
• Some systems have their own metrics endpoints - instead of getting Prometheus to scrape these directly I set up a Cron job to curl these into files for node exporter - this means I don’t need extra config in Prometheus to find the endpoints, and don’t need to mess with firewall rules
• Other systems don’t directly expose metrics in a format Prometheus can use - in this case I will write/find a script that can do the conversation, then either set it up to write the metrics file directly and run it on a Cron, or run it as a service and another Cron job to do the scrape

• Base ansible role installs Prometheus node exporter, configured with the text file collector
• VM automations push DNS records so that the Prometheus dns-sd automatically discovers them
• Ansible roles for add Cron jobs that generate metrics for specific systems and dump them for the text file collector
• Grafana for dashboards
• Karma as a UI in front of Prometheus alert manager

Jellyfin has explicitly asked that people find other places to donate to: https://opencollective.com/jellyfin/updates/were-good-seriously

Something like

!“A line with exactly 0 or 1 characters, or a line with a sequence of 1 or 3 or more characters, repeated at least twice”!<

Syntactically valid Perl

• Back up your data now
• Reseat the cables for the drive
• Run a self test on the drive - smartctl -t long - if it doesn’t pass, then the drive is trash. If it does, then it might limp along a bit longer before catastrophically failing

If only we lived in a world so simple as to allow the whims of managers, customers and third parties to be completely definable in UML

Good thing there hasn’t been any remotely exploitable security bugs in any of the mail system components in the 6 years since Debian 7 went EoL

Looks like it’s an x86_64 kernel though? So this is a VM - it’s not running as a paravirtualised system, it’s having to emulate everything from the CPU up?

If a project is hosted on sourceforge then its a pretty good sign that the developer hasn’t progressed their craft since about 2005, which is a pretty big red flag for anything

At the rates I’m paying for 4G data, there are very few places in the world where it wouldn’t be cheaper for me to get on a plane and sneakernet that much data

Don’t disagree with you, but yeah - good luck with that

As long as someone is willing and able to maintain it.

It’s open source. All the work is either done by volunteers or by corporate sponsors. If it’s worth it for you to keep a GPU from the 90s running on modern kernels and you can submit patches to keep up with API changes, then no reason to remove it. The problem isn’t that the hardware is old, it’s that people don’t have the time to do the maintenance

The early twenties intermediate dev on my team was explaining the other week that if you remember a time before smartphones and broadband, you are old

I personally am familiar with 2 organisations with millions of dollars in annual revenue that deploy critical line of business applications like this in 2024

git-annex maybe?

Dealing with this at the moment - in an org that’s been pretty lax at writing anything down about what and why as far as internal software goes, trying (with support from C-suite) to get people to actually write up any amount of detail in their requests is like pulling teeth.

I tend to take that position as well; if it’s not defined, I get to define it. If I ask for feedback or review and get silence, that means you approve.

Definitely interested - is the mainline situation any better than with ARM?

I’ve been bitten before with a device that “supports” a major distribution, but only if you install our custom pre-built image (good luck auditing what we’ve tweaked) and only with our special pre-built kernel that isn’t even an LTS version, and has a bunch of patches applied to support whatever weird peripherals we decided to throw on the board, and will get exactly 0 updates after the initial release.

Raspberry Pi gets around this by being big enough to get buy in from vendors (Ubuntu distributes a special kernel + firmware bundle), but support for all the other smaller knock offs seem shaky at best

I think the conclusion is that as a population of people grows the average behaviour stays pretty much fine, but the extremes of the bell curve become more apparent