Relevant place to ask: I've been trying to find a reference for the earliest Emacs that could host a terminal emulator or subshell in a window.

Multics emacs appears to have had both split windows and a character-at-a-time input and output mode as far back as 1978 for use as a SUPDUP and/or TELNET client, which is currently the earliest I'm aware of. Ancient ITS TECO EMACS had splits pretty early on, and may have sprung the necessary character plumbing earlier - but I've never found any reference material to confirm/deny.

It's a fringe to a larger interest, which is that I've been trying to document the history of terminal multiplexers, especially in the Window (1986)-Screen(1987)-Tmux(2007) tradition (as opposed to the historical meaning which we'd call terminal servers). I'm slowly becoming convinced they came about after the advent of floating window GUIs hosting multiple terminal emulators. If you were super connected and could get access to one, sometime fairly early in the window between the 1973 introduction of the Alto and the surviving 1979 manuals the Alto program "Chat" could run multiple telnet sessions in floating windows (I'm also looking for a more precise date for when Bob Sproull made Chat able to do that trick). Several other early graphical systems like Blit terminals (1982 inside Bell, commercial as the 5620 in 1984) and early Sun Windowing System of early SunOS (1983) could also do multiple floating terminal emulators, so they were common by the early 80s.

Because the 36-bit DEC lineage had pretty robust psuedoterminals all the way back into the mid 1960s ref, a lot of hackers did a lot of fun shit on PDP-10s with ITS and TENEX and WAITS, and Stanford and MIT had PDP-10s connected to fancy video terminals by the mid 70s, it's IMO the most likely place for the first terminal multiplexers to emerge... if I could just find some documentation or dated code or accounts.

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.

Originally it was a governance structure thing.

Now, Rocky is aiming to hold RHEL bug for bug compatibility, and Alma is giving up on that and situating to ABI but not bug for bug compatible.

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.

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.

Gonna give too much answer:

Arch is an "Install what you want" distro - the base installation is quite minimal (eg. No gui by default), and the defaults mostly follow upstream - so there isn't much inherent heft.

If you pick light software it stays light, if you install bulky stuff, it gets bulky.

That said installing most of the major binary package distros (eg. Debian, Rocky) with the same package selections will be of similar size and runtime bulk. There are exceptions, eg. Nix is probably an unsuitable choice on a machine like a Chromebook with small storage because its package managent model keeps a lot more stuff around to enable some neat flexibility/compatibility tricks. Likewise, distros that depend heavily on Snaps or Flatpacks (eg. Silverblue, increasingly Ubuntu) will tend to use more disc space and have some runtime penalty that will be more noticeable on a low end machine.

Arch is "rolling" model, so they track current upstream fairly closely and just upgrade indefinitely. This means things are always fresh but change when they change, some other distros, like Suse Tumbleweed are similar. Stepped release distros like Debian Stable or Rocky try to keep things as consistent as possible for the support period of the release (but upgrading from release to release is likely to be more of a hassle).

There used to be some Chromebook specific distros like GalliumOS that carried patches for the common issues and pre-selected suitable weight packages, but as things got upstreamed they became unnecessary and died out.

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.

I really enjoy the ritual of espresso as a little morning meditation.
Here's the current station, and the current process goes:

Turn on Bambino, load portafilter with empty "double" single wall basket into machine.

Place a small glass on the scale, turn on, spoon in 16g of whatever coffee I have that week.

Start an empty single auto-shot into the glass I'm going to brew into to heat everything up.

Dump measured beans into SK40 grinder which will typically be about "6" on its scale for good fresh coffee, or 5 for not quite so fresh coffee, and start it.

Remove, drain, and wipe portafilter, set it in the little 3D printed base I ran off to hold it level (not my design). Drop the dosing ring on. Set glass of usually dirty with fines hot water aside.

Pump the grinder bellows 3 times when it sounds empty, then turn off.

Dump grounds into basket, massage briefly with a cheap little WDT tool and tamp.

Dump glass into a waste cup I keep on hand for the purpose, wipe, and place on scale. Place scale on drip tray, and re-tare.

If I've dialed the coffee: Hold single button for ~5s of preeinfusion, release, and tap again aiming for a ~32g shot.

If I'm still working on the coffee: Get out my phone, hold single button, start timer on phone when the preeinfusion pump kicks in, tap lap and release button at ~5s, watch timer and scale aiming for vicinity of 32g/30s. Grunt and adjust the grinder in the appropriate direction if it's not close.

Stir espresso, taste, add a little milk while I make my breakfast food if needed.

Consume espresso and breakfast.

Come back to to put away the glass, dump the puck (no 3-way valve, it'll sneeze at you if you don't wait a second), and rinse the portafilter. Place it upside down on the base to dry.

The setup is a recent upgrade so I'm still pretty pleased and working on refining my technique. I've been trying different beans (mostly espresso blends from local roasters, but also some weird stuff just for fun).

I actually stopped because I realized I'd missed some important early-game stuff that was making it frustrating to continue. Not a softlock, just a pain in the ass and/or long trek back.
The environment and exploration are amazing and the uh... things left behind by the alien children... are supremely unsettling.

S9

I'm still using my S9. Size is about as big as I want to deal with. Indicator LED is great. 3.5mm jack is great. SD socket for local storage. Camera is still fine. Qi charging is one of the few gimmicks that hasn't turned out to be useless. Screen is drastic overkill. Design is a stupid friction-less glass egg, but that's easily fixable with a minimalist case. Performance is still perfectly adequate.

It's long out of support, but I'm finding the market wildly un-compelling, and will probably just roll with it until something renders it unusable.

I never did finish it, but The Solus Project is, I'm pretty sure, exactly what you're asking for. 2017 first person exploration game, very environmental, set on a subtly creepy and somewhat confusing alien world. I got a copy in my Steam library...somehow that was cheap enough I don't remember and played a big chunk of it a couple years ago.

Less action than the Half Life/Unreal/Marathon alien horror FPS lineage, but similar feel.

Now days they're almost all flavored coconut oil.

Which, as someone who is rather allergic to coconut, is annoying, because I have to assume I'll have an issue with any not-actually-milk coffee cream product.

Land O Lakes Mini Moos are shelf-stable actual milk products and I keep some in my desk. Essentially all the rest of the shelf stable products, liquid or powder, have converted to coconut based. I don't know if the economics have changed, or if it's because they don't have to say "Hydrogenated" if its hydrogenated right from the plant.

Played any Beyond All Reason? (or it's predecessor Balanced Annihilation on Spring)

I played a lot of TA in the 90s and early 2000s, and I think its a better successor in many regards than Supcom or Planetary Annihilation.

For the most part, I'd rather have native packages. I'm not deeply philosophically opposed to secondary packaging systems, and only mildly opposed to "ship the whole dependency tree in an archive" software distribution methods (lookin' at you NextStep/OS X style bundles), and see their potential especially on platforms with no/bad native package managers or to bring in specific software that would pose a compatibility problem for the host system... but they never seem to work nearly as well as native packages, and the two big players on Linux have problems.

As far as I'm concerned, they're just taking the old last-ditch practice of "I have this piece of recalcitrant software that is incompatible with the rest of my system, so I'll throw it in /opt with its entire dependency tree," replacing opt with a bunch of bind mounts, and doing so with varying degrees of additional tooling.

The sandboxing is a nice idea, but it seems like in practice the models on both snap and flatpack are simultaneously restrictive in ways that make them annoying-to-unusable for many tasks, and too sloppy to provide reliable security guarantees.

They make debugging problems harder because you can't check functionality from another program because they likely don't share libs. ldd is a lot easier than spelunking around with eg. flatpak list --app --columns=application,runtime until you find a "peer" to test.

If I need a one-off piece of software that is a compatibility nuisance on my host distro (but not so much of a nuisance it needs to go in a container or VM, which is a pretty narrow window), I'll usually reach for an AppImage because unlike the other two, they're actually fairly standalone and don't involve a big invasive runtime/tooling system.

The Immutable-core OSes that depend on them are kind of the same way at the moment. Fundamentally a pretty neat idea, but so far I find them super frustrating in practice. Nix is ...different... to work with, but is likely a more elegant scheme to solve the same class of problems.

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.

My usual suggestion: Get a generation-old business or workstation class machine from one of the major manufacturers, as a refurb. Mostly meaning keep an eye on Dell Refurbished or Lenovo Outlet - sometimes you can also get a deal on a refurb via woot - for something that appeals to you. The stock is always changing at those, and there are almost always sales/coupons for around 40% off at the first-party refurb stores, so +/- a week of patience can save you a bunch of money.

Business or workstation class machines (think Dell Latitude or Precision, especially the ones with models that start with a 7, or Thinkpad) are typically mechanically much better built than their consumer counterparts, and usually full of reputable components that are connected in standard ways - low end consumer stuff sometimes has issues where they got weird less-common components or connected things in stupid ways to save a few cents per unit that will cause driver issues.

Waiting a generation gives time for mainline kernel driver support to fully mature to minimize driver problems, and drastically cuts the price.

I've had several machines following that advice, and I think the only driver trouble I've had with them has been with unsupported fingerprint/smartcard readers, which I ...don't care about anyway.

Or, if you want a way cheap beater and don't mind some hackin', grab a used/refurbished AUE Chromebook that is on the Mr. Chromebox Supported List. AUE means they no longer receive ChromeOS updates, so their price craters to like $50, and you can flash a normal UEFI payload and use them as a (feeble, storage starved, low resolution) computer. Not a good main machine, but they make fun beaters for experimenting. There are often batches of them being dumped via woot.

...also, don't buy anything with an Nvidia GPU unless you have a specific compelling reason, it'll be a pain in your ass for the life of the machine.