So they pretty much have to ship one, to stay relevant. And they are privacy-focused, so I'm happy they are not just using ChatGPT or whatever under the hood to implement support.

Unfortunately, you're only getting attention in 3 second chunks.

Rust + EDITOR.COM is kind of like remaking/remastering an old video game.

I guess they thought that inheriting 25 years of C code was more trouble than designing a new editor from scratch. But you'd have to ask the devs why they decided to go down that route

Yes, but you have to put `set mouse` into your nanorc.

This is not a rewrite. Maybe it’s slightly inspired by the old thing, especially with having GUI-style clickable menus (something not seen often in terminal editors), but it’s much more modern.

CUA-style menubars aren't that uncommon in textmode editors. Midnight Commander's editor has traditional menubars with much more extensive functionality, as does jedsoft.org's Jed editor. Both of these also support mouse input on the TTY console via GPM, not just within a graphical terminal.

* https://news.ycombinator.com/item?id=44034961

However, Google might have planned to slowly make Android proprietary, which means death to 3rd party forks.

The big problem is that aaaaaalll these forks are still just a tiny tiny tiny drop in the bug mobile phone OS bucket.

If the forks want to be sustainable they need to cater to the market a bit. (Of course that's much harder said than done, but we see - for example with Nothing Tech - that there are new successful upstarts from time to time.)

> not much will change overall. It's a major step in the wrong direction but without a large direct impact on us

Yes, the problem is that someone has to manage it all (full disclosure: I work for Elastisys, a company exactly in the space of fully-managed application platforms on top of the infra operated by others).

But the fact that smaller cloud providers haven't had the money to invest in their capabilities to offer managed services to the same degree as the enormous hyperscalers isn't exactly impossible to overcome. In fact, it's never been more possible. Other comments here show that very well, too. And that the particular choice of identity management services is perhaps not the best for showing where the hyperscaler options shine.

Most CNCF projects and incubators are coming out of American, Chinese, and Indian teams at American or Chinese firms.

The 5G rollout in the US, China, and India in the mid-2010s meant an entire ecosystem of K8s and eBPF versed engineers exist in those geos.

There isn't a similar ecosystem in Europe, and all the major telcos in Europe decided to become resellers of white labeled American cloud products.

We can definitely reinvent the wheel, perhaps even making better products, but for the time being these open source tools are good enough, again, IMHO

OSS is not plug-and-play (nor should it be), and the ecosystem of talent for technologies like eBPF, OTel, or Operator Frameworks doesn't exist because the primary forcing function to generate that kind of an ecosystem (5G rollouts) has lagged for over a decade in much of Europe.

Remember that Tim Cook quote about not being able to fill a room of American die cast engineers? It's the same thing in Europe and America for a lot of core technologies in cybersecurity, systems programming, and devops.

If you cannot incubate your own OSS offerings or play a major role in contributing to these projects, then you will always remain a laggard. Almost every incubated CNCF, eBPF, or Linux Foundation project has some sort of corporate backing behind it, and it's almost inevitably some company or team in America, China, Israel, or India that monetizing the offering and remains the primary contributor.

OSS is extremely political, just like creating a company, and open-core players always end up muscling or out-competing passion projects alone. And for those that they can't, they end up sponsoring those or hiring those developers and thus subsume it.

Countries like China and India have actual bureaucrats with EECS backgrounds at ministries who have worked for a decade building public-private strategies around building a Kubernetes, RISC-V, or eBPF strategy, and in the US and Israel, it's highly capitalized private sector players taking advantage of that.

https://pypi.org/project/qrcode/

That way, someone has already done all the configuration of various plugins and components for you. For instance, the major clouds that all let you easily start with their Kubernetes services and that they integrate well with the logging and monitoring systems, IAM, server/node provisioning, etc.

Or ones that are not tied to any particular cloud provider, and perhaps focused on security (full disclosure: I work for Elastisys, who makes exactly that) or ease of use.

I'm sure we will see more and more such efforts in this space, exactly because cobbling together something yourself from scratch (basically just a control loop runner, as you said) is neither very appealing when you think about ongoing maintenance, nor very cost-effective for businesses to spend engineering time on.

"You can get this property by stapling HKDF onto your protocol (once for key derivation, again for commitment). See also: PASETO v3 and v4, or Version 2 of the AWS Encryption SDK.

It may be tempting to build a committing AEAD scheme out of, e.g., AES-CTR and HMAC, but take care that you don’t introduce canonicalization risks in your MAC."

I would almost suggest breaking stuff like this into two articles, one which is very technical and correct, and one that conveys the high-level message. The high-level one can link to the technically correct one whenever the urge would come to explain something more fully.