81–90 of 107 posts
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.
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…
Earlier quoted context omitted.
It wasnt until 2006 that curl added HTTP/1.1 pipelining support. Hence I always used netcat instead of curl because I utilised pipelining heavily for text/html retrieval (IME, most servers supported it). Imagine something like this with curl: curl where curl only opens a single connection. Alas, AFAIK, pipelining is still not enabled in the curl binary. As I understand it, the --libcurl option only generates code for…
If you invoke "curl http://example.com/a.htm http://example.com/b.htm" , curl will only use a single connection.
Earlier quoted context omitted.
Why would you be using a random ip? That incantation is usually used with a URL where you would have just downloaded and installed the software manually anyway. There are various arguments against the curl-piped-to-shell idiom but "random ip" doesn't seem like a valid one.
A URL and an IP are not equal. Building a script that acts differently for a web browser, a normal download, and curl, is trivial, and I've seen it happen. Here's a proof-of-concept[0] someone else wrote. Manually downloading is safer, at least you can review, curling straight into a shell is inherently unsafe. The better option is still a package manager, but curling straight to a shell is very unsafe. [0] https://j…
And why wouldn't you trust the source of the install script as much as any other installer?
Do you audit the binary installers you use as well?
I don't disagree about a minor difference between the methods, but I definitely disagree with piping to sh being "very unsafe". If you trust the site/author enough to run their code on your computer at all, the install method risk difference is but a tiny drop in the bucket.
Earlier quoted context omitted.
A URL and an IP are not equal. Building a script that acts differently for a web browser, a normal download, and curl, is trivial, and I've seen it happen. Here's a proof-of-concept[0] someone else wrote. Manually downloading is safer, at least you can review, curling straight into a shell is inherently unsafe. The better option is still a package manager, but curling straight to a shell is very unsafe. [0] https://j…
Why would you be using an IP and not a URL? And why wouldn't you trust the source of the install script as much as any other installer? Do you audit the binary installers you use as well? I don't disagree about a minor difference between the methods, but I definitely disagree with piping to sh being "very unsafe". If you trust the site/author enough to run their code on your computer at all, the install method risk d…
Piping curl, means you can't be sure it came from the author's site.
It means you can't be sure you're getting the same software you've been considering installing.
It means a broken connection is a broken install, with no cleanup and no idea what it has changed.
> Do you audit the binary installers you use as well?
Don't install random binaries either. The security implications of that should be fairly obvious.
Earlier quoted context omitted.
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.
Regardless of its merits, they blew it in terms of marketing. PowerShell is destined to be a deadend technology only used by Windows sysadmins.
Earlier quoted context omitted.
Why would you be using an IP and not a URL? And why wouldn't you trust the source of the install script as much as any other installer? Do you audit the binary installers you use as well? I don't disagree about a minor difference between the methods, but I definitely disagree with piping to sh being "very unsafe". If you trust the site/author enough to run their code on your computer at all, the install method risk d…
> If you trust the site/author enough to run their code on your computer at all Piping curl, means you can't be sure it came from the author's site. It means you can't be sure you're getting the same software you've been considering installing. It means a broken connection is a broken install, with no cleanup and no idea what it has changed. > Do you audit the binary installers you use as well? Don't install random b…
Up to the trustworthiness of the CA system yes you can. If the author's site is serving malicious downloads to the curl UA then you're probably hosed either way. It would be easier to just slip malicious code in the software itself.
> It means a broken connection is a broken install, with no cleanup and no idea what it has changed.
This is the real draw of package management. The argument surrounding curl|bash should really focus on this rather than hand-wavy security.
> Don't install random binaries either
Nobody who is running curl|bash isn't installing a 'random' binary but downloading an installer from a source they trust.
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.
Curl some url and execute is a massive security risk.
Earlier quoted context omitted.
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.
This does get a little murky when some of the packages are distributed directly but others are pulled from upstream like Antergos but the changes are so minor that I would still consider it an Arch spin.
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/
1. By default curl doesn't follow redirects and I think most use-cases (not all) require that behavior (at least from the cli).
2. Similar to wget, many users who start using curl do it to download something, probably a file. But opposite to wget curl doesn't write a file but to stdout. Actually, I find curls behavior much more UNIX style, but it is probably the first obstacle every user has to tackle. Nevertheless, in the end this makes curl easier to use, because you do not have to remember which parameter is used to set the output file name, but instead just use the universal unix operator '>'.