"Bovine Cult of the Dead" is obviously Cult of the Dead Cow

"The Melody of Buried Bells" a reference to the Breakup of the Bell System and the ever recombining Baby Bells?

That's credible.

I find the hardware architecture and licensing situation with AMD much more appealing than Nivida and really want to like their cards for compute, but they sure make it challenging to recommend.

I had to do a little dead reckoning with the list of supported targets to find one that did the right thing with the 12CU RDNA2 680M.

I've been meaning to put my findings on the internet since it might be useful to someone else, this is a good a place as any.

On a fresh Xubuntu 22.04.4 LTS install doing the official ROCm 6.1 setup instructions, using a Minisforum UM690S Ryzen 9 6900HX/64GB/1TB box as the target, and after setting the GPU Memory to 8GB in the EFI before boot so it doesn't OOM.

For OpenMP projects, you'll probably need to install libstdc++-12-dev in addition to the documented stuff because HIP won't see the cmath libs otherwise (bug), then the <CMakeConfig.txt> mods for adapting a project with accelerator directives to that target are

find_package(hip REQUIRED)
list(APPEND CMAKE_PREFIX_PATH /opt/rocm-6.1.0)
set(CMAKE_CXX_COMPILER ${HIP_HIPCC_EXECUTABLE})
set(CMAKE_CXX_LINKER   ${HIP_HIPCC_EXECUTABLE})
target_compile_options(yourtargetname PUBLIC "-lm;-fopenmp;-fopenmp-targets=amdgcn-amd-amdhsa;-Xopenmp-target=amdgcn-amd-amdhsa;-march=gfx1035"

And torch, because I was curious how that would go (after I watched the Docker based suggested method download 30GB of trash then fall over, and did the bare metal install instead) seems to work with PYTORCH_TEST_WITH_ROCM=1 HSA_OVERRIDE_GFX_VERSION=10.3.0 python3 testtorch.py which is the most confidence inspiring.

Also amdgpu_top is your friend for figuring out if you actually have something on the GPU compute pipes or if it's just lying and running on the CPU.

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.

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.

Suggestion: the Search key under your left pinkie emits SuperL (aka. Meta, same as a Windows key), and it is an great way to make up for some other keyboard weirdness Chromebooks have, and map to WM controls.

I recently discovered keyd, an excellent system-wide key remapper that works as a tiny daemon that intercepts input events and re-emits them as a virtual keyboard, and have it mapping Search+Arrows to PgUp/PgDn/Home/End (like a lot of laptops do with Fn+Arrows, or ChromeOS does with Ctrl+Shift+Arrows). I've already run into a couple other folks doing the same because it's such a clean solution to the Chromebook keyboard.

AFIK GalliumOS has been unmaintained for over a year, and most of the patches they used to add are now in mainline, so long term you may want to consider a different distro - it's probably OK for a while still though.

The CB3-431 is device name EDGAR. You'd most likely pull the write protect screws and flash a UEFI payload into the firmware, probably using Mr. Chromebox's tooling and payloads. Most modern Chromebooks boot Coreboot with a depthcharge payload, and it can either be coerced to boot something different with a lot of effort, or easily swapped with a Tianocore UEFI payload to make it behave like a normal PC. Once flashed, it's an ordinary Braswell generation PC with 4GB of RAM and 32GB of storage.

The S330 is an ARM machine built on a Mediatech MT8173C. Installing normal Linux on ARM Chromebooks is substantially less well-established, but often possible. It looks like those are doable but you won't get graphics acceleration, and the bootloader situation is a little klutzy.

Of the two, the CB3-431will be easier and better documented to bend to your will.

The major limitation with Chromebooks is really just that there isn't much onboard storage, so you'll want to pick reasonably light software (A distro where you pick packages on a small base install or at least a lighter spin will be preferable) and avoid storage-intensive distros (eg. Nix or the immutable-core-plus-containers schemes whose packaging models have substantial storage overhead are probably unsuitable). You may have a little hassle with sound because many Chromebooks have a goofy half-soc-half-external-codec sound layout for which the Linux tooling is still improving - a pair of annoying PipeWire and Kernel bugs that sometimes cause them to come up wrong and spew log messages got fixed last week but aren't in a release yet.

They aren't fancy machines, but hacked used Chromebooks make great beaters.

They're both simple text formats, but Hyprland uses a "key = value" type config with section labels. Sway is largely compatible with i3 config files which are more like an unstructured script.

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.

I have an ESP32 set up with Zimodem which just makes the ESP32 act like a Hayes modem that talks IP instead of phone numbers to the serial port. They're a ton of fun.
FujiNet appears to offer a little bit more in the way of high level service translation.

IIRC, the Ultra 1 and 2 are strictly SBus machines, the all the later Ultra 5/10/30/60/80 are PCI machines, plus most but not all members of the family have UPA slots with that freaky two rows of card edge connector for fancy video boards?

For readers not exposed to lots of Sun lore, Ultras were distinguished from SparcStations because they host 64 bit SPARCv9 parts branded "UltraSPARC," as opposed to the 4m SparcStations which were based on 32-bit SPARCv8 processors.

I'll also add that, 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.

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.

I've recently decided to take a tour of my local roasters' espresso blends. The first two candidates have been:

4th Level Roasters' Espresso Blend. Not terrible, but $18/lb, darker than I prefer, and "robusta forward" in that great body but unfortunate tire-fire flavor sort of way, so I'm glad I only went for an 8oz bag and I don't think I'll get it again.

Nate's Coffee's Nate's Espresso Blend which is $15/lb, and delicious. Balanced, not too dark, good mouthfeel. I'm having to dial a bit, it's pulling a slow shot at my usual starting settings, but even the slow ones were tasty and they're just getting better as I dial the grind out toward a 30ish second shot.

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.

It more or less has been abandoned in favor of PipeWire - even at 0.3.something it's a better solution than Pulse ever was. Pipewire was started by Wim Taymans (previously of gstreamer so they had experience in AV plumbing), has a much better thought out architecture, and can act like a Pulse or JACK server so it transparently replaces either for most applications.

I'll give PulseAudio a little bit of a pass for triggering some cleanup in the lower levels as it tried to use features that no one knew were broken until it touched them, and being a first attempt at dealing with some of the modern-sound-architecture bullshit (ever look at how Intel baytrail platforms audo devices are attached? It's nightmare fuel), but it is, was, and always has been awful.

Or, if you want something simpler and less featured, you can use ALSA directly or sndio (originally from OpenBSD), though increasingly you'll have application compatibility problems doing so... but you mention Bluetooth, so use Pipewire.