Why should people buy special, extra expensive hardware to test with a bad web browser?

It's logical to skip that step.

> Yes, that would limit things, but with today’s 64-bit address spaces I think it could work reasonably well for many systems programming tasks.

As long as the systems programming tasks are strictly sequential, without threads, coroutines or signal handlers.

There is more to memory access than just out-of-bounds access which could be solved by just allocating every accessed memory page on demand as a slightly alteration of your variant.

Good points. As to signal handlers, I’m not aware of any language that fully supports them by making it impossible to call other than async-safe functions (https://man7.org/linux/man-pages/man7/signal-safety.7.html) from asynchrony signal handlers.

But isn't that incompatible with the proposed transition to Git?

This just adds a new tool though.

Obligatory XKCD reference: https://xkcd.com/927/

New tools during the transition, hopefully fewer tools in the long run. Also things making a lot more sense in the long run.

> The parser is implemented in C++ and handles deferred execution pipelines—nothing runs until you call .run(), which allows the JIT to optimize the entire chain of operations.

I think "The parser would hypothetically be implemented in C++" would be more correct as this looks more like an empty skeleton with hypothetical benchmarks.

> "Security through Omission" model

I guess a systems-level programming language that omits the implementation like Orbit is indeed more secure, but also not very useful.

Most distributions also don't allow to 'customize' any of the following:

- compiler used for building the distribution, - libc implementation, - C++ standard library implementation, - coreutils implementation, - system shell, - kernel (e.g., using Hurd), - PAM or equivalent, - util-linux, - package manager,

and so on. systemd is just one more thing in that looong, looong list.

And has a lot more practical benefit than any competing implementation of, say, your libc or coreutils.

> I'm sure there are a number of bearded dudes who would commit themselves to keeping an old distro alive, just for the sake of not having to deal with systemd for example.

I don't think so: there are Debian forks that aspire to fight against the horrors of GNOME, systemd, Wayland and Rust, but they don't attract people to work on them.

That there are so many indicates to me the opposite. There are lots of people who want to work on that kind of thing, just they all have slightly different opinions as to which part is the part they’re fighting against, hence so many different forks.

The forks are all volunteer projects (except Ubuntu), so having slightly different opinions isn’t considering capitalism as a driving force.

> ssh -X is a must.

Reminds me of sites that required ActiveX to run arbitrary code on the user side when visiting a web site outside a sandbox. Turned out to not be ideal from a security point of view.

But I guess `ssh -X` users still miss those times...

I suspect you don't really guess that. There are differences between the two cases. For example, security threat models are a thing. Something can be secure against the threats it will face. I don't ssh -X into servers I don't already trust. There is no arbitrary code being run.

There is a simple solution: automated translations for Excel formulas!

Read more about Microsoft's Excel Functions Translator here: https://support.microsoft.com/en-us/office/excel-functions-t...

popcon.debian.org reports 3 alpha installations and 261750 amd64 installations. Assuming comparable opt-in rates there are less than 0.002% of the users using alpha.

The other mentioned architectures hppa, m68k and sh4 are at a similar level.