• 0 Posts
  • 19 Comments
Joined 1 year ago
cake
Cake day: August 31st, 2025

help-circle

  • That never seems to work with wine

    Wine has nothing to do with double clicking. You can set up your desktop environment to do this if you want. Wine requires environments to run apps (aka wine prefixes), and the way I do it is I reuse one environment as much as I can.

    Nowadays, I just reuse the wine prefixes Heroic creates, since it usually installs a good chunk of dependencies. Lazy, but it works and saves disk space.





  • I’m a programmer with pretty bad astigmatism, and didn’t go to an eye doctor until my late twenties. I had never worn glasses before that, and had no idea how fucked my vision was.

    Yet, I still have no problem writing code in dark mode without glasses. Even though the text is blurry, I’ve gotten used to it. I squint a lot, and idk if there are any negative consequences from doing that, but glasses tend to tire out my eyes faster, so I sometimes prefer the blurriness.


  • Lol I had the same procedure and sat in my car after calling someone to come pick me up, but they took too long and I decided to just drive myself anyways. I couldn’t read signs, but traffic lights and other cars were visible enough. I bet there are a lot of old people on the road driving around regularly with eyesight that bad or worse.




  • This doesn’t appear optimal. The correct way to melt a CPU is to make use of as many functional units as possible in parallel, while avoiding pipeline stalls and cache misses. I’m not a Rust guy, but skimming through the code it seems like the only work it’s doing is some integer math, so it’s not even touching the FPUs. Also I see while running.load(Ordering::SeqCst). Idk if Rust’s memory model is similar to C++, but does that mean it’s using atomic operations? That’s going to create a lot of unnecessary cache coherency traffic that works against the goal of melting. Each thread should have its own counter not shared with other threads, and it should only spawn enough threads for the number of physical cores (not logical cores) on the system, and ideally pin each thread to a single core to prevent the OS from acting like a firefighter.

    The gpu parts I’m not sure about. There’s might be some special consideration required when dealing with integrated graphics though.



  • CouchDB (a no-sql db, but whatever) automatically provides a REST API that’s designed to be exposed directly to clients. It even implements its own client-facing authentication system. “queries” are configured in advance from the admin side, and clients just pull the results, allowing for very efficient caching. Basically, if you RTFM enough to get a couchdb instance running, you have 90%-100% of your backend complete. You could create an entire scalable full-stack app using only client-side code… and if you’re clever with HTMX, you might even be able to do it without writing any javascript at all! (I tried once, but failed because I’m not that clever, but it’s definitely probably possible)

    So TL;DR: I like couchdb, and the idea of exposing your database directly to users isn’t unprecedented. I wonder if there are any SQL databases that offer a similar thing?








  • This non-sarcastically. The operating system is better at cleaning up memory than you, and it’s completely pointless to free all your allocations if you’re about to exit the program. For certain workloads, it can lead to cleaner, less buggy code to not free anything.

    It’s important to know the difference between a “memory leak” and unfreed memory. A leak refers to memory that cannot be freed because you lost track of the address to it. Leaks are only really a problem if the amount of leaked memory is unbounded or huge. Every scenario is different.

    Of course, that’s not an excuse to be sloppy with memory management. You should only ever fail to free memory intentionally.