scatbot

Cool project. Feels like writing a C compiler in Zig aligns nicely with the old "maintain it in Zig" idea that was part of Zig's early value proposition. Is that still considered a relevant goal today?

Longer term it also makes me wonder whether something like this could eventually reduce reliance on Clang/LLVM for the C frontend in zig's toolchain.

I know this is satire, but I would wish to see something like this for liberating proprietary & closed-source hardware drivers.

Lego is one of those companies that is simultaneously amazing and kind of sucks. On one hand the core product is incredible. The tolerances on the bricks are micrometer-level precision and the fact that pieces from the 70s snap perfectly into ones made today is mind blowing.

On the other hand, a lot what the company does today just sucks. Set prices are outrageous. Printed bricks get replaced with stickers and many sets feel like display models than something you can play with. The Mindstorms/NXT line had huge potential but then just sort of fizzled out. And the push towards smartphone-dependent toys feels weird. Who actually wants their kids staring at a phone to play Lego?

It's so sad, because the core product is basically perfect.

That's not how SMTP reputation scoring works. Even in IPv4 per-IP reputation stopped being sufficient many years ago because bulk senders churn pools and rotate addresses. Modern systems typically score prefixes, ASNs, DKIM/SPF alignment, TLS and behavior.

>But I do think s-expressions are an improvement over HTML in certain scenarios.

I agree. S expressions are a data interchange format. HTML is a markup language. They solve different problems.

S expressions define nested lists of atoms. HTML describes semantic hypertext documents defined by a document tree made of element nodes as subtrees, attribute nodes as subtree metadata, and text nodes. In some scenarios a uniform data structure like s expressions is nicer to work with.

To be honest it boggles my mind that XML was ever used as a universal data format.

This seems similar to _hyperscript, except it uses custom tags instead of the "_" attribute. I'm not sure which approach is better, but personally, I prefer keeping the same document structure and varying behavior through attributes. Easier to rewrite on the fly. Custom tags can be clearer in some cases, but attributes tend to work better with existing HTML and tooling.

Not really. BLAKE3 isn’t a reduced-round tweak of BLAKE2 like K12 is for Keccak. It's a different construction that still meets its full security target. K12 and TurboSHAKE on the other hand are literally the same permutation with fewer rounds, which actually reduces Keccak's security margin. The situations are not really comparable.

Honestly, I'm skeptical of the whole Keccak-derived ecosystem. The reduced-rounds variants like K12 and TurboShake are trading a conservative security margin for speed, which kinda feels odd when compared to BLAKE3. Meanwhile, BLAKE3 covers everything for real-world use. It's super fast on any input, fully parallelizable and has a built-in key mode. The only real advantage Keccak-based functions seem to have is standardization and potential hardware acceleration.

If you care about speed, security and simplicity, and you don't care about NIST compliance, BLAKE3 is hard to beat.

One of the reasons why I'm using OpenBSD is because it passes what I think of as a litmus test for FLOSS software: can I build the whole thing from scratch, in a short time and with minimal fuss? In the case of OpenBSD, the answer is yes. I can install it on a new machine, fetch the source code from mirrors, do some edits to the source, build a fresh release, write it to a USB stick and boot it on another machine. On my machine, the whole process takes about 10 minutes for the kernel, additional 20 minutes for base and maybe an hour if you add Xenocara. Compare that to Linux distros like Ubuntu or Arch where building from scratch is either discouraged or some fringe activity that requires skimming through wiki articles, forum posts or old Websites on the Wayback Machine.

From the submission title I expected some kind of chorded keyboard. This is just a tiny regular keyboard. What a bummer.

This reminds me how I once spend months trying to track down a Frogpad for a cyberpunk-inspired wearable computing project. I found one on eBay but got outbid at the last second. It still hurts a little.

Any Forth system at it's core is essentially a stack-based virtual machine with a reprogrammable high-level assembler and a REPL. Some Forths use direct or indirect threading, others are implemented as bytecode VMs, not unlike the JVM, high-performance JavaScript engines or the Erlang VM, but that's really just an implementation detail.

People say that stack juggling is boring, but I actually find it to be a very natural way to think about computation. Forth's linear, concatenative style gives you SSA-like semantics for free, which makes it straightforward to lower into register-optimized bytecode or native code.

And once you're there, dynamic recompilation at runtime can do the rest. A naive, threaded implementation of Forth might not be performance-friendly on modern hardware, but there's nothing that prevents it from being high-performance. It just depends on how much effort you're willing to put into the implementation.

I get the appeal of the 512KB Club. Most modern websites are bloat, slow and a privacy nightmare. I even get the nerdy thrill of fitting an entire website into a single IP packet, but honestly, this obsession with raw file size is kinda boring. It just encourages people micromanage whitespace, skip images or cut features like accessibility or responsive layouts.

A truly "suckless" website isn't about size. It's one that uses non-intrusive JS, embraces progressive enhancement, prioritizes accessibility, respects visitor's privacy and looks clean and functional on any device or output medium. If it ends up small: great! But that shouldn't be the point.

The author is deeply misguided and clearly frustrated. The claim that the GPL can't be enforced is simply wrong. GPL violations are regularly challenged in court and through community pressure. But let's assume for a moment that the author's claims are valid in the context of AI. Wouldn't the GPL be just another permissive license? Why switch to the BSD license, which explicitly throws away the one right GPL still guarantees: the ability to demand that derivative works remain open?

The GPL gives you enforceable rights. The BSD license gives corporations a free pass to close off your code. Calling this "pragmatic" isn't just backward, it abandons protections that matter. And frankly, it baffles my mind that someone who believes closed source shouldn't exist would be this fatalist to give up the leverage that still protects openness.