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.
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.
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.
You should list your side projects if they've been influential in some significant way, e.g., if they've developed a large user base, become a dependency of some other noteworthy project, or changed how other people approach similar problems. If you're merely proud of the code, then don't list them directly; instead, pin those repos on your GitHub profile and link to it from your résumé.
If there's some deeply legalistic answer explaining how the IRB correctly interpreted their rules to arrive at the exemption decision, I believe it. It'll just go to show the rules are broken.
IRBs are like the TSA. Imposing annoyance and red tape on the honest vast-majority while failing to actually filter the 0.0001% of things they ostensibly exist to filter.
How in the world is conducting behavioral research on kernel maintainers to see how they respond to subtly-malicious patches not "human subject research"?
Last time I applied for job through a headhunter (2010), they ran my LaTeX resume through an automated .doc converter that destroyed all the formatting and then didn't even attempt to fix any of it. Somehow I still managed to get some interviews, and when I saw the printout on the interviewer's desk I shrieked in horror and handed him one the original paper copies that I'd luckily had the foresight to bring with me.
So am I! Permissioned blockchains (essentially, as you say, distributed databases) are the motivating use case, but I'm excited to discover what uses other people come up with.
The CIECAM02 and CAM16 color models include a "hue quadrature" correlate from which "redness/greenness" and "yellowness/blueness" can be calculated. I find changing the hue quadrature by 200 (which flips the signs on the latter two quantities) gives results that match my own perception of "complementary" pretty well.
Oldie but goodie! I remember submitting this to very early Reddit, getting seven upvotes, and this keeping it at the #1 spot on the page for multiple days. I'm a credited contributor and sometimes I list this on résumés as a gag.
There are certain classes of creative work that especially turn this essay on its head: writing a textbook, typesetting a page, creating a film as an homage to a particular time period or genre. To do these things exceptionally well means noticing and meticulously following conventions that nobody realized existed before you did.