from the future

@nafonsopt The glibc issue is real, and super annoying

For anybody saying "Just use Linux", you need to realise that Linux is worse than Windows. Windows has all the bloat, and while you can have Linux without any of that you still don't have tools like Remedybg, RAD Debugger and Super Luminal. Once you have such tools, then Linux is a suitable app development environment. But _it is still trash_ because of the whole Linux model of you needing to compile everything. The fact that you cannot run an app built using a newer version of glibc is an insane decision. I shouldn't have to upgrade my whole machine in order to run something built on a newer version. I shouldn't be worried that an upgrade will break my machine. I shouldn't be forced to compile things from scratch to work on my machine. I shouldn't be forced to install N packages, I just want self contained binaries I can just download and run. I shouldn't be forced to develop with an old distro to have "max glibc compatibility". I shouldn't have to worry about X11 / Wayland / Window Managers. I shouldn't have to worry about asking the user to select a folder, display a dialog or show notifications. Linux is such a huge waste of potential, if they got their shit together they would completely obliterate Windows. I first got into Linux in 2000, and even back then there was this "it will take over Windows any time now!". It's been _26 years_! The same way I'd pay quite a lot for Windows without any bloat, I'd be willing to pay for a distro that gives me all this.

Good for him for building a proof of concept. But it’s not real ,usable software yet, nor has he published any real benchmarks to show any improvements for real workloads. I get the urge to block haters like me, but he’s either a delusional junior programmer or a bullshit artist. In either case his grand, ungrounded, claims should be shunned by the engineering community.

@nk @kettanaito There are replies like this on the X posts but the author hides them and blocks anybody who comments any criticism. It's bizarre.

Extremely conflicted about Electrobun. On one hand, a nice idea. On the other, it lacks so many essential parts that I cannot recommend it for anything serious. Detailed list of issues I encountered below.

@kettanaito You could use this electron-ipc.com which is by one of the Electron maintainers. I cannot vouch for this though. You can also use node in the rendering process and avoid IPC altogether if you aren't executing untrusted code.

I have no idea how ya'll building apps on Electron when IPC has zero type-safety and is an absolute nightmare to use. Community packages that "solve" this problem don't really solve it (unidirectional tRCP !== IPC). This is very, very sad.

@pvncher I have been using git-lfs for a couple of years on this computer and repo prompt for 6 months and it was working yesterday fine and not today after "install and relaunch."

@nk Strange I haven’t seen that. Is it an lfs repo? If so did you properly install git lfs?

@pvncher today's version is not working for me

@dhh Like if it's not obvious, this is written as if the interior monologue of someone the economist detests.

@dhh How is it possible not to notice this is extremely ironic??

Find someone who will eulogize you with the romantic flair and fawning adoration of The Economist remembering Khamenei. archive.md/Jl1ki

@z @ericmitchellai I think this is just a bug. It gets confused what it is doing.

@z @ericmitchellai Can I just show you something that happened 5 seconds ago? We discussed a design. I said "try it. but allow redoTopologies to also be empty". You can see it says it's about to do the work. Then it didn't do what it said it was going to do, and did like a code-review or something.

Chat GPT 5.4 is really frustrating to work with. Awful hallucinations and laziness. It's hard to tell if it's "smarter" when it's so difficult to steer.

I think there’s something to be said for having it baked into the runtime or stdlib. I use onetbb but the fact that I even have to use something outside the stdlib is annoying. But I find myself extremely skeptical of beam. The number of large production deployments worldwide is very few in number compared to like the jvm or cpp. Projects like riak and rabbitmq weren’t successful. There is whatsapp I guess, but a messaging app hardly counts. So where is the concrete evidence it works more generally?

This is why I’m unimpressed by Erlang/Elixir: every major language runtime has VERY high-quality M:N work-stealing “thread” schedulers with good APIs (structured concurrency), and the “isolated processes” and “RPC” got pushed up to an orchestration layer (DC/OS, Nomad, k8s…)

Yeah there needs to be an eval for "solve this problem with fewer lines of code rather than more". But not optimizing for "golf" solutions either. If start with X pattern, then ask it to refactor to Y, then clear context and ask it to refactor to X, you will almost always end up with more code than you started with.

@yanndubs code *waves hands* je ne sais quoi code taste delete code when it’s appropriate. it’s not write-only. do what i want, not necessarily what i say if there is a better approach than my prompt, tell me i’m an idiot

🔥Two things I'm esp excited about 5.4: 1. Unification: we merged our codex & mainline models 2. Efficiency: we brought the efficiency of 5.3-codex to CUA & knowledge work. We only showed 3 such plots in the blog but many of our evals required less time (tokens/tools) than 5.2. What should we fix for the next model?

@filpizlo @rtroar You can also compare JavaScript and typescript performance which I think is a more direct typed/untyped comparison. I wager the llms will do much better when using a new api with ts.

@rtroar So many folks are finding that Ruby is the best language to have LLMs write. They're really good at it

Especially with the context of using LLM code tools I think this is hilariously wrong. I don’t even enjoy writing rust that much, but it’s the only native language I’m okay letting agents write. The type system and borrow checker are why.

@istvan_csanady Yeah - either the basic algorithm either naturally leads to that being a config option or some customer with deep pockets specifically requested it

@nk i'm just wondering why the brep kernel developers put so much effort into it so far i couldn't find a production (manufacturing, not graphics) use case

literally nobody ever designed overflowing fillets

@fat @amadeus @SlexAxton I'm not sure if we can actually use it because we have a lot of extra chrome in our tree and wiring it all up seems like more trouble than just borrowing ideas

@nk @amadeus @SlexAxton @amadeus has a twitter post somewhere on this he can link – but also mb you can just use our tree stuff? (if you're just doing to render layers)…. not sure if that's your usecase tho

Our primitives team has been working on a new project we're calling "trees". Trees will be a new SSR, shadow dom, drag and drop, virtualized, vanilla js / react web-component, with a handful of search / filter niceties, collapsible repo paths, themeabilty, diff stat representation, and more. Like most Pierre Computer Company things, it's built very well by people that care a lot about these sorts of things. Sadly so far trees[dot]com is unwilling to give us their domain.

@fat @amadeus @SlexAxton I only need to know how to solve this in chromium but I gave up before I could figure it out. Would love to know

@nk @amadeus and @SlexAxton have spent an unreasonable amount of time on exactly this. especially in safari, lots of dark arts

@nest_elf @vic_hates_x speaking from experience: v8 bytecode is more difficult to reverse engineer than normal compiled C code. Obfuscated C (e.g., from via Oreans) is very difficult to reverse engineer though.

@vic_hates_x native code isn't encrypted in ram either. debuggers exist (gdb, frida, ida pro). the real gap is effort. js takes 2 mins in devtools. native needs assembly knowledge and days of reversing but neither should store api keys client side. just proxy through a backend. problem solved

> anyone with a debugger can dump your unencrypted application state. you cannot hide api keys in client side javascript as opposed to native code in which memory is obviously encrypted and debugging does not exist 🙄