Tootfinder

I'm building webkit-gtk right now. It's one of these messy packages where a few source files need a lot of memory to compile, and ninja can randomly order jobs so that all of them suddenly start compiling simultaneously. So to keep things going smoothly without OOM-ing, I've been dynamically adjusting the available job count via steve the #jobserver.
While doing that, I've noticed that ninja isn't taking new jobs immediately after I increased the job count. So I've started debugging steve, and couldn't find out anything wrong with it. Finally, I've looked into ninja and realized how lazy their code is.
So, there are two main approaches to acquiring job tokens. Either you do blocking reads, and therefore wait for a token to become available, or you use polling to get noticed when it becomes available. Ninja instead does non-blocking reads, and if there are no more tokens available… it waits till one of its own jobs finish.
This roughly means that as other processes release tokens, ninja won't take them until one of its own jobs finish. And if ninja didn't manage to acquire any job tokens to begin with, it is just running a single process via implicit slot, and that process finishing provides it with the only chance to acquire additional tokens. So realistically speaking, as long as there are other build jobs running in parallel, ninja is going to need to be incredibly lucky to ever get a job token, since all other processes will grab the available tokens immediately.
This isn't something that steve can fix.
#Gentoo #NinjaBuild

#Steady
Unterschätzen #Arbeitnehmer die Auswirkungen von KI auf den eigenen #Job?
Wie realistisch schätzt man eigentlich die eigenen

Unterschätzen Arbeitnehmer die Auswirkungen von KI auf den eigenen Job?
Neue Forsa-Zahlen zeigen: 72 % halten ihren Job für KI-sicher. Doch Verdrängung kann einen teuer zu stehen kommen.

Worked on some more #Gentoo global #jobserver goodies today.
Firstly, Portage jobserver support patch: #PyTest jobs will also be counted towards total job count.
Again, it's not a perfect solution, but it works reasonably. The plugin still starts -n jobs as specified by the arguments, but it acquired job tokens prior to executing every test, therefore delaying actual testing until tokens are available. It doesn't seem to cause noticeable overhead either.

Had to turn my LinkedIn job notifications off. I’ve been practically hyperventilating at the wall of job noise I’m met with every time I open my email.
#redundant #redundancy #job

A great opportunity is now open for a Tech Team Manager in the Discovery and Delivery Program at the California Digital Library where I work! This is a great group of folks doing innovative work in core library areas. #jobs #libraries

i always knew it, but for everyone else looking for a #job in #support:
basic requirements are limited eyesight 👀

Nach meinem Urlaub werde ich alle E-Mails im Posteingang löschen.
Wenn es wichtig war, wird sich derjenige schon melden
#SoAltBinIchJetzt #job

I love it when a flan comes together. #AI #JobHunting2025
https://www.fastcompa…

Sweet revenge! How a job candidate used a flan recipe to expose an AI recruiter
It's only one example of people trying to trick AI, which is being used more and more in hiring.

Heute ist ein Tag, der mich beruflich etwas frustriert zurücklässt:
Als ich damals anfing, war das ein begeisterter kleiner Haufen, der zusammen hielt und der alle Probleme unbürokratisch und schnell löste. Genau das fand ich immer super.
Und jetzt ist der Laden nur wenig größer, aber ein Paradebeispiel für Passierschein A 38
#job

Mit #KI im #Job geht die Zeit auch viel schneller vorbei, weil man immer jemand zum diskutieren hat.

#Gentoo #jobserver revealed another problem with steve in particular, and (I believe) the jobserver protocol in general: blocking clients are prioritized over polling clients.
The problem is simple: when handling blocking reads, steve can issue a job token immediately. When handling a poll, it merely indicates that a token is available, and the client must issue another read request to get it. So if tokens are scarce and there are both blocking and polling clients running, the former are likely to be taking all the incoming tokens.
My idea of working around this is to implement temporary reservations. If a client polls for a token, we reserve one for it. The reserved token can afterwards be only read by the same client. This way, both blocking and polling clients get a token — the former get it immediately, the latter get it reserved for them. And if there are no tokens available, both get into a single FIFO queue, for a poor man's round-robin (steve also throttles all reads to one token at a time).
However, polls technically don't guarantee that the client will eventually read the token, so we need to handle reservation expirations as well.

#Steve the #Jobserver has undergone a major rewrite over the last week. It's now implemented using CUSE, the #FUSE API for character devices. It is using pidfd to track processes acquiring job tokens, and automatically reclaims them if processes die without returning them, preventing dead processes from effectively locking the system jobserver.
The code's still a bit ugly — it's a C-changed-midway-to-C , with libevent for event loops and (still) FUSE's ugly argument parsing.
If someone wants to play with it, the live ebuild is available in #Gentoo as dev-build/steve.
https://gitweb.gentoo.org/proj/steve.git/