Curl 8.0.1 | Hacker News Reader

Curl 8.0.1

daniel.haxx.se

196 pointstapanjk97 comments

Comment section reminds me of those for VLC. No clue why people complain about free stuff no one forces them to use. Like, just pay someone to implement DNSSEC if you really need that in curl, or write it yourself.

Tried to leave a friendly comment, but apparently the database is hugged to death...

> Replace this text with the error page you would like to serve to clients if your origin is offline.

> No clue why people complain about free stuff no one forces them to use

Just like roads. Nobody forces people to use them, you know; sure, some people might want to use them, to go for some place for some other non-road-related business but that's just their problem.

On a more serious note: people complain about "stuff" when they try to use that "stuff" to do something and it doesn't work no matter whether it's free or not, it's just human nature. As for "forced to use"... if you need to make a network request from command line, the options are basically curl or wget. Neither of them support your use case? Well, you can always just give up and not do whatever you intended to do, nobody forces you to achieve things anyhow.

Roads are not free, we pay taxes so that the government maintains them, like every other public utility.

Open source software is not a public utility and not paid for with tax money, therefore your analogy is flawed.

I guess this should be the revert he mentioned, for those interested:

https://github.com/curl/curl/commit/c2df780a97d9913eb20a55d4...

I always find it a small miracle that you can yank an individual git commit out of a program, and end up with a working program. If I commit anything, follow-up commits quickly make the original quickly a hard requirement.

Maybe it is a sign of bigger and more stable source code, that individual commits influence each other less.

Working on new, small bits of software often implies that a single commit will be more relevant to the rest of the codebase. The more code there is, the less any one particular line, on average, would matter.

Making smaller and atomic commits makes them more easily reversible.

Atomic meaning they can be reverted on their own; I'm sure plenty of people make the mistake of making small commits, but not atomic commits.

If your git history looks like a work log, you're not writing atomic commits.

And people should get comfortable with git commit --amend and interactive rebase.

I'm a nobody, but surprises me that the revert (and so the original feature) didn't include any tests. I always imagined that a project like curl (no deadlines? no pressure? no bosses?) would lead to people to work on it at their own pace (so more tests maybe? Maybe not, I don't know)

It was a performance optimisation, so I suppose it should be covered by existing tests as there should be no change in behaviour

Ah, good point!

It did in-fact have test coverage, from tfa:

> Apart form the little bug that caused it to crash in several test cases. (...)

> Exactly why this was not discovered in our tests and CI jobs before the release we have yet to figure out, but it is certainly more than just a little disturbing.

This looks like an integration point, which are pointless to test.

This happens every single time I make a new major release of a piece of software I maintain. There is always some mistake—even a typo in documentation—and it's the tiniest possible mistake, and there is always only exactly one mistake, but it's always enough to bug me so much that I have to make a patch release just to fix the one single mistake.

Some software developers are just cursed.

Yep, have definitely done this once or twice with Chalk. I don't recall a time that a X.0.0 wasn't immediately followed up with an X.0.1 release for some dumb mistake I made.

And that's why I never trust/use x.0.0 releases because they must have missed something :)

Same reason why many people wait a couple of days before updating their OS to the next major version.

Sorry did you say days? Still on macOS 10.14 after almost 5 years. It'll be fine~

Is not a curse, it’s probability and statistics. If you make a major release, you touch a lot of places and there’s a higher likelihood of introducing a bug.

I review it 10 times before I make the release and spot nothing, but then spot something only immediately after I release it. Just like how I can only spot typos in emails after I've already sent them.

Looking at the comment section I feel assured that comments are a thing of the past. I wonder if those people would take the hurdle to send an email instead.

The death of the comment section has been greatly exaggerated...one comment, that the moderator didn't even see fit to remove. Ain't much.

Also funny that you wonder if people would take the hurdle to send an email instead. In this particular case, the author has in fact written about the torrent of email abuse he faces on multiple occasions, for example here [1]. Is his 2021 post evidence that email is a thing of the past?

https://daniel.haxx.se/blog/2021/02/19/i-will-slaughter-you/

> one comment, that the moderator didn't even see fit to remove. Ain't much.

It's not only about the comments we can see, but also about those comments that get filtered out by the moderator

> Also funny that you wonder if people would take the hurdle to send an email instead.

Of course you also get non-friendly emails. I was wondering if the people that leave those comments would send an email instead.

> filtered out by the moderator

If that's what he left in and responded to, what do you think he's taking out?

> wondering if the people that leave those comments would send an email instead

The evidence presented is that he gets abusive emails with a comment section...why would he get less emails if he closed the comment section?

Of course he will not get less email when closing the comment section. The question was if he will get more email abuse when closing the comment section.

From experience, yes. "Those" people will send an email, add you on LinkedIn, and call you landline if they don't like the content of your blog.

You mean the single flagged comment? There are more comments talking about the bad comments than there are bad comments.

At the time I wrote my comment here there were only one comment from Taran telling us what he gives about the topic and Daniel's reply to it. Should have made this more clear. It was to expect that comments will explode from HN visitors.

Well, they didn't, so this thread just ended up polluting the comment section with the very noise it sought to lament. HN comments in my experience are far more reasonable than you're describing, and the entitled "free stuff" attitude only comes up in response to things like big corporations yanking support for a project (see: Docker). Everyone loves curl and nobody is complaining about the amazing software built and maintained primarily by a single developer.

I don't know who you are replying to. I never spoke about 'free stuff' nor the quality of HN comments.

Bumping the major version for fun is actually a pain, since configure scripts set upperbounds on major versions to be future-proof, anticipating breaking changes. Now it's just another edge case to deal with, and old versions of curl-dependents to patch.

I thought the 8.0.0 was justified by dropping support for platforms without 64-bit integer types?

Dropping support for a group of platforms is definitely something I'd consider a breaking change.

I do not consider that a breaking change because they are no longer supported. Prior versions of the application will still run. Breaking changes to me are at the API level for SUPPORTED platforms.

Typically removing support for a platform is considered breaking, because users on those platforms can still run the previous versions, but cannot upgrade beyond the point where support was dropped. Very commonly seen in various Node libraries dropping support for old LTS releases coming out of support, for example.

Removing support for a platform is 100% a breaking change, regardless of the circumstances or reasoning.

But it would break builds for those platforms, and unless the change was marked as breaking, they would be silently incorrect and/or need to go and implement special-casing on the versions in their build systems as the parent comment said.

I think that's a breaking change by most definitions.

In fact, it does break builds. I've seen it personally with several Go libraries: they drop support for e.g. Go 1.12 in some minor version and then suddenly "go install ./..." step in your CI stops to work. And since we're talking about Go 1.12, that is, pre-module days, fixing that entailed either a) upgrading your whole project to use modules; b) changing the build pipeline to explicitly check out the last working version of the library's repository into GOPATH in the pre-build step.

This is particularly nasty when it happens in mostly stable, rarely-updated internal projects because what was supposed to be a 5-minute, 3-line update turns into a several hours long wrangling match. Apparently, the code does rot and rust or something.

Prior versions did not get their version bumped...

I'd rather deal with that than the team at Google who maintains the grpc Go library who are more than fine breaking the public API in minor changes.

https://github.com/grpc/grpc-go/issues/3798

If you read the first comment, you’ll see the API was documented as being experimental.

https://github.com/grpc/grpc-go/issues/3798#issuecomment-670...

I'm clearly in the camp of "you can add and depreciate (experimental) features all you like in minor versions, but you should only remove them in major versions" camp.

See the discussion on semver and experiments: https://github.com/semver/semver/issues/238

That's the rule for normal features, that would mean there is no meaningful difference between stable and experimental parts of an API.

Hyrum’s law. Rust mostly gets around this by requiring you run the nightly compiler and library in addition to explicitly opting into experimental pieces.

That's only true for a small portion of software released. I have an idea about where this fixation in semver comes from, but I can't really believe that everyone here is a web dev who wasn't around before semver started getting traction.

It isn’t “for fun”.[1] The project apparently just doesn’t support the versioning scheme that you allude to.

If you want this project to use a particular versioning scheme then you should just argue for that directly.

[1] Other than this snippet :) : “on curl’s 25th birthday made it extra fun”

Should've instantly bumped it to version 9.0.0 instead of 8.0.1

Or copy what Windows did and jump straight to 10!

Curl 98 SE was the best Curl.

Curl 2000 was the best to me.

Curlhammer 40k is the ultimate one.

CurlEL 3.0 was the best. He could try to release Curledora for exciting new features.

Since there is no /s at the end I will assume it was not a joke. Most versioning schemes assume logic behind bumping numbers, please check for example „semantic versioning 2.0.0“

> Since there is no /s at the end I will assume it was not a joke

Definitely a sane policy on the internet.

Since there is no /s at the end I will assume it was not a joke. This is definitely not a sane policy on the internet.

I think the parent might be referring to this: https://news.ycombinator.com/item?id=35228608

Is there a commitment from curl to use semver? If not, all the discussions about why the bump to v8 is void. We know a huge project that doesn't stick to semver and update major version whenever they want: Linux Kernel.

Ofcourse we wish everyone would use semver...

If Linux used semver, it'd never go past 1.x. Public kernel API never breaks, ever. So what's the point for semver?..

If Linux used semver

Solaris tried something like this for a while. While their competitors were releasing versions 4, 5 and 6 of their OS, Solaris was releasing version 2.4, 2.5 and 2.6. This made it look like they were just doing minor updates to Solaris, when they were in fact major new versions. Eventually they gave up and renamed solaris 2.7 to Solaris 7 just to keep up with the version numbering.

Not because of competition, but Emacs¹ and MiKTeX² also dropped the major number from their versioning schemes.

¹ https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS.1-...

² https://github.com/MiKTeX/miktex/issues/554

Java did it ages ago (1.5 and 1.6 became 5 and 6; I forget if 7 and 8 were also 1.7 and 1.8 originally)

> If Linux used semver, it'd never go past 1.x. Public kernel API never breaks, ever.

Yep:)

> So what's the point for semver?..

Exactly that: To trumpet it to the world - this project never broke compatibility, accept no substitutes.

Except it did. Multiple times. And I vaguely recall one incident where they couldn’t revert although maybe I’m misremembering.

> The Linux ABI definition is both fuzzy and controversial. Some ABI breaks are unavoidable. [1]

[1] http://she-devel.com/Chaiken_LinuxABI.pdf

Ultimately it sounds like the policy is actually 0 “reallly bad ABI breaks” where “bad” is a subjective evaluation of how many bug reports they get or breaking something foundational (eg pulse audio). It’s just not possible to freeze the ABI because people may have found kernel bugs and worked around them and the fix for the kernel bug breaks the workaround. That’s what Hyrum’s law means and the Linux kernel doesn’t have a unique solution here. Don’t get me wrong. They do a fantastic job all things considered. But the “never break ABI” is more marketing than a hard and fast rule (but yes they generally get as close as is feasible to sticking to it)

ABI ≠ API. The ABI is a property of the program, the compiler (including options used during compilation), and the target platform. Semver only concerns itself with API, ABI isn't even a consideration there.

I doubt many practitioners of semver would agree that changing the behavior of a function in a breaking way would technically be a ok because it only covers the API signature. Semantic versioning frequently means “non-major version is ok to blindly update and not only will the code still compile it’ll also behave the same way at runtime”, branding notwithstanding.

“Public api never breaks” as OP posted, for example, is a reference to the Linux ABI policy

Linux kernel user facing APIs never break? It really depends on what you consider user facing. If you’ve ever relied on or considered sysfs to be a user facing API there have been numerous and severe breakages over time in the Linux kernel.

I think gp was referring to Linus Torvalds somewhat famous mantra to "never ever break userland, ever"

Quite a few engineers has seen the sharper side of his tongue for not taking that mantra seriously enough

Sure, he does rant about it, but the user facing APIs break constantly none the less.

A relevant example from yesterday: https://lore.kernel.org/lkml/CAHk-=wjifBVf3ub0WWBXYg7JAao6V8...

Linux is more than just an API, its support of platforms changes over time for example

Sure, the point is that semver cares only about the API. Thus it's not really applicable to anything but userland libraries.

The joke is 8.0.0 did not break API.

To never use the first release of any major version is confirmed as a good policy again ;-)

> Exactly why this was not discovered in our tests and CI jobs before the release we have yet to figure out

Oh, just because the tests can't imagine what the environment on all those hundreds of millions of client machines is :)

Bugs not being caught by tests seems like a big deal. I recently discovered a bug in the nodejs repl and couldn't get the tests to fail, even though there was a consistent infinite loop. It made me think about how many other tests are not surfacing bugs. It seems this is an example of at least one more.

I personally use wget because you can download files without any extra flags.

Curl more equivalent to cat as a unix tool, making it easier to use in pipes. If your only use case is downloading then wget might look more practical

Yup. curl for when I want to see it, wget for when I want to save it. No shame.

Or `wget -S` when you want to save it AND see the headers.

alias wget="curl -sL -O --no-clobber"

Update: Based on comments from @xorcist and @stabbles:

alias wget="curl -fLsS --no-clobber --remote-name-all"

That will only download the first argument. You need

  --remote-name-all

instead of -O (--remote-name) to download all arguments files. It was in my opinion a mistake in the curl cli that remote-name works like output and needs to be repeated for each url. Remote-name-all is what rename-name should have been all along.

The curse of a non-breaking API...

Not the same... you need: `-S` to print error messages and `-f` to return exit code on non-200 responses.

Also, --no-clobber is very recent (v7.83), so unlikely to work in general.

So `curl -fLOsS ...`

Or just use wget ;)

The best thing about curl is that developer tools of browsers (firefox for example) have a convenient "Copy as curl" feature that mimics the web request. The reason there isn't a "Copy as wget" option, I think, is the level of control that curl allows so the request can be tailored to exactly mimic the browser.

But when you want to recursively download a website, of course, nothing better than wget. curl doesn't support that, and you'll need to parse and fetch the urls recursively yourself with a script.

You can paste that curl command into https://curlconverter.com/wget/ to turn it into a Wget command.

> The reason there isn't a "Copy as wget" option, I think, is the level of control that curl allows so the request can be tailored to exactly mimic the browser.

That's not true. You can read the code that generates the curl command, it's pretty straightforward:

https://github.com/ChromeDevTools/devtools-frontend/blob/c9a...

The arguments it uses are --url, --data-raw, -X/--request, -H/--header, --compressed and --insecure, all of which Wget has an analog of. I think the reason is that they don't care to do it and/or they don't want to make that "Copy" dropdown too long.

Copying from the web and pasting in a terminal, is that not a bad practice from a security viewpoint?

The command comes from a text field of the developer tools, which are provided by the browser vendor, not the websites.

It allows you to repeat a request that the browser did, but in your own terminal. It only downloads data, but doesn‘t run downloaded scripts.

Ok, I misread that.

    curl https://example/file >file

But what if you want to send an API request?

uhhhh i wonder why the guy behind curl doesn't have a responsive website. Yeah I get it, he's a c++ developer and web design is not his job but it's not that hard

LMAO

Reply on news.ycombinator.com