A thing I'm quite tired of seeing in technical spaces are exceptions being made for engineers because they are "smart". Widely known as the brilliant asshole.

This is code. It can be difficult, doing it well is even more difficult. It's also table stakes for this job. Especially when it comes to OSS. We are not so unique that we can't be replaced with another coder. I have replaced myself with very competent engineers at Meta in my work with btrfs.

What makes "smart" engineers is their ability to work with other people. This fantasy that "ideas" are how we communicate and the best idea wins, the most technical argument wins, is simply not true. You get your code in because you know how to communicate. Does that include technical arguments? Of course it does. But if you bring that technical argument to the table with "I can't believe you were so stupid to do it this other way, you should all thank me for being here" you are going to be far less successful.

That doesn't make you smart. To me, "smart" includes all the things necessary to accomplish your task as quickly and efficiently as possible. Part of that for us is coding, but the larger part is communication and the relationships we build with each other by being consistent with how we communicate and treat other people.

I work with the smartest people in the world. They are smart because they can code. They are smart because they are kind and gracious with their communication. They are smart because they build community in the work that they do.

If your community is a developer of 1 and nobody wants you around, it doesn't matter how good of a coder you are. You have failed at one of the core tenants of your job. In the real world, with real stakes, real bosses, real accountability, you would be fired. And that would be the correct outcome.

The power of OSS is the fact that it's many developers working on a thing. We all witness the power of this every day, but still cling to this fantasy that it's one smart asshole that keeps the whole thing together.

We are all replaceable in OSS. That's the beauty of it. It will outlast every once of us.

If you run an operation that pays freelance authors for articles, you get a *lot* of people trying to sell you the output from their slop factory of choice. These pitches far exceed the legitimate ones at this point.

Today we got a pitch for an article about the load-balancing scheduler regression caused by the sched_ext framework in the 6.11 release. Somebody has clearly put a bit more than the usual amount of attention into the sort of topic that might appeal to @lwn. There is only one little problem... that regression had nothing to do with sched_ext, which was merged in 6.12. The pitch was a bunch of authoritative-sounding bullshit; the article would surely have been more of the same.

Sometimes I truly lose hope about humanity's ability to keep its head above the flood of this stuff.

I love how Apple will now be repeating every security mistake by writing their own container runtime. I thought we're past all that but hey, let's have some more path lookup CVEs. @cyphar

https://github.com/apple/containerization/pull/173

@stefanct It's an in-house solution developed and maintained by one of my customers.

@stefanct Thx!

@agraf @manut
I did report the issue already:
https://lists.gnu.org/archive/html/bug-bash/2025-06/msg00149.html

Given the responses so far, I'm not sure whether I want to continue this path.

@manut I meant for Linux. Having the fallback available on Linux makes no sense.

@manut sure. I'd go so far and suggest removing the getcwd() fallback at all.

In the i686 discussion in #Fedora we currently hear quite a lot of voices in support for the Steam client, but not that much of other use cases.

If you have anything specific using i686 packages on Fedora, which is _not_ Steam, this is a good time to mention it, so that your use cases are not lost.

https://discussion.fedoraproject.org/t/f44-change-proposal-drop-i686-support-system-wide/156324

And please do not panic, it is a discussion, nothing is decided yet :)

Hunting down bugs on embedded systems is not always fun. That one was.

https://sigma-star.at/blog/2025/06/deep-down-the-rabbit-hole-bash-overlayfs-and-a-30-year-old-surprise/

Mein Freund und Kollege Fefe lässt Grüße aus dem Krankenhaus ausrichten, wo er sich nach einem Schlaganfall auf dem Weg der Genesung befindet.

#fefe

Intel to replace their marketing people accenture and AI.
I guess if your ship is about to sink anyway you might as well pull the plug

https://www.oregonlive.com/silicon-forest/2025/06/intel-will-outsource-marketing-to-accenture-and-ai-laying-off-many-of-its-own-workers.html

#intel #ai

Enshittification comes for open source:
Slack is kicking two large open source groups, Cloud Native Computing Foundation and Kubernetes, off of their donated enterprise tier, giving them one week notice to migrate multiple years of data to a new platform before it's all deleted: https://www.cncf.io/blog/2025/06/16/cncf-slack-workspace-changes-coming-on-friday-june-20/

Instead of learning from this experience and not trusting the good will of profit-motivated closed source companies, it looks like both projects will be moving to ... Discord. Because "people know it." Will we never learn?

@pluralistic

#enshittification

📢 🐧 🇪🇺 The schedule for Linux Security Summit Europe (LSS-EU) 2025 is now up:

🏰 https://events.linuxfoundation.org/linux-security-summit-europe/program/schedule/

LSS-EU will be co-located with OSS-EU in Amsterdam, NL, on 28-29 August 2025.

For more information, see:

🏤 https://events.linuxfoundation.org/linux-security-summit-europe/

#linux #security #linuxfoundation #linuxsecuritysummit

The missing translate caffe was great 😁

OH: “Wer keinen Enterprise-Architekt kennt: das sind Softwareentwickler, die sich sehr gerne selber reden hören”

JURASSIC PARK was released 32 years ago today. Also, Jurassic Park is a cautionary tale about how you compensate IT staff :P

Guckt mal! 👀
https://ruthe.de/shop

🥔🥔🥔

Like everybody else, LWN is affected by the current turbulence in the political and economic spheres; we expect to get through this period, but there will be some challenges.

To put it bluntly: starting around the beginning of March, we have observed a distinct drop in both new subscriptions and renewals. [...] #OpenSource #Linux #LWN

https://lwn.net/Articles/1019217/