Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft cURLs too

daniel.haxx.se

Post reply on HN
Print view View original

11–20 of 107 posts

Re: Microsoft cURLs too

#11

Post by temp-dude-87844 »

colemannugent wrote: post #3

Cool, now I don't need to remember the arcane incantation to download a file with Powershell. Do you think we'll see things like the good old "curl | bash" for Windows now? They still have no package manager worth using.

Windows 10 has a "package manager", of course, that's quite good, but both user culture, developer disinterest, and years and years of inertia keeps it from being used for enough things to cross the network-effect side of some treshold of "worthwhile".

The 'download | execute' paradigm, on the other hand, is the complete antithesis of package management, to where your desire to obtain and execute the code trumps your willingness and patience to wait until it has been vetted by your preferred package manager, and installed in a less haphazard way. I fail to see your point.

Re: Microsoft cURLs too

#12

Post by frik »

Please keep builds of Win32/Win64 plus source on your website, built by you.

Every M$ exe nowadays contain some telemetry phone home stuff, extra annoying.

Re: Microsoft cURLs too

#13

Post by unkoman »

orf wrote: post #9

Curl is alright, and congratulations on this massive and very impressive step forwards, but the CLI not exactly very user friendly. httpie[1] is a great tool if you find curl invocation somewhat arcane. 1. https://httpie.org/

curl is much more than http.

Re: Microsoft cURLs too

#14

Post by lettergram »

One thing I am always sure to share with collegues when we discuss curl, is the fact from the command line you can generate the underlying C code.

This is pretty useful when creating a CLI for pretty much any app, and I've used it regularly to generate a CLI for an app.

My post on how to do it: http://austingwalters.com/export-a-command-line-curl-command...

Re: Microsoft cURLs too

#15

Post by Analemma_ »

colemannugent wrote: post #3

Cool, now I don't need to remember the arcane incantation to download a file with Powershell. Do you think we'll see things like the good old "curl | bash" for Windows now? They still have no package manager worth using.

Yeah, “iwr” sure was hard to remember.

Re: Microsoft cURLs too

#16

Post by Something1234 »

orf wrote: post #9

Curl is alright, and congratulations on this massive and very impressive step forwards, but the CLI not exactly very user friendly. httpie[1] is a great tool if you find curl invocation somewhat arcane. 1. https://httpie.org/

HTTPie is great, but sometimes you need curl. Curl supports a lot more protocols.

Re: Microsoft cURLs too

#18

Post by koshersalt »

colemannugent wrote: post #3

Cool, now I don't need to remember the arcane incantation to download a file with Powershell. Do you think we'll see things like the good old "curl | bash" for Windows now? They still have no package manager worth using.

Have you tried chocolatey? I’ve really enjoyed using it

Re: Microsoft cURLs too

#19

Post by dfox »

oblio wrote: 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…

Apart from various technical reasons the workflow of essentially all linux package managers is built on the notion that the binary package is built by some well defined (and repeatable, at least in the "does same thing" sense) process from some kind of source package. Also the souce package format usually contains mechanism that allows distributions to comply with copy-left licenses while also cleanly documenting which modifications were made to the package from upstream version (it is sort of special purpose versioning system).

Re: Microsoft cURLs too

#20

Post by geofft »

oblio wrote: 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…

In order to make sure you actually have the freedom to modify the software, you want packagers to have the ability to rebuild the package from source - and preferably using just their OS as a build environment, not a black-box build environment from upstream like a Docker configured just so and make sure they have an equivalent binary. Even if there's nothing to patch today, there might be something to patch tomorrow.

I have seen many times Debian packagers try to build something from upstream and find that it just does not build anywhere other than the maintainer's computer. The fact that Debian requires that every package it ships can be built buy anyone in a generic environment is immensely valuable to free software, even if nobody used the binaries that Debian built. (And to be clear, other distros do the same, I'm just most familiar with Debian.)

I'd agree that in an ideal world, all the patches would be upstream and the binary would not just be equivalent but bit-for-bit reproducible. Some practical reasons why it wouldn't be are that various dependencies are of slightly different versions (e.g., one distro manages to get a new libc uploaded a little bit before another), that downstream conventions are different in different distros (e.g., Red Hat-style distros use /lib64 and Debian-style distros use /lib/x86_64-linux-gnu), or that a dependency has some shortcoming which many but not all distros patch in the same way, and the patch impacts things that use the dependency (e.g., upstream OpenSSL <1.1 does not have symbol versions, but most Linux distros patch them in). Yes, in an ideal world, all these things would be resolved, but there are going to be so many tiny things like this that come up that having infrastructure to accommodate them is the right plan.

Post reply on HN