Recent submissions

Comment · 2 months ago
I propose “sloptimizing”
Comment · 2 years ago
Tell me you don’t ski in New England without telling me you don’t ski in New England.
Comment · 3 years ago
I have the same issue, seemingly, with my 2017 Outback. My battery kept dying for which I got a lot of run around from the dealer (gaslighting about keyless entry drains it if the key is too close to the car, etc.) Eventually I found a Reddit post about the DCM (Starlink) module, removed this fuse, and it hasn't died since. It sounds like it wakes up in the middle of the night to do something and thereby drains the battery, so whenever they test at the dealer for extra drain, they find nothing. Having that fuse out kills some speakers and the mic too, so it's a kind of annoying solution. I have not gone back to complain again recently though, so maybe they can do whatever it is they did for you. I saw some posts about wiring it to another circuit that's off when the car is off, but I am not confident doing that myself.
Comment · 3 years ago
I spent three summers sorting QSL cards at the outgoing bureau (between giving tours) at the ARRL. It perhaps wasn’t so much “magical” as tedious, but it was a pretty cool job as a high school-aged ham. I even got my own ARRL staff QSL cards which was pretty sweet. I probably still have some in a box somewhere.

I too haven’t been active in a long time, but do think about getting back into it now and again as well.

Comment · 3 years ago
Looks like that’s the max weight for any package.
Comment · 3 years ago
Comment · 5 years ago
Comment · 7 years ago
Comment · 7 years ago
Comment · 7 years ago
IMO as someone who works on games, developers will come along with high quality Linux builds when there are a significant number of users that demand it. I think anyone who's doing a Linux port now is doing it out of the goodness of their hearts and not as an economic decision. It doesn't matter if you're using an engine that already supports Linux, it's still extra work to develop and test, and it's still more support issues that (in the current market) you are very unlikely to make back in additional sales. I'm certain most Linux gamers also have Windows installs, so while they might complain about having to dual-boot, they still do it.

If Proton bridges the gap to the point where people are 1) more willing to be on Linux and 2) less willing to deal with dual-booting for the few games that don't work without it, then maybe the number of Linux-exclusive gamers will grow. That's when you'd see significant attention paid to proper Linux builds. (There are of course other impediments to people switching over to Linux full-time besides games support, so I don't think the Year of Desktop Linux is quite imminent yet.)

Comment · 8 years ago
Beers on "nitro" are still carbonated with CO2. The nitro is used to achieve a higher serving pressure used to force it through a diffusing nozzle on the tap. N2 doesn't actually dissolve in liquid very easily compared to CO2. If you put the CO2 at higher pressure, it makes the beer more carbonated over time.
Comment · 8 years ago
You can run your updates faster than the slowest ping. You just need more command latency. So when you, say, command a unit to move somewhere, there's an agreed-upon future time when that's going to happen. This time has to be longer than it takes for the command to get to everyone. If it's not, then you stall. If command latency is very high, the game feels very unresponsive though (and tricks of showing local/visual-only confirmation of your commands only goes so far).

You can't run updates any faster than the slowest machine can run them, though, or again you stall. This was a bigger problem on Age 1 and 2 where render rate and update rate were linked. On Age of Mythology and beyond, the render rate was decoupled from the update rate, so updates could happen more slowly while animations and so forth could still look smooth via interpolation.

Comment · 8 years ago
We got way better at dealing with synced/deterministic simulations over time. Much better sync logging system, decoupling render rate from simulation rate, more institutional knowledge/intuition about all the surefire ways to break determinism (using unsynced random number generator, uninitialized variables, reading local machine state from sim, using local timers rather than synced ones, not resetting floating point flags after calling Direct3D, etc). The bad news was once we were generally avoiding all the common causes as a matter of course, the sync bugs that remained were non-trivial ones that took lots of time to diagnose.
Comment · 8 years ago

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton