Live data from Hacker News

Curl to shell isn't so bad

arp242.net

151–160 of 201 posts

Re: Curl to shell isn't so bad

#151
post #135

Earlier quoted context omitted.

Making Debian packages is a colossal pain in the ass, or at least it's poorly documented. I've tried to learn it twice and abandoned it for more user-friendly solutions to the problem. Some people may say I'm stupid for not figuring it out, but the standard for usability of software has improved a lot since these systems were invented. The UX needs a serious overall.

I guess you are exagerating quite a bit. Creating a Debian package is actually pretty straight forward: 1. download upstream tarball. 2. execute dh_make -f 3. debuild -us -uc -b That is it! There is no secret. dh_make does the heavy lift of generating everything you need. Your only job is to declare the dependencies (build and runtime ones) inside the "control" file, maybe change the "rules" file (it is a Makefile).…

And how is using a package built like this any better than curl | sh from upstream? You're still trusting the upstream tarball. Now in addition you are trusting the packager.

Re: Curl to shell isn't so bad

#152
post #131

Earlier quoted context omitted.

Ubuntu LTS (freezes every two years) or "regular" Ubuntu (freezes every six months)? I'm wondering if the periodic freeze-the-universe model that many distros use reflects a world that doesn't really exist anymore where distros came on DVDs (or CDs, or floppies). Whatever version you had on the disc, that's the version you're going to use. I just started playing with FreeBSD in a VM, which has a frozen base system an…

This isn’t how Ubuntu even works. Ubuntu doesn’t just “freeze” their operating system every two years. They are constantly delivering package, security, and hardware enablement fixes. Often the stuff that lands in Ubuntu non-lts versions end up in the lts point releases. They keep a stable base of x.x versions but they definitely backport bug fixes to x.x.x versions of their software packages. For example there was a…

Maybe "version freeze" or "feature freeze" is a better term. The sudo bug was fixed in version 1.8.28, but Ubuntu LTS didn't upgrade to the new version. They're still on 1.8.21p2 from 2017, but with the bugfix and other Debian and Ubuntu patches applied, resulting in a bizarre package version of "1.8.21p2-3ubuntu1.1".

Which with something relatively small and stable like sudo, is one thing. For big projects on rapid release cycles, like GNOME, it's got a much bigger impact.

Though I do see that Ubuntu does keep updating Firefox and Chromium to the latest versions in LTS, because they're so big and change so fast that backporting fixes has become practically impossible. That looks like a very rare exception to the rule; your typical Python library won't be getting that treatment.

Re: Curl to shell isn't so bad

#153
post #99

Earlier quoted context omitted.

Well if this was true "Every decent Linux distro has a package manager that covers 99% of the software you want to install" we wouldn't have to install it thru sh.

4/5 of the examples the author gave have a package in Fedora. The one that doesn't (oh-my-zsh) is simply a git clone so it doesn't make much sense to package it.

Rustup doesn't seem to have a fedora package?

Re: Curl to shell isn't so bad

#154

Earlier quoted context omitted.

Agreed, but that's actually an (UX) problem that Debian should fix. "Testing" is an awful name for "stable enough for normal use". When I first installed Debian I made the same error of installing stable on desktop and then fighting with it to install packages from testing... Just renaming testing to "regular" would prevent lots of wasted time all around.

Testing is only ok for desktops if you are ok with reinstalling it every so often, like with other distros. It won't last longer than your hardware, and will get odd problems after an upgrade once in a while. Stable basically means it won't change, and says nothing about freshness. Debian has recently adopted a policy of releasing on a time basis, so it's never very stale.

I used testing for many years without reinstalling.

Re: Curl to shell isn't so bad

#155

Earlier quoted context omitted.

It seems like you're assuming that there's someone vetting these packages. For enterprise distros like Red Hat that's certainly true. Community package maintainers in, for example, the Debian project provide some safety as well. But there are plenty of package managers where that's just not the case. In the case of Homebrew, the package manager pulls down the program directly from upstream and installs it. It's exact…

> In the case of Homebrew, the package manager pulls down the program directly from upstream and installs it. Sure, in the most basic case it does this, but even in the most basic case it does more than that. At minimum it also verified the download matches a known good hash. The important part (to me) is that Homebrew also ensures the package installed conforms to Homebrew’s standard. There’s a lot of standards (ins…

Homebrew is only as secure as the results of that first curl command

     /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
I get why https://docs.brew.sh/Installation doesn’t discuss the versioning or security practices. It is interesting that homebrew doesn’t seem to interface with macOS’s signing and installation practices.

Reminds me that there is still no official package manager on macOS. So https://nodejs.org/en/download/ has you comparing check sums.

Re: Curl to shell isn't so bad

#156
post #135

Earlier quoted context omitted.

Making Debian packages is a colossal pain in the ass, or at least it's poorly documented. I've tried to learn it twice and abandoned it for more user-friendly solutions to the problem. Some people may say I'm stupid for not figuring it out, but the standard for usability of software has improved a lot since these systems were invented. The UX needs a serious overall.

I guess you are exagerating quite a bit. Creating a Debian package is actually pretty straight forward: 1. download upstream tarball. 2. execute dh_make -f 3. debuild -us -uc -b That is it! There is no secret. dh_make does the heavy lift of generating everything you need. Your only job is to declare the dependencies (build and runtime ones) inside the "control" file, maybe change the "rules" file (it is a Makefile).…

You should expand this to blog post size and publish the hell out of it. Few people know this as the gp alludes to.

Re: Curl to shell isn't so bad

#157

Earlier quoted context omitted.

If Ubuntu is the not stale alternative to Debian (stable), then I can't imagine how bad the situation is there. I often build software myself because Ubuntu is very often stale.

I've always preferred to use Debian stable just because it's stable. And because it's arguably got the latest security updates. But for Tor, I always use the Tor Project repository. Or for Docker. And then there's stuff that won't even build in Debian, because it's been developed specifically for Ubuntu.

My former boss had us use Debian stable in production for this reason. He did not like apt-get related surprises.

Re: Curl to shell isn't so bad

#158

Earlier quoted context omitted.

> In the case of Homebrew, the package manager pulls down the program directly from upstream and installs it. Sure, in the most basic case it does this, but even in the most basic case it does more than that. At minimum it also verified the download matches a known good hash. The important part (to me) is that Homebrew also ensures the package installed conforms to Homebrew’s standard. There’s a lot of standards (ins…

Homebrew is only as secure as the results of that first curl command /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" I get why https://docs.brew.sh/Installation doesn’t discuss the versioning or security practices. It is interesting that homebrew doesn’t seem to interface with macOS’s signing and installation practices. Reminds me that there is still no official pack…

1. Using curl|sh isn’t the only way to install Homebrew

2. Most of my post wasn’t addressing security, but actual real usability gains by using Homebrew.

Re: Curl to shell isn't so bad

#159
post #113
post #36

Earlier quoted context omitted.

> Every decent Linux distro has a package manager that covers 99% of the software you want to install I wish this were true, but plenty of experience with Linux usage tells me that not having something packaged is a very common occurence. Though of course this can be improved: More people should actually help working on their favorite Linux distro, so more software gets packaged. And upstreams should try better to co…

I wish more repositories took the NixOS approach of writing the build scripts (+ patches if necessary) on GitHub for easy visibility and a more familiar way to submit a new or upgraded package. Once approved the binary is built and distributed from the Nix binary cache.

NixOS is awesome, but contributing to Nixpkgs is at least a little challenging. The tooling leaves a bit to be desired, and it’s really hard to keep all of the guidelines and rules in your head. It would be an excellent experience if there was extensive linting and the tools were easier to understand, imo.

Certainly isn’t an easy problem.

It’s still probably a lot better than contributing to say, Debian. OTOH, the PR backlog is always daunting.

Re: Curl to shell isn't so bad

#160
post #81

Earlier quoted context omitted.

Right. I love Debian, but its packages are often very stale. That's why many end up using Ubuntu. And yes, I get that package review takes time, and that Debian is arguably more secure. But that's little consolation when you're dead in the water because what's packaged is too old.

If Ubuntu is the not stale alternative to Debian (stable), then I can't imagine how bad the situation is there. I often build software myself because Ubuntu is very often stale.

If you need a continuously updated Debian then Kali may fit the bill - it’s not just for security work.
Post reply on HN