yjftsjthsd-h

Because it's pointlessly incompatible. You can do the exact same thing purely in the application, leaving the file format the same. Why do you hate interoperability?

So, the good news is that I can probably now get root on almost any Linux-based device I own. Don't even need to solder on a serial port or w/e, just direct network connection.

That surprises me; I assumed they dropped the last pre-Darwin code when they discontinued the classic environment. What remains that's that old?

Nice job mainlining the micropython:)

I do like the pinetime, but it really is just a little too limited IMHO. Just a little more RAM would make it so much easier to work with. High hopes for the pro model.

I mean, basically just sounds like the status quo but with a smaller initial firmware chaining to a user-flashable second stage. Which I'd certainly support, but that... just sounds like coreboot? (Which is an initial firmware that usually gets combined with tianocore to provide UEFI or seabios or ...)

I said "and capable of booting arbitrary target operating systems" for a reason. Linux can kexec itself and I believe modded (but not mainline) FreeBSD. UEFI is rather more general.

> Everything else should probably be left to whatever is running at the initialization vector of the storage. Which, if you'd like, can be a complete UEFI implementation.

Putting it all in a single location on the storage device means that 1. Multibooting will always suck because Windows will unconditionally overwrite whatever is there with its own bootloader that only boots Windows, and 2. you now have to have local storage, which would be somewhat annoying to those of us trying to do diskless network boot (or anything else more interesting than "always boot internal disk0").

Any chance you could recommend a board or two?

What operating system would you use, that is small enough to be burned into a flash chip on the motherboard, and capable of booting arbitrary target operating systems?

> Most developers just didn't want to admit it because it meant more work

Sounds like it wasn't very usable

I feel quite comfortable asserting that anything involving systemd is no longer associated with the Unix philosophy

But the NetBSD community already exists?

Well, several of those have reasonable alternatives (e.g. clang). They're just, you know, probably also using AI

> which was selling people only for people that either don't understand docker layers or can't make Dockerfile correctly.

I don't think that's fair. Alpine-derived images are generally smaller, all things held equal. Of course if you do everything else right then it will matter less, but a proper multistage Dockerfile should still be smaller than the same thing built out of another distro (most of the time).

> AlpineBSD is not a fork of Alpine Linux, its package collection is original (though many packages are ultimately based on aports).

> Alpine Linux uses the OpenRC init system. Currently, AlpineBSD uses s6 and we intend to add OpenRC as an alternative.

I'm not sure where exactly the line should be, but that feels like it's not an Alpine* then. Like, if you're starting your package collection separately and use a different service manager, you're further from Alpine Linux than Adélie Linux is.

(To be clear, I'm a big fan of making a new OS from a *BSD core and a new userspace. I'm just quibbling about naming semantics)