You can also just run Bitmagmet for a few weeks and then you have your own tracker. (I think "tracker" might be technically incorrect jargon but it solves the same problem).

If anybody ask, it's not me who said it, but you can also easily use Shodan to find a lot of open Bitmagnet instances. Many people who self-host do not seem to be aware of the “questionable” decision of docker to always listen on 0.0.0.0 by default and make a firewall rule to expose your service to the entire web (you can also find instances of jackett and some *arr stack, but most of them are at least password protected).

There's also my project that also crawls the DHT and other sources.

https://github.com/sergiotapia/magnetissimo

> This is not a substitute for a proper C tutorial

'bool' is still at least 1 byte in C. If you want to store one Boolean per bit you have to manually implement a bitmap.

Or pull out the C++ and use std::vector<bool>,... But you should probably never do that

I heard the C++ guys regret defining vector<bool> using 1 bit per value.

Also for most code it will be premature optimization to worry about that.

From what I can tell in a cursory web search, that regret is more about issues with C++ being unable to abstract that field vs bit divergence properly, not about the concept of having the specialization be bit-based, which is sound.

I think your description is technically accurate, but maybe this phrases it better:

std::vector<bool> is a perfectly nice growable bit array type, and if the exact same code were in the C++ standard library named std::growable_bit_array nobody would be annoyed about this type, some people would use it, others would ignore it, nobody would write epic rants about it or name it the singe worst thing about C++.

The problem is that C++ popularized generics, and std::vector<T> is a generic growable array type, you ask for a std::vector<Goose> you get a growable array of your custom Goose type, great idea, very popular these days -- yet std::vector<bool> is not a generic growable array of bool, it's this other thing instead that's similar but not quite similar enough to be a drop-in replacement.

In C++ there is no way for the specialization to be bit-based without it being apparent that you are not in fact getting a growable array of the bool type.

No, that's not really an accurate rephrasing. Your comment indicates the problem is that it was exposed as a specialization, KerrAvon is saying the problem was instead that the specialization wasn't effectively abstracted (hidden) behind the API of vector (ie: implication is that ideally we'd have a better API for vector that might require C++ language changes due to the nature of the problems with vector<bool>. not that we shouldn't have the specialization)

> Your comment indicates the problem is that it was exposed as a specialization

Because that is the problem? That's what C++ programmmers are unhappy about.

> ideally we'd have a better API for vector that might require C++ language changes

Ideally after almost thirty years "maybe we could re-design the whole programming language to paper over this bug?" would be such an obviously bad idea that I wouldn't see it in a response.

> but maybe this phrases it better

I recommend not indicating you're rewording another commenter when you actually disagree with them if you don't want that difference in content pointed out. I note that you've trimmed out the parts of my comment that made it clear I was drawing that distinction. Maybe you missed those?

Separately, though, it's not accurate to call this "papering over [a] bug". Wanting to have a thing that behaves like a reference that can identify things that aren't addressable directly (ie: having custom reference representations) shows up in a surprising number of places as desirable because we use references (and things like references) as an abstraction in many programming languages to enable nicer, more usable syntax (ie: having assignments behave in a particular way).

Edit: and changing the language would have been at the time that std::vector was designed (ie: c++98-ish c++ has a real problem with abstracting over not-really-references). With current c++, we can get a reference-like-object much closer to being fully transparent (`auto&&`, ranges iterator model, etc). But std::vector regrets reflect the constraints of the time when it was initially designed/standardized. C++ doesn't have a good story for making breaking changes, so if folks want a good vector for bits, today they'll go elsewhere.

> I recommend not indicating you're rewording another commenter when you actually disagree with them if you don't want that difference in content pointed out.

I can see why you're upset but KerrAvon describes their statement as the result of "a cursory web search" and it isn't false so I wanted to be clear that what they wrote was not wrong per se. I don't think I "disagree" with a person who used Google, read some stuff and came away with an emphasis on the technical reasons this is a problem rather than how it's actually a problem for real programmers.

Maybe I do disagree with you, that's very possible.

With current C++ you could design a specialization that's somwhat less crap. But what's actually important - and what would actually happen - is that you would not standardize such a specialization at all because everybody knows it's a bad idea to do this - it would still be crap if you tried today, just less crap than in 1998.

C++ chooses to have a bad story for breaking changes. That's a deliberate choice and should be understood that way. WG21 are not hapless victims.

I definitely agree that the state of the committee's management of C++'s ability to have breaking changes is not good. Languages should really learn from how rust is handling that pattern, as it seems like it's working fairly well there. Though rust so far has a much shorter lifetime, and hasn't needed to make as large of changes as C++ has needed, the editions model (or something like it) with isolation between translation units seems like it's very workable as a general pattern.

A bool does automatically cast to an unsized bit slice.

Meaning, if you have a struct and you want to bit-pack your booleans, you can declare each one as, say, uint8_t some_bool : 1;

You may then do `x.some_bool = true;` etc.

It's a small nicety to avoid bitwise operators, anyway.

I do tend to think people under use bitfields.

I suspect this is because they are usually introduced like "here are bitfields, but DO NOT USE THEM for anything that might become ABI because their order is implementation defined". I think that causes people to mentally file it under <sketchy language features to avoid> when actually there are many contexts where the ABI risk is not real.

It's beautiful to see this perspective! The fact that we are at "whoa, C is fucked up compared to my expectations" instead of "look at Rust's fancy safety stuff" shows that as a field we've started lifting the baseline.

Nowadays I actually believe I'll likely see a world without memory corruption within my lifetime.

It’s definitely great that memory safety is becoming more pervasive. Though I’ll believe “a world without memory corruption” right up until another <insert your relevant hacker hero name> comes along and finds a way through an unsafe block, an FFI boundary, or the hardware itself (Rowhammer says hi).

> Rowhammer says hi

Yeah I was thinking of prefixing my "memory corruption" with "software-bug induced"! I don't see a credible solution to Rowhammer. ("DDR[n+1] fixes it" - lol)

> an unsafe block, an FFI boundary

Honestly these feel solvable to me at this point! I think we'll see:

- unsafe code shrink as languages get more powerful

- amount of analysis we can apply to each unsafe line shoot up exponentially as AI gets cheaper

- amount of FFI we actually need shrink as it gets easier to just click "rewrite it in $lang" on the decision card when your coding agent says "I found a library for that but it's in a different language"

(Having said all of that, people seem to be adopting Zig for some bizarre reason... So maybe I'm naive to expect unsafe lines to shrink)

(But also, maybe AI gets so good and so cheap that we can just type "go fidn all the bugs andfi xthenm" into an LLM, between sips of a Piña Colada)

I'm one of those people who's adopting Zig :) But I don't think it's best for every project. For context, I've used Rust before for probably two years writing a realtime audio synthesis engine, so I'm fairly familiar with Rust vs Zig for handling low level details.

The biggest reason I use Zig is it's a very explicit language. The creators made a very intentional decision to avoid too many "high level" designs. This doesn't mean there's no capabilities for abstraction (comptime is great for that), but when you see array indexing, you can think "ptr + index * size with bounds check". There's lots of other things like that where the language does exactly one thing, and that thing is a low level operation.

This is terrible when you want to create high level abstractions that hide details from the programmer, but it's what I need when doing realtime audio synthesis or what I'm doing now which is writing an interpreter. I know exactly what allocates, I know what calls IO and can block (both operations explicitly take in an allocator or IO parameter), no data structures have private fields so I can always poke around at the insides. I know what types of errors a function returns, and creating errors is cheap with Zig's error union design.

So I don't use Zig because I think it's the safer language, I know it has sharp edges because of the number of times I've caused a panic on a poisoned pointer or use-after-free. But because it gives me such a transparent view into what is happening I find it liberating.

My take too. (Aside from this being a well-written, clear article, that I think highlighted a fair selection of relevant points; especially the "always use uint8_t instead if int" part).

I don't see rust a "memory safe" language, or a niche one. I have complaints about it etc, but it's overall a fair baseline of reasonable decisions. When I look at C or other languages rust has learned from, I have more "Yikes, that's rough" takes. So... rust as the language of least "fucked up", to use your phrase? Ownership/safety are one part of the picture, but not what defines it for me.

I would say there are two big misconceptions here, which this article (and your comment) unfortunately reinforces.

The first is that it is "C is fucked up" instead of the poor defaults of the C implementation your are using.

The second one is the idea that C all has to be fragile low-level pointer fiddling instead of much safer high-level code build around abstractions, which good C would usually have.

Sorry but no, this is totally wrong. There is no set of compiler flags or design practices that can fix the lack of lifetime analysis in C.

I do actually think that with modern C++ it's possible to get to a style of programming where memory unsafety is mostly a theoretical concern but not with C.

It is true that you will not get full lifetime analysis with a C compiler, I do not think this defeats my point. (and you can get lifetime analysis with other tools, but we lack good tooling for this)

For me, memory safety is also mostly a theoretical concern in C. This is achieved by having proper abstractions instead of low-level pointer fiddling and by having a clear strategy for managing lifetimes.

The thing that defeats your point is that there is no consequential C codebase that has dynamic allocation and no UAF. There simply isn't an argument to be had here, it's an empirical question and it's settled. It's time to move on and adopt memory safe languages. There are no valid excuses any more now that Rust is basically tolerable.

If you wanna claim this is a skill issue and you are built different etc, fine. I guess we can just say C is fundamentally unsafe for _everyone except you_.

(This is like when people wanna argue about if self driving cars are safe or not and they're blathering on about technical capabilities and limitations. No. We have the data).

Focusing narrowly on memory safety is frequently a distraction that incompetent developers use to excuse their buggy code. "Sure, my Rust code might cause deaths and cause millions of dollars lost; and my code might be unsafe, insecure and incorrect; but at least my code is memory safe and easy to debug when I fuck it up!". And then it often turns out that Rust is not memory safe in practice. https://news.ycombinator.com/item?id=49697392

The real value of Rust is likely pattern matching and tagged unions. Apart from modules/packages that are not a disaster, like Gabriel Dos Reis the saboteur's disaster with modules in C++.

Were you intentionally rude with your first sentence or just unaware?

> And then it often turns out that Rust is not memory safe in practice. https://news.ycombinator.com/item?id=49697392

For what it's worth, in that specific instance there's no memory safety issue since Rust is guaranteed to crash on stack overflow on Ubuntu (and probably other supported Linux distros)

For what it's worth, this is not only that specific instance. Rust might not be memory safe in theory, but when talking about "in practice" - there is profound evidence that Rust's memory safety works.

this argument is so stupid, yes rust doesn't prevent all bugs but eliminating a large proportion of them is very obviously a good thing.

Indeed! They shrug it off when you ask them about supply chain safety or compiler complexity. I opine that post 1.0 they wasted precious engineering time trying to placate nodejs webshits over building the best systems language.

    There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.

        — C.A.R. Hoare, The 1980 ACM Turing Award Lecture

i suppose a supply chain that doesn't exist is pretty secure.

What would you have preferred the devs work on instead?

Does anyone know what the play here is?

(Is it given that there's a play? Waymo is culturally a little distinct from Google so from personal experience I can't actually rule out that they're just doing this coz they think it would be good for the world).

The way they mention the governor immediately made me think this is mainly to gain political capital.

I would bet it's part of the larger campaign by credit card companies to make contactless payment the only option for as many things as possible.

The more people use it, the easier it is to remove alternatives. Then everyone's movements and spending habits are tracked.

I suspect they are fielding complaints that autonomous vehicles increase road traffic, so they want to show that they are encouraging the use of public transit. Uber and Lyft have long been blamed for an increase in overall traffic.

I don't think it makes much sense to expect such a cohesive/specific philosophy from an open source project like this.

The goal is "Linux on Mac". In a commercial product, specific details of what gets built usually stem from a more detailed vision that can be articulated as one. In open source projects those details are determined by what individual contributors are motivated to work on.

That doesn't means a cohesive vision can't emerge, there might be one for Asahi actually. But I think the default position is that it's kinda just a mob of people doing what they each feel like doing.

I don't think it matters that Asashi is a generation or three behind, because the moment you really need it is when Apple stops updating the OS for your hardware.

When M1 drops out of support I bet Asashi for the M1 machines will be pretty polished.

Another thing is, the M1 and later hardware is still years later some of the best arm64 hardware youre going to find. Combine that with the really affordable prices you can find on the used market and Linux arm64 on this kind of great hardware at a low price is quite appealing.

I think LWN is not just the best linux news site or the best tech news site, or the best new site. I think it's actually the best website. I just can't think of anything else that comes close in terms of quality of information.

If you have any professional connection at all to Linux then $11/mo is an absolute bargain!

The Asahi folks have been making really impressive progress on Polishing Cloth drivers so I'm optimistic that we'll at least have a community solution for the E-waste in future decades.

I came to these comments coz I was curious about the AI usage here, and FWIW I also thought it smelled AI written, but I didn't think it was slop. (IMO not all AI output is slop and not all slop comes from AI).

My main question was "did Claude do the investigation by itself or just write up the article from someone's notes?"

Also though, I'm quite willing to believe this is human written and the human just happens to have a Claudey style. The actual prose isn't that Claudey it's just the structure of how it presents ideas. But, Claude had to get that structure from somewhere. It's not that surprising to see people with that style of communication.

Nope, I'm one of those lucky folks who was privileged enough to be accused of writing in a weird and probably too mature for my high school English paper-way before the advent of gpt, lol. I've had to all but remove the em-dash from my vernacular, thanks to the ~ plague of inauthenticity ~ as I call it.

I did all the digging, researching, writing, etc myself. The reason the screenshots are from mobile is because I wrote a lot of it literally in my notes app, on my phone before I started putting together more dots. I eventually asked gpt if I was correct in my understanding about refrigeration controllers doing XYZ and if it was plausible for them to be hacked in this way, when looking for some docs I asked if it would be standard to have XYZ part of a contract public and XYZ private, and other singular questions like that. I also use a browser extension for spellcheck that (I think) uses AI to suggest phrasing improvements, which I used pretty nominally.

Is there any type of sidebar/footnote that you, as a reader, would like to see to denote AI usage during the writing and/or research process? Would you expect none? I don't plan to do many investigations such as this (literally started because I was personally impacted) but I do have a few potential article seeds about defense procurement tech I've asked a few definition/research questions to AI about and would like to make sure I'm keeping tabs on it since this is something I want to be perhaps hyper aware of moving forward. Keeping in mind this is my personal substack and I would like to maintain integrity, but also, not doing really any groundbreaking work here. Intended to be an outlet for my thoughts, not news.

> Is there any type of sidebar/footnote that you, as a reader, would like to see to denote AI usage during the writing and/or research process?

It's not something I expect, but I definitely don't see an issue with people putting a couple of sentences in an "expand to see AI usage notes" tab at the top or bottom of the page.

> Would you expect none?

As in, would I expect no AI usage? Coz no I absolutely expect people to use AI.

If you had got Claude to do this investigation for you then actually I think that would have been notable enough to include details of your AI workflow. But not because "it's cheating not to disclose it", rather because you'd probably have come up with quite a neat workflow that is interesting in its own right.

It's funny coz it seemed like they also cloned the confusion.

I don't really understand what Claude Cowork is. Sometimes I use it instead of plain Claude Chat for tasks that "feel big"? And when I've done that I've felt this was the right choice. But until I actually had that session up and running I would not be able to articulate what Cowork is or enumerate any specifics of how I expected it to behave. I just thought "maybe this is a Cowork task?"

(I have only used the cloud one. My understanding is the the local app is essentially Claude Code but for non-coders, which matches the description of the OpenAI equivalent).

Even as someone who's now used it a few times I wouldn't have been able to articulate as many details as Simon W does in this article, it's a weirdly shaped product structure.

I echo this. It is not clear to me what the actual difference is.