massive_bereavement @ massive_bereavement @fedia.io

Did you ever thought we will become what we are?

---

Read more

Posts

2

Comments

791

Joined

1 yr. ago

Well, what if they can command the exit door and help other passengers exit in an orderly manner? It would be a very tall and strong toddler.

I want to believe.

There should be a timer and if you take too long the "sonic running out of air" music should start playing.

Accessory to second-degree constipation.

I don't see any horse balls physics in your list.

Utterly unplayable.

Cartridge manufacturing and distribution was hella expensive back then and that took a big bite on any sales.

Digital storefronts do take as well their lion share though, but that's on sales.

For being a major pest, it is quite striking.

"The clown car"

Wow, Israelis are pretty chirpy for being in the middle of an ethnic cleansing.

Two birds with one stone, I see.

It remembers me to that Fry and Laurie bit: https://youtu.be/oy3iTVwJmxk (starts by 0:28)

Recommended by 9 out of 10 raccoons.

I'll say it happen when Musk got involved with production as he thought he will disrupt manufacturing by heavily relying in automation, disregarding what every manufacturing expert had told him that it ain't that easy.

He fumbled the ball hard and IMO that was the beginning of the end of Tesla's hegemony, where they started making serious quality mistakes and dropped finishing quality as well.

That said, I'm not sure if they ever had any to begin with, but for a while customers valued that brand very highly, even being on waiting lists for months.

To me, this was the Jets' Butt Fumble of car manufacturing.

Well paired with that salad then.

Are you sure this isn't a Ghibli-like forest spirit cat?

Let me check dmesg:

amdgpu 0000:03:00.0: amdgpu: failed to write reg 291c wait reg 292e

or

[46531.357889] amdgpu 0000:c5:00.0: [drm] ERROR lttpr_caps phy_repeater_cnt is 0xff, forcing it to 0x80.

Let me know if more examples are needed ;)

Bone hurting juice.

I gave a bit of a heads-up on a different thread, but the TLDR is that I use usb for the main disk and there's an issue with usb in the latest uboot for rk3328. I tried flashing the SPI to an early version but as soon as I would update a kernel to LTS, I would start having problems.

To be honest, I feel that this is a solvable issue, but also that I'm done trying to make these cards work on my own. (I wasted a lot of time and money fixing the eemc modules and the sockets).

At this point I reached a conclusion that I would use my selfhosting time to focus on software and networks, and just use reliable hardware, even if it means doing less and paying more, and leave soldering for my diy projects.

That said, the Rock64 pro sbcs I have are still going strong despite being used non-stop for the last 5-6 years.

Rock64s had several issues with emmc slots, however one way I had to circumvent it was flashing the SPI allowing me to boot from usb, following the official guide: https://github.com/ayufan-rock64/linux-build/blob/master/recipes/flash-spi.md

The issue here is that with the recent updates on u-boot, some older models have issues with old u-boot systems, and while I can flash again to the previous working SPI and u-boot, I can't make it work with the latest lts kernel.

Could it be solved? Sure, if I invest time solving the issue and compiling my own kernel version, I guess.

Is it worth it? My time is more limited than my money. I'll rather some cash on three rpi5 or similar, than wasting more time on a set of cards that have been failing on several things for the past five years. (lattepandas and rock 64 pro had no issue during the same amount of time)

At the end of the day, I like selfhosting services but I also like having free time :)

Thanks, that is one of my biggest concerns. Rpi5 is on my radar, despite the supply situation that often plagues rpies