fps-hero

> In fact to my knowledge, student-led revolutions have never produced a long term positive outcome. Any examples?

Huh, now that you mention it, what is actually going on with the “cockroach movement” in India? It seems like you only ever find out about the driving force behind a movement 5 years after the fact when all the truth is laid bare, for better or worse.

> No LLMs for finding bugs.

If an LLM finds a bug in some code, but you fail to report it because of a project's code of conduct regarding AI, does the bug even exist at all?

If you find a bug in some code, and use AI to help you find the fix, are you allowed to submit the fix? Or should you just let them "figure it out".

I'm sorry, but I can't take stances like this seriously. Policies like this are unhelpful. This reeks of the academic knee-jerk reaction of ban AI, without considering the reality that yes, students continue to use AI, even if you tell them not to. AI should be used responsibly. Ban the behaviour you don't want, don't ban the technology.

There is something about the gamification of social interaction which breeds a hostile community. Power hungry users chasing internet points, or moderators needlessly raising their hammer.

I am not going to miss Stack Overflow. "Question already asked" for some hyper specific question where this is the first google result. "Not enough status" to do x/y/z (sorry, can't answer that unanswered question!), out of date answers, wrong answers being accepted as right, a right answer left high and dry.

I think anyone who has had to make a dense UI work on mobile has felt the allure of using icons as a substitute for text. It’s practically encouraged by the material guidelines.

You will spend weeks/months (sigh, years) agonising over the six icons you can lay horizontally over a bottom toolbar in a mobile layout, only to sit down and guide a user a user through your UI and realise how monumental stupid and unfriendly your UI is.

I was guiding my boss through some features “ok, just click the view you want in the bottom toolbar”, “um? Which button do I click for a forward view?”. This is someone who knew our product capabilities inside out and helped debug users on a daily basis. I felt even stupider having to geometrically describe the details of the icon, realising how stupid of a UX this was, just to continue with the demo.

I scrapped the entire thing for a textual status toolbar that when you click brings up a drawer with every option in plain English. The only icons were a tickbox next to the currently selected item in a drop down menu. News flash, turns out people can read, and much faster than they can interpret abstract icons.

The next time I did a demo, not only did I feel the immense relief not having to sweat over “describing what icon to click”, didn’t have to worry about flicking through icon catalogs to find the “perfect, vaguely connected icon to the idea I’m trying to convey”.

Turns out VIM was right all along, model UI is king. Don’t get me wrong, 20 years of mobile UI has beaten some visual language into is, but it is no substitute for actual language.

There are some novel ideas in here worth appreciating. The classic “time scramble” is absolutely worth considering, even in top level human play.

It seems strange that even with fairly abundant datasets such as Lichess, that it is still difficult to approximate human strength with a bot.

As a “low strength human”, it’s very easy to see how traditional chess engines fail to emulate humans.

As far as actual calculation look ahead goes, humans aren’t calculating to chess engine depth. How often is a human really considering every possible move to greater than a 3 move depth?

Humans are moving with instinct. We cull the decision tree based on our evaluation of how promising a branch may be, not its objective calculated strength. This is where the chess engines break down.

Humans rely on instinct, pattern recognition, and strategy. None of this translates to a chess engine unless you are a top level player with near perfect instincts and pattern recognition.

My hunch is that for approximately human strength, the lowest ELO human makes moves completely at random, where the highest ELO human with follow the brute forced top lines. The challenge is tweaking the decision tree to match human evaluation of a branch based on skill level, and a second conditional probability of selecting a branch based on the player’s ELO.

The output of the chess engine shouldn’t be deterministic, but probabilistic. History has shown when you take a probabilistic approach to a problem, normally magic falls out. I’m yet to see a probabilistic chess engine.

It’s the insane having these discussions in 2026 given samba issues have been a thing as long I’ve been using OSX/macOS. Mixed windows/mac network shares have always been a PITA.

WebGL2 already has a compatibility layer to make it work on macOS. macOS is stuck on the 2010 vintage OpenGL 4.1 which predates even OpenGL ES 3.x on which WebGL2 is based. They use the ANGLE (Almost Native Graphics Layer Engine) from the Android project with a metal based backend.

Which kind of hints towards the fact that they could definitely have supported OpenGL in a way that project like MoltenVK work. The OpenGL standard is frozen in time, last update was in 2017. It's not too late.

The decision not so support modern OpenGL is why so much engineering/3D/CAD/gaming software is suck on the windows platform. There is no true cross-platform graphics standard anymore. WebGPU might be our last hope.

One thing often missed in these conversations is energy storage is not equal to generation capacity. To get solar to power a full 24 hour cycle, you need 2x the installed capacity compared to a "traditional" generator. One part for the daytime baseload, one part to charge batteries for storage at night. And realistically with seasonal/weather variations, probably far greater than that again.

So saying that solar has caught up with nuclear, well that's great, but it's a long way off where it needs to be, and energy storage is even further off again.

At least in Australia, the solar + battery combo has become realisically genuinely competitive against energy costs from the grid for domestic use. At commercial scale, there is still a long way to go.

That’s one way to avoid use after free bugs!

Most of my initial foray in programming was on microcontrollers, of which dynamic memory allocation came late.

Atmel ATMega didn’t support it at all. Rabbits supported allocation but not freeing, so, static memory with extra steps. It wasn’t until I was using cortex’s that the idea of using malloc was even entertained.

Even still today, I pretty much stuck with static global with reference passing or allocate everything at initialisation time. It’s a surprisingly robust strategy.

> My first stab at a UX render usually sucks too, it’s the iteration that brings perfection

With AI, your iteration cycle gets 10x/100x quicker. For the same developer effort, you can effectively try out 10s of ideas the same period of time.

Iteration also has a human component. When a person works hard and writes the code, they are personally invested in its success. So iteration, or, chucking out someone’s hard work is psychologically damaging and causes human conflicts in teams. If AI wrote it, and AI deleted it, no-one gets upset. All that matters are good ideas. Reducing the human cost of iteration is just as important as the time saving.

And, now you have freed up implementation time, you now have way more time for testing, that thing that everyone wished they had more time to do, with a super intelligent 100x developer (ai) as your coding partner, and a 100x lever for automating regression testing. Bad UX has zero excuses.

Anacdote, I have a friend who is a locksmith. I needed his services one day, gave him a call, and it turned out his day job had evolved since I last talked to him 5 years ago.

Basically, he was now just a safe cracker. He is a a locksmith, but 100% of his full time hours are cracking safes. He didn’t even carry around the stuff in his van to repin a lock. He gave me mates rates but the shop had to do it.

This man was attending multiple callouts, per day, to crack into a safe. Because of, you guessed it, human fallibility.

In a city with with millions of people, basically a hundreds of people needed a single locksmiths service because they had locked themselves out of there own “personal store of wealth”.

I’ve heard zero such examples through traditional banking, with the exception of stolen cards.

I’m not saying they are perfect, but on aggregate they are better than hardware wallets. Legally they will be responsible if your money is lost. They are about as close as you can get to the type of legal assurances provided by a bank.

> Needing to typedef a unique struct for every possible function return type isn't very ergonomic, but you can work around that with C23:

I think you’ve unraveled the mystery of why that didn’t catch on in nearly 40 years of C.

Honestly it’s got to be the biggest disappointment in computer science that nothing has displaced C as the Franca Lingua. And now with the advent of AI, I don’t think anyone is going to care anymore. Rust will be the future, but not because it’s ergonomic, but because it can prevent memory errors.

Banks and payment providers (Visa Mastercard AMX) provide services beyond simply a store of wealth and a mechanism to transfer it.

Actually 2FA, hardware biometrics, behaviour based fraud prevention and personal confirmation of suspicious transactions. If you’re using credit they can refund fraudulent transactions, and there is the chargeback mechanism. This is probably banking system dependent, but in AUS there is a refund mechanism for mistaken/fraudulent traditional bank transactions.

BTC has effectively none of the safety net, and humans are fallible. We need the safety net. It’s the hugest barrier to adoption. Exchanges do a far better job of managing the risks than trusting your wealth to a hardware wallet.

Man, the netbooks were amazing for their time, but even by 2008 standards, they were not powerful computers.

At the time you needed a fairly capable gaming PC for PS2 emulation, which is a far cry from the igpu in an atom. Given a PSP is basically a cut down PS2, I don’t think emulation on that calibre hardware is an achievable goal. An atom doesn’t even have a hardware programmable vertex shaders, on windows I don’t even think they had GL 2.1.

I never thought I’d see the day where an atom would be vintage tech, and people would still be rocking said vintage tech. It’s amazing you’ve kept it running and usable. Modern PCs can’t even keep up with modern OS, and you’re still rocking the good old days of single core single thread. Rock on!