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.

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.

I will preface that Xorg is obviously an unmaintainable mess of legacy decisions and legacy code, and I have both a machine that runs Hyprland and a machine that usually starts Plasma in Wayland mode so the Wayland situation getting to be more-or-less adequate with persistent irritations here and there... but Wayland is trauma-driven-development. It's former xorg developers minimizing their level of responsibility for actual platform code, but controlling the protocol spec, and in the position to give up on X in time with their preferred successor.

Essentially all of the platform is being outsourced to other libraries and toolkits, who are all doing their own incompatible things (Which is why we have like 8 xdg-desktop-portal back-ends with different sets of deficiencies, because portals were probably designed at the wrong level of abstraction), and all have to figure out how to work around the limitations in the protocols. Or they can spend years bikeshedding about extensions over theoretical security concerns in features that every other remotely modern platform supports.

Some of that outsourcing has been extremely successful, like Pipewire.

Some attempts have been less successful, like the ongoing lack of a reasonable way to handle input plumbing in a Wayland environment (think auto-type and network kvm functionality) because they seem to have imagined their libinput prototype spun out of Weston would serve as complete generic input plumbing, and it's barely adequate for common hardware devices - hopefully it's not too late to get something adequate widely standardized upon, but I'm increasingly afraid we missed the window of opportunity.

Some things that had to be standardized to actually work - like session management - have been intentionally abdicated, and now KDE and Gnome have each become married to their own mutually-incompatible half solution, so we're probably boned on that ever working properly until the next "start over to escape our old bad decisions" cycle.... which, if history holds, isn't that far away.

We're 15 years in to Wayland, and only in the last few years has it made it from "barely a tech demo" through "Linux in the early 2000s" broken, and in the last year to "problems with specific features" broken ... and it is only 4 years younger than the xf86->xorg fork.

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.

Selecting Suns is easy because there aren't many bad choices in the era you're talking about, but a little weird because the internal names and the package label names don't always match in obvious ways. Most of the "classic era" Sparc boxes are Sun-4 variants, with SparcStatons mostly being Sun-4c or Sun-4m and Ultras mostly being Sun-4u machines. The Sun-4* name is more important to knowing what you are looking at than the case badge. For example, I have a "SparcServer 20" that some previous owner installed a TurboGX (cgsix) video board in, so it's almost exactly a similarly-spec'd SparcStation20 with different badges.

Pre-SparcStation Sun-3 and Sun-4 VME based machines are quite a bit more exotic to source parts for in a modern context, and newer stuff are PCs (remember they did go and re-use the Ultra name for a family of x86 boxes a couple years later, so watch model numbers if you're trying to buy a SPARC Ultra).
SparcStations are a little more bespoke and workstation-y (SBus cards, SCSI discs) and Ultras are generally a little more PC-like (mostly PCI cards, ATA discs), but neither are particularly hard to work on these days since the common SBus peripherals aren't terribly expensive and SCSI disc emulators like BlueSCSIs have come down in price and up in performance. IIRC, in all cases you have to be kind of specific with RAM, some older machines use memory modules unique to the family and Ultras mostly take 168pin PC style DIMMs but are picky about the exact details.

IMO the SS10/SS20/SS5 Sun-4m machines are pretty nice to work with because they are still "workstation grade" high reliability parts but were made in HUGE quantities and are extremely modular within the family so it's easy to work on them and get parts/upgrades/documentation/etc. They also have 10baseT Ethernet onboard (careful about degrading your whole switch), while the older SS1/SS2 need an AUI transceiver.

Peripherals:

Remember that older Suns use their own protocol over MiniDIN-8 for keyboard and mouse and 13-W3 video cables. You'll need a suitable Sun keyboard (probably a Type 5 or Type 6) and mouse, and those can be expensive on their own if not bundled because keyboard people. They're not as bad as some of the more exotic and/or desirable to keyboard enthusiast bespoke keyboards, but still pay attention when considering a machine to buy. Video is a little easier because 13W3-to-VGA cables are a thing, (I have one of these with switches so you can configure for Sun or SGI or Next or IBM's particular signaling). You still need a monitor or scan converter that works with Sync-On-Green to accept the signal... most modern LCDs with VGA ports actually can, but the labeling is typically not very clear about that. Sun video adapters are generally a little more willing to negotiate video modes than some of the other workstations (eg. My SS20 has talked to almost everything I've plugged it into, my HP Apollo 9000/735 and its absurd CRX-24z video board will talk to the Dell P2314H on my real work desk and has spurned every other monitor I've tried it with).

NVRAM:

Most older Suns have a chip on the motherboard - typically with a yellow barcode sticker if it's original - which contains a small battery-backed NVRAM storing the serial number, the Ethernet MAC, and various configuration parameters, and a RTC (Real Time Clock). At this point the internal batteries on all of them should be presumed dead. The M48Txx line of chips Suns use were originally made by Mostek, who was absorbed by SGS-Thompson, who became STMicro. Ref for NVRAM chips. Once it dies the machine loses its machine ID and MAC address and such. Fortunately, they can be reprogrammed from OpenFirmware, either with original values read from stickers and the like, or suitable made-up replacements. There are a lot of surviving Suns hand-assigned MAC addresses containing amusing strings like DEAD, BEEF, CAFE, C0FFEE etc. as people have made up suitable numbers. Sun's factory MAC addresses have a 08:00:20 prefix if you want networking tools that notice that sort of thing to assume it's a Sun.

Generally there are 3(and a half) options for dealing with them:

1. Modern production compatibles are still available though you have to be a bit careful about model compatibility, and they're rather expensive these days, something like $25 a piece (eg. Mauser has a small stock of MT48T08s for $26.50+S&H ).

2. You can also grind an end and attach a 3.3v coincell battery holder yourself - some folks say you should always cut the old battery all the way out because there may be unwanted effects to having the dead battery in parallel with the good one.

3. You can crack the whole top of the module with the battery and crystal off and solder on a module with a replacement crystal and user-serviceable battery holder in place.

4. For rarely-used machines, you can just do the reprogramming procedure (in the first ref) at the OpenFirmware OK prompt by hand each time you start the machine, it will hold while the computer is powered.

It's not a huge deal, but it is a thing to expect to have to deal with.

Software:

Remember that the OS nomenclature is a little weird because Solaris started out being versioned on top of SunOS (eg. SunOS 5.1 hosts Solaris 2.1), and at they dropped the SunOS name then leading "2" from Solaris versions so you have Solaris 2.5->2.6->7->8. The Wikipedia version history table is straightforward enough to work through, and has decent notes on supported systems. You'll generally be between 2.1 and 9 on the era of systems you're talking about, and those are the ones that "feel" like old commercial workstation Unix with OpenWindows and CDE and whatnot - I'm partial to 7 as "peak Solaris" but I'm sure that's because I helped maintain a bunch of 7 boxes at one point, it's a fully mature SVR4 with all the commercial Unix-isms before it started to converge with the modern Free Unix-likes. Many of the usual suspects like Tenox and WinWorldPC have install media and/or software.

Edited to add from downthread:

Emulation:

If you don't want to fuck around with large pieces of aging hardware and just want to marinate yourself in a retro Solaris environment, the qemu sparc support is really good. Folks restoring Sun stuff with disc issues often do their installs via netboot from an emulated server. Adafruit even has a beginner click-by-click tutorial for spinning your own emulated Sun4m system.

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.)

It's not just the technical interest community on the lemmy instance, SDF as an entity has gravitas that I appreciate.

It's backed by a 30 year old 501(c)(7) nonprofit established from an even older entity, instead of "someone who spun a VM the other week."

They've handled the abuse of hosting public-facing UNIX systems for decades, so this isn't a crew who will freak out when they get a look at the Internet's gaping hate hole.

This is a community with roots in the BBS era, and the Usenet era, and which maintain their connection to the culture of the ARPANET era via the historical systems (Ya'll played with the TOPS-20 box?). These are people who know that, as platforms go, 'All of this has happened before, and it will all happen again.' and that's the perspective I deeply desire in my platforms these days.

Have you seen that Jason Scott recently received and started digitizing 200 issues of Computer Shopper? The February 1986 issue is already uploaded as a pilot test, and it's pure nostalgia fuel to flip through. You lose a little bit of the experience not having to wrangle a ridiculously large piece of low grade paper, but it's still delightful.

He doesn't currently have a complete set, if anyone has a cache they might be willing to contribute to the effort, check the bottom of the post for missing issues.

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.