321 karma · joined August 27, 2017
if grep "logging = syslog" /etc/stupid-service/stupid-service.conf >/dev/null; then
printf "[Unit]\nAfter=rsyslogd.service\n" > "$1/stupid-service.d/10-syslog-dep.conf";
fi;
> It's pretty basic and straightforwardPostgres config supports line continuations, so the OpenRC service file you quoted is buggy; it could potentially match a file just because some other option contained a multi-line value that had the string "log_destination = syslog" in it.
The whole philosophy of systemd is to move away from these kinds of "simple" and "mostly working" pile-of-shell-script systems to actually-unconditionally-correct configuration that doesn't come with bonus text processing surprises.
But of course in this particular case, because systemd makes the /dev/log journal/syslog socket a dependency of every unit by default, there is no need to encode this dependency at all.
Anyway if you really wanted to you could write this script as a generator and have it put a drop-in in /run/systemd/system/postgres.service.d. But… why?
Depending on what you want to do, a generator might be appropriate:
> Their main purpose is to convert configuration and execution context parameters that are not native to the service manager into dynamically generated unit files, symlinks or unit file drop-ins
TIL
If you call anything that comes out of a model “slop” the term uses all meaning.
> Look at his CV. Tiny (but impactful) features ///building on existing infrastructure which has already provably scaled to millions and likely has never seen beneath what is a rest api and a react front end///
Off the top of my head he wrote the socket monitoring infrastructure for Zendesk’s unicorn workers, for example.
Your ideas about how psychiatry is practiced might have been correct in the 1950’s but they’re a world away from how it’s done in the 2020s.
Uh, can’t imagine too many people reading this are playing Origin-era EA games on a Pentium 4
I do want to pick on this specifically - people can and should be patching open source projects they depend on and deploying them to production (exactly as described in the article). Something being in the language vs in “user” code should be no barrier to improving it.
Also you can use nsenter(8) to run a command (or even a shell) under another process’s mount, pid, network, etc namespace.
When the stub is hit the code that gets generated is somewhere _else_ in executable memory, not contiguous with the original bit of the method. Because these "lazy basic blocks" are actually quite small, the bookkeeping involved in "where is the code for this ruby method" would actually be an appreciable fraction of the code size itself. Plus you then have to do more bookkeeping to make sure the method you want to GC isn't referred to by the generated code in another method.
Since low memory usage is an important YJIT goal, I guess this tradeoff isn't worth it.
Maybe someone who knows this better will come along and correct me :)
Still just a tidy 1072 lines in that folder though.
I spent 5 minutes staring at your file trying to understand how on earth it does the things in the man page, but of course it doesn’t.
This is like Ruby's Ractors and I haven't really seen that be super successful so far. The "Objects" that need to be shared are things like class definitions, etc.... there are a ton of subtle issues with objects that are being marked as sharable when they should really not be or vice versa.
It _could_, but the kernel folks have made it pretty clear they don’t want to put any code related to dwarf in the kernel.
Of course that F comes with a substantial maintenance cost. I’ve moved onto other projects internally at work and still every month or two I’ll get roped in to deal with some confluent-kafka-go releng issue or some such.
Tried giving them money too but confluent were pretty explicit with us that go was a low priority client library for them. I guess I’m not really saying anything other than I agree with everyone else in this thread, there’s no magic answer, only tradeoffs.
I _get_ that I don’t have any right to free maintenance, but the stale bot paints some veneer of process around a maintainer thinking “issue looks hard, doesn’t affect me, so I don’t care”. I would just so much prefer them to be honest and just say that rather than passive-aggressively send me emails every 30 days warning that my issue is becoming stale or whatever.
Nice to see the fixes make it into a release!