mjw1007

When was "today" when that was written?

I never liked the way he used TCP as an example here.

I don't think it's sensible to think of "make it reliable" as a process of abstraction or simplification (it's obviously not possible to build a reliable connection on top of IP if by "reliable" you mean "will never fail"). "You might have to cope with a TCP connection failing" doesn't seem to be the same sort of thing as his other examples of leaky abstractions.

TCP's abstraction is more like "I'll either give you a reliable connection or a clean error". And that one certainly does leak. He could have talked about how the checksum might fail to be sufficient, or how sometimes you have to care about packet boundaries, or how sometimes it might run incredibly slowly without actually failing.

The old documentation often wasn't good.

But if you're trying to replace an existing system, it's a mistake to think "the old system had poor documentation so it's OK for the new system's documentation to be poor too", because people have already learned to cope with the old system.

I've seen people make that mistake distressingly often in recent years.

> Hyrum's Law isn't about what you should do, or how things should be, it's telling you an observable fact about our world

But it isn't.

Neither Hyrum, nor anybody else, has ever seen a system where "all observable behaviors" were depended on by somebody. And if they somehow had, they couldn't know that it hadn't mattered how clear the documentation had been.

There are two much weaker statements which I think are true:

- "No matter how carefully you document your contracts, it will happen from time to time that you leave something unstated and people reasonably guess wrongly what you intended."

- "No matter how carefully you document your contracts, from time to time some people will choose to rely on things you didn't promise, without caring about that."

As well as actually being true, these statements have the advantage of not falsely implying that you can't improve the situation by putting effort into documentation.

That is emphatically not what I am "getting at". I cannot express my opposition to that approach strongly enough.

I do not believe that the place people should hold documentation is "in their heads".

I do not believe that Hyrum's "Law" is helpful in getting to a situation where people's beliefs about what software will do match reality.

This isn't the first time I've come across people (particularly around the Rust community) who have got the idea into their heads that saying "reading documentation is important" is somehow close to saying "Real programmers don't make mistakes". I think that conflation is doing great harm.

Yes, the relationship between "Hyrum's Law" and having a terrible documentation culture is strong.

The important part of the "Law" is the bit where it says "it does not matter what you promise in the contract".

That's definitely going to be true in a place where neither writing nor reading documentation is taken seriously (and one of the main things this site teaches us is that Google is such a place).

If I'm considering reporting a bug I came across in a free-software project while at work, that's already something I probably couldn't justify with a strict cost-benefit calculation for my employer.

In practice my employer would be happy for me to spend my time doing it anyway, because it's the right thing to do. But asking them to pay Github for the privilege is pushing it.

I think the main lesson here is that a scripting interface that lets you make major changes to an application, including building UIs, is a great deal more valuable than one that only lets you plug in to extension points that the application developer has already thought of.

This was, of course, a large part of the reason why Firefox was successful in the days when it was successful.

I don't think the idea that things are "very different from the way things were when Stallman began" is very relevant to this. After all, Emacs is one of the best examples of an application whose scripting system has this sort of power.

I was thinking something along the lines of people who tend to set unusually high standards for themselves.

Rust has something of a self-image of always being best-of-breed in everything it attempts, so I could believe that it might be particularly attractive to those sorts.

Other possibilities might be that Rust developers skew younger than average (I don't know whether that's true), or that its six-week release cycle attracts people who think that a year is a long time.

I think, from observation, that the Rust project has worse burnout problems than most other similarly-sized open source projects.

I'm not sure whether it's more to do with the way the project is organised, the state of the codebase, or the sort of person that's attracted to working on Rust in the first place.

Have Google actually documented what they mean when they say DMARC is mandatory?

Does a DMARC record with p=none count?

Does DMARC with an SPF record that that places no restrictions count?

The theory that Red Hat users are supposed to be paying for development of the system is a recent one. What Red Hat used to say is that the software is free and their users are paying for support.

That made a great deal of sense, as of course Red Hat themselves were shipping a great deal of software written by other people without paying for its development.

There's nothing confusing about people declining to go along with this change.

The GCC Ada frontend is written in Ada (and has been maintained that way in the gcc source tree for well over twenty years now).

That RFC is accepted, and this is starting to happen.

Progress has been disappointingly slow, but the project is alive, and has potential to speed up next year.

https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio...

True. The traditional binding was was just `C-x x`, but they've already done one round of making register features more inconvenient to get at.

I see this advice a lot, and I think it's making the problem worse.

The most common form of bad documentation I come across is simply documentation with pieces missing: it uses terms without defining them, it tells you what problem an option is intended to solve but doesn't say what effect it actually has, and so on.

One possible cause is the "empathy" theory: the author missed that bit out because they assumed the reader already knew it. But I think it's more common that the author just did a half-way job, because we don't have a documentation culture that takes being complete and correct as the minimum baseline.

If that's the case, I think the advice authors need is to _not_ spend so much time thinking about what their reader is trying to do, and spend more time thinking "is what I've written complete?".

If the X11-and-Wayland maintainers had put X11 up for adoption that might not have been the case.

That is, they might have said "We're looking for new maintainers for X11. They will be responsible for its future direction, representing X11's interests to the kernel and to distributions, and deciding when (and if) X11 is to be declared deprecated."

As far as I can make out, what they did instead was say "We're looking for people to fix bugs in X11, but they won't get to make any nontrivial decisions."

The attribute for controlling this is implemented but not yet stable: https://doc.rust-lang.org/beta/unstable-book/language-featur...

I'm not so relaxed about how easy it will be to move to a new issue tracker.

When you're moving from a self-hosted system to a proprietary system, you can do the work yourself to make sure there are redirects from the old URLs to the new ones.

That option isn't likely to be available when you're moving the other way.

I observe that github is happy for you to "bring your own domain" for github pages, but AIUI issue and PR URLs are always under github.com .

I agree. I'm not, at this stage, tremendously worried about Microsoft finding ways to use its control of Github to get its own way in some kind of conflict.

I am worried about what happens if, or when, Github's owners decide it's time to stop caring about having a good reputation and instead squeeze it for as much profit as possible (what we seem to be calling "enshittification" these days).

Pointing git remotes somewhere different shouldn't be a huge pain, but all those issue trackers are a different matter.

I think we already give Github far too much influence over the free software world without also paying attention to who they see fit to hand awards to.

I wonder whether Github would have considered the PSF to be "wonderfully welcoming" if they hadn't switched from their self-hosted bug tracker to Github's offering last year.

Personally I don't find being asked to read [1] before I can submit a bug report at all welcoming.

[1] https://docs.github.com/en/site-policy/github-terms/github-t...

I think a lot of it is that there was pent-up demand for a language like Rust.

Rust feels like the language that in 1990 I was promised I would have in the year 2000.

Over the years I've done a fair amount of reworking documents from "he or she" style to "they" style.

I've found that using "they" style does quite often make it harder to be clear, when you've got a sentence that's talking about both a person and some things.

Something like

"Then the operator must update all the rules. They must ensure that no bad things happen."

Does the "they" refer to the operator or the rules?

Of course you can always rephrase to make it clear again, but you're losing a certain amount of freedom of arrangement that you might have wanted to use for other purposes.

One reason CPUs don't trap on overflow is that it lets them use the same instruction for unsigned values and two's complement values.

The instruction can then set one condition code that means "if you intended this as an unsigned addition, the answer was out of range" and a different one that means "if you intended this as a two's complement addition, the answer was out of range".

Their motivating example is dealing with a function that needs to both indicate success/failure and return a value on success.

One option is to make this a first-class feature of the language, rather than sugar for something else.

Icon (from 1977) is interesting here.

https://en.wikipedia.org/wiki/Icon_%28programming_language%2...

CSS was to a large extent a Microsoft project (when the time came to introduce stylesheets it was more-or-less Opera and Microsoft against Netscape, and Microsoft had many more users than Opera).

Nonetheless Microsoft managed to use CSS to achieve a great deal of user lock-in by refusing to conform to the standard they co-authored.

I don't think you're being an idiot.

There are some connections in mathematics that are quite "magical", where you get something like a correspondence between a family of curved surfaces and a family of integer-valued equations, and it's not at all obvious why that might be until you study it deeply.

And sometimes articles about the Curry-Howard Isomorphism suggest that it's an example of that sort (I think this article does, to some extent).

But (as I understand it), that isn't the case: here we have a simple directly-constructed correspondence. It's valuable, but not the sort of thing that mathematicians think of as a wonderful result.

Nowadays there is a configurable tramp-allow-unsafe-temporary-files variable, which defaults to annoying me by prompting.

Does a licence that says "you must distribute the source unmodified, but you're allowed to distribute patches with it and a build system that applies them" count as free?

The DFSG said yes.

Does a licence says "you may modify this and redistribute it as much as you like, but if you put it on a CD then everything else on there must also be free" count as free?

The DFSG said no.

I get the impression that some people think of crates.io as purely a place for distributing arbitrary Rust free software, while others think it's also a place where people are building something like a community-developed "batteries included" standard library for Rust.

I think a fair amount of unpleasantness in recent years has come from this disconnect: some people think that by publishing on crates.io you're making some promises (that they might not assume simply for, say, having a repository on github).

To me, using an extremely generic name like 'base64' does suggest that you're in the second camp, and so that you might expect to have a conversation that feels more like "we're equals building this project together" than "I'm the maintainer and my judgement is all that matters".