@awb I can't think of a POSIX utility for this. I wouldn't be surprised if the omission was deliberate; is there anything in POSIX that requires there to be more than one user? (Who has some arbitrary but constant UID.)
That would be a perverse Unix, but the folklore I heard was that POSIX was deliberately designed so that non-Unixes could conform, for US government contracting reasons. (And I believe some non-Unixes once were POSIX certified.)
I expected to have a bike stolen sometime,but it would have been nice if it wasn’t through my own stupidity and absentmindness. Now I need a new commuter bike and a bunch of stuff with it.
I am swearing at myself a lot. I probably will be for some time.
(It is the small stuff I lost with it that pains me most. A bike GOS unit mount, nice cases for tools. bike light mounts for lights that I think are out of production…)
@binford2k@GeePawHill My techblog uses a CGI that runs a giant Python program (with some efficiency hacks some of the time), on a shared VM that has a total of 4 GB of RAM and a not that modern CPU. It has repeatedly made the front page of that orange site and a few other places, and basically no one has noticed.
It isn't the machines that are slow, it's the software. (And my other rant is "you don't need static HTML to stand up to loads", although static HTML makes it much, much easier.)
Bicycle jargon has played us for absolute fools. "Don't forget to clip out of your clipless pedals or you'll fall over", this is a real thing cyclists say.
(Not me, I rock platform pedals and whatever footwear I want to use.)
In re comparing fire drills to phishing tests[1], if phishing tests were like fire drills, they would test the *response* to a successful phish. Was the person phished able to rapidly report and mitigate things? Do the organization's phish alarms work and reach people? Etc etc.
Current "phishing tests" are like testing people to see if they accidentally start fires if they're handed (dangerously) flammable materials. That's not a fire drill.
@ireneista@dr2chase@dave_andersen When I started noticing that Gatorade was tasting good even when I didn't feel really thirsty, I decided that my rule of thumb was that anything being sold in supermarkets wasn't really being sold to serious athletes. There just aren't that many of them.
(I'm not sure I ever had Gatorade classic, but ~15 years or so ago I may have had something that was only part way to the modern supermarket formulation.)
Pretty much every time I change the time of an alarm on my phone I am irritated all over again at the fundamental laziness and robotic computer-ness of time controls. What I want to do is move the time forward or backward, not to separately change (or set) the hours and the minutes. But separate 'hour' and 'minutes' spinners or options are the easy computer way out so that's how UIs implement it.
Dear self, just because you have finished listening (once) to all of the new music you picked up last BC Friday is no reason to go pick up more. Among other things, you still have ~400 or so releases not listened to from two 'buy our 250-release catalog for cheap' offers in the past. So at least listen to some more of them before giving in to temptation. (Yes I have a 'to purchase' list.)
(Normally I would hold off for the next BC Friday but that's not going to be for months.)
It's surprisingly difficult to bicycle at 10 km/h and no more, at least on my bike with standard 700c wheels. It generally feels like if I sneeze I'll go clearly over and it's easy to drift into too fast.
(Toronto's Mt. Pleasant cemetery has an official bike speed limit of 10 km/h. One of my personal perverse acts is that when I go through it riding by myself, as I did today, I try to stick to this speed limit. It's absurdly hard to go that slow but oddly fun.)
It has been '0' days since I wrote 'Oath' when I meant to write 'OAuth'. Such a tempting not exactly a typo, more a mind slip.
(Also, don't ask me to describe the differences between OIDC and OAuth2, and I suspect that all sorts of documentation blurs the two and talks about 'OAuth2' when it really means 'OIDC'. For example, I'm not sure Grafana would be happy with a pure OAuth2 provider that didn't add the extra OIDC stuff, although maybe it would be.)
My first cloud VM isn't even in production yet and its external monitoring of our stuff already found a real problem. On the one hand, clearly it's valuable. On the other hand, I'd rather that this sort of problem wasn't there in the first place.
I've now created my first cloud (virtual) machine. It is of course a special snowflake, because I had no desire to try to simultaneously learn this cloud vendor's web UI, terminology, etc and also some cloud machine automation setup. At least it's an extremely simple special snowflake and I kept notes (and off-machine copies of everything important).
I suspect that it is terribly set up and there are much better ways to do what I want, but meh. It's simple.
@phillmv Yep, we're still on-premise (although I've used locally hosted VMs for testing for years). Partly this is because of (our) university funding model, where it's very hard to guarantee ongoing funding but it's comparatively easy to get one-time funding through grants. The cloud converting one-time capex into ongoing opex is terrible for us; we can't be sure of the opex funding, and if we stop paying the cloud goes away. Hardware is ours for as long as it keeps working.
How good was (is) the Linux kernel at security assessments? Well, between 2006 and 2018, 41% of kernel CVEs had already been fixed in the main kernel by the time they were reported as security issues (in someone's kernel), and the overall average 'time to fix' was -100 days. Clearly a lot of security fixes were not being recognized as such. Which is not a surprise; modern exploit developers are extremely clever.
A realization: One way to describe the Linux kernel CVE situation is that the Linux kernel developers aren't going to be providing security analysis of bugfixes (or kernel changes in general) any more, especially for unsupported kernel versions. This is not quite accurate; some fixes will certainly come with a security analysis (eg, ones reported to the kernel as unfixed security issues). But fewer will than before.
Is this bad? Well, the analysis before was not infrequently wrong, so.
Half formed hot take: the Linux kernel CVE situation is the tip of an emerging iceberg as OSS people push back and refuse to do supply chain/security work for free just because third parties want it.
(AFAIK, the ultimate trigger was third party maintainers of old kernels wanting the mainstream kernel to note all changes that turned out to be security fixes so the 3rd parties could backport them and only them. Identifying what is actually a security fix is non-trivial extra work (& fallible).)
Blog post: Some ideas on what Linux distributions can do about the new kernel situation https://utcc.utoronto.ca/~cks/space/blog/linux/DistributionKernelHandling2024 tl;dr: distributions can longer release whenever they want, have the same kernel version for years and years, and have great security (unless they want to do a lot of work themselves). But realistically they never could.
Volunteer run distributions should probably get used to updating their kernel versions over the lifetime of a release. Commercial ones? Whatever you'll pay for.
Today's cursed X Windows System knowledge is about how X has two cut and paste systems and they don't interoperate, because after people used the first system for a while they realized it had limitations and was kind of a bad idea but of course it couldn't be replaced. Do all programs support both? No, of course not.