yjftsjthsd-h

> Blacklisted the hardware a KVM guest never has or doesn't need

I'm a little surprised that matters; shouldn't Linux be lazy loading drivers only when it sees hardware?

Based on what?

People are paying money for Ubuntu, though. I suppose if only the free versions were unpatched we could consider the ethics and merits of who is allowed to complain about what, but when the paying customers are also being left out in the cold I don't think your argument has much merit.

It's actively developed; did you just see a recent commit or release?

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)

Is it? I'd like a UEFI phone booting GNU/Linux but last I looked it was a bunch of hacky aftermarket firmwares.

PS your profile links a blog that says you moved

I think uboot is kinda doing that?

> It executes code before the operating system but doesn't really provide a hardware abstraction layer like BIOS does.

Yes it does? If anything, it provides way more; a .efi program can use firmware services to load files and print text. There's like 80% of a DOS in there.

> Most operating system don't use BIOS or any other software layer and configure the hardware themselves. Why is it there then?

Because we still want enough functionality to load the OS in the first place, which means e.g. nvme drivers, Ethernet drivers (for netboot), keyboard input and some display output (to let a user pick what to load), and of course filesystem drivers because loading an OS/bootloader from a single shared MBR was awful.

> it won't be long before someone comes up with a crazy chimera of an OS that can run DOS, Windows, Linux, BSD, and macOS binaries

TBF, the only missing part of this is that Darling isn't developed enough to run many Darwin programs; otherwise you can have that today by installing WINE+DOSBox+Darling on Linux or your pick of *BSD or illumos. (Well, running *BSD programs on other systems is a weak point, but otherwise.)

Okay, that's fun:) ...so if I use this on an ESP* with a physical display and keyboard attached, at what point does it stop counting as a terminal emulator again?:)

> Libghostty now builds and is tested (in CI) for: [...] freestanding (i.e. direct on hardware with no OS).

That's really cool, but I'm drawing a blank; what's it used for? Embedded terminal something?

How's that different than just not connecting?

> start classic Mac OS in the built-in SheepShaver emulator with your own ROM

Built-in as in preinstalled, or is there some deeper integration?

> And, though I feel bad for saying it, I can't blame them. If some idiot roots their phone and downloads malware, the bank may be responsible for refunding them. I can see why they don't want that headache.

This argument has never held any water for a simple reason:

Consider 2 phones.

1. Runs self-built lineageos (latest version), with magisk installed.

2. Runs official stock ROM, no mods, all apps from Play Store. Also, hasn't gotten any updates in 6-9 months and is running a 4.4.x kernel that isn't even the latest version on its branch.

If your app blocks phone 1 and allows phone 2, then you're doing security theater in a way that actively undermines actual security. The ability for a user to flash an OS or allow apps root access doesn't make a device insecure, but the ability for any app to grant itself root because the vendor can't be bothered to patch the OS certainly does.

If you have evidence that someone is using fake accounts, you should email that to the mods. I will agree with the rest of your comment though.

> Native encryption.

I think maybe that's the one feature that's iffy? Theoretically great but bad history of bugs. (Unfortunately)