One could get an iPhone 18 and an iPad Air for the same cost as this.

I wonder where in the training data does this behaviour exist that the LLMs are doing it.

It's as if the training data is filled with internet discussions on approaches to hacking and the LLMs are mimicking it.

The power of the other tools mostly shines in large scales. For most applications, though, performance of postgres more than suffices.

I tried to use rabbitmq for a small app, installed it, configured it and then it didn't work. Spent a day jumping through hoops getting it right.

Dumped it and used postgres, in half an hour. Worked like a charm.

Sure, best not to overcomplicate early if you don't need it.

PG is great and I work with it daily, but it's also not a problem to think about scale early and at least have a notional plan for what to and how to know when scale is becoming an issue in your system as you're designing it. Even PG is overkill and sqlite is more than enough for some of my projects.

There are a lot of specialized tools available, but you definitely don't need to put every one in your toolbox. Experience and observation help you make those edits -- and of course there's almost always room for improvement, but "good enough" definitely exists (until it doesn't anymore :D).

This is the way. Notionally building a space/path to scale into architecture early, but delaying implementation of that scaling component until actually needed.

Then a system gets most of the benefits of not accidentally making it torturous to rearchitect for scale, without paying the headcount / complexity cost until it's needed.

Would your app run equally well with sqlite?

If NASA made a lightbuld, it would outlast the universe !

The one thing I hate about flutter is the ui code having an ungodly amount of nested brackets.

I treat nesting as a feature: if the nesting starts getting deep, that's the code indicating to extract a child widget. It pushes me toward better composition and smaller, reusable components instead of giant monolithic views.

While you aren't wrong, in my experience when the amount of nesting starts giving me bad vibes it usually indicates that something can be refactored out as a standalone widget.

Still, Flutter now feels ancient to use compared to something like Compose, in that regard.

For some reason I prefer those to curlies.

On what hardware do you run the model locally, if so?

Not the GP, but I run this model as daily driver too. It runs great on a Macbook Pro 64GB (M3 Max). Token generation speed can be about 100 tokens/sec with multi-token prediction, although it depends on the context. Worst case speed is around 50 tokens/sec.

The weaker point is prompt prefill, which starts at 1,400 tokens/sec but decreases significantly at high contexts. That said, for agentic scenarios, if you're using a harness that doesn't needlessly bust the cache, it doesn't feel slow.

I really hope they release a Qwen 3.8 35B, although the lack of a mention seems ominous.

The last bit of the last bit of what you said is what Warren Buffett has been saying for decades.

I still wish we had more phones that have eink screens in them.

I love the folding ones, but if only I had a folding eink screen, that would be glorious !

Or at least, something close.

I loved technical books from Mir publishers. Russian authors have a special place in my heart for explaining complex technical topics in concise yet engaging way.

Books like Problems In physics by I E Irodov were my favourites

I see posts like this, this deep dive into the call stacks and am always humbled and reminded of the limits of my knowledge about computers and programs.

These sort of bugs require a lot of knowledge about a) Windows Internals b) Tools to debug at that level. Most application-level programmers won't need nor are exposed to these.

However, if you are interested in knowing what is all involved, see; Advanced Windows Debugging by Mario Hewardt and Daniel Pravat - https://advancedwindowsdebugging.com/

Review of the book by Raymond Chen himself! - https://devblogs.microsoft.com/oldnewthing/20071218-01/?p=24...

Goes both ways, author probably knows little about FPGA programming, React or PyTorch.

I am, for 20 years now. I do embedded stuff too. Still.

I'm a bit surprised you don't run into things like this then :). Do you use GDB and the like at all?

Or do you mean all the windows specific stuff etc, I guess I was more imaging the call stack etc.

No insult was intended XD

As someone who has debugged his fair share of tricky low-level issues, the parts that I find impressive in his blog posts are things such as "then we look at the bytes in memory and oh yeah, this looks like an exception record". I would usually not think to do that (or be able to recognise it as easily as I presume he did).

I assume it's mostly just something you learn to recognize after decades of poking at the same things. I remember being impressed with Thiago (Qt developer) being able to immediately tell if a pointer was heap allocated, invalid/unaligned, etc. until I spent more time poring over /proc/*/maps and in gdb. Never figured out how he could tell someone's Qt version just from an strace excerpt, though.

> Never figured out how he could tell someone's Qt version just from an strace excerpt, though.

Sonames might be a big clue? Otherwise, initialization order changes maybe? Sometimes there's enough file content in an strace to be able to see a strong indicator?

Those are just guesses, I do a lot more debugging with pcaps rather than straces. Although you do often want to determine which side of the syscall caused whatever you're seeing in the pcap.

I have done everything from desktop apps to web apps and a bunch in between. Regular debugging is good enough for me. Never had the need to go down into call stack level.

Even with embedded programming, regular C debugger has always been enough.