xerxes901

I plugged my iPhone 16 into my usb-C docking station the other day to charge it and was pretty surprised to discover it just started mirroring my phone screen. Keyboard worked too!

Put a script in /etc/systemd/system-generators/ that does something like

  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;

Postgres 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.

Yeah parsing config files with regular expressions that may or may not properly handle quoting or line continuations etc is… not a great idea in my opinion.

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?

As a trivial example, you can dynamically depend on other services depending on system configuration (as PostgreSQL does)

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

Something like the stm32mp2 series of MCUs can run Linux and act as a PCIe endpoint you can control from a kernel module on the MCU. So you can program an arbitrary PCIe device that way (although it won’t be setting any speed records, and I think the PHY might be limited to PCIe 1x)

Was expecting some real unproductive and entitled whining based on the title, but was pleasantly surprised - someone actually investigating and debugging their wayland issues rather than putting their head in the sand and screaming “X11 FOREVER!!!”

Hm. I found this (that memory must be stable wherever a SEH exception could be thrown) surprising, because I thought the unwind information generated by the compiler should be able to reconstruct all the correct variable values during stack unwinding.

TIL

I have no idea whether the text was generated from an LLM, but “slop” it absolutely is not - it’s clearly a very logically ordered walkthrough about a very thorough debugging process.

If you call anything that comes out of a model “slop” the term uses all meaning.

That’s exactly what it was. He discovered the customer was using a version of ffi that had this “use-after-free” (ish) bug, but the question “is this actually what my customer was seeing or is there _another_ bug lurking” still needed to be answered.

I personally know and have (tangentially) worked with the guy and none of what you’ve said is true.

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.

Thanks for clarifying, and implementing this essential feature!

Question: what actually reads /etc/pooper to configure the character? I can’t work out how that file’s contents ends up as module parameters and I’d love to know!

I don’t know what you’re basing this on. Good psychiatrists absolutely “call themselves doctors” and definitely seek to exclude or treat organic causes of psychiatric symptoms. All the psychiatrists I know absolutely understand there’s a link between the immune system and mood disorders and will involve immunology/rheumatology for these things.

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.

In order to proceed, you’ll need a PC with a 64-bit CPU — and that might mean you have to buy a new PC if you don’t want to lose your EA games.

Uh, can’t imagine too many people reading this are playing Origin-era EA games on a Pentium 4

Which means your changes have to go through the Ruby team first. Any additional changes would also need to go through them …

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.

/proc/PID/root is a view of that process’s mount namespace.

Also you can use nsenter(8) to run a command (or even a shell) under another process’s mount, pid, network, etc namespace.

This is in fact exactly what Ruby’s Fibers and the async fiber-scheduler gem do

I don't work on YJIT but I _think_ i know the (or maybe an) answer to this. The code for a JIT'd ruby method isn't contiguous in one location in memory. When a ruby method is first compiled, a straightline path through the method is emitted , and branches are emitted as stub code. When the stub is hit, the incremental compilation of that branch then happens. I believe this is called "lazy basic block versioning".

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 :)

This doesn’t really change your conclusion, but I think that’s the wrong file. This is the real doas afaict: https://github.com/openbsd/src/blob/master/usr.bin/doas/doas...

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 essentially what systemd-resolved with the nss-resolve NSS module is right? It’s possible to use /etc/nsswitch.conf to entirely disable the built-in DNS resolution in glibc if you want.

a per-thread GIL with an explicit mode to share particular objects

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.

I winced when I saw the phrase "multithreaded fork" but then I realised this is the _other_ kind of fork, not the fork(2) syscall.

The problem is that with perf the stack trace is collected by the kernel (when the interrupt from the performance counters fires), and the kernel doesn’t implement dwarf unwinding of user space code.

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.

Hope these people never send any emails, I hear they can be searched for a long time too.

In the specific case of confluent-kafka-go I’ve had to make extensive use of the second F. Trying to get the major improvements I’ve made into upstream has been… challenging.

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 think this is something git rerere is supposed to help with

Nothing infuriates me more than googling for a problem I’m having and finding a relevant issue that’s been closed by a bot as “stale”.

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.

Sorry I missed this message - I think the best write up of it is from the issue thread: https://github.com/docker/roadmap/issues/7#issuecomment-1044...

Oh hey, I’m the Konstantinos mentioned at the end. The excellent work done by the Asahi Linux folk on discovering demonstrating the incredislow MacBook nvme flush is what prompted me to dig into this for Docker.

Nice to see the fixes make it into a release!

Heh, yeah this doesn't look like it makes a lot of sense... I'll go shake a few trees internally and point this out.