Not enough plaid skirt IMO

Old thin clients and mini PCs are great for this. Many either have a half sized PCIe slot or can take a second network interface using the WiFi m.2 slot and a 3d printed bracket to mount the nic port.

You’re best off splitting the routing and WiFi tasks into separate hardware. Buy yourself a used ruckus unleashed r550/650 or r510/610 depending on how much you want to spend for wifi then run routing on whatever hardware is fit for purpose. I usually slap OPNsense on something like a dell/wyse 5070 j5005 mini PC, any mini PC with a PCIe slot will allow you to build a 1/2.5/10GbE router with open software. Chinese N100 router boxes are cheap now too, or you could reuse an old mini PC of some kind.

I don’t like rolling my own router using arm boards anymore, router distro support for them is unreliable and j5005 pulls <10W anyway.

When you’re coming from a position of extreme privilege and you’re either a bit stupid or lack empathy or general social awareness being treated equally with “lesser people” (like women, brown people or people from particular religious backgrounds) can seem an awful lot like you’re being discriminated against.

Not as badly as you’d expect, modern compression is pretty quick using the lz*'s and you’re only expending cycles when you’re hitting swap

We joke but zram swap works wonders on low resource systems sometimes

Ah, gotcha. It’s just difficult to figure out what this does if you’re not already neck deep in configuring status bar JSON

Screenshots showing what this does in action would help a lot

Yeah, that was my thinking too. Lilac is a generic enough platform that OEMs can do the bulk of their platform work with a lilac dev kit before they have real hardware in hand for the last 10%.

Valve hasn’t even announced their own steam machine yet have they? I’d be betting on ASUS to be first to market with whatever’s in the pipe from OEMs.

Lilac is an AMD dev platform, it’s used to do early development before you have the real platform in hand to work with. It’s been spotted in the wild running 7700 HS, 8500 U and Zen3 embedded <55W SoCs - there’s no way to extrapolate new steam hardware performance info from this reliably.

The scientific community would just collapse and we’d be worshipping cats as a world wide religion.

You’re a couple thousand years late on this one

Better to figure this out late than never I guess. Wasn’t this obvious 10+y ago though? Facebook has always been a predatory propaganda firehose.

I miss windows eating my work when it chooses to install updates and reboot automatically while I’m asleep

Edit: even after I’ve set registry flags and policies to “never automatically reboot” - it’s always fun losing 4 days of work because windows randomly says “fuck you”

I’m not sure how to get the N from session history, nor how to check my session history…

journalctl --list-boots will list all sessions stored in the journal.

The output is from yesterday, when the device stopped working correctly.

I’m not familiar with linux kernel, but I can see there is definitely something wrong…

The HDD (old) is attached to a USB hub (new), I tried switching port of the hub but the same issue happened again, if I try to mount it with sudo mount /mnt/2tb, it says it is already mounted:

Those messages tell you what’s happening, there’s an unrecoverable error on the USB bus connecting the hard drive which is causing filesystem errors when writes fail. Diagnose that, lose the hub first and directly connect the drive to the pi, then try replacing the cable that attaches the drive if the error still occurs. I’d also check with people in the rpi community in case there are any known issues with USB on your model. There may be some pi specific USB firmware things you can do to increase reliability.

You can also try disabling UASP for the drive in case BOT transfer somehow stabilizes the connection. You’ll lose performance but that helps with some USB storage bridges.

Some USB storage bridges are just unreliable under Linux and crash under load, your last option is to buy another drive enclosure that’s tested and known to work correctly. I went through like 5 USB/NVMe enclosures looking for one that worked properly, that whole space is a compatibility mess.

I know right, I can’t handle another round of disappointment

When he started pushing his own tweets and Republican influencers to the top of my feed I quit the same day

Don’t just look at sdb hits in the log. Open up that entire session in journalctl kernel mode (journalctl -k -bN where N is the session number in session history) and find the context surrounding the drive dropping and reconnecting.

You’ll probably find that something caused a USB bus reset or a similar event before the drive dropped and reconnected. if you find nothing like that try switching power supplies for the HDD and/or switching USB ports until you can move the drive to a different USB root port. Use lsusb -t and swap ports until the drive is attached beneath a different root port. You might have a neighboring USB device attached to the bus that’s causing issues for other devices attached to the same root port (it happens, USB devices or drivers sometimes behave badly.)

Always look at the context of the event when you’re troubleshooting a failure like this, don’t just drill down on the device messages. Most of the time the real cause of the issue preceded the symptom by a bit of time.

200% markup doesn’t matter when you’re billing it straight to the client anyway 🍻

They’ve done it more than once now

Whatever they can get their hands on, including your unique hardware identifiers