samueloph

Yeah, the definition of "portable" being used is one that is not useful for most users, the fact that it's not in Fedora and neither Debian is a sign of it. Especially considering the demand for ghostty, it's a very cool project.

Someone willing to distribute ghostty has to pull in a whole programing language stack just for it, ghostty seems to be the most important project written in zig so far.

For the definition of portable that matters to me, this is the least portable possible, if it was written in almost any other language it would have been more portable. And yes, this all goes away once zig is onboarded to all distros, then it becomes "empirically portable", but we're not there yet.

PS.: "Portable" meaning which CPU architectures are supported is not a very useful meaning of the word for me, even though it's more accurate, it says nothing about the ability to actually build and run it in different OSes.

exactly, that's why in my opinion the patches should have been made available straight away instead of doing this, it made it worse.

Deciding to announce it like this is wild, it's an invitation for everyone to put their agents to work in order to find out what the vulnerability is and exploit it, while nobody is allowed to patch it until tomorrow.

You can test it on Debian experimental, or use a Debian container:

$ podman run debian:experimental /bin/bash -c 'apt install --update -t experimental -y curl && curl --version'

Version 8.13.0~rc3-1+exp1 is syncing to the repositories and has HTTPS RR support enabled.

> In unstable you get a timely fix from upstream, in stable you get a fix by the security team.

For anything that is serious enough, you will get a security fix straight away for both unstable and testing (through the testing-security repository).

For things that are not really that important, yes, you will get the fix later.

> We should be able to fix this within the next few days, thank you!

It's fixed now, should work in non-linux environments.

argh, we are looking into fixing that now.

I knew getopt was linux-specific but I thoughts the only impact was that the long form argument (--opt) would not work. I turns out it doesn't run at all instead.

We should be able to fix this within the next few days, thank you!

> There is also --remote-header-name (-J) which takes the remote file name from the header instead of the URL, which is what wget does.

I don't think that's the case, that behavior is opt-in as indicated in wget's manpage:

> This can currently result in extra round-trips to the server for a "HEAD" request, and is known to suffer from a few bugs, which is why it is not currently enabled by default.