hifromwork

When I was a kid, my CRT sometimes switched to a wrong resolution (it got narrower, so squares became slightly rectangular, for example). I say "my CRT", because that was a hardware, not software issue. I know, because kid-me solution was to smash the (hard, brick) wall with that CRT. And it worked. I still don't know why, I was too young to investigate - and hey it worked so why bother.

My parents were less impressed, when after a few years the screen was moved and the wall was scratched everywhere.

Oh, I like that solution! My problem with dates is indeed lack of reproducibility.

The only issue here is that it's not technically monotonic - both commit and author date are changeable:

    $ git init
    Initialized empty Git repository in /tmp/kk/.git/
    $ echo a > a; git add .; git commit -m a
    $ echo b > b; git add .; git commit --date="Wed Feb 16 14:00 2011 +0100" -m b
    $ echo c > c; git add .; GIT_COMMITTER_DATE="Wed Feb 16 14:00 2011 +0100" git commit -m c
    $ git lg
    * 523aa1a - (2024-11-28) c - user (HEAD -> master)
    * cbdbbbe - (2011-02-16) b - user
    * 1055e1e - (2024-11-28) a - user
    $ git show --no-patch --format=%ci HEAD
    2011-02-16 14:00:00 +0100

But I guess if you use a typical pull-request based workflow this won't happen in practice.

I'd like to hear your alternative. What do you propose? That we stop even trying to tackle this problem, and all libraries are sequentially or date-versioned? And you can pin to, for example, library version built from march last year to today?

That would be a huge mess, IMO. Of course for non-libraries semver is fairly pointless, but for libraries it describes a contract and that contract works well in practice. But maybe there is a better way - hence my question.

>Time is sequential. Otherwise, sequential build numbers are kind of hard to orchestrate in a distributed architecture

Time is sequential, but this means that just building an older version is now a production breaking incident. That's weird to me, but I'm not a CD person.

You are downvoted (probably for saying "nope"), but my account was recently banned for being a bot. I used it almost exclusively for lurking, rarely for commenting or upvothing something. I guess I'm too botlike.

I know we all have our pitchforks out, and I hate tracking as much as everyone else here, but "tracking" is a very broad term, and is not always malicious. Unless you want to outlaw access logs, for example.

I didn't downvote you (I'm just reading this thread for the first time), but I don't get your original argument. Usually benchmarking two languages means either:

* microbenchmarks comparing speed of doing stupid things (like adding 10000 integers or sorting a list with bubblesort 1000 times)

* 'real world'-ish benchmarks comparing idiomatic solutions in two languages doing the same thing

In both cases it doesn't matter (much) how big a standard library is. If you want to compare two languages doing something complex, you need to have -standard or not- implementation of that something for both languages.

But maybe I (and possibly others) have missed your point?

Hyrum's law is specifically about how every change is a breaking change if you have enough users. So it's always a bit subjective. No sane person considers changing an error message a breaking change in context of semver. It's just go going above and beyond to take care of backward compatibility.

I assume you never tried to add a contact form to your website.

Explanation: I did, and within a few days bots started sending me spam using that form. I just added a trivial captcha (hardcoded '2+3=' question), but if my scale was bigger that would be untenable. Think also of PM spam, autoregistering accounts to abuse free tiers, etc.

>You could add "I don't care about fixing security vulnerabilities" somewhere in the beginning of the readme

I care about fixing security vulnerabilities in my OS projects, but I care more about my sanity, my family, getting enough money to survive, and a few other things. Unless you pay me I don't care about your problems with my free (as in a beer) software.

And that's a good thing btw - I tried to ask for donations once, got the equivalent of a few cups of coffee per month, and... burned out almost immediately. I started to feel responsible for that project, staying up late to fix reported minor bugs, and it turns out watching Github issues 365 days a year for a few dollars monthly is not a great business strategy.

Six days for me:

>Your account meets this criteria, and you will need to enroll in 2FA within 45 days, by November 8th, 2024 at 00:00 (UTC). After this date, your access to GitHub.com will be limited until you enroll in 2FA. Enrolling is easy, and we support several options, starting with TOTP apps and text messages (SMS) and then adding on passkeys and the GitHub Mobile app.

I think the exact deadline depends on the organisation. I know that I only enabled 2FA for my throwaway work account (we don't use github at work, and I didn't want to comment using my personal one) last week.

That's a quick jump from "in my opinion" to "you have no clue about".

I mean, the author is probably not a programming language design specialist, but I feel that's overly harsh - they hopefully learned a bit when working on this toy project.