PAPPP

Sure, drop me a note with the details and I’ll see if I can give you a hand. I’m not super expert in all the specifics of the Chromebook ecosystem, but I have good general computer/Unix skills and have hacked a couple so I know where to look for resources.

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.

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.

Since you’ve used both, what are your feelings on FreshRSS vs. tt-rss?

Around the death of google reader, I set up a tt-rss instance, imported all my saved stuff, and I’ve been using it continuously since (I’m technically in an unsupported configuration because I set it up long before docker became the preferred then only supported configuration, but it just keeps ticking installed like a normal piece of software on a rented VM).
I’m generally super pleased, and it’s my primary mode of content consumption via browser + Android App, and I use the “note” and “share with note” features pretty extensively to plumb to some other folks with similar setups.

Fox (the main tt-rss dev) is clearly an asshole, and there are some geopolitical complications because he’s a Russian national, but he’s made an excellent focused piece of software. I’ve considered looking seriously in to FreshRSS, but have a lot of inertia and at a glance it looks like it’s missing a few features.

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.