In the readme: if you want this program to be usable, press the turbo button until the turbo light is OFF.

I gave him a dollar so he’d go away.

On the other hand, we’re currently in the midst of what many people already consider to be an AI bubble, so investing in new DRAM factories might be considered too risky, since the bubble might have popped before it even gets production going.

I’m glad I opted to start at 64GB ram on the PC I built about a year ago. Compared to the other parts like CPU and GPU, it felt relatively cheap to bump it up from 32GB.

Wondering if I should pull the trigger on more storage though… Don’t really need it right now but eventually I’ll probably need some.

Yeah, who the hell associates macs with higher competence? Before the 00s, I associated mac users with stumbling on the worse option but not realizing it, after the 00s, wanting to follow trends and/or overpay for hardware to seem rich. They’ve always been form over function, and simplicity over power, which are things that novice uses look for, not more experienced ones.

Or maybe more experienced ones when most of those experiences went badly and little was learned.

Github copilot can do some impressive things, but it also ignores my instructions to not try to run anything and leave testing to me that I’ve stopped bothering saying it and just block the attempt when it asks permission. Just yesterday, it confidently said it had figured out an issue I was debugging with it and made a bunch of code changes that literally only affected comments. If I leave it in agent mode (which allows it to edit code) when asking a question to clarify something and not intending any code changes but wanting to think about the answer (and telling it that), sometimes it still runs ahead and tries to make changes anyways.

When it does well, it’s uncanny how effective it can be these days, but it’s not reliable enough to be trusted to be in control of the whole system. Plus I don’t trust Microsoft enough to put my data on onedrive, and believe that access to data is the real reason behind their AI push, no matter how much usefulness and reliability improves.

So going forward, social engineering will also be applicable to some computers themselves instead of just the users.

I had an A5 a while back and samsung didn’t make me hate them so the next phone I got was an s10. On that phone, they decided that they needed to dedicate a physical button to their fucking virtual assistant bixby. It was pretty obvious to me that these virtual assistants were mostly actually data vacuums, wanting to integrate into every aspect of your life so they can access better data on all those aspects.

Every single time it opened that fucking thing, it was unintentional. It wasn’t as annoying as your TV, since I bet the phone was way faster and had enough memory to not have to discard whatever else you were doing just to open its app, but it exemplifies how I see samsung today. Hardware had great specs but the software made it annoying by trying to lock everything in to their ecosystem without a hard lock like apple. Even MS had ways of disabling the windows button (which used to have a high chance of crashing a game if you accidentally hit it).

Same kind of people who lie all the time to look good to others. Some people want to be awesome but know they suck, or even more pathetic don’t suck but can’t stand not being the best, and cheating is their pathway to getting the social results of being awesome without needing to develop the skills.

The way I’ve seen it for ages now, being a loser isn’t just about losing games, it’s how you handle losing games and how much you internalize that. I see it as short for “sore loser”. Cheaters are losers in that sense.

Though it makes the idea of them still losing despite cheating even more hilarious, which is why I love the idea of games that detect cheaters but stick them in cheating queues instead of just banning them.

There’s another whole category that also doesn’t care about what the game is running on the kernel: seperate device cheats. They act as a man in the middle for the input and output signals, and can auto shoot when you’ll hit or adjust your aim if you’re close but not quite there. Or just play for you entirely if it’s that good at processing the output.

And blocking that isn’t likely possible without killing streaming for the game or convincing all users to get input devices with encrypted connections or they can’t play your game.

I’d respond to the original comment that anyone who doesn’t have server side cheat detection isn’t serious about stopping cheaters. In any case, I just removed that game from my wishlist. Not that I needed another survival builder game anyways, though they do tend to catch my eye.

Windows 10 had a better kernel than 7. Unfortunately, that kernel was packaged with the rest of windows 10.

One has a function that takes the next node as an argument, another just sets that up in a loop. Personally, I found the loop one a bit easier to visualize and debug via stepping through code, though admittedly the difference isn’t huge.

At one point I developed a habit of converting any recursive algorithm I was writing into a loop instead, since I knew function calls have overhead and all recursion really does is lets you use the calling stack and flow control as an invisible data structure.

Then I got a question about parsing brackets properly during an interview and wrote a loop-based parser to solve it and the guy had to fish for a bit before I remembered recursion and realized that’s the answer he was looking for. My mind just wouldn’t consider using a whole calling stack when an integer would do the trick faster.

Steam is the reason I was able to get away from windows without having to give up a lot of games (and probably would need to do annoying troubleshooting for the ones that do work, since most of the compatibility issues I have seen were because the game tried to run natively instead of via proton).

Maybe they tried to target only senior managers but were only 75% successful.

Also, the conflict of interest is apparent in the first 4 words of your quote, which explains why they picked such a weird study population.

I don’t think the bubble bursting will slow AI that much, it’ll just be a round of hot potatoe over, the losers will lose their money and others will come in hoping to be profitable since they can skip a bunch of R&D costs.

AI is overhyped, but just like the internet after the dotcom bubble burst, it’s not going anywhere.

Plus I suspect that this time will be a dollar collapse rather than stock market collapse, which would mean prices would go up even more.

They say that about the company that has <professional sports league> <insert next calendar year> which are even more forever games because (as I understand, not really a fan of sports games either way) the changes from year to year seem to mostly be rosters.

It looks like one exec thinking he’s dunking on another and will look cool hating the hated one, but from my pov it just looks like two of the asshole kids in the playground trying to one up the other, thinking the others egging them on are laughing with them instead of at them.

Also, EA made over a billion (non-GAAP) in FY2025 while Ubisoft lost $175 million (GAAP, so not completely apples to apples, but switching to non-GAAP won’t turn that loss into a profit, let alone 1 billion worth). Not that I like EA or anything, it’s just that they are doing a much better job of what ubisoft wants to do and don’t need edgy execs trying to dunk on companies they hope are more hated than they are.

That assumes SetTimeout() is O(1), but I suspect it is O(log(n)), making the algorithm O(n*log(n)), just like any other sort.

Did some looking into the specifics of SetTimeout() and while it uses a data structure with theoretical O(1) insertion, deletion, and execution (called a time wheel if you want to look it up), the actual complexity for deletion and execution is O(n/m) (if values get well distributed across the buckets, just O(n) if not) where m is the number of buckets used. For a lot of use cases you do get an effective O(1) for each step, but I don’t believe using it as a sorting engine would get the best case performance out of it. So in terms of just n (considering m is usually constant), it’ll be more like O(n²).

And it’s actually a bit worse than that because the algorithm isn’t just O(n/m) on execution. It needs to check each element of one bucket every tick of whatever bucket resolution it is using. So it’s actually non-trivially dependent on the wait time of the longest value. It’s still a constant multiplier so the big O notation still says O(n) (just for the check on all ticks), but it might be one of the most misleading O(n)'s I’ve ever seen.

Other timer implementations can do better for execute and delete, but then you lose that O(1) insertion and end up back at O(n*log(n)), but one that scales worse than tree sort because it is literally tree sort plus waiting for timeouts.

Oh and now, reading your comment again after reading about SetTimeout(), I see I misunderstood when I first read it and thought you meant it was almost as fast as bucket sort, but see now you meant it basically is bucket sort because of that SetTimeout() implementation. Bucket sort best case is O(n), worst case is O(n²), so I guess I can still do decent analysis lol.

Yeah, I can say that covers most of the “troubleshooting” I’ve had to do with games that don’t work. I usually go in thinking “uh oh, maybe it’s time for me to have to check a bunch of proton versions, this will be a pain” only to see that it’s trying to run it natively and switching to proton at all resolves any issues.

The only other thing that comes to mind is that I use dvorak and something about the way keyboard layouts are handled means it tries to “preserve” the bindings when I switch layouts in game, so it keeps the messed up QWERTY keys but dvorak layout even when I switch (and can tell it’s switched from typing things like in chat). Most games let me rebind the keys so I just need to go through the bindings, hitting the key currently bound each time as if I was using QWERTY and it rebinds. Though I suspect that due to the “preserve the layout” behaviour that keyboard input is handled specially by proton and maybe I can tweak settings to get the desired behaviour (ie, changing layouts in game means I want the bindings to change).

It is a translation layer, but the bit you added “to native code” sounds like you’re misunderstanding what translation layer means.

Games use a collection of APIs (DirectX is a set of APIs, but there’s others to handle offer operations like network access and such) to interact with OS functionality, and also receive communicarion back from the OS (the windows message loop). Proton and wine are implementations of those APIs that translate the API calls to their equivalent in linux, as well as setting up their own message loop that translates messages from the linux kernel and UI system into their windows equivalent before sending them to the registered windows messaging loop functions.

A simple example would be if a function header in windows looks like int32 SomeFuncWin( int64 index, char* name ), but looks like int32 SomeFuncLinux( std::string name, int64 index ), then the translation would be something like:

int32 SomeFuncWin( int64 index, char* name ) {
std:string TranslatedName( name );
return SomeFuncLinux( TranslatedName, index );
}

So it doesn’t change/translate any of the code of the program itself, it just provides the environment that behaves exactly like a windows environment by translating the “hey could the OS do this for me?” requests from windows to linux. Note that not all translations are that simple, there might need to be more processing on the values, missing arguments might need to be filled in, irrelevant arguments ignored, sometimes data needs to be translated to another format, etc.

The speed ups can come from improved efficiency in the underlying implementations (which Vulkan has, as I understand even using a translation layer from DX to Vulkan in windows can result in better performance) or having fewer services running in the background.