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”

“Credible exit” is just the twitterati huffing their own farts. Bluesky has exactly the same monetization problems twitter did and any other ultimate result beyond selling the company off to the highest bidder is fantasy.

Eventually, sooner or later, bluesky will fatten a nice crop of highly engaged users and sell the platform to someone with a better plan to monetize all of those eyeballs. The only real question is who? Will it be fElon Musk? Will it be ZuckerBot? Will it be some other billionaire who wants to own their own left leaning Twitter clone so they can monetize all those professional eyeballs with greater than average disposable income? Keep using the platform to find out!

Stares in local duopoly

And the bootloader unlock keys need to be posted so these devices aren’t just landfill fodder

Stares at Google OnHubs

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.

Bluesky has exactly the same monetization and profitability issues twitter did, if anyone tries to tell you differently they’re lying. Sooner or later Bluesky will fatten a sufficient crop of highly engaged users and run out of venture capital runway and be forced to look for someone to buy the platform. There’s no way around this.

Manjaro manages to do just about everything wrong for one reason or another. They’re trying to be the Canonical of the Arch ecosystem and they’re not even close to competent enough to pull it off.

I’m sure they’ll find some way to DDOS something with their own telemetry sooner or later.

Anyone want to place bets on how much of their “AI” medical advice was just medical students and low cost doctors overseas answering questions?

The compile times are abusive on older hardware for sure

That’s almost as good as this one I got months back

It’s not that hard, just read the install guides and instructions. My first Arch install was like 8y ago and I expected it to be difficult - it wasn’t.

Friends don’t let friends use Manjaro

Use EndeavourOS or another Arch derivative instead.

You didn’t do that a couple of years ago when Musk decided to push his own posts and right wing content to the top of everyone’s feed? I dropped twatter that same day.

Mastodon works well, tell your twatter refugee friends.

I read this as preparation for round two of the USA’s China tariff boogaloo

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.

They’ve done it more than once now

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

Friends don’t let friends use Manjaro

They’ll find some way to make this change break the AUR again