dfranke

This behavior is required, possibly by accident, by the WHATWG spec. Chromium and other V8-based browsers take the spec literally and implement this behavior. Spidermonkey (Firefox) and Node don't.

This isn't an HPC cluster. It's just btrfs on my workstation.

Yes, I'm aware, and POSIX has many such bugs that make command input or output unavoidably ambiguous if certain unexpected characters are present that they didn't think to prohibit. A lot of the revisions that went into POSIX 2024 were aimed at fixing some of these, such as standardizing find -print0 and xargs -0. The fact that this one got overlooked doesn't mean it's a good idea to make the situation worse and harder for future POSIX revisions to address.

Allowing purely numeric usernames seems like a terrible idea to me, because it creates ambiguity between what's a username and what's a UID. It's common for tools like ls or ps to display a username when one is found and fall back to displaying a UID if it isn't, and similarly tools like chown will accept either a UID or a username and disambiguate based on whether it's numeric or not. Now suppose there's a numeric username that doesn't match its own UID, but does match some other user's UID. It doesn't take a lot of imagination to see how this would lead to vulnerabilities.

I retrained myself on Barchowski last year. Barchowski and its close cousin Getty-Dubay are italic rather than looped, and a lot easier to read for someone who only ever learned print.

Author of the essay here. I did a double take at seeing it posted here because I thought it was completely forgotten, nearly including by myself. I think the actual date of this essay is 2007 or maybe 2006, because I remember writing it from my university computer lab and I was class of '07. Anyway, there's certainly a lot of water under the bridge since then and the political composition of hackerdom today looks nothing like it did 15 years ago. With the growth of the FAANGs there are far more hackers today than there were then, and the younger ones are a lot more likely to be leftists than libertarians. Still, though, when I travel in libertarian circles it's pretty clear to me that hackers are overrepresented there, so I think the reverse remains true as well, even though it's not as dramatic or obvious as it was in the '00s.

It probably wasn't the only thing affected. It's just flipping bits in encryption keys has much more dramatic and obvious effect than flipping other random bits in memory. Flip a bit in a raster image and you get one funny-looking pixel. Flip a bit in an AES key and you completely corrupt all the data handled by that key.

Steno devices are well-known to the speed typing community. Some competitions allow them, some don't. You can't bring this to one that doesn't for the same reason you can't bring a F1 to a stock car race.

That's what mmap is for.

You're not up to your elbows if somebody else has already done the work for you. If the input to your macro is a valid production in Rust, then all the parsing work that's incumbent on the macro author is to write

    let ast = parse_macro_input!(input as Foo);

Where foo is some type defined by the `syn` crate and there's one for every production in Rust's grammar. But neither are you limited to those. You can also extend or replace that grammar as you see fit, but in that case the added parsing is on you.

Haskell and Rust both pass this. The input doesn't even have to be a production in the source language; you can parse it any way you'd like.

Common Lisp macros are precisely "compile time code execution that enables syntax manipulation". If by "runtime generation of code" you mean to include executing that code after it's been generated, that's not macros, that's `eval`.

Just as use of `eval` tends to be discouraged in Lisp land, it's not something that a Haskell or Rust programmer would often reach for. But in Haskell, if you really want it, GHC has an API and you can have the whole power of the compiler available to you at runtime. This isn't really a language feature per se, it's literally just linking in the whole compiler and calling it like an ordinary library. I'm not aware of anything similar to that in Rust but I haven't really looked. However, if you're only trying to generate code and not JIT-compile or execute it, the same Rust crates that support compile-time AST manipulation (like `syn` and `quote`) can equally well be used at runtime.

Implementing a modern, production-quality compiler is not easy as a baseline, but nothing in the design of OCaml, Haskell, or Rust adds any significant obstacles, relative to Common Lisp, to supporting this feature. Slinging an AST around and dropping it into a quasiquoted template is a well-understood problem. The simplicity of Lisp's syntax is not a prerequisite and hasn't been since the parsing techniques that were developed in the 1970s.

Done properly? I can't speak to camlp4, but at least in the case of Haskell and Rust, certainly. Incidentally I just had my first occasion to write a Rust procedural macro last weekend. I had a significantly complex transformation written and working in half a day, learning curve included, and I found it all pretty frictionless.