Basically everything that was invented up to 3 years ago was invented without the help of "AI". And that includes "AI" itself, for we, humans, invented that too.

So yup, humans can be quite resourceful.

https://www.youtube.com/watch?v=K-ZZkZk9QRk

Some of it went to museums too.

Wait... Are you telling me models everybody told me were better than coders up to just one month ago are actually making lots of mistakes?

This is shocking.

You do understand that this is just an example out of a bazillion and that planning to solve every place where data is fed to LLMs at 10 characters so that it's not mistaken for instructions ain't a viable solution?

Because they're vibe-coded ultra sloppy code. And it really shows.

The "don't do premature optimization" mindset is the reason why we've got monstrous Electron apps doing jack shit.

I hate that quote, I hate that mindset. It's the reason everything is bloated and sucks.

For the power button is located next to two USB ports I use and, for whatever reason and although it's a very good PC tower, the button is ultra sensitive.

So I created a "not-molly guard" that "plugs" into the two audio jacks (which I never use and which are, also, next to the power button) and that only leaves a narrow hole and a guardrail of a few millimeters.

Printing it in black, matching the tower's lip where the power button is, and life is good. Already hit that Molly guard several times by mistake so I figured out I already saved more time than it took to design it.

As it's a small piece, it printed in a few minutes on the 3D printer.

P.S: AFAICT there's no software setting (?) to prevent the power button from doing what it does!? But who cares, I've got the Molly guard now.

I do it at the software level (Linux / Xorg): complete remapping, with an "hyper" key modifier etc.

The reason I do it at the software level is that you can pry my Topre switches from my cold dead hands and the HHKB Pro JP I'm using doesn't have, by default, a programmable controller. Now I know some people mod their Topre keyboards to add a programmable controller but I never got to that point.

Doing so in hardware using .xkb files is... Something. I know way more about .xkb files than I should but, thankfully, so far I've just been able to brink my .xkb file to every new Linux version (supporting Xorg, I'm not on Wayland).

I take at some point I'll look more into how to mod my HHKB keyboards with programmable controller.

That's a very dumb theory. People cannot just be exchanged: you cannot take say, 60 million people out of Bangladesh, put them in Japan, and expect Japan to stay the same. Just as you cannot take 60 million Japanese, put them in Bangladesh, and expect Bangladesh to stay the name.

That's a fact. But I could give a shitload of historical examples too... Here's one: when white and black people arrived in the americas, there was still cannibalism taking place in both northern and southern america. The americas had neither white nor black people. Today there's no cannibalism anymore and there are not many kids sacrifices happening in the US to please Inca/Maya gods anymore either.

A slightly more reasonable theory is that if you import people through immigration at a reasonable rate, you can assimilate those people. For example for a long time in Europe female genital mutilation wasn't a thing anymore. Now sadly due to mass migration, ask any ob-gyn doctor in western Europe what he sees and what kind of act he has to do: like re-stitching hymens to pretend the women-to-be-married are virgins (because, yes, there are patriarchal cultures where men are going to inspect a woman's hymen to make sure she's a virgin).

People just live in a fantasy land in their heads: there are 300 million women alive, today, who've been genitally mutilated (that's a very sizeable percentage of all the women out there). What's actually ongoing is weirder and shittier than most people realize.

I say good for Switzerland to curb immigration a bit.

People may be not dissimilar but cultures certainly are.

We had good runs mate!

Same: presbyopia and I hate low-light now: it's just as you wrote: better acuity in bright settings. Either during day time or with proper lighting.

Still can read signs from the car (say while on the highway) before anyone else so there's that.

Can't really share any experience as I don't have a good understanding of glasses/focals.

> ... initiatives that are interconnected and mutually reinforcing across each stage of the value chain, from chips, to infrastructure, to software, cloud and AI, and in synergy with past and ongoing initiatives such as AI Factories and AI Gigafactories

Software / Cloud: yes, Europe can try to do something but I doubt it. Although it should be pointed out that the EU has one software company in the Top 100 companies in the world by market cap. One. And it's that fucking lame piece of uber-shit that SAP is.

SAP: that's what europeans can do. While the US has Google, Amazon, Netflix, Microsoft, Oracle, Palantir, CloudFlare, etc. Not that these are all great companies but these are heavyweights compared to that pointless, irrelevant, turd that SAP is.

Chips? Besides ASML (which is only part of the chain), we're a wasteland and ASML is mostly US-owned.

Not going to see the next Intel / AMD / NVidia from the EU: that simply is not going to happen. It just won't.

AI gigafactories? Bull-fucking-crap.

The only area where Europe can try something is software but this must be put in perspective: SAP vs all the US software companies.

Don't forget all we could do is SAP. And that is a monstrous piece proprietary lock-in shit.

Be well mate.

https://www.gabrielgambetta.com/remakes.html

is wild!

I love the idea. I used Claude Code / Sonnet 4.6 to get back to compile an old DOS game I wrote back around 1991 and for which I had lost the tooling (compiler / linker / notes / build files). It was on my todo list since years, decades even, but I never got to it. With a LLM it was easy: I didn't let the LLM do everything, I used it to find what needed fixing (like two macros I had used with names that were now clashing with "modern" compilers methods names etc.).

> I hacked together the art using my terrible Gimp skills and some Public Domain and Creative Commons assets from OpenGameArt

IMO AI models are better at generating pictures than at writing code, in that pictures do tolerate sloppy approximations. While code doesn't tolerate slop that much.

Why not use AI for the assets?

But that really depends on what you're doing. For example if I'm not mistaken Amazon was run for a very long time on a Java backend. And so was GMail's backend (and back then GMail's frontend was, IIRC, Java converted to JavaScript using GWT).

And by "early Amazon" and "early GMail", we're already talking about massive scale. It's not as if the JVM got worse since then (as someone commented: a recent addition is that Clojure now use Java's virtual threads) and it's not as if it didn't scale.

So I'd say having Clojure on top of Java (for those using that Clojure: there's also ClojureScript, babashka, etc.) ain't really a problem, as long as you're fine with the occasional Java stacktrace and Java ecosystem (GP mentions that btw: that he's not familiar with Java and that, I think, can be a bit of an issue).

I'm not sure Clojure is about it's syntax: I like the focus on immutability / pure functions and I do really dig the REPL a huge lot. In addition to that something has to be said as to the incredible stability of the language and many of its libraries.

The big value add to me is that I can have a REPL and inspect, in dev (or in prod but that'd be wild), the app I'm working on. And manipulate it: redefining variables and functions etc. And it's not some hacky hot-reloading bolted on as an afterthought kludge: it's a real Lisp REPL. There's value in that IMO.

Central banks and the IMF only own less than 20% of all the gold ever mined: it's probably not the one or two additional percent they bought that made the prices skyrocket by 70%.

For example used supercars and hypercars' values have gone through the roof too: and that's for sure not because central banks are stockpiling those.

Causation / correlation and all that.

That's introductory course to systemd's shenanigans. People are going to tell you that you're not doing it properly, that there's of course this setting (unless that other setting takes precedence etc.), yada, yada, yada.

If I really have to suffer systemd the first thing I do is manually edit /etc/resolv.conf and then chattr +i /etc/resolv.conf.

And of course remove/purge systemd-resolved.

Not only is it "always the DNS" but then things turn from bad to worse when "it's the DNS, but with systemd".

Removing systemd-resolved is the first step. The second one is moving to an OS or a Linux distro that doesn't have systemd at all.

Oh nooooo... I've been so wrong. Seen the direction most Linux distro took I decided to move to VMs (VMs which runs systemd-less systems), OCI containers (where by definition PID 1 is not systemd) and now an hypervisor to run systemd Linux VM but I'm now into... An hypervisor that is precisely not Linux (so no systemd at all).

I sinned. So now maybe it's time to buy Microsoft stocks, praise Windows [ini] config files, and venere the Linux PID 1 god with its tentacles meddling with every part of the Linux system.

Or not.

I think it's mostly due to the CLI being much more powerful than a full-blown IDE: when you try to make everything simple (in a menu, accessible with one mouse-click or a shortcut), then semi-advanced things (which haven't been thought of in the IDE) become impossible.

They also compose way more easily with the network: it's much easier to SSH/tmux TUIs than to try to network GUIs. That's very important in this day and age of incessant exploits and the need to run things in VMs to try to prevent exploits from pwning your entire world.

TUIs sadly doesn't entirely solve the bloat issue: look at Claude Code CLI... An Electron app because, as the Pi author mentioned, people at Anthropic thought they were writing a game. A full headless Electron app converted, on the fly, to pretend it's a TUI.

The madness is real (shitload of message of users not happy with characters shown on screen not being those saved to source files: and I've been bit by this) and the bloat issue hasn't been solved.

But in any case you cannot go back to a GUI and not have that problem of GUIs being too restrictive: invariably there shall be a need to chain several simple commands that do one thing and that excel at that one thing and that only become powerful when chained with other commands. GUIs cannot solve that.

LLMs have just proved what many knew all along: that the CLI is more powerful.

Instead of GUIs on the contrary I expect more TUIs, more command line, and more, much more, REPL usage by LLMs and by devs using LLMs.

What I do hope though is that we get more lean TUIs (like Pi by Mario Zechner, all the utils written in Rust etc.) and less madness like "headless Electron converted 60 times per second to a fake TUI".

I'm still on Anthropic models to code but I'm on Gemini 3.5 Flash for everything else. How can you say Google is bad at LLM when their little flash model is literally SOTA on many benchmarks?

> ... yet OpenAI and Anthropic are eating their pie.

They're eating nobody's pie: it's a new pie. Google is a $4.5 trillion company, the 2nd biggest in the world as I type this.

Seen that fact and seen how good Gemini 3.5 Flash is, I'm not really sure Google is "bad at LLMs".

Mandating that the final binary is compiled without having any access to any test file though would have prevented the xz-utils backdoor as it was conceived though.

A proper packaging setup would first verify that all the tests are passing and happen in an isolated environment. And that isolated environment either returns which tests failed or gives the green light.

When the greenlight is given (that all tests are passing), another environment should first delete all files related to tests and then build (in a bit-for-bit reproducible way btw and we're basically here already so that's good) the final binary / package.

If you prepare your final package in an environment that has access to test files, there are simply way too many ways obfuscated binary data can be hidden in test cases / test files.

I'm not saying the NSA (sorry, Jia Tan) wouldn't have tried something else but I think we should really move to build/packaging that discards non essential data/files before compiling.

P.S: note that as a side-effect of reproducible builds... If we have reproducible builds and if we add, later on, a builder/packager that discards tests files and ends up with a final package that's not bit-for-bit identical to the package created while having access to the test files during the build, we've just detected a backdoor hidden inside test files (like the XZ utils one). As a really mindboggling food for thoughts: if we were to recompile all the Debian binary packages that are already reproducible today (95% of them), but while discarding all tests files before the build, we may catch other backdoors.