bjackman

My extremely non-technical mum is using a 2008 MacBook Air on Ubuntu, it works great. Claude says the iMac is essentially the same to get running.

Only hassle was setting up the Broadcom WiFi drivers which aren't upstream, but I did this before I would have trusted AI with this task and even then it was not a big deal. I think these days running Linux on those things is likely trivial.

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).

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).

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.

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.

> 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)

> 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.

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.

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).

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 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.

> 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.

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.