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.

And, as we know from Hyrum's law[1], every change might be breaking ;).

Oh, you added a bar() method to Frobinator? Shame, this other project depends on the fact that Frobinator only has one public method. And that project distinguishes Frobinators and Barinators by checking bar() method existence.

And you fixed a bug where username returned from API had a space appended at the end? But my frontend developers used that for layout and now my site is broken.

Written partially in cheek, but it's true that every change is breaking for someone if you have enough users.

[1]See https://www.hyrumslaw.com, Wikipedia entry, recent discussion on HN, and of course that one xkcd.

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.

You need to rely on one of the four trusted publishers. You can't do it yourself: https://docs.pypi.org/trusted-publishers/adding-a-publisher/

Even more, the previous way was to use GPG signatures, which were recently deprecated and removed. So you don't really have a choice.

>Where the only official workflow is "Use GitHub Actions".

Well you can do it manually with other solutions... as long as they are one of the four trusted publishers (see "Producing attestations manually does not bypass (...) restrictions on (...) Trusted Publishers":

https://docs.pypi.org/trusted-publishers/adding-a-publisher/...

This means that you literally can't do it manually, you have to rely on one of:

* Github

* Google Cloud

* ActiveState (I'm not familiar with it)

* Github.com (not just github, only that one instance)

Really surprising development, IMO.

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.

>They'd be wasting their time and making their lives needlessly harder, though.

Using Kubernetes where it's not needed is just that - wasting your time and making your life harder.

Before you say that I just need to research more: I know Docker swarm mode, I run my personal server on Kubernetes using Traefik and Let's Encrypt, I professionally work with Kubernetes (both as an admin and working on Kubernetes security, which is tough to get right), most services in my dayjob run on Kubernetes, and I was the person who introduced CI/CD pipelines there some years ago.

I still claim that there are production usecases that are better served by docker-compose.

How is 400MB trivial? I run more than 2 programs at once, and this adds up. Imagine if every trivial process in your OS used 400MB on startup. And what pisses me off, is when I have to close resource heavy electron applications (signal, vs code) running in the background to free up RAM.

Hi! I'm not from the US so I probably miss the cultural context. Are the words you listed considered offensive? With exception of maybe "xe", this seems more like a list of controversial topics, not words, which is a completely different thing. If I understood you correctly, I don't think it's relevant in context of the article posted.

Fully agree. As a non-native English speaker, I always thought English doesn't have "real" curse words, and the only actual (taboo) curse words I know are so-called "n-word" and similar.

It's hard for me to explain the difference, but (as an educated and relatively eloquent person) I would really hesitate (as in, physically struggle with my throat) to curse in my language aloud in a public place. Saying them among my friends or family would be seen as between mildly offensive and absolutely unacceptable. When hearing someone curse in public, I instinctively assume they're uneducated or intoxicated.

Meanwhile, i can freely swear in English among the same people (and online, and in most situations abroad). My mother, who I have never heard curse in my language, says "shit" like it was "oh darn". I see English swear words everywhere online. They really don't feel like a taboo to me.

We all live in our own bubbles. I never saw a tech person using MacOS, it's always Windows or Linux - I assume that's not your experience either (and I only know a few people using MacOS privately). That probably mostly depends on the country one resides in.

But we're talking about writing laws here. For example:

>with only minimal requirements made of the driver.

could easily be changed by changing the requirements.

25% trivial code sounds like a reasonable guess.

>In the PEP, Larson argues that providing PGP and sigstore signatures fails to give downstream projects any incentive to adopt sigstore. So long as CPython continues to provide PGP signatures, there is little motivation to adopt sigstore.

No better way to convince people to use a standard than forcing them. Taking away choice by force sounds a bit contradictory to the idea of Open Source. I mean, maybe sigstore is a better idea, but why not let people make their choice.

I agree, but in my very walkable european neighbourhood I don't see any vending machines either (except on the train stations, in waiting rooms, etc). Granted, there are small shops every corner, so vending machines don't feel necessary, but sometimes it would be useful to have some.

>just put up some initial capital in exchange for even more money back, is always a scam. some people might come out ahead sometimes, but more people will lose than win.

How so? My all-world index funds are doing pretty well. For more risk averse, almost every buyer of USA governmental bonds gets "even more money back" in exchange for the initial capital. I don't think that's a scam either.

I see your point, but it's hilarious that I can ask AI "Write a python program that takes an URL parameter, connects over http to that URL, interprets the response as a CSV file and prints a sum of integers in the second column. Use argparse for command line parsing" - pure science fiction a few years ago - and you call this a "boring low-hanging fruit". Truly we humans get used to the good stuff quickly.

That sounds like an useful tool for willing users, but if forced that sounds genuinely dystopian. And I'm afraid the people who would benefit the most (conspiracy theorists) wouldn't opt into that.

>Outside of science people invent random units, they just say three football fields or 70 school busses. Which works just fine, aside from taking effort to write and maybe making some readers feel insulted.

Is this something people do? I only saw this in English (American I guess) online articles.

Seems to be OK now:

    int mseal(unsigned long start, size_t len, unsigned long flags)

This is not my experience with Windows users. Tree hierarchies are very natural for us humans.