Notices by Lars Wirzenius (liw@mastodon.acc.sunet.se), page 4

Reading online discussions about the GDPR, it strikes me that people in the US are very much afraid of their govenment and of bad actors using the legal system as a weapon in ways never intended by legislators. Probably with good cause: it's a fact of life, over there.

It feels strange to me, as someone who grew up in a Nordic socialist culture, where the government wasn't an enemy and fellow citizens are mostly not hostile.

It's like looking at Mad Max from Love Actually.

@cwebber who doesn't?

Had a shit day. Trouble sleeping. It's 1:30 and I've given up trying to fall asleep, for the time being.

@ColinTheMathmo I saw it on the federated timeline, which I occasionally glance at.

@ColinTheMathmo GNU coreutils tail does that for me. In one window:

for i in $(seq 1000); do echo $i>> output; sleep 1; done

In another:

tail -f output

I get a new line from tail every second.

http://ick.liw.fi/architecture/

I've updated the #ick architecture document. Any feedback would be welcome. Is something unclear? Missing?

@Greg Do you mean how many jobs can be concurrently? So if one were to have access to, say, a 5000 node supercomputer, can the CI system keep each node busy? That kind of thing?

@Greg Can you expand on that?

@ted I'm inclined to want to know how long a no-op job takes, from when it's triggered until it's finished. No-op = user-specified build command is "true".

Plus I'm curious about how many such projects my CI can build per unit of time, given a set of hardware.

Maybe I'm thinking this too implementor-centric?

The question is, what would be good benchmarks for a CI system? Number of workers that can build some toy project concurrently? Each worker would be building a separate "project", even if the source would be the same. The toy project would be something like hello.c.

Does that make sense?

What does performance even mean for a CI system?

@ted That's an excellent benchmark basline. It took me hours write because the Anrdoid app was clumsy. (The app, not me. Never me. I am never clumsy. When I stumble and fall, I meant to do that.)

Every time I neglecg to set up benchmarks for my programs early on I end up regretting it and having bad performance.

While premature optimisation may be the root of all evil, there's no such things as premature benchmarking.