jomar

> Except nobody uses the .us tld

This is a bug, not a feature.

Indeed. Back in 2018 and 2019 I expended a fair amount of time and energy reporting a squash 'n' merge metadata rewriting bug to GitHub and advocating for the behaviour to be changed. [1]

Once or twice someone internal to GitHub got interested... and then drifted away again. Years later the broken behaviour remains. And I'm a lot more cynical about thinking GitHub fundamentals might ever get any better.

[1] https://github.com/isaacs/github/issues/1368

Apparently it's about as expected for a southern giant pouched rat. But he was indeed a particularly good one!

> I think even the development system wasn't free either.

Metrowerks CodeWarrior was the original development system for PalmOS and was indeed not free (in either sense).

However a bunch of enthusiasts cobbled together some free development tools: the main parts were adapting the GCC and binutils m68k targets to PalmOS's constrained PIC runtime environment (it was constrained even by m68k standards); a tool to convert the resulting COFF or ELF executable to PalmOS's .prc database format; and a text-based resource compiler for generating UI elements using its own home-grown description language to express what CodeWarrior users were using a graphical UI editor to make.

That mostly still exists as it was back in the PalmOS days at <https://prc-tools.sourceforge.net>. And if you hunt around on GitHub you'll find a few people who've kept the code compiling with stricter more modern compilers.

(And see also <https://pilrc.sourceforge.net> for the resource compiler.)

Wikipedia says "ISO 8601:2004 established a reference calendar date of 20 May 1875 (the date the Metre Convention was signed), later omitted from ISO 8601-1:2019." I was curious what "reference calendar date" is supposed to mean.

Thanks to links in the SE thread, I found the relevant actual text in ISO 8601:2000 (I don't know how different it might be, if at all, in the 2004 document):

> The Gregorian calendar provides a reference system consisting of a, potentially infinite, series of contiguous calendar years. Consecutive calendar years are identified by sequentially assigned year numbers. A reference point is used which assigns the year number 1875 to the calendar year in which the “Convention du mètre” was signed at Paris.

This last sentence is simply an obtuse way to say "this year right now, as I [jomar] write this -- we call this 2025". Apparently the ISO committee did not want to refer to what was going on around 1 AD or felt that the missing 0 between 1 BC and 1 AD would lead to confusion or something, so instead used the birth year of the metre to state the bleeding obvious.

I'm another one who's had two colonoscopies. Try to schedule it for the morning so that most of the fasting time will be while you're asleep. The prep is not a lot of fun, but it's only about half a day and it's very much not as bad as gastroenteritis or anything else that'll give you a good bout of diarrhoea.

As noted above, what used to be a cool little Wellington-based company got bought by some offshore conglomerate. Lenz himself left about five years ago.

Probably the older email address is still the primary one for the GitHub account.

GitHub took it upon themselves to change email addresses and author names when merging via the UI buttons like "Squash and Merge" in 2018 and then again in 2019. See <https://github.com/isaacs/github/issues/1368> for the tedious details.

Essentially the post-2019 behaviour seems to be that where possible with "Squash and Merge" they will set noreply@github as the committer so that they can sign the merged commit themselves, and set author name & email to what they have recorded for the GH account involved (and the signature is then a record that GH have verified that account's involvement).

Personally I think it is shocking that they ignore the name and email address that the actual author of the commit has selected. This is both a violation of the author's intentions -- for example, you may set work and personal email addresses in different repositories as discussed here, but GitHub will rewrite them all to the same thing when other people press "Squash and Merge" on your pull requests -- and potentially a doxxing security risk.

I have considered re-reporting this to GitHub via the newer community discussions or via support again, but given the extent to which they've ignored all such reports over the last five years it is hard to find the motivation to do so.

Handy, but is it really easier to type? Or as pleasantly reminiscent of one of the first Unix commands you ever learnt, back in the days when they actually really were multiuser machines? :-)

That is a nice trick. I've had my main email address in .config/git/config, added an override in ./.git/config for projects that need it, and checked who I am from time to time with

    [alias]
        whoami = "!f() { echo $(git config --get user.name)' <'$(git config --get user.email)'>'; }; f"

but I might switch to your less error-prone approach.

Having said that, given that many people do use separate GitHub accounts for their separate private and work personas, and many organisations seemingly expect their employees to do so, perhaps GitHub could consider revising this Terms of Service restriction to better reflect reality.

There have also been times when I would like to have access to a second GitHub account for testing purposes. (In particular, for testing GH behaviour when the accounts corresponding to PR commits, PR creator, and PR merger all differ -- see for example <https://github.com/isaacs/github/issues/1368>.)

It's always been very clear in their Terms of Service (which obviously everyone reads carefully...):

The third bullet point at https://docs.github.com/en/site-policy/github-terms/github-t... --

> One person or legal entity may maintain no more than one free Account (if you choose to control a machine account as well, that's fine, but it can only be used for running a machine).

This is the primary reason why I have only ever used my own personal account for work stored at GitHub. If a company is expecting its employees to use a separate work GH account, one assumes that company is planning to pay for all those accounts for its employees.

Various government departments of those countries use domains under .gouv.fr, .gob.es, .gov.ro respectively. The argument is that fairness and clarity would suggest that the US likewise use .gov.us or some other convention of their choice under .us.

That was introduced in 1985, almost 40 years ago.

For how many decades is this going to be a reasonable argument?

In 100 years, will it still be reasonable for the USA to say "we built the thing, so it is appropriate for us to continue to be the default country in domain names. The rest of you must use your ccTLDs, but we remain special."

In 200 years?

The only non-pathetic option is for the United States to transition to using its .us ccTLD for governmental and military domains in particular, with .edu and probably some others not far behind. The only question is how gradual the process is, and when it starts.

Export $BASH_SILENCE_DEPRECATION_WARNING as described in the Apple web page pointed to by the nag message, or change your shell to your own version of Bash.

See also <https://apple.stackexchange.com/questions/371997/suppressing...>. I went with the "use an updated brewed Bash" approach, which has been working well. Using `sudo chfn` means you don't need to futz around with editing /etc/shells.

Zlib-ng doesn't contain the same code, but it appears that their equivalent inflate() when used with their inflateGetHeader() implementation was affected by a similar problem: https://github.com/zlib-ng/zlib-ng/pull/1328

Also similarly, most client code will be unaffected because `state->head` will be NULL, because they (most client code) won't have used inflateGetHeader() at all.

Prior to 1.2.13 released a few days ago, neither of these commits was contained in a zlib release. The CVE exists in the state of the code prior to that first commit, and is fairly obvious when you read the explanation in the commit message. The first commit fixed the CVE but introduced a silly null pointer deference, which was quickly fixed by the second commit and never appeared in a release.

Studying the code it's easy to convince yourself that the CVE description is correct and client code that does not use inflateGetHeader() is entirely immune to the CVE. Searching GitHub suggests that use of this function is uncommon, and certainly it's not used by any of the client code that I checked for potential vulnerability to this CVE. So all the client code that I checked was unaffected by this CVE.

Hence IMHO this particular CVE is not really a big deal, because very little client software uses the somewhat obscure inflateGetHeader() API function. I suspect this is why the zlib maintainers didn't seem to be in a particular hurry to get this release out, after the CVE was made public in at least August or early September and they had already fixed it in early August. (Me, I became aware of it in early September, so the vulnerability was publicly disclosed at least by then.)

I too was surprised to see these were shell scripts. I was expecting the grep/fgrep/egrep names to be hard links to the same executable that would check `argv[0]`, as the BSD implementation does.

More interesting than the commit diff is the brief discussion on the bug report from when this all happened a year ago, as referenced in the commit message: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49996

Sigh. Time to retrain the old fingers again...

Looking at the linked script, it indicates which cow orker to credit.

To the OP: You might be able to simplify the script by using `git commit --trailer …`. Or maybe you tried that and it didn't display the message in the editor window satisfactorily?

The scheme proposed in TFA is not particularly amenable to automation:

> Can I programatically convert from what I use now?

> Unfortunately, probably not

Moreover, even if a syntax-aware formatter could detect mistakes made in following this scheme, that presupposes that these coworkers will actually use said tools.

Some of us work in organisations where it is not politically feasible to insist that everyone work in any particular way or adhere to any particular standards. Welcome to academia…

Or just consider whether everyone contributing PRs to an open source project will get this right or use such tools.

This is nice in theory, but it will inevitably get screwed up by your less details-oriented coworkers.

The spaces and tabs are mostly invisible, so even if they did care about it these people can't really see the conventions that are in use. So the source code will inevitably accrue indentation done via spaces mixed up with the good lines indented via tabs, and then it's game over.

A script I have been working on lately is mostly tab-indented but has space-indented tracts and individual lines mixed in as it has been worked on by multiple authors over the years. When I started working on it, I thought the indentation was just plain borked (with the subclauses of if statements indented less than their if lines, etc). But then I discovered that setting tabstop=2 made most of the space-indented lines line up properly -- turns out this script was written to a 2-space indent (crazy narrow by my standards!) using tabs, with a few space-indented lines mixed in on the same scheme. Until another author came along some years ago with their tabs set to 4, and added some space-indented lines written to line up with the 4-space tabs they were looking at. So now there are several incompatible categories of space-indented lines in this 200 line source file.

The real argument from the spaces camp is that their approach is the only realistic compromise with reality: by banning explicit tab characters in source files on disk, there is no room for error.

(Except that the same coworkers are wont to include trailing whitespace or omit the final newline, but at least that sort of invisible difference does not affect reading the indentation.)

TFA is a war story about how infelicities such as caching in tools and “those darn browsers” contributed to the identification of the cause of this issue taking longer than it should have.

Once the missing intermediate certificate issue had been identified, the fix (to the server) was indeed clear. But it's not stated whether the author is in charge of the server in question (it's only mentioned as “couldn't connect to a particular HTTPS site”); I suspect this was some external web site not under their control.

If you want a separate clone you know where to find it, but then you will be plagued by the uncertainty I mentioned in my other comment (https://news.ycombinator.com/item?id=30400869).

I did not say that was the only sane way to use worktrees. I frequently use them for separate strands of ongoing work (on separate branches per work strand, named appropriately). Less common (for me) is the use case of easy reference to older versions, with more ephemeral worktrees checking out a tag, a new branch (created for the purpose, and short-lived), or a particular commit (viewed as a detached HEAD).

If you had two worktrees set to the same branch and made a new commit in one of them (thus changing the commit the branch ref points to), what would happen in the other worktree?

Either it wouldn't have the right commit checked out anymore, or git would have to miraculously change what files are checked out in it -- which would likely come as a big surprise to whatever you were doing in that working tree.

Ergo, it is forbidden.

I periodically find myself creating a new (temporary) branch referring to the same commit when I want a new worktree looking at the same place, or just create a new worktree with a detached HEAD looking at the same commit.

When you're done with a worktree, you just delete it (via `git worktree remove`). Any additional branches or stashes etc are part of the repository that the worktree was part of, and they (of course) remain.

When you're done working in a separately cloned repository in another folder, if you're anything like me, before deleting it (via `rm -rf`) you'll want to check very carefully for additional branches, unpushed work, anything stashed. Deleting an entire repository that's been around for a while is a risky operation in that it may have accumulated other unrelated work in addition to the current branch (which was the primary reason for the clone), and you'll want to check carefully before deleting the whole lot.

Additional worktrees within the same repository are great for medium-term ephemeral separate strands of work. They can be created and removed without concern.

> For a specific doc fix, a PR is indeed the way to go. If it's not a simple fix, creating an issue on the tracker may also be called for.

That is precisely what I did. As noted, there has been no indication (by activity on the issue or PR) that having filed these helped or is appreciated. Hence discouragement.

It is one of the hard lessons of open source maintainership that, without providing feedback to contributors, there is no demonstration of the project's appreciation. Therefore new contributors will (correctly!) conclude that the project does not appreciate these efforts.

I agree with everything you say, and alluded to much of it in the parent post. I myself also volunteer happily on a number of projects, and attempt to keep up with similar deluges on those projects.

For someone like myself who is not already a core Python maintainer, how would you recommend making improvements to things like the Python documentation if not by raising pull requests?

For a one-character typo, I would probably have just reported it as an issue. An issue is sufficient to say what fix is needed, and in some ways it's easier for a maintainer to make such a fix themselves than to verify a change made by an external contributor, correct the commit message, verify their CLA status, etc.

However my experience of reporting Python documentation issues has been frustrating for other reasons. I reported a lack of detail in the multiprocessing.Process.exitcode documentation in October:

    https://bugs.python.org/issue45554

Nearly three months later, no-one has commented on the bug report -- not even to triage it. Fair enough, it is a minor issue, people are overstretched particularly with the current world situation, and perhaps proposed fixes would be of more interest.

So in late November I set about improving this documentation myself. I found the CLA process relatively straightforward, though I was unimpressed that the online signing via Adobe Sign refused to work in an incognito window. Emailing a scanned signed paper form was an effective and straightforwardly handled alternative.

I filed a PR with a proposed documentation improvement in mid December:

    https://github.com/python/cpython/pull/30142

Apart from one drive-by comment from a non-core contributor, no-one has commented on the pull request -- not even to approve running the remaining basic workflows. Also fair enough, it has only been a couple of weeks outside the holiday period, and it is a minor issue.

By now the PR is on page 4 of the cpython repo's list of open PRs, so it is difficult to imagine anyone getting back to it except by accident. The Doc-SIG mailing list appears to be mostly moribund, so doesn't appear to be a good place for a nagging message.

All in all, I'm not feeling encouraged to spend time making what are intended to be useful (albeit minor so far) contributions.

A small Perl script <https://github.com/jmarshall/manconvert> that grinds a subset of man page nroff syntax directly into HTML. (That subset being “the constructs that are used in the man pages that it's used on”.)

Some of the styling could be improved (those section headings for one!), but IMHO it produces better results than other more general-purpose manpage to HTML converters: see e.g. <https://www.htslib.org/doc/samtools.html>.

Dude, you seem to be very keen to put words into other people's mouths. Perhaps you should reflect upon that.