Brief items

It gets even worse. Our system of disclosure and patching assumes that vendors have the expertise and ability to patch their systems, but that simply isn't true for many of the embedded and low-cost Internet of things software packages. They're designed at a much lower cost, often by offshore teams that come together, create the software, and then disband; as a result, there simply isn't anyone left around to receive vulnerability alerts from researchers and write patches. Even worse, many of these devices aren't patchable at all. Right now, if you own a digital video recorder that's vulnerable to being recruited for a botnet -- remember Mirai from 2016? -- the only way to patch it is to throw it away and buy a new one.

Patching is starting to fail, which means that we're losing the best mechanism we have for improving software security at exactly the same time that software is gaining autonomy and physical agency. Many researchers and organizations, including myself, have proposed government regulations enforcing minimal security-standards for Internet-of-things devices, including standards around vulnerability disclosure and patching. This would be expensive, but it's hard to see any other viable alternative.

In programming, "Appeal to Standards" should be considered a potential logical fallacy. Standards have their place, but they definitely have their caveats too.

When you're a kernel dev, you sometimes do get the feeling that everyone is waiting for you. We're not. There is no rush. We read through your email and reply and then it's gone from our mind like dust in the wind. There is never a rush and you will never run out of more work to do.

Of course, we all know that working in QA is more or less a 24×7 whirl of red carpets and high-end cocktail parties…but today is particularly glamorous! Here’s what I’m doing right now:

1. Build an RPM of a git snapshot of Plymouth
2. Put it in a temporary repo
3. Build an installer image containing it
4. Boot the installer image in a VM, see if it reaches anaconda
5. Repeat, more or less ad infinitum

I just can’t take the excitement!

As far as I'm aware, our Bylaws, Social Contract etc. don't say anything about having to hate Microsoft.

Gentoo should continue to support users via GitHub as long as users are willing to contribute this way, and there are developers who wish to support them.

PS the word "dogfooding" is ridiculous. Our software is much better than dogfood. I prefer "champagning" - as in, Debian often drinks its own champagne.

... the bug in question is indeed in m4 1.1 dated 1993-11-08.

As far as I know, this holds the record for the oldest bug reported in GNU software so far this year. (Maybe we should give Andy a prize; how about a plaque inscribed in EBCDIC? :-)

The Microsoft of today is a company that understands and embraces open-source development, both in the strict technical sense of publishing source code and in the broader sense of community-driven, collaborative development. The movement appears to be genuine, and frankly, that's not something that we should find altogether surprising: there's a hell of a lot of programmers working at the company, and many of them are users or contributors of open-source software themselves. They get it; it was only a matter of time before the company did, too.

The biggest screen in your house would seem a logical place to integrate cloud apps, but TVs are walled gardens. While it’s easy enough to hook up a laptop or PC and pop open a browser, there’s no simple, open framework for integrating all that wonderful data over the TV’s other inputs.

Consider all the data that's used to provide the value-added features on top of git. Issue tracking, wikis, notes in commits, lists of forks, pull requests, access controls, hooks, other configuration, etc.
Is that data stored in a git repository?

Github avoids doing that and there's a good reason why: By keeping this data in their own database, they lock you into the service. Consider if Github issues had been stored in a git repository next to the code. Anyone could quickly and easily clone the issue data, consume it, write alternative issue tracking interfaces, which then start accepting git pushes of issue updates and syncing all around. That would have quickly became the de-facto distributed issue tracking data format.

Instead, Github stuck it in a database, with a rate-limited API, and while this probably had as much to do with expediency, and a certain centralized mindset, as intentional lock-in at first, it's now become such good lock-in that Microsoft felt Github was worth $7 billion.