dfranke

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

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.

[Lisp macros] by their nature would be hard to implement properly in a language without turning it into a dialect of Lisp.

Camlp4, Template Haskell, and Rust procedural macros all serve as counterexamples to this claim.

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.

I hope we eventually get Presburger arithmetic support so that one could write

    fn concat<T,M,N>([T; M], [T; N]) -> [T; M+N]

Thanks. I should file a bug about this against the Linux man-pages project.

I think it uses thread-local storage like errno does, but I'd have to verify.

Clear your floating point exception register by calling feclearexcept(FE_ALL_EXCEPT). Convert to long by calling lrint(rint(x)). Then check your exception register using fetestexcept(). FE_INEXACT will indicate that the input wasn't an integer, and FE_INVALID will indicate that the result doesn't fit in a long.

Edit: check for me whether just calling lrint(x) works. The manpage doesn't specify that lrint() will set FE_INEXACT, but it seems weird to me that it wouldn't.

Reproduced from feedback that I gave pg on an earlier draft (omitting things he seems to have addressed):

When you say,

But I also believe it will be possible to write efficient implementations based on Bel, by adding restrictions.

I'm having trouble picturing what such restrictions would look like. The difficulty here is that, although you speak of axioms, this is not really an axiomatic specification; it's an operational one, and you've provided primitives that permit a great deal of introspection into that operation. For example, you've defined closures as lists with a particular form, and from your definition of the basic operations on lists it follows that the programmer can introspect into them as such, even at runtime. You can't provide any implementation of closures more efficient than the one you've given without violating your spec, because doing so would change the result of calling car and cdr on closure objects. To change this would not be a mere matter of "adding restrictions"; it would be taking a sledgehammer to a substantial piece of your edifice and replacing it with something new. If closures were their own kind of object and had their own functions for introspection, then a restriction could be that those functions are unavailable at runtime and can be only be used from macros. But there's no sane way to restrict cdr.

A true axiomatic specification would deliberately leave such internals undefined. Closures aren't necessarily lists, they're just values that can be applied to other values and behave the same as any other closure that's equivalent up to alpha, beta, and eta conversion. Natural numbers aren't necessarily lists, they're just values that obey the Peano axioms. The axioms are silent on what happens if you try to take the cdr of one, so that's left to the implementation to pick something that can be implemented efficiently.

Another benefit of specifying things in this style is that you get much greater concision than any executable specification can possible give you, without any loss of rigor. Suppose you want to include matrix operations in your standard library. Instead of having to put an implementation of matrix inversion into your spec, you could just write that for all x,

    (or
     (not (is-square-matrix x))
     (singular x)
     (= (* x (inv x))
        (id-matrix (dim x))))

If you do stick with an operational spec, it would help to actually give a formal small-step semantics, because without a running implementation to try, some of the prose concerning the primitives and special forms leaves your intent unclear. I'm specifically puzzling over the `where` form, because you haven't explained what you mean by what pair a value comes from or why that pair or its location within it should be unique. What should

   (where '#1(#1 . #1))

This is completely knowable, by taking repeated measurements of a reference object, one which was either checked by a more precise instrument or is definitionally correct (e.g. the old reference kilogram or the Greenwich meridian)

I've never seen the convention you're using and I don't think I understand it. Conventions I've seen include:

* Give an error bound like 45.73490534578° (±0.00002°) and indicate in prose that this is a 2σ bound.

* Put non-significant figures in parenthesis, like 45.73490(534578)° (EDIT: possibly I've misinterpreted this one when I've seen it, see logfromblammo's reply)

* Put a bar over the last significant figure, like 45.73490̄534578 (hopefully this one renders properly when I post this... (EDIT: nope))

People have this idea that when you take a measurement, you have so-and-so number of significant figures that are probably correct and the rest are just pure noise. But that's not how measurement error works. In the real world, physical measurement errors are more-or-less normally distributed (we don't have to argue about the "more-or-less" part because my argument here holds for any distribution other than a uniform one). Let's say your measurement gives you a latitude of 45.73490534578° with a standard deviation of 0.00001° (that's about 11 meters). Those last few digits of your measurement are almost certain to be wrong. But does that make them meaningless? No! Because if your measurements are unbiased, then slightly more than half the time, 45.73490534578° is still going to be closer to the true value than 45.7349053457° is. By performing significant figure rounding, you aren't throwing very much information, you may not be throwing away any information you care about, but you are nonetheless throwing away information.

That won't work. When we say "constant-time code" what we really mean is "code whose running time is independent of its input". It won't really be constant due to factors like the OS scheduler and the initial state of the CPU's instruction cache.

What you really want is https://github.com/agl/ctgrind or something similar.

As one of the people who would be getting phone calls about all the software that breaks when EST gets redefined to be four hours behind UTC rather than five, I'd really not want to go to there. Either of "EDT is now year-round" or "The east coast of the US is now on AST" would lead to a lot fewer problems, as changes of that nature have to be dealt with pretty regularly.