Naja ... bei mir persönlich ist das Deutschlandticket auch beliebt, obwohl ich vorher schon ein (teureres) Abo meines lokalen Verbunds hatte, was meinen Zwecken genügt hat.
Die durchaus nachvollziehbare Argumentation gegen das Deutschlandticket ist eben, dass 90% der Inhaber schon vorher ÖPNV-Kunden waren, und damit das Ziel, den Individualverkehr zu verringern, auf recht teure Art verfehlt wird.
Ich glaube nur, auch das greift zu kurz. Um das Ziel wirklich zu erreichen, braucht es zwei Komponenten: Ein verbessertes Angebot und einen einheitlichen und für breite Massen erschwinglichen Preis. Man könnte nun diskutieren, ob auch hier Deutschland eine suboptimale Reihenfolge gewählt hat (siehe auch Atomausstieg vs Kohleausstieg), aber das Deutschlandticket wieder abzuschaffen wäre ziemlich sicher kontraproduktiv...
#Electron is the worst threat to human #sanity in the realms of software. I see the same dystopia slowly becoming reality though. 😵
I personally use quite some TUI software (neomutt, irssi, tin, ...), but when it comes to things GUI, the only somewhat regularly used application remaining besides a browser (IOW monstrosity of an application platform) is gimp. 🙈
But hey, When was the last time a "native" application was developed? ... wouldn't my "Xmoji" count here? 😅
A crashing program obviously has undefined behavior, which means it could do anything, including very harmful things. A quite typical outcome would be corrupting its own data. As a responsible operator of services, you'll have a good backup strategy of course, so the impact of such behavior would be limited, but still you should be aware that just restarting something that crashed before you know why and how it crashed is quite risky. You should weigh that risk against the (business?) risk of the particular service being down for a while...
Yes, that's the problem daemon(8) solves. You shouldn't write rc scripts that just fire something that isn't a daemon "into background" indeed. Just wanted to clarify you also shouldn't use daemon(8) on, well, actual daemons.
In my personal opinion, the auto-restart is a misfeature here, it's a completely different concern and belongs into some kind of "service manager/supervisor" instead. And there, it should be used with care, as a temporary workaround for crashes already analyzed, but not fixed yet. Unfortunately, we're trained to just accept broken software more and more (e.g. systemd allows for easy respawning, even whole containers are just respawned), forgetting about the risks attached. 😞
On a side note, this discussion gives me an idea for a blog article: Clearly define the terms "daemon", "service" and "server", so people stop confusing them 😁
Seriously? The purpose of daemon(8) is to run something as a daemon that actually isn't one. And I'd define a daemon as "a program able to fork itself into background while properly detaching from the current session and terminal, and optionally also handling a pidfile". Such programs should never be wrapped into daemon(8).
Now, if snac can't do that by itself, it's fine. But the "automatic restart" feature of daemon(8) is IMHO very questionable, because it's a workaround just hiding a problem that could go worse. Imagine a broken program that, while triggering broken behavior, deletes or corrupts important data. You don't want that to automatically restart, giving it the chance to wreak more havoc.
Ok, I can't immediately spot the issue with the parts of the code seen so far. If I had to debug this, I'd fire some tooling on it (e.g. the compiler's "address sanitizer" and similer, valgrind, ...) first.
But then, this also looks like some code in desperate need of refactoring. "Three stars" should almost always raise an eyebrow: https://wiki.c2.com/?ThreeStarProgrammer ... and the MAX_INPUTS constant looks weird, if it's actually the maximum index, making it one less than the number of inputs 🧐
I'd also suggest to use expressions instead of type names with the sizeof operator, making the code more robust to change, e.g. sizeof(char **) → sizeof *sub[slot].udp_volts in the above line of code, but that's a stylistic thing...
Oh! So, everything fine and I just never noticed this specific behavior before. 😳 That's definitely good to know, thank you! I boost some of my own replies for this reason. Makes sense 😉
Dipl.inform., FreeBSD ports committer, musician, C64 fan/coder, hetero cis white male, not proud, no wing, no ally, leaning liberal/ecologist, pro facts/science