I initially didn't do enough of that in my PhD thesis (CS, about some weird non-frame-based imaging tech that is still only of academic interest), and my committee demanded I add more stake-claiming favorable comparisons to other tech to my introduction before I submitted.

NeXTStep became MacOS (OS X and later) and related systems. It does contain quite a number of BSD pieces that are now periodically pulled from FreeBSD.

The story is fun and I like telling it, strap in:

NeXTStep was basically the MACH microkernel hybridized with BSD (actual Berkley BSD before the court cases and diaspora that lead to Net/Free/Open BSD and Solaris and such) parts to make a reasonably performant modern design Unix-like, with a fancy PostScript based display layer on top, lead by Steve Jobs after he was ejected from Apple, a bunch of folks he effectively took with him, and Avie Tevanian who was the major force behind Mach when it was a research project at CMU.

Between 1988 and 1996 Apple failed like 3 times at building their own next-gen OS. Apple and IBM cooperatively fucked up the Pink/Taligent development process so hard it's still told like a ghost story to software developers, Copland got out of control with feature creep and empire building, and A/UX, cool as it was, was never going to be a mainstream OS because it contained Unix-brand-Unix and the associated thousand dollar license fee (Also IBM got involved combining some future development of A/UX and AIX for PowerPC and some of the Taligent stuff entered the picture and it turned into a clusterfuck).

So it's the mid 90s and Apple is shipping an OS from the mid 80s that they had to do hacky shit to make do even cooperative multitasking, and the executives are looking to acquire one that is already done.

Two former heads of the Mac division had left and built companies that tried to build whole computer platforms then pivoted to just selling software, Steve Jobs with NeXT and Jean-Louis Gassée with Be. The exact details of the negotiations about how they chose NeXT over Be are kind of ambiguous and vary from account to account, I'm personally of the opinion that the biggest reason is that OpenStep looked a lot like "Taligent, but not completely bungled."

So Apple Bought NeXT in 1997 in a scenario better described as "NeXT Bought Apple with Apple's Money" because all the executives in charge after the shakeup were NeXT folks.

There was an initial plan to more or less slap a OS 8 like Copland-looking GUI on the hybridized Mach/BSD kernel and most of the userland from OpenStep (an environment that at the time was called "Yellow Box"), ship it with a virtualization environment called Blue Box to run legacy MacOS programs, and call it a day. You can even play with the missing link Rhapsody from that era, and the Classic environment that early OS X versions had is the direct descendant of that BlueBox compatibility environment.

Then some of the important software vendors (read: Adobe, whose shitty development practices are why Macs are case insensitive by default to this day) revolted at the idea of having to do ground-up rewrites so Apple designed the Carbon APIs that are kind of a stepping stone between classic MacOS and the native Cocoa APIs that evolved from the Yellow Box deign which are the usual target on modern macOS/iOS.

(The story of how Windows NT - which is the underlayer of all modern windows systems - is basically "The DEC VMS team got pissed off about obviously-dumb management decisions and were looking to leave DEC while Microsoft became aware that OS/2 was failing largely due to bad IBM decisions, so Microsoft hired the core of that team to write the operating system they were designing, moved the few remaining competent folks over from OS/2 to help, and sold it as Windows" is similarly absurd. As the joke goes, it may not be a coincidence that WNT is VMS incremented).

Neat.

I set up some basic compute stuff with the ROCm stack on a 6900HX-based mini computer the other week (mostly to see if it was possible as there are some image processing workloads a colleague was hoping to accelerate on a similar host) and noticed that the docs occasionally pretend you could use GTT dynamicly allocated memory for compute tasks, but there was no evidence of it ever having worked for anyone.

That machine had flexible firmware and 64GB of RAM stuffed in it so I just shuffled the boot time allocation in the EFI to give 8GB to the GPU to make it work, but it's not elegant.

It's also pretty clumsy to actually make things run, lot of "set the magic environment variable because the tool chain will mis-detect the architecture of your unsupported card" and "Inject this wall of text into your CMake list to override libraries with our cooked versions" to make things work. Then it performs like an old GTX1060, which is on one hand impressive for an integrated part in a fairly low wattage machine, and on the other hand is competing with a low-mid range card from 2016.

Pretty on brand really, they've been fucking up their compute stack since before any other vendor was doing the GPGPU thing (abandoning CTM for Stream in like a year).

I think the OpenMP situation was the least jank of the ways I tried getting something to offload on an APU, but it was also one of the later attempts so maybe I was just getting used to it's shit.

Don't trust that they're 100% compatible with mainline Linux, ChromeOS carries some weird patches and proprietary stuff up-stack.

I have a little Dell Chromebook 11 3189 that I did the Mr.Chromebox Coreboot + Linux thing on, a couple years ago I couldn't get the (weird i2c) input devices to work right, that has since been fixed in upstream coreboot tables and/or Linux but (as of a couple months ago) still don't play nice with smaller alternative OSes like NetBSD or a Haiku nightly.

The Audio situation is technically functional but still a little rough, the way the codec in bay/cherry trail devices is half chipset half external occasionally leads to the audio configuration crapping itself in ways that take some patience and/or expertise to deal with (Why do I suddenly have 20 inoperable sound cards in my pulse audio settings?).

This particular machine also does some goofy bullshit with 2 IMUs in the halves instead of a fold-back sensor, so the rotation/folding stuff via iio sensors is a little quirky.

But, they absolutely are fun, cheap hacker toys that are generally easy targets.

The argument was that if you put all your static resources in /usr, you can mount it RO (for integrity, or to use a ROM on something embeddedish) or from a shared volume (it's not uncommon to NFS mount a common /usr for a pool of managed similar machines).

...that said, many of the same people who made that argument are also the ones that went with making it so systemd won't boot without /usr populated anymore, so that feature is now less useful because it has to be something your initramfs/initcpio/whatever preboot environment mounts rather than mounted by the normal fstab/mount behavior, and the initcpio/initramfs/dracut schemes for doing that all (1) require a redundant set of tools and network configs in the preboot (2) are different and (3) are brittle in annoying ways.

It still works OK if you're using a management tool like Warewulf to manage configs and generate all the relevant filesystems and such, but it's a lot more fucking around than a line in fstab to mount usr once the real system is up like the old days.

The near instant heat up is a big part of how I ended up with my Bambino with its "Thermojet"(Thermoblock coil thing) heater.

3s from wake to ready, it takes longer to grind and prep than to heat. I usually pull a blank shot through the clean portafilter into the cup I'm going to pull the shot in so the downstream parts aren't crashing the temperature, but that's still seconds.

Ascaso and Decent have more up-market offerings with thermoblock heaters that are similarly fast but offer more control. I wasn't 5-10x price compelled for my needs, and I'm certainly not over 100x price in to that thing... But it is a great feature that the commercial derived machines don't do.

Most of my machines are KDE on X, but I have one where I've been feeling stuff out in Wayland-land. The most appealing thing I've tried has been Hyprland with Waybar. It's a little bit of a kit in traditional WM fashion, but easy to configure from straightforward config files, fairly light, and not "Just like this X WM, but broken because of missing Wayland functionality" (I know, I know, it's not technically Wayland deficiencies, its "not yet complete extensions", because it's all extensions, the Wayland protocol itself does almost nothing).

I've been using Kitty for a terminal emulator and it's pleasing as well.

I haven't found a launcher I love, I have fuzzel right now and the only major issue is it doesn't currently support mouse interaction, and I prefer a "use whichever input device your hand is on at the time" to keyboard-only.

Most Chromebook's firmware is Coreboot, but it's running a Depthcharge payload instead of UEFI (or BIOS or whatever). Mr. Chromebox maintains UEFI Coreboot payloads and install tools for a wide variety of (x86) Chromebooks, which can be used to flash a normal UEFI payload and boot normal OSes. It's strictly possible to boot normal Linux systems on a the Depthcharge payload modern Chromebooks use, but uh... here's the gentoo wiki on it, it's a substantial pain in the ass.

Yup.

I have a little Dell 3189 2-in-1 that I originally got used just to see what the ChromeOS fuss was about and hack on.

I'd rooted it, and played with the various hosted/injected Linux options (like chromebrew and the 1st party Linux VM stuff, neither of which was great) while it was under support, but some time after it went AUE I went ahead and flashed a Mr. Chromebox UEFI payload onto it and just slammed normal Linux onto it. It basically "Just Works" though that's thanks to considerable efforts in the Coreboot port and Kernel because there is a bunch of cheap bullshit (badly plumbed i2c input devices, that stupid bay/cherry trail style half integrated audio setup, etc.) in the hardware. I had briefly flashed it over a couple years ago and that hadn't all been smoothed over yet back then.

Lately its an Arch system playing with various Wayland options - Hyprland is ricer bullshit, but it actually does a pretty decent job at being not wildly broken compared to the big environments in Wayland mode, tiling makes good use of the not enough pixels, and the search key in the left pinkie position makes a great WM key.

It's not a nice computer, an N3060 with 4GB of RAM 32GB of emmc and a 1366x768 panel is distinctly in craptop territory these days, but you can also get them for like $50 now because no one wants past AUE Chromebooks, and they make nice beaters - and unlike refurb SFF boxes, SBCs, and similar usual sub-$100 beater options, they come with a screen and keyboard and battery.

Just wait for the 9,000th repetition of the same three posts and it'll start getting sassy.

"Your print problems are almost certainly because you haven't properly trammed and offset the bed."

"PLA itself is foodsafe, filament additives may not be, and print texture is a bacteria farm."

"Consensus starter printer in each price bracket right now is..." (actually not as obvious as it has been, some Ender3 variant and Bambu P1P? That one isn't as tired as the other two because it changes over time.)

Many manufacturers have been moving to cardboard. Less wasteful than plastic spools, more convenient than reusable spools.

In the same kind of vein as imagemagick, Dave Coffin's dcraw tool at least partly underlies almost every non-proprietary RAW image decoder, and some of the commercial ones (if they don't use code, they use constant matrices and such).

He's not a sole maintainer to any of his major projects anymore, but honorable mention to Fabrice Bellard who initiated both ffmpeg and qemu among other notable activities.

IIRC the Expat XML parser that's embedded everywhere was basically on spare-time maintenance by Clark Cooper and Fred Drake for a couple decades, but I think they have a little more resources now.

SQLite is a BDFL situation more than single-maintainer, but D. Richard Hipp still has his hands on everything, and there are only a relatively small number of folks with commit access.