It should be maintained by humans, relying on widely available hardware and software, requiring little of both.

Not saying that using LLMs as a convenience is forbidden or anything, but the direction is problematic.

(Also, this sounds like a cheap alternative to actually funding FOSS work.)

> Orthodox C++ (sometimes referred as C+) is minimal subset of C++ that improves C, but avoids all unnecessary things from so called Modern C++. It’s exactly opposite of what Modern C++ suppose to be.

"Modern C++" is usually considered to mean the significant changes to the language in 2011, or 2011 and later. The thing is, that a "small subset improving over C", and without "unnecessary things" will not necessarily avoid 2011-and-later language features, and splurge with pre-2011 features. And this becomes clear as you read the recommendation. So, it's recommand to avoid:

* exceptions

* STL objects which allocate memory

* C++ streams

all C98 features. On the other hand, it's not recommended to avoid constexpr, and it is in fact hinted it is useful.

-----

C++ is a multi-paradigmatic language. It has lots of features, in the language and via the standard library. It is perfectly reasonable and legitimate to pick feautres which are well-tested enough; or well-regarded by, say, embedded or game developers, or doesn't seem too outlandish coming from C. Of course, different people will quibble over what exactly to adopt or discard, but I'm sure that different flavors of "orthodox C++", "sane C++", etc. are in fact used by many groups of developers.

Here's a big part of the problem right there. Google requires something, it becomes a requirement. In fact, Google's hold on email is a problem in itself. Among other things we need variety. Without it, "Google begins requiring" will be a recurring theme. It's happening again now with mobile phone apps! "Google begins requiring" that you register with them so that the apps you write can be installed on Android phones.

> This shifted authentication from something senders could deprioritize to a basic prerequisite for reaching inboxes.

And later, Google and a few other large players could just prevent individuals and smaller email service providers from being able to send email, at all.

> so the filtering systems can tell where bad content is coming from and avoid hurting the reputation of the wrong parties.

Be ready for people who don't register with the big corporations to be marked as having "bad reputation" and being simply blocked. There might be some technical excuse.

> The inbox of the future will be faster, smarter, and more capable than what most of us use today.

That sounds like the inbox of the future might be controlled by somebody else. I don't like that at all.

> dn42 is a large, dynamic VPN that employs Internet technologies (BGP, whois database, DNS, etc.). Participants connect to each other using network tunnels (GRE, OpenVPN, WireGuard, Tinc, IPsec) and exchange routes using the Border Gateway Protocol.

(dn42.dev)

Oh, sure, both kinds of factories are legitimately slashable as they are totally the same thing. Pretty much. Right? :-(

https://tomtunguz.com/spacex-openai-anthropic-ipo-2026/

and I don't know what worries me more - a burst in this bubble (and maybe some other tech stocks), or a failure of these valuations to be burst somehow, and even more concentration of capital and power around those corporations.

> ...

> The... sustainability initiative...[:] If the permanent resident population exceeds 9.5 million ... the Federal Council and Parliament will need to take measures, particularly in the areas of asylum and family reunification.

So, this measure says that if companies need more workers, Switzerland will refuse to grant asylum, and will prevent Swiss residents from having their spouse, child or parent come live with them.

Regardless of whether population capping is legitimate or not, that sounds quite nasty. If the measure had said "in case of population growing, there will be a moratorium on recruiting employees from abroad", then you would have a discussion.

I wouldn't say that.

> But as AI-generated code becomes the dominant path to production

I really hope that's not the case.

Would have made them without UI with a bit more elbow grease invested in web-searching for some examples, maybe even a StackOverflow question.

Generally, I'm not a fan of LLMs and their social effects.

Chromium? You mean the browser engine controlled by the Be-Evil corporation Google, which recently killed support for a huge swatch of important extensions (manifest-v2)? And thus prevents much of adblocking?

Gecko... now that's something less people are aware of, but let's just say if you know how the Mozilla ecosystem is governed internally, I believe you would be rather aghast.

But what happens if:

* You're not the only possible reviewer, and they get some patsies / kool-aid drinkers to approve the PR?

* Their manager is also the code repository owner?

:-(

Them's fightin' words.

A person who says that to me - I ban them from... well, actually, I don't believe in banning people from platforms. Let's say I put them in my basket of deplorables.

1. Opening an issue. 2. Talking about what they want/need that's not catered to right now. 3. Asking for my thoughts or suggestions - even if they already have a potential PR to submit.

and that is for a small codebase where changes are rarely that big of a deal in terms of amount of effort.

I've gotten a few decent 'cold-submit' PRs as well, but my bias has usually borne out, in that these are usually PRs to reject, and only some of the time get adapted into something useful, following some back-and-forth of course.

So, on the one hand, the measure the LB people are taking seems extreme to me; but the previous state of affairs they allude to seems equally weird. (I mean, unless it's a "here is a two-liner fix for a bug" kind of patches).