davemp (u/davemp) - Readit News

davemp commented on Synadia and TigerBeetle Pledge $512k to the Zig Software Foundation tigerbeetle.com/blog/2025... · Posted by u/cratermoon

davemp · 16 days ago

Very good news. Happy to see Zig getting more investment. I already use the build system for production systems and am looking forward to writing some more Zig when projects allow.

Having a modern language that attempts to directly model low level systems is very important.

davemp commented on We built a cloud GPU notebook that boots in seconds modal.com/blog/notebooks-... · Posted by u/birdculture

binaryturtle · a month ago

I remember visiting a computer exhibition (CeBIT) in the very early 90s. In one booth they had some of the big Amiga systems (2000, I think) and at some point on of the booth's staff did the 3 finger salute (press 3 specific keys on the keyboard to force a reboot) on one of the machines. The machine was back up in what felt like an instant. I was amazed by that. They probably had setup the whole boot process via RAM (see "RAD" disk on the Amiga), but I hadn't any idea about that back in the days.

Still to this day I think this is how it should be. You want to switch ON your computer and it should be ready for use.

But what do we get? What feels like minutes of random waiting time. My Raspberry PI with Linux which probably eats 10 of those Amiga 2Ks for breakfast shifts through through a few 1000 lines of initialising output… my Mac which probably eats like 50 of those Amiga 2Ks for lunch… showing a slowly growing bar doing whatever… Why didn't this improve at all in the last 30 years?

davemp · a month ago

Windows prioritize phoning home and data collection over UX. If you have a corporate install you’ll also have negligent EDP software killing your boot times.

You can get fast boot times on linux if you care to tweak things.

davemp commented on Simple trick to increase coverage: Lying to users about signal strength nickvsnetworking.com/simp... · Posted by u/tsujamin

metadat · 2 months ago

You know, I don't recall ever seeing 1 bar of signal strength on a smartphone. And once it's down to 2 bars, it barely works, if at all.

Human brains: wow, what a bunch of suckers. Damn.

By the way, is it legal to be deceptive in this way?

davemp · 2 months ago

I’ve always just blamed the extreme bloat of the web and lack of design around poor connections for 2bar lack of performance. HN usual works fine on but that’s about it for sites I visit.

davemp commented on Hard Rust requirements from May onward lists.debian.org/debian-d... · Posted by u/rkta

zozbot234 · 2 months ago

The safety guarantees of Rust the language around unsafe are just as good as C or Zig if you use the appropriate facilities (raw pointers, MaybeUninit, UnsafeCell/Cell, Option for nullability, Pin<> etc). Sometimes this is made unnecessarily difficult by standard library code that expects all the guarantees of ordinary Safe Rust instead of accepting more lenient input (e.g. freely aliasable &Cell<T>'s), but such cases can be addressed as they're found.

davemp · 2 months ago

My point is that it’s easier to write correct Zig code than correct unsafe Rust. Raw pointers can be null in rust so you should use NonNull<T> but there’s aliasing rules that are easy to mess up. And difficultly with the stdlib as you mentioned.

I don’t actually mind Rust when I was able to write in safe user land, but for embedded projects I’ve had a much better time with Zig.

davemp commented on Hard Rust requirements from May onward lists.debian.org/debian-d... · Posted by u/rkta

zozbot234 · 2 months ago

Basically correct, but Zig is not a memory safe language. It may be an improvement wrt. syntax over C, and its standard library facilities may be genuinely better than Rust's wrt. writing unsafe code, but it's simply not interesting from a safety perspective. I'm sure that even the most rabid Zig advocates would readily acknowledge this point.

> Garbage collection is a huge dealbreaker for the people still on C/C++.

The problem is not so much GC itself, but more like pervasive garbage collection as the only memory management strategy throughout the program. Tracing GC is a legit memory management strategy for some programs or parts of a program.

davemp · 2 months ago

Rust technically isn’t a memory safe language the second you use “unsafe”. Rust advocates tend to pretend the can have their cake and eat it too when comparing it to other low level languages. No, just because you have the word unsafe next to the scary parts doesn’t make it okay.

I’ve written a good chunk of low level/bare metal rust—unsafe was everywhere and extremely unergonomic. The safety guarantees of Rust are also much weaker in such situations so that’s why I find Zig very interesting.

No oob access, no wacky type coercion, no nullptrs solves such a huge portion of my issues with C. All I have to do is prove my code doesn’t have UAF (or not if the program isn’t critical) and I’m basically on par with Rust with much less complexity.

davemp commented on Keep Android Open keepandroidopen.org/... · Posted by u/LorenDB

sham1 · 2 months ago

Yeah, this is pretty much the rationale behind the Paradox of Tolerance, which you alluded to. Just as a tolerant society cannot tolerate intolerance without eventually just becoming intolerant, this clearly demonstrates that the same is true for Free Software. If we tolerate the use of Free Software for the use of the non-free software, eventually one loses the freedom in Free Software.

It's of course not a perfect analogy since the original Free Software still exists, but since in practice the dependency was from free towards non-free, like in this instance, it still works. Google and its anti-freedom practices are still in effective control of the Android ecosystem even though it's still technically free by way of AOSP.

And just as how some people argue that intolerance of the intolerant by a tolerant society is bad, so do some people argue that things like the GPL is bad because it prevents downstream modifications etc. going from free to non-free. Maybe this will help re-evaluate the culture around this stuff.

davemp · 2 months ago

> Paradox of Tolerance, which you alluded to. Just as a tolerant society cannot tolerate intolerance without eventually just becoming intolerant

I’ve always thought this was hand wavy nonsense. Tolerance and tolerating is so ill defined in these discussions that they end up pointless.

I’m also not sure game theory supports that intolerance wins out if you view it as repeated instances of the prisoner’s dilemma.

davemp commented on Solving the Wrong Problem ufried.com/blog/ai_assist... · Posted by u/erlend_sh

ajkjk · 2 months ago

Feel this strongly. That all of the "autocomplete"-style improvements that LLMs to programming are indications of massive deficiencies in programming: we're in many ways stuck in a ~2010-era model of what programming is, which is actually quite medieval and useless.

Probably programs as "text that you run on a computer" is, long-term, not how anything is going to be done. After all, what is a prompt but a (lossy, error-prone, inexact) specification for a program, or at least part of a program, before you go in and modify it by hand? The code itself is just an interchange format, no different than JSON. Can we formalize that abstraction such that the prompt is an exact specification, just, at a super high level? AI-text generation makes it faster to write text, but no amount of text-generation gets around the fact that maybe text generation is... not... what we should be doing, actually. And the LLMs are going to be better working at that level also.

I really wish the people geeking out over LLMs would be geeking out over radical new foundational ideas instead. Picture Bret Victor-style re-imaginings of the whole programming experience. (I have loads of ideas myself which I've been trying to find some angle of attack for.) Hard work at improving the world looks like finding radically new approaches to problems, and there are loads of ways to make the world a better place that are being distracted from by the short-term view of working entirely in the existing paradigm.

davemp · 2 months ago

Programs aren’t text that you run on a computer though. Programs are text that describe an abstract syntax tree which encodes the operational semantics of the thing you’re computing.

Maybe (likely) you could come up with a more convenient set of operations, but I don’t really see how expressing that as plain text ast is really holding things back.

davemp commented on IDEs we had 30 years ago and lost (2023) blogsystem5.substack.com/... · Posted by u/AlexeyBrin

tombert · 2 months ago

Maybe it's Stockholm syndrome for me, but I never really understood what was so unusable about the vanilla command line git interface.

If you want to do some really advanced stuff, sure it's a little arcane, but the vast majority of stuff that people use in git is easy enough. Branching and committing and merging never seemed that hard to me.

davemp · 2 months ago

imo git does a terrible job of showing its state so when anything more complicated than committing changes you really have to have thing internalized.

davemp commented on A kernel stack use-after-free: Exploiting Nvidia's GPU Linux drivers blog.quarkslab.com/./nvid... · Posted by u/mustache_kimono

jibal · 2 months ago

You won't get anywhere with people who just like to argue.

Note that the mention of Zig that I responded to was in reference to Tony Hoare's "billion dollar mistake", which was making null a valid value of a pointer type, not free after use, which is a quite different issue. As I noted, the mistake doesn't occur in Zig because null is not a valid value for a pointer, only an optional pointer, which must be unwrapped with an explicit null test.

I do think it's a bit too easy to forget a deferred free, although it's possible for tools to detect them. Unfortunately Andrew Kelley is prone to being extremely opinionated about language design (GingerBill is another of that sort) and so macros are forever banned from Zig, but macros are the only mechanism for encapsulating a scoped feature like defer.

davemp · 2 months ago

> You won't get anywhere with people who just like to argue.

Yeah not really sure why I bother. I think I just get bothered that Rust gets touted everywhere as a silver bullet.

> Tony Hoare's "billion dollar mistake", which was making null a valid value of a pointer type

It’s funny how we got stuck with his biggest mistake for decades and his (probably not entirely his) algebraic types / tagged unions have just started to get first class support now.

davemp commented on A kernel stack use-after-free: Exploiting Nvidia's GPU Linux drivers blog.quarkslab.com/./nvid... · Posted by u/mustache_kimono

tialaramex · 2 months ago

You were correct about the lack of billion dollar mistake in Zig, once I'd decided to list some "C replacement" languages not just C and C++ I should have either checked they all make exactly this mistake (Odin does, Zig does not) or removed that part of my comment.

However actually in practice for this nVidia bug Zig's "defer" is just irrelevant, which is why nVidia's "fix" doesn't attempt the most similar C equivalent strategy and instead now performs a heap allocation (and thus free) on the happy path.

There's a kernel Oops, likely in someone else's code. When that happens our stack goes away. In Rust they can (I don't happen to know if they do in Rust for Linux but it is commonly used in some types of application) recover from disasters and unwind the stack before it's gone, such as removing the threadState from that global state. In Zig that's prohibited by the language design, all panics are fatal.

davemp · 2 months ago

What a crap, disingenuous argument.

A kernel oops isn’t a panic at least however zig or rust defines a panic. So zig saying things about panics don’t apply here.

Rust fails here the same exact way if drop semantics aren’t upheld (they aren’t afaik). Also Rust’s soundness goes immediately out the window if UB happens in unsafe code. So immediately when a kernel Oops happens safety is moot point.

I’m not sure if Zig has a clean way to kill a thread, unwind the stack, and run deferred code. Zig is a pre-1.0 language after all so it’s allowed to be missing features.