lubutu

I initially read "the order of files in /etc/ssh/sshd_config.d/" to mean the order of files in the underlying directory inode, i.e. as returned by `ls -f` — and thought, "oh god"... But the lexicographical order, that's not too surprising.

I mean, no. If you work on a codebase that's been going for more than a few years, the author likely doesn't even work there anymore. The commit is the important thing.

C23 has constexpr, albeit only for objects, not functions. The code also uses namespaces, as in `std::aligned_alloc(P, T)`.

Meanwhile, Kerberos (also Project Athena) has been at version 5 since September 1993.

There has been recent work on RPC-with-TLS (RFC 9289), xprtsec=mtls.

> NFS still sucks (IMO it sucks more than it used to)

Any chance you could elaborate?

The distinction I suppose is that what you really mean is "the difference in [necessary] skill level between a burger flipper and an accountant".

I suppose such feedback could be used for reaching a fixpoint. Suppose you have a build system that reads targets to be built from stdin and outputs to stdout targets that are dependent on that target and must now be rebuilt. With an ouroboros, the build system will continue to run, even if the dependency graph is dynamically cyclical, until the fixpoint is reached and the build terminates.

I mean, learning Haskell has made me a better programmer even if I've never used it at work.

Perl I have used. I wouldn't say the same about that...

It does make sense — the Unix debugger has always been *db, with no bridges in sight.

https://en.wikipedia.org/wiki/Advanced_Debugger

You can do...

  <access.log head -n 500 | grep ...

... though that's less familiar to many, I'm sure.

> So the idea is really "what's the point of having a history full of broken state?".

I rebase commits so they don't break the build but the history remains clean and incremental. Selective fixups and so on isn't the same as squashing everything into a single commit.

> This would be a hint that your PR was too big and addressing more than one thing.

I don't think so. Sure, that can be true, but squashes can also simply lose vital history. Suppose you remove a file and then replace it with code copied and modified from another file. If you then squash that, all Git will say is you made a massive edit to the file.

You're not the only ones, but I can't understand this approach. Do people never then read the version history? It must be impossible to understand commits' diffs with the changes all squashed together.

It's not by the same person — sta.li was by Anselm R Garbe. It's more like a spiritual successor.

Thanks for sharing!

  ; these produce an error, since `b` isn't defined when the body of `a` is compiled
  let a = \x -> (b x * 3),
      b = \x -> (a x / 2)

It surprised me when this was called out, given that both a and b are defined in the one 'let'. Was there a specific reason you decided not to treat it as a 'letrec'?

Lurrus into Dead Weight — that's a nice start.

I think this is the one thing I feel BitKeeper does better than Git. Git can get confused about where a file came from, for moves but especially for copies, and so the version history ends, even if you ask it to try and follow along. BitKeeper, on the other hand, keeps the moves and copies as part of the history, so you can always trace it through to the origin of the file, no matter how circuitous.

I looked around and found an AMA [1].

> Python, using the Twisted framework for networking.

> Omegle runs on just one server: a Linode 2880. It used to be on a 720, which was very close to sufficient. No database at the moment, but if it never needs one, I'll most likely use PostgreSQL.

[1]: https://www.reddit.com/r/IAmA/comments/9vbd7/i_made_omegleco...

When I was looking for work back in 2012 there was a company who advertised their way of working as "infrared", if I remember correctly. It was all about total openness and autonomy. For example, they asked one employee to decide how many hours everyone should work per day, and they decided on something, which was then applied company-wide. This was apparently "democracy in action". Quite odd. I think they've since dropped that whole thing.

You know another project with much of its source files in the top-level directory? https://github.com/git/git

It's in bash(1) under "Process Substitution" — https://manpages.debian.org/bookworm/bash/bash.1.en.html#Pro...

> Phispher - use javascript to show a phisphing page

Do you mean phishing? I searched for "Phispher" thinking it might be a particular tool or something, but nothing turned up.

The same is true in Norwegian, but then they go and ruin it all with "oldemor" = "great grandmother", instead of persisting with e.g. "mormormor".

No, they're saying they can't imagine it happening at a private company, but can once the company has gone public.

That works for new code, but I'm much less keen when maintaining legacy code. Sure, you could reformat every file and then proceed to work on them, but then you've had a serious impact on the version history, worsening tools like git blame and often making it harder to understand how a particular piece of code evolved. It's even worse if one reformats and then makes a code change in the same commit...

To expand, Brzozowski introduced derivatives and Antimirov partial derivatives. Essentially the former correspond to DFAs and the latter to NFAs.

> accounting for patient, procedure, surgeon, anesthesiologist, and hospital characteristics

This suggests to me that they have accounted for that to at least some degree. (I can't read the paper itself so I don't know the details.) At the very least I don't think one can simply dismiss the findings out of hand citing "if you think about it."

I've heard that some well-off parents will even send their children to schools with attendance fees...

It's unsurprising given the way it was phrased — very US-centric, and essentially that "if you disagree with me, you're as bad as Putin's soldiers in Ukraine"? Hardly the best way to encourage friendly debate.

Very sad to hear. I interacted with him only a couple of times, but each time I came away with a very good impression of the man. And, of course, I'm very thankful for the editor he created that I've been using daily for over a decade now. He will be missed by many, and I'm sure intensely by some. Rest in peace, Bram.