e0qdk

joined 2 years ago
[–] e0qdk@reddthat.com 6 points 20 hours ago (3 children)

Generally the professor in charge of the research group.

[–] e0qdk@reddthat.com 4 points 20 hours ago (1 children)

Going back even older... Mysterious Cities of Gold. That's never been remade or adapted...

They actually resumed the story directly in a sequel series in 2012: https://en.wikipedia.org/wiki/The_Mysterious_Cities_of_Gold_(2012_TV_series)

[–] e0qdk@reddthat.com 3 points 1 day ago

Is BotBall still a thing? They had that (waaay) back when I was in high school, at least.

[–] e0qdk@reddthat.com 8 points 2 days ago (1 children)

Congrats. I groaned IRL.

[–] e0qdk@reddthat.com 27 points 4 days ago (2 children)

Hmm. So... how long do you think before we start seeing news stories about their DRM servers getting hit with DDOS attacks (or other network fuckery) and no one being able to play their PS4/PS5 games? 😛️

[–] e0qdk@reddthat.com 7 points 5 days ago

Better out-of-the-box text-to-speech voices would be very welcome. The defaults are pretty painfully robotic... (Try spd-say "Hello world" if you don't know what I mean.)

Trivial to use on-device dictation software could also be useful.

The capabilities of models like qwen3.6 to do things like on-device image analysis are pretty incredible if you have hardware capable of running it -- I've run it on a Framework Desktop -- but I have no desire to expose my systems directly to AI agents. That's just asking for trouble... If an AI agent can fuck up, it will fuck up eventually, and I'd rather it not have the ability to delete my files when it does.

[–] e0qdk@reddthat.com 5 points 1 week ago

Probably hundreds of millions or billions if you include things like washing machines, dish washers, automated gates, garage openers, etc. that automate specific tasks. Just the read/write arms in hard disks alone is probably a staggeringly huge number, if we're counting things like that...

[–] e0qdk@reddthat.com 5 points 1 week ago

Based on what I see on my Steam Deck (not sure on Bazzite specifics), it looks like the WINE prefixes are stored in ~/.local/share/Steam/steamapps/compatdata

I think the number in each folder name is the game's steam ID, which makes it a bit cryptic. You can probably find that ID by running grep -i "name of game" *.acf in the steamapps folder. The files are named like appmanifest_STEAMID.acf, if I understand how this works correctly. You might also just be able to search for the file you're looking for directly though if you know what the name is inside the prefix and it's distinct enough.

[–] e0qdk@reddthat.com 8 points 1 week ago

Glad you got outside and were able to get things sorted out without too much trouble! Having gone from "complete shut-in" back to "goes outside at least once in a while" myself, I will say it gets easier the more you do it.

[–] e0qdk@reddthat.com 4 points 1 week ago

Not really. I'm just in kind of a snarky mood. 😛️

[–] e0qdk@reddthat.com 9 points 1 week ago (3 children)

So, my taxes are paying for this, huh? Do I get to watch the movie for free then? 🤨️

[–] e0qdk@reddthat.com 3 points 1 week ago

At this point, it's been down long enough that setting up a Unix Surrealism community somewhere else is reasonable, IMO.

 

I had some free time this weekend and I've spent some of it trying to learn Go since mlmym seems to be unmaintained and I'd like to try to fix some issues in it. I ran into a stumbling block that took a while to solve and which I had trouble finding relevant search results for. I've got it solved now, but felt like writing this up in case it helps anyone else out.

When running most go commands I tried (e.g. go mod init example/hello or go run hello.go or even something as seemingly innocuous as go doc cmd/compile when a go.mod file exists) the command would hang for a rather long time. In most cases, that was about 20~30 seconds, but in one case -- trying to get it to output the docs about the compile tool -- it took 1 minute and 15 seconds! This was on a relatively fresh Linux Mint install on old, but fairly decent hardware using golang-1.23 (installed from apt).

After the long wait, it would print out go: RLock go.mod: no locks available -- and might or might not do anything else depending on the command. (I did get documentation out after the 1min+ wait, for example.)

Now, there's no good reason I could think of why printing out some documentation or running Hello World should take that long, so I tried looking at what was going on with strace --relative-timestamps go run hello.go > trace.txt 2>&1 and found this in the output file:

0.000045 flock(3, LOCK_SH)         = -1 ENOLCK (No locks available)
25.059805 clock_gettime(CLOCK_MONOTONIC, {tv_sec=3691, tv_nsec=443533733}) = 0

It was hanging on flock for 25 seconds (before calling clock_gettime).

The directory I was running in was from an NFS mount which was using NFSv3 unintentionally. File locking does not work on NFSv3 out of the box. In my case, changing the configuration to allow it to use NFSv4 was the fix I needed. After making the change a clean Hello World build takes ~5 seconds -- and a fraction of a second with cache.

After solving it, I've found out that there are some issues related to this open already (with a different error message -- cmd/go: "RLock …: Function not implemented") and a reply on an old StackOverflow about a similiar issue from one of the developers encouraging people to file a new issue if they can't find a workaround (like I did). For future reference, those links are:

view more: next ›