8 ms·

Not so bad comparing to what? Yeah, comparing to downloading a tar file from the website and running ./configure, make etc - right, it's probably quite a simila

by yoavm 7y ago

Not so bad comparing to what? Yeah, comparing to downloading a tar file from the website and running ./configure, make etc - right, it's probably quite a similar risk. But who does that? Every decent Linux distro has a package manager that covers 99% of the software you want to install, and comparing to an apt-get install, pacman -S, yum install and so on - running is a script off some website is way more risky. My package manager verifies the checksum of every file it gets to make sure my mirror wasn't tempered with, and it works regardless of the state of the website of some random software. If I have to choose between a software that's packaged for my package manager and one I have to install with a script - I'll always choose the package manager. And we didn't even start to talk about updates - as if that isn't a security concern. The reason we should discourage people from installing scripts of the internet is because it would be much better if that software would just be packaged correctly.

hannob 7y ago
> 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 collaborate with distros, which unfortunately they rarely do.
- mirimir 7y ago
  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.
  - jacobush 7y ago
    I'd go back to Debian and their stale packages if only they had scheduled releases like Ubuntu has. Imagine Debian 19.10, 20.04 and so on, with Long Time Support on the .04 releases every other year. What a bliss.
    - samueloph 7y ago
      Debian has been doing a stable release every two years since 14 years now. If you want the equivalent of a non-LTS Ubuntu release, you should use Debian Testing (besides the naming, it's pretty stable)
      - beatgammit 7y ago
        Yup, and Debian recently started committing to 5-year support cycles, so it's basically the same as Ubuntu LTS releases (can skip one, but not two releases), with the difference that Debian is released when it's ready, whereas Ubuntu is released on a schedule. Personally, I don't trust Ubuntu LTS releases until they get their first point release, and even then I'm skeptical since they're a bit more loose with package versions on stable. I do trust Debian when it first releases because they're far more rigorous in their testing, though I usually wait a week or two before doing a release upgrade just in case. I used to really like Debian testing, but I've since moved to OpenSUSE because they have a real rolling release (for my desktop) and a solid release based version (for servers). I like Debian, but testing gets a bit sketchy around release time (frozen, and then a ton of updates), and I honestly don't trust Sid aside from pulling in the odd package. I don't trust Ubuntu at all, since it has caused me far too many problems in the past.
  - samueloph 7y ago
    Well, in this case people should have been using Debian Testing instead of Stable. But yeah it's often that people don't understand what's Debian stable and its trade offs compared to Testing and end up unhappy with it or switching to Ubuntu (which is ~very~ similar to Debian Testing).
    - pm7 7y ago
      Unfortunately, Debian testing doesn't get security updates.
      - rollerrrr 7y ago
        To the best of my knowledge, this is not true. Have a link?
        deleted 7y ago
        [deleted]
        pm7 7y ago
        See this comment: https://news.ycombinator.com/item?id=21492080 https://news.ycombinator.com/item?id=21492080 Also, this: https://www.debian.org/security/faq.en.html#testing https://www.debian.org/security/faq.en.html#testing > there is a minimum two-day migration delay
      - hollerith 7y ago
        Good to know. From https://wiki.debian.org/Status/Testing https://wiki.debian.org/Status/Testing, here is some more detail: >there is security support for testing, but in general it cannot be expected to be of the same quality as for stable: >Updates for testing-security usually get less testing than updates for stable-security. >Updates for embargoed issues take longer because the testing security team does not have access to embargoed information. >Testing is changing all the time which increases the likelyhood of problems with the build infrastructure. Such problems can delay security updates in testing.
      - tuldia 7y ago
  - tuldia 7y ago
    Ubuntu is nothing more than the Debian "unstable" branch with Canonical branding plus non-free packages. Compare https://distrowatch.com/table.php?distribution=debian https://distrowatch.com/table.php?distribution=debian and https://distrowatch.com/table.php?distribution=ubuntu https://distrowatch.com/table.php?distribution=ubuntu and you will realize that all the freshness of Ubuntu is build on top of what is available in Debian unstable. I don't think this idea of "Debian packages are often very outdated" still applies nowadays. One can add "testing" or "backports" channels in your /etc/apt/sources.lists.d and get "upstream version" software. Even "stable" ships fresh enough software these days. In the last case you can always get the source, update it and send a nmu back to Debian. Lets not forget that that is how open source works :)
    - axaxs 7y ago
      > Ubuntu is nothing more than the Debian "unstable" branch with Canonical branding plus non-free packages. This just isn't true. Ubuntu is typically quicker to update popular packages, such as desktop environments, kernel, etc. Debian unstable, even experimental, are often months behind on Gnome, for example.
      - tuldia 7y ago
        https://en.wikipedia.org/wiki/Ubuntu#History https://en.wikipedia.org/wiki/Ubuntu#History
  - TeMPOraL 7y ago
    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.
    - mirimir 7y ago
      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.
      - PopeDotNinja 7y ago
        My former boss had us use Debian stable in production for this reason. He did not like apt-get related surprises.
    - bbanyc 7y ago
      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 and constantly-updated packages separate from it. This works better for software you don't think of as an "OS component" but the question then becomes where you draw the line. Or maybe it's just a fundamental disconnect between consumer-facing "move fast and break things" and enterprise-level "never break anything even if it means you can't move at all" and there's no way to make software that works for both.
      - farisjarrah 7y ago
        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 bug in sudo like 3 weeks ago, and Ubuntu immediately issued a fix within hours of the upstream project’s fix.
- Shoue 7y ago
  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.
  - jchw 7y ago
    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.
- shpx 7y ago
  Linux distros should make tasks that are just link collecting as easy as editing Wikipedia and make contributing not require learning git, their syntax and giving out your real name or creating an account. I've seen StackOverflow questions for "how do I install X" with thousands, sometimes hundreds of thousands of views and no-one has tried to contribute the 10 or so lines of code in the accepted answer as a package. Something is clearly too hard or not approachable.
- titanomachy 7y ago
  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.
  - acdha 7y ago
    It’s improved a lot but also consider how many people use FPM to generate multiple formats very easily.
  - tuldia 7y ago
    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 <path-to-tarball> 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). There are also several helpers that goes even further and automate 99% of the process.
    - gpm 7y ago
      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.
    - mixmastamyk 7y ago
      You should expand this to blog post size and publish the hell out of it. Few people know this as the gp alludes to.
    - eikenberry 7y ago
      > That is it! There is no secret. I've been using Debian for 20 years and have never seen this advice. I currently use custom scripts for building local packages of things. I think this comes down to Debian's weak documentation. The recommended intro guide from the wiki page [1] doesn't say this and looking through the maintainers guide I do see this [2] in there but it is buried in pages and pages of other docs. Really, someone needs to write a new basic intro that doesn't bury the lede. It should start with this then expand on what to do for various issues. Or maybe start with one of those 99% automation options. If they are even easier. As is you cannot find this information without some person telling you as you cannot find it by searching for it or reading the docs. [1] https://wiki.debian.org/Packaging/Intro https://wiki.debian.org/Packaging/Intro [2] https://www.debian.org/doc/manuals/maint-guide/first.en.html#non-native-dh-make https://www.debian.org/doc/manuals/maint-guide/first.en.html...
bonoboTP 7y ago
The package manager is only an option if you have root rights. Otherwise you either download binaries or compile it yourself, from the source downloaded from their website.
- tommos0 7y ago
  There are user space package managers, e.g. conda, flatpack and homebrew come to mind.
  - DrKabab 7y ago
    Ironically conda and Homebrew themselves need to be installed from a script off the internet
    - kalefranz 7y ago
      Conda has an .exe installer on Windows and a .pkg installer on macOS. Both signed by Anaconda, Inc. for the OS. There are RPM and deb bootstrap repos for Linux. Then there’s also the .sh shar file installer.
      - bonoboTP 7y ago
        It would be nice to have something like a fusion of conda and apt to work right out of the box on distros like Ubuntu. Like an "apt install --user". I don't understand why we need root rights to install programs that will not need root rights to run anyway. Seems like a huge and obvious oversight to me. I guess it's not a big pain point because in most cases people use their own machines and have root access. Not always the case though in companies or university labs for example.
        detuur 7y ago
        I have been wondering this for ages. Just last week I had to manually set up KeePass, VSCode, IntelliJ, Guitar (git ui) by manually unpacking tarballs (luckily already built) into ~/bin. Guitar luckily had an AppImage which worked beautifully as a single executable. For that reason alone I'm a huge fan of AppImage above snaps and flatpaks.
ivanstame 7y ago
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.
- HankB99 7y ago
  For one of the examples provided, rustup.sh, there were not complete packages the last time I looked for them. There were some packages on Debian and Fedora but I ran into problems configuring the Rust plugin for VS-Code because it assumed that the rustup executable was present and it was not (at that time.) Going down this path, one then becomes dependent on using rustup to update the Rust installation. Now I need to run two commands to keep my system up to date. (pip? Make that 4 commands pip, pip3. CPAN? Yet another.) I have some confidence that at the least the Debian packages won't be changing rapidly, making it more likely that any problems will be discovered before they get to me. A script (or tarball) fetched and installed from the Internet can change literally from one second to the next. If a trusted site is compromised the next download could be tainted. Not all "package managers" instill confidence. I've heard too many bad things about npm and the associated environment and won't have it on my systems, but I am not a web developer so the impact is the occasional utility I have to forgo.
  - Fnoord 7y ago
    Topgrade (written in Rust) [1] allows you to queue different package managers, including those you mentioned. [1] https://github.com/r-darwish/topgrade https://github.com/r-darwish/topgrade
- Un1corn 7y ago
  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.
  - gpm 7y ago
    Rustup doesn't seem to have a fedora package?
coldtea 7y ago
>Not so bad comparing to what? Compared to donwloading a binary and 10 other similar methods people use. >Yeah, comparing to downloading a tar file from the website and running ./configure, make etc - right, it's probably quite a similar risk. But who does that? Millions of people? And even more just download binaries off of websites...
- minxomat 7y ago
  Isn't there even a comment from Linus (could have been someone else) saying that he does exactly that and if that doesn't work gives up on the software?
  - louiz 7y ago
    But Linus is bad at everything except writing C code.
brianpgordon 7y ago
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 exactly the same as downloading a tar file from the developer's website over HTTPS. Same with npm. Some package managers like Maven and NuGet will rehost artifacts but if the project owner is malicious or compromised then that won't help - so the risk profile is again basically the same as downloading a tar file from the website.
- paulddraper 7y ago
  npm removes malware when reported.
  - mceachen 7y ago
    s/when/if/ Fixed that for you.
    - paulddraper 7y ago
      I don't believe that changes the meaning.
      - mceachen 7y ago
        (sorry, it was an obscure inverted reference to the saying "not if, but when")
  - acdha 7y ago
    Which is repeating that sources matter: curl from a source like Github with a solid abuse process is a very different story than an unknown server.
- jsjohnst 7y ago
  > 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 (install in /usr, /usr/local, /opt, etc) on something as simple as where the files are put, let alone how it’s built and it’s dependencies are pulled in. So to say there’s no value in installing from Homebrew over curl|sh is clearly misguided IMHO.
ben509 7y ago
There's still an issue with the package managers requiring arbitrary shell commands to be run, often with sudo. From docker[1] there are steps like these: Install packages to allow apt to use a repository over HTTPS... Add Docker’s official GPG key... Use the following command to set up the stable repository... Once you've done that, then it's just apt-get install. > And we didn't even start to talk about updates - as if that isn't a security concern. I think that's the worst part of it. Some software will nag you about updates, yarn and pipenv for example, but it's far more reliable to have one system that keeps everything up to date. [1]: https://docs.docker.com/install/linux/docker-ce/ubuntu/ https://docs.docker.com/install/linux/docker-ce/ubuntu/
- pm7 7y ago
  Or just apt install docker.io https://packages.debian.org/search?keywords=docker.io https://packages.debian.org/search?keywords=docker.io
sullyj3 7y ago
A giant chunk of Linux users are software developers. Running code that has not yet been packaged or never will be is an extremely common occurrence for a developer.
munmaek 7y ago
> Yeah, comparing to downloading a tar file from the website and running ./configure, make etc - right, it's probably quite a similar risk. But who does that? Many linux users? I get most of the software I need through package managers, but somewhat frequently I need to build it by source. Particularly if I want the most up-to-date version on debian. Git cloning a repo is marginally better in the sense that, well, it's open. Theoretically if it were doing something nefarious, someone would've noticed. Is it perfect? No, of course not. I still think it's better than running random curl'd scripts.
goatinaboat 7y ago
it's probably quite a similar risk. But who does that? After downloading you can at least do some sanity checks - even if you don’t checksum it if you are familiar with it does it look right? Is make doing anything weird? Whereas curl|sh doesn’t give you this opportunity.
Barrin92 7y ago
>Yeah, comparing to downloading a tar file from the website and running ./configure, make etc - right, it's probably quite a similar risk. But who does that? are you asking who compiles and runs software? A lot of people, for example I every time a new emacs version comes out and it isn't in the package manager yet

by yoavm 7y ago

hannob 7y ago

> 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 collaborate with distros, which unfortunately they rarely do.

mirimir 7y ago
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.
- jacobush 7y ago
  I'd go back to Debian and their stale packages if only they had scheduled releases like Ubuntu has. Imagine Debian 19.10, 20.04 and so on, with Long Time Support on the .04 releases every other year. What a bliss.
  - samueloph 7y ago
    Debian has been doing a stable release every two years since 14 years now. If you want the equivalent of a non-LTS Ubuntu release, you should use Debian Testing (besides the naming, it's pretty stable)
    - beatgammit 7y ago
      Yup, and Debian recently started committing to 5-year support cycles, so it's basically the same as Ubuntu LTS releases (can skip one, but not two releases), with the difference that Debian is released when it's ready, whereas Ubuntu is released on a schedule. Personally, I don't trust Ubuntu LTS releases until they get their first point release, and even then I'm skeptical since they're a bit more loose with package versions on stable. I do trust Debian when it first releases because they're far more rigorous in their testing, though I usually wait a week or two before doing a release upgrade just in case. I used to really like Debian testing, but I've since moved to OpenSUSE because they have a real rolling release (for my desktop) and a solid release based version (for servers). I like Debian, but testing gets a bit sketchy around release time (frozen, and then a ton of updates), and I honestly don't trust Sid aside from pulling in the odd package. I don't trust Ubuntu at all, since it has caused me far too many problems in the past.
- samueloph 7y ago
  Well, in this case people should have been using Debian Testing instead of Stable. But yeah it's often that people don't understand what's Debian stable and its trade offs compared to Testing and end up unhappy with it or switching to Ubuntu (which is ~very~ similar to Debian Testing).
  - pm7 7y ago
    Unfortunately, Debian testing doesn't get security updates.
    - rollerrrr 7y ago
      To the best of my knowledge, this is not true. Have a link?
      - deleted 7y ago
        [deleted]
      - pm7 7y ago
        See this comment: https://news.ycombinator.com/item?id=21492080 https://news.ycombinator.com/item?id=21492080 Also, this: https://www.debian.org/security/faq.en.html#testing https://www.debian.org/security/faq.en.html#testing > there is a minimum two-day migration delay
    - hollerith 7y ago
      Good to know. From https://wiki.debian.org/Status/Testing https://wiki.debian.org/Status/Testing, here is some more detail: >there is security support for testing, but in general it cannot be expected to be of the same quality as for stable: >Updates for testing-security usually get less testing than updates for stable-security. >Updates for embargoed issues take longer because the testing security team does not have access to embargoed information. >Testing is changing all the time which increases the likelyhood of problems with the build infrastructure. Such problems can delay security updates in testing.
    - tuldia 7y ago
- tuldia 7y ago
  Ubuntu is nothing more than the Debian "unstable" branch with Canonical branding plus non-free packages. Compare https://distrowatch.com/table.php?distribution=debian https://distrowatch.com/table.php?distribution=debian and https://distrowatch.com/table.php?distribution=ubuntu https://distrowatch.com/table.php?distribution=ubuntu and you will realize that all the freshness of Ubuntu is build on top of what is available in Debian unstable. I don't think this idea of "Debian packages are often very outdated" still applies nowadays. One can add "testing" or "backports" channels in your /etc/apt/sources.lists.d and get "upstream version" software. Even "stable" ships fresh enough software these days. In the last case you can always get the source, update it and send a nmu back to Debian. Lets not forget that that is how open source works :)
  - axaxs 7y ago
    > Ubuntu is nothing more than the Debian "unstable" branch with Canonical branding plus non-free packages. This just isn't true. Ubuntu is typically quicker to update popular packages, such as desktop environments, kernel, etc. Debian unstable, even experimental, are often months behind on Gnome, for example.
    - tuldia 7y ago
      https://en.wikipedia.org/wiki/Ubuntu#History https://en.wikipedia.org/wiki/Ubuntu#History
- TeMPOraL 7y ago
  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.
  - mirimir 7y ago
    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.
    - PopeDotNinja 7y ago
      My former boss had us use Debian stable in production for this reason. He did not like apt-get related surprises.
  - bbanyc 7y ago
    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 and constantly-updated packages separate from it. This works better for software you don't think of as an "OS component" but the question then becomes where you draw the line. Or maybe it's just a fundamental disconnect between consumer-facing "move fast and break things" and enterprise-level "never break anything even if it means you can't move at all" and there's no way to make software that works for both.
    - farisjarrah 7y ago
      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 bug in sudo like 3 weeks ago, and Ubuntu immediately issued a fix within hours of the upstream project’s fix.
Shoue 7y ago
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.
- jchw 7y ago
  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.
shpx 7y ago
Linux distros should make tasks that are just link collecting as easy as editing Wikipedia and make contributing not require learning git, their syntax and giving out your real name or creating an account. I've seen StackOverflow questions for "how do I install X" with thousands, sometimes hundreds of thousands of views and no-one has tried to contribute the 10 or so lines of code in the accepted answer as a package. Something is clearly too hard or not approachable.
titanomachy 7y ago
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.
- acdha 7y ago
  It’s improved a lot but also consider how many people use FPM to generate multiple formats very easily.
- tuldia 7y ago
  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 <path-to-tarball> 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). There are also several helpers that goes even further and automate 99% of the process.
  - gpm 7y ago
    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.
  - mixmastamyk 7y ago
    You should expand this to blog post size and publish the hell out of it. Few people know this as the gp alludes to.
  - eikenberry 7y ago
    > That is it! There is no secret. I've been using Debian for 20 years and have never seen this advice. I currently use custom scripts for building local packages of things. I think this comes down to Debian's weak documentation. The recommended intro guide from the wiki page [1] doesn't say this and looking through the maintainers guide I do see this [2] in there but it is buried in pages and pages of other docs. Really, someone needs to write a new basic intro that doesn't bury the lede. It should start with this then expand on what to do for various issues. Or maybe start with one of those 99% automation options. If they are even easier. As is you cannot find this information without some person telling you as you cannot find it by searching for it or reading the docs. [1] https://wiki.debian.org/Packaging/Intro https://wiki.debian.org/Packaging/Intro [2] https://www.debian.org/doc/manuals/maint-guide/first.en.html#non-native-dh-make https://www.debian.org/doc/manuals/maint-guide/first.en.html...

bonoboTP 7y ago

The package manager is only an option if you have root rights. Otherwise you either download binaries or compile it yourself, from the source downloaded from their website.

tommos0 7y ago
There are user space package managers, e.g. conda, flatpack and homebrew come to mind.
- DrKabab 7y ago
  Ironically conda and Homebrew themselves need to be installed from a script off the internet
  - kalefranz 7y ago
    Conda has an .exe installer on Windows and a .pkg installer on macOS. Both signed by Anaconda, Inc. for the OS. There are RPM and deb bootstrap repos for Linux. Then there’s also the .sh shar file installer.
    - bonoboTP 7y ago
      It would be nice to have something like a fusion of conda and apt to work right out of the box on distros like Ubuntu. Like an "apt install --user". I don't understand why we need root rights to install programs that will not need root rights to run anyway. Seems like a huge and obvious oversight to me. I guess it's not a big pain point because in most cases people use their own machines and have root access. Not always the case though in companies or university labs for example.
      - detuur 7y ago
        I have been wondering this for ages. Just last week I had to manually set up KeePass, VSCode, IntelliJ, Guitar (git ui) by manually unpacking tarballs (luckily already built) into ~/bin. Guitar luckily had an AppImage which worked beautifully as a single executable. For that reason alone I'm a huge fan of AppImage above snaps and flatpaks.

ivanstame 7y ago

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.

HankB99 7y ago
For one of the examples provided, rustup.sh, there were not complete packages the last time I looked for them. There were some packages on Debian and Fedora but I ran into problems configuring the Rust plugin for VS-Code because it assumed that the rustup executable was present and it was not (at that time.) Going down this path, one then becomes dependent on using rustup to update the Rust installation. Now I need to run two commands to keep my system up to date. (pip? Make that 4 commands pip, pip3. CPAN? Yet another.) I have some confidence that at the least the Debian packages won't be changing rapidly, making it more likely that any problems will be discovered before they get to me. A script (or tarball) fetched and installed from the Internet can change literally from one second to the next. If a trusted site is compromised the next download could be tainted. Not all "package managers" instill confidence. I've heard too many bad things about npm and the associated environment and won't have it on my systems, but I am not a web developer so the impact is the occasional utility I have to forgo.
- Fnoord 7y ago
  Topgrade (written in Rust) [1] allows you to queue different package managers, including those you mentioned. [1] https://github.com/r-darwish/topgrade https://github.com/r-darwish/topgrade
Un1corn 7y ago
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.
- gpm 7y ago
  Rustup doesn't seem to have a fedora package?

coldtea 7y ago

>Not so bad comparing to what? Compared to donwloading a binary and 10 other similar methods people use. >Yeah, comparing to downloading a tar file from the website and running ./configure, make etc - right, it's probably quite a similar risk. But who does that? Millions of people? And even more just download binaries off of websites...

minxomat 7y ago
Isn't there even a comment from Linus (could have been someone else) saying that he does exactly that and if that doesn't work gives up on the software?
- louiz 7y ago
  But Linus is bad at everything except writing C code.

brianpgordon 7y ago

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 exactly the same as downloading a tar file from the developer's website over HTTPS. Same with npm. Some package managers like Maven and NuGet will rehost artifacts but if the project owner is malicious or compromised then that won't help - so the risk profile is again basically the same as downloading a tar file from the website.

paulddraper 7y ago
npm removes malware when reported.
- mceachen 7y ago
  s/when/if/ Fixed that for you.
  - paulddraper 7y ago
    I don't believe that changes the meaning.
    - mceachen 7y ago
      (sorry, it was an obscure inverted reference to the saying "not if, but when")
- acdha 7y ago
  Which is repeating that sources matter: curl from a source like Github with a solid abuse process is a very different story than an unknown server.
jsjohnst 7y ago
> 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 (install in /usr, /usr/local, /opt, etc) on something as simple as where the files are put, let alone how it’s built and it’s dependencies are pulled in. So to say there’s no value in installing from Homebrew over curl|sh is clearly misguided IMHO.

ben509 7y ago

There's still an issue with the package managers requiring arbitrary shell commands to be run, often with sudo. From docker[1] there are steps like these: Install packages to allow apt to use a repository over HTTPS... Add Docker’s official GPG key... Use the following command to set up the stable repository... Once you've done that, then it's just apt-get install. > And we didn't even start to talk about updates - as if that isn't a security concern. I think that's the worst part of it. Some software will nag you about updates, yarn and pipenv for example, but it's far more reliable to have one system that keeps everything up to date. [1]: https://docs.docker.com/install/linux/docker-ce/ubuntu/ https://docs.docker.com/install/linux/docker-ce/ubuntu/

pm7 7y ago
Or just apt install docker.io https://packages.debian.org/search?keywords=docker.io https://packages.debian.org/search?keywords=docker.io

sullyj3 7y ago

A giant chunk of Linux users are software developers. Running code that has not yet been packaged or never will be is an extremely common occurrence for a developer.

munmaek 7y ago

> Yeah, comparing to downloading a tar file from the website and running ./configure, make etc - right, it's probably quite a similar risk. But who does that? Many linux users? I get most of the software I need through package managers, but somewhat frequently I need to build it by source. Particularly if I want the most up-to-date version on debian. Git cloning a repo is marginally better in the sense that, well, it's open. Theoretically if it were doing something nefarious, someone would've noticed. Is it perfect? No, of course not. I still think it's better than running random curl'd scripts.

goatinaboat 7y ago

it's probably quite a similar risk. But who does that? After downloading you can at least do some sanity checks - even if you don’t checksum it if you are familiar with it does it look right? Is make doing anything weird? Whereas curl|sh doesn’t give you this opportunity.

Barrin92 7y ago

>Yeah, comparing to downloading a tar file from the website and running ./configure, make etc - right, it's probably quite a similar risk. But who does that? are you asking who compiles and runs software? A lot of people, for example I every time a new emacs version comes out and it isn't in the package manager yet