Live data from Hacker News

Microsoft cURLs too

daniel.haxx.se

31–40 of 107 posts

Re: Microsoft cURLs too

#31
post #23
post #2

Either the Curl developers are at fault somewhere, which I somehow doubt, or distributions are really special snowflakes, which I also doubt, or software distribution in the Open Source world is, in my opinion, flawed: > Finally, I’d like to add that like all operating system distributions that ship curl (macOS, Linux distros, the BSDs, AIX, etc) Microsoft builds, packages and ships the curl binary completely indepen…

I can think of a few reasons (1) Use of a different libc (alpine linux with musl) (2) most builds are not reproducible, rebuilds are needed for security reasons (3) non-rolling release distros (-> most distros) fork the upstream projects to backport fixes for their older releases (4) Different filesystem structure (Gobo Linux) (6) Most distros want to use the build system associated with their own package manager The…

> In the future we will most likely have an distro-specific basic system build and container apps (snap, appimage, flatpak) build directly by upstream on non-server systems.

I sure hope not. A better system would be something like NIX/GUIX or even Gobolinux, that give us a single package as today, but with the option of installing multiple versions in parallel if upstream has screwed up the API (again).

Flatpak and like will just be and excuse for upsteam to bundle everything and the kitchen sink, resulting in bloat and having to update a mass of paks rather than individual libs in case a flaw is found.

Re: Microsoft cURLs too

#32
post #10
post #2

Either the Curl developers are at fault somewhere, which I somehow doubt, or distributions are really special snowflakes, which I also doubt, or software distribution in the Open Source world is, in my opinion, flawed: > Finally, I’d like to add that like all operating system distributions that ship curl (macOS, Linux distros, the BSDs, AIX, etc) Microsoft builds, packages and ships the curl binary completely indepen…

Rebuild is necessary for things as trivial as changing the default install path. It's absolutley standard; a Linux distro that doesn't rebuild packages somewhere would almost not count as a distro.

Hmm. All the various Ubuntu derivatives (eg, Hanna Montana Edition or Christian Edition, or even Kubuntu and MATE Editions) that change some defaults without rebuilding packages... don't count as distributions?

This is somewhat tongue-in-cheek, but it's actually a question I don't have a solid yes or no answer to. I can see it both ways.

Re: Microsoft cURLs too

#33
post #23
post #2

Either the Curl developers are at fault somewhere, which I somehow doubt, or distributions are really special snowflakes, which I also doubt, or software distribution in the Open Source world is, in my opinion, flawed: > Finally, I’d like to add that like all operating system distributions that ship curl (macOS, Linux distros, the BSDs, AIX, etc) Microsoft builds, packages and ships the curl binary completely indepen…

I can think of a few reasons (1) Use of a different libc (alpine linux with musl) (2) most builds are not reproducible, rebuilds are needed for security reasons (3) non-rolling release distros (-> most distros) fork the upstream projects to backport fixes for their older releases (4) Different filesystem structure (Gobo Linux) (6) Most distros want to use the build system associated with their own package manager The…

7) CPU architecture,

8) output binary format (though these days people generally only use ELF or PE),

9) compile time options (eg some packages will allow you to choose which TLS library to use at compile time)

10) hardware specific optimisations

Basically just a plethora of reasons

Re: Microsoft cURLs too

#34
post #5
post #2

Either the Curl developers are at fault somewhere, which I somehow doubt, or distributions are really special snowflakes, which I also doubt, or software distribution in the Open Source world is, in my opinion, flawed: > Finally, I’d like to add that like all operating system distributions that ship curl (macOS, Linux distros, the BSDs, AIX, etc) Microsoft builds, packages and ships the curl binary completely indepen…

Almost all Linux distributions rebuild upstream software from source -- this ensures everything is built from the same toolchain (gcc/libc etc), and that the binaries distributed match the source. It also allows for ease of patching in a stable release -- generally it's preferred to just fix specific high-impact bugs rather than moving to a new upstream version, which might introduce regressions. (Context: I'm a Debi…

"Almost all Linux distributions rebuild upstream software from source"

On Gentoo et al, the end user does the building. OK, yes the ebuilds are recipes but I've lost count of the times I've used epatch_user (https://wiki.gentoo.org/wiki//etc/portage/patches). You have a near infinite choice of ways to destroy your system, what with USE flags, mixed stable/unstable and all the other crazy stuff. Despite that, my Gentoo systems have been surprisingly stable.

In winter an update world session on a laptop keeps you (very) warm 8)

(wrt "Context": Ta for your work)

Re: Microsoft cURLs too

#35
post #23

Earlier quoted context omitted.

I can think of a few reasons (1) Use of a different libc (alpine linux with musl) (2) most builds are not reproducible, rebuilds are needed for security reasons (3) non-rolling release distros (-> most distros) fork the upstream projects to backport fixes for their older releases (4) Different filesystem structure (Gobo Linux) (6) Most distros want to use the build system associated with their own package manager The…

> In the future we will most likely have an distro-specific basic system build and container apps (snap, appimage, flatpak) build directly by upstream on non-server systems. I sure hope not. A better system would be something like NIX/GUIX or even Gobolinux, that give us a single package as today, but with the option of installing multiple versions in parallel if upstream has screwed up the API (again). Flatpak and l…

You've got good points and I admit I'm split on this issue.

In theory i would rather have everything handled by the package manager but container apps provide a few useful advantages:

  - sandboxing/isolation out of the box
  - being able to report bugs directly to upstream
  - It's easier to distribute a small app to all distributions (for some value of all)*
  - much easier to distribute proprietary applications (subjective advantage)
  - much easier to install old versions of an application (sometimes needed)
  - it's possible to record the bandwidth/ram/cpu usage; with a standard package that's quiet difficult

Re: Microsoft cURLs too

#36

What would be the reason behind disabling all those protocols?

Probably to reduce exposure to security issues. The more code you ship, the more code you're responsible for keeping secure.

Looking briefly at the list at https://curl.haxx.se/docs/security.html I see issues for FTP (x2), IMAP, and TFTP in 2017 alone. These protocols which are outside of curl's core competency of http are likely to have less scrutiny and more bugs. While FTP shouldn't be removed from curl I don't think a protocol like TFTP or gopher is crucial, and I wouldn't mind too much if it got the axe in a distribution I used

Re: Microsoft cURLs too

#37
post #17

Now, just ~1000 other commands to go

But they're _all_ already there via the WLSS (Bash on Ubuntu on Windows) if you want them.

Not to mention that the PowerShell equivalents of a lot of *nix commands are _much_ better. "Everything is an object" is a brilliant philosophy and it's a joy to use.

Re: Microsoft cURLs too

#38
> They ship 7.55.1, while 7.57.0 was the latest version at the time. That’s just three releases away so I consider that pretty good. Lots of distros and others ship (much) older releases.

Indeed. I am running latest High Sierra and:

    curl --version
    curl 7.54.0 (x86_64-apple-darwin17.0) libcurl/7.54.0 
    LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0

Re: Microsoft cURLs too

#40
post #22

For debugging on remote servers this is pretty handy (at least, one it makes its way into the server versions). Now I have hope they'll put in a text editor that understands unix line endings.

It's like they're trying to get a record by not doing that. For years I've been baffled why Notepad at the very least couldn't understand unix line endings.

It's possible they lost the source code and literally can't. They've done it before:

https://www.bleepingcomputer.com/news/microsoft/microsoft-ap...

Post reply on HN