timschmidt

> Yes, and the made up words of kilo and kibi were given specific definitions by the people who made them up

Good for them. People make up their own definitions for words all the time. Some of those people even try to get others to adopt their definition. Very few are ever successful. Because language is about communicating shared meaning. And there is a great deal of cultural inertia behind the kilo = 2^10 definition in computer science and adjacent fields.

I've been using the T-Deck Pro and T-Lora Pager, so the device is the app.

oof. right in the self-image.

Have you ever watched an interview with Tom Homan? Man is single-minded and highly motivated. Like leashing the dog, and letting loose a wolf.

It seems like, in the course of calling out a perceived assumption, you may have made an assumption yourself. I'm aware of the difference between casualties and deaths. My chosen terminology applies equally to both. And I think both are relevant to a number of related stats like lifetime earnings, mental and physical health, family prospects, etc.

War is hell. And I don't think anyone comes out untouched by it. The stats on vets are brutal.

And they've recently chewed through > 1 million young men: https://www.dw.com/en/12-million-russian-soldiers-killed-inj...

chipfoundry.io charges $14,950 for packaged 100 chips. As far as small batch manufacturing goes, that's reasonably affordable. $149 ea. Occasionally I see better deals crop up as part of group buys or for bare dies. Presumably, one would prototype their design on an inexpensive FPGA board first, to verify functionality. So as to be reasonably sure the first batch of chips worked. Folks like Sam Zeloof are working to build new tools for one-off and small batch designs as well, which may further reduce small quantity prices.

As state of the art machines continue to chase the latest node, capacity for older nodes has become much less expensive, more openly documented, and actually accessible to individuals. Open source FPGA and ASIC synthesis tools have also immensely improved in quality and capability. The Raspberry Pi Pico RP2350 contains an open source Risc-V core designed by an individual. And 4G cell phones like the https://lilygo.cc/products/t-deck-pro are available on the market built around the very similar ESP32. The latest greatest will always be behind a paywall, but the rising tide floats all boats, and hobbyist projects are growing more sophisticated. Even a $1 ESP32 has dual 240mhz 32bit cores, 8Mb ram, and fast network interfaces which blow away the 8bit micros I grew up with. The state of the open-source art may be a bit behind the state of the proprietary arts, but is advancing as well.

It's really fun to have useful hardware that's easy to program at the bare metal.

Even with MoE, holding the model in RAM while individual experts are evaluated in VRAM is a bit of a compromise. Experts can be swapped in and out of VRAM for each token. So RAM <-> VRAM bandwidth becomes important. With a model larger than RAM, that bandwidth bottleneck gets pushed to the SSD interface. At least it's read-only, and not read-write, but even the fastest of SSDs will be significantly slower than RAM.

That said, there are folks out there doing it. https://github.com/lyogavin/airllm is one example.

Using OpenSSL's malloc may bypass protections of hardened libc mallocs like OpenBSD's.

If memory crosses the boundary between OpenSSL and your app, or some other library, freeing it with a different allocator than the one it was allocated with is undefined behavior.

OpenSSL's allocator doesn't free in in the same ways other mallocs do, which prevents memory sanitization tools like valgrind from finding memory bugs.

OpenSSL has a completely separate idea of a secure heap, with it's own additional malloc implementation, which can lead to state leakage or other issues if not used perfectly at the (non-existent because the entire library surface is exposed) security boundary and is accidentally intermingled with calls to the (insecure?) malloc.

It's just a big can of security worms which may have been useful on odd platforms like VMS, though that's questionable, and only serves to add additional layers of inscrutability and obfuscation to an already messy codebase today. It's not enough to know what malloc does, one must familiarize themselves with all the quirks of both(!) of OpenSSL's custom implementations, which are used precisely nowhere else, to judge the security or code correctness implications of virtually anything in the codebase. There's no good reason for it.

That's a lot of ifdefs, sure. But at least Vim doesn't have it's own malloc which never frees and can be dynamically replaced at runtime and occasionally logs sensitive information.

The badness cannot be overstated. "Hostile codebase" would be an appropriate label. Much more information available in Giovani Bechis's presentation: https://www.slideshare.net/slideshow/libressl/42162879

If someone meant to engineer a codebase to hide subtle bugs which might be remotely exploitable, leak state, behave unexpectedly at runtime, or all of the above, the code would look like this.

Tribalism is part of the brainrot. Divide and conquer. To paraphrase Carlin, wealth and power are are big club and we ain't in it.

> which means that now, they need to make a conversion, which is obviously slower than doing nothing.

One would think. But since caches have grown so large, and memory speed and latency haven't scaled with compute, so long as the conversion fits in the cache and is operating on data already in the cache from previous operations, which admittedly takes some care, there's often an embarrassing amount of compute sitting idle waiting for the next response from memory. So if your workload is memory or disk or network bound, conversions can oftentimes be "free" in terms of wall clock time. At the cost of slightly more wattage burnt by the CPU(s). Much depends on the size and complexity of the data structure.

I mentioned the estimated unregistered firearms, but they are just that, an estimate. I went looking for some references and found the following: household gun ownership is down over the last 50 years, hunting is down, gun ownership among men is down, gun ownership among women remains steady, gun ownership by race has not appreciably changed: https://vpc.org/studies/ownership.pdf Gun ownership declining would be consistent with increased gun control.

Yet gun deaths by suicide and murder per 100k people hasn't varied widely between 5 and 7 over the same period: https://www.pewresearch.org/short-reads/2025/03/05/what-the-...

I also found the stats on this site interesting (many are estimates):

https://www.nationmaster.com/country-info/stats/Crime/Murder...

https://www.nationmaster.com/country-info/stats/Crime/Violen...

https://www.nationmaster.com/country-info/stats/Crime/Violen...

> individuals are responsible, but that doesn't mean that the tool is not a significant factor.

Individuals are responsible. No buts. And there is no solving violence on any scale without understanding and addressing the reasons someone might commit it. This is a rabbit hole of difficult and uncomfortable truths we must address as a society.

Good question. Canada has twice as many registered firearms as the US (though the number of unregistered firearms is likely greater in the US). It's certainly not difficult to purchase guns in either country. And Canada experiences an order of magnitude fewer gun deaths per capita than the US. The US is somewhat unique among western nations in how it handles mental illness, and crime, and I would suggest those are more fruitful avenues of inquiry.

So I'll stand by the stance that individuals are responsible for their own actions, that tools cannot bear responsibility for how they are used on account of being inanimate objects, and that all tools serve constructive and destructive purposes, sometimes simultaneously.

An accurate statement. In places where guns are difficult to come by, you'll find knife crime in it's place. Take the knives away and it'd be fists.

Thanks, I'll give 'em a read.

Oh I'm all for pragmatism. I think Fil-C is great in that regard. For shoring up legacy code and maybe even for new projects if you're a C/C++ shop and velocity is important and you can eat the performance and memory costs.

I've also written some bindings for C/C++ in Rust and it couldn't have been simpler. bindgen is amazing. So with the experience I have today, I wouldn't hesitate to start rewriting portions of a C/C++ project in Rust where it made sense. And keep the thing building before, during, and after.

I'm currently in process on a rewrite of the RepRap.org stack I helped write 20 years ago in C++ and avr-c++, Python, OpenSCAD, and other languages to idiomatic Rust in order to reduce the number of languages involved, support building a fast wasm user interface, build the interface and firmware in the same language and share types across the boundary, explore GPU compute, enable multithreading of interface and firmware, and explore async firmware architecture. And I'm enjoying it a lot.

Compared to writing it the first time, I am spending zero time fighting build systems, able to reuse much more code from libraries much easier, and have been able to delve deeper into complex issues like advanced numerical representations, ensuring algorithmic determinism under all possible cases, and the implementations of vector math library which is the foundation of much of the code. Even egui, the UI toolkit I've been using, seems simpler and easier to work with than QT or GTK or anything I've worked with save FLTK which was dead simple. I've really enjoyed Rust for all that.

I have the sense, after working with rust, that I am much less likely to get myself into trouble with it than with C++, and much more likely to know where that might happen. Past some point, my big C++ projects got big enough that it got difficult to hold a coherent picture of the whole thing at runtime in your head all at once, to understand it's behavior. That point seems to be farther out, for me, in Rust.

The most challenging thing about the rewrite has been chasing down all the little bits of state hidden away in various C++ functions, and normalizing all that into one of a few architectures which work well with Rust's borrowing rules. But the process of doing so consists entirely of things which are best-practice anyway, and the resulting code is definitely easier to read and understand to my eye.

These are just observations from my position, as a person with a big legacy C++ codebase, currently rewriting in Rust. And occasionally working in other languages, of course. I have lots of projects.

> The allocator work is facing a lot of obstacles, unfortunately.

Got any links? Sounds like interesting reading. Seriously. Kind of thing I come here for. I'd really appreciate it. Or I can ask the AI for some.

> I prefer it to be unstable for as long as it needs, though.

Sure, same. Fully baking things is a process, and it's nice when things are fully baked. So I agree. I think Rust's async could be a bit more ergonomic, though it wasn't too difficult to wrap my head around, and sort of shockingly simple to implement a basic no-std async executor (~10 lines), so maybe I'm coming around. I was pleased to find out that it was simple enough that I could do it, and understand how it worked, as I try to do with all my microcontroller code, and wasn't dependent on a big async runtime like Tokio if I didn't need it's features (or bloat).

I purposefully refrained from judgement or commentary either way when posting it. My intention was merely to show that this line of thinking about the duality of violence and non-violence is something the nation's founders themselves were thinking about. It is the reason I posted the quote in full, instead of the abbreviated form most commonly referenced. I hope that the added context lends nuance and perspective which might otherwise be overlooked.

"I do not know whether it is to yourself or Mr. Adams I am to give my thanks for the copy of the new constitution. I beg leave through you to place them where due. It will be yet three weeks before I shall receive them from America. There are very good articles in it: and very bad. I do not know which preponderate. What we have lately read in the history of Holland, in the chapter on the Stadtholder, would have sufficed to set me against a Chief magistrate eligible for a long duration, if I had ever been disposed towards one: and what we have always read of the elections of Polish kings should have forever excluded the idea of one continuable for life. Wonderful is the effect of impudent and persevering lying. The British ministry have so long hired their gazetteers to repeat and model into every form lies about our being in anarchy, that the world has at length believed them, the English nation has believed them, the ministers themselves have come to believe them, and what is more wonderful, we have believed them ourselves. Yet where does this anarchy exist? Where did it ever exist, except in the single instance of Massachusets? And can history produce an instance of a rebellion so honourably conducted? I say nothing of it’s motives. They were founded in ignorance, not wickedness. God forbid we should ever be 20 years without such a rebellion. The people can not be all, and always, well informed. The part which is wrong will be discontented in proportion to the importance of the facts they misconceive. If they remain quiet under such misconceptions it is a lethargy, the forerunner of death to the public liberty. We have had 13. states independant 11. years. There has been one rebellion. That comes to one rebellion in a century and a half for each state. What country before ever existed a century and half without a rebellion? And what country can preserve it’s liberties if their rulers are not warned from time to time that their people preserve the spirit of resistance? Let them take arms. The remedy is to set them right as to facts, pardon and pacify them. What signify a few lives lost in a century or two? The tree of liberty must be refreshed from time to time with the blood of patriots and tyrants. It is it’s natural manure. Our Convention has been too much impressed by the insurrection of Massachusets: and in the spur of the moment they are setting up a kite to keep the hen yard in order. I hope in god this article will be rectified before the new constitution is accepted."

-- Thomas Jefferson

https://www.monticello.org/research-education/thomas-jeffers...

> Rust is literally the fast stab at making a memory safe systems language.

Graydon started developing Rust in 2006, 20 years ago. The guy is somewhat famously a compiler buff with experience in a half dozen of them. What about that comes across as a "fast stab" to you?

std may not yet provide a stable interface for custom allocators (the Allocator API appears to be available in unstable presently), but use of custom allocators is common in no-std rust environments like embedded. Reading through https://github.com/irbull/custom_allocators the Allocator API doesn't seem particularly complicated. I think it's fair to expect that it will stabilize in time.

> That's like saying Rust has GC because GC libraries/runtimes can be implemented in/for Rust.

Quite a few have already been implemented and are available as libraries exactly as you describe, today. I wouldn't phrase that as "Rust has GC" because that might imply that the GC is required. But if your application might benefit from GC, it's certainly available in the language. I might say "GC is optionally available in Rust if desired" to be more accurate.

All replies to a parent comment about Rust which wasn't mine, and which you're responding under too. Heaven forbid folks converse freely.

> If you ever wonder why people get a bit tired of Rust advocates, this is why.

I'm no Rust advocate. Just a developer who's worked in the languages being discussed, who is happy to talk about them. If I'm an advocate for anything, it's more sophisticated, powerful, safer, better tooling, in every language. I appreciate it when any of them make advancements.

Have fun! Toodles!

> What I'm saying is that the boundary between where you use a 'systems programming language' and where you use an 'application programming language' is artificial

Well, everything humans have ever created is artificial, so I'm not sure even how to parse this sentence. There are objectively tasks which can be accomplished with systems languages which cannot be with others. That is an indisputable fact, and not determined by anything but the language specification and implementation.

> we are using too much of the former in a place where we probably should be using the latter

If I loosen this sentence to mean that we should write more code in languages which have the familiar properties of applications languages - memory and thread safety, low boilerplate, helpful tooling, reduced cognitive load - then I can agree with it. Otherwise it seems an opinion without reason.

Where that code needs speed, uninterrupted control of execution, to be embedded, target wasm, or might want to do any of those things in the future, I think Rust is an excellent choice which provides many of those benefits.

I'd rather not have runtimes sneaking into low level performance critical areas like kernels and drivers. But some folks are into that sort of thing - Microsoft famously worked on https://en.wikipedia.org/wiki/Singularity_%28operating_syste... in C# but then again C# has very similar memory semantics to Rust. Microkernels seem to work well enough, with several extant examples. Anyway, you do you! I look forward to ogling your OS project from the sidelines.

Agreed. C++ has advanced incredibly over the years, with the developers putting in immense, important, and useful effort. But Rust has had the benefit of a fresh start with lessons learned. People who have yet to understand the choices made in it's design see the differing semantics as unnecessary hurdles, whereas people who've taken the time to learn why those choices were made and what adhering to them enables find themselves enamored of their newfound abilities. It's why there's such an intense communication rift between folks on either side of the experience.

That afternoon effort on the hot loops netted ~3x improvement on the test suite on an 8 core machine. The test suite is intentionally minimal, so I'd say that represents a reasonable low bound. The greater the number of polygons in an operation, the more it would benefit.

I write a bit of everything, including a little Rust CAD library which is a continuation of work I did in C++ 20 years ago. The C++ version was never multithreaded. The Rust library was fully multithreaded in an afternoon by importing Rayon behind a cargo feature, and using par_iter in place of iter in a few hot loops. That alone made the rewrite worth it.

Safe threading seems like fully exploiting hardware features to me. That's the biggest thing smart pointers and Rc, Arc, and Cell types enable. Perhaps I could have been clearer.

The comment about memory layout was an additional point that dealing with hardware requires that you format, align, and position information in memory as the hardware expects, which requires either exposing those details, or encoding them in a runtime.