1. 28
  1.  

  2. 10

    The system is aggressively self correcting.

    I love this point. People trying to hide malware in open source software are going to have a hard time having it stick for long. This wouldn’t be true if everyone got packages directly from upstream and did not have the time/knowledge to do what package maintainers do.

    1. 4

      I think this may have been true in the days where distributions were like, e.g., OpenBSD – spartan, severe, and unadorned. And it may still be true for some. But the big Linux distributions have absolutely surrendered to the giant churn monster of newbies writing desktop-expecting frameworks in gnomethis and kdethat, and the software is getting palpably worse, more crashy, more screwed up, and less curated. Bugs are getting deeper exponentially faster than the eyes are making them shallow.

      1. 5

        I suppose I have been insulated from this as I mostly use freebsd and Arch. I am sorry to hear that major distro’s are having these issues, but I do think they should probably vet the software added to their repos more strictly and report bugs upstream.

    2. 4

      More fundamentally, the maintainer is the primary line of defence and interaction between users and developers. Maintainers shield developers from uninformed users, allowing the devs to write software with less support overhead.

      This isn’t true in the GitHub era. Newer devs don’t like mailing lists, Bugzilla, etc and won’t go out of their way to use them to speak to a middleman when the alternative is the familiar GH workflow. Expecting non-developers to use these tools (or IRC, from the example) is unrealistic.

      Could ISVs possibly make everyone happy? They can’t. It is impossible. What happens when two groups of users expect different things from the same software? To give an example, imagine an ultralight distribution like Puppy. They want the software as slim as possible. Recompile as i386, it’ll save 5%. Chop out the built-in-help, we’ll use the website. Get rid of the autosave-every-0.1-seconds, it’ll wear out the flash drives. Now imagine an Ubuntu user. They want every bell and whistle enabled. In fact, could you add integration for our new notification and desktop search services? And then imagine the paranoid LFS user.

      I doubt ISVs have Puppy Linux in mind when developing. It seems far-fetched to me that you can take software developed under a certain set of assumptions and then mold it into something significantly different via compiler flags and small patches. And does the existence of universal packages stop Puppy from maintaining their own packages?

      And then imagine the paranoid LFS user. They don’t trust any binary package and insist on getting full sources, reviewing them and building them From Scratch.

      Is this a joke? Who reads the source code to everything they install? Even reviewing one major package (say, gcc) for security would be a massive undertaking.

      1. 9

        This isn’t true in the GitHub era.

        Believe it or not, the majority of linux software packages do not come from github. It is totally reasonable. Honestly I hope that github never becomes the sole/primary holder of software. It is a single point of failure and controlled by a for-profit company.

        It seems far-fetched to me that you can take software developed under a certain set of assumptions and then mold it into something significantly different

        This is exactly what happens to packages every single day. Here is a small example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703

        Is this a joke? Who reads the source code to everything they install?

        I often look at the source code for packages that I build. Its not insane for someone to do a quick overview of source code. It doesn’t take that much time and you are just looking for anything that jumps out and sets alarm bells off in your head.

        1. 2

          Believe it or not, the majority of linux software packages do not come from github.

          Maybe not for the projects that predate GitHub, but I would argue it is true for newer projects. Especially software not written in C.

          xscreensaver

          I don’t see how this example contradicts anything I’ve said.

          1. 4

            I would love to see an example of a linux distro that gets the majority of their software from github. Github’s downtime alone would make the entire endeavour a sight to see.

            Nearly all of the core system on Linux is written in C (or variations of). All the sytem utilities, most of the desktop environments and all of the software you probably use day to day. I don’t personally have anything essential installed from github, and the majority of the software I have installed form there is eye candy or system maintenance scripts.

            You said that package maintainers don’t change upstream packages to something significantly different, but this happens fairly often and that was one example. Another would be the various firefox packages each distro creates.

            1. 2

              I would love to see an example of a linux distro that gets the majority of their software from github.

              I never said the majority of software packaged with a Linux distribution is from GH? Are we even talking about the same thing? My observation is that newer applications tend to be developed on GH.

              all of the software you probably use day to day.

              Out what I have open at the moment: Firefox and Emacs predate GH, but most of the extensions I have for them are developed on GH. HexChat, mpv, Clementine, RedShift, Zotero are developed on GH. Also, again, I’m speaking to trends, not the current state of things.

              Github’s downtime alone would make the entire endeavour a sight to see.

              I don’t see the relevance of this. I wasn’t referring to using GH as somewhere you download packages from. I was referring to it being the place where upstream collaborates.

              1. 4

                So newer applications are developed on GitHub, that doesn’t counter that most distros will still package that separately. I’m not sure what point you’re trying to make, but I don’t think it’s that unrealistic for most package maintainers to look through the source of a package they maintain and are responsible for saying “yeah, this is good to go out to the distro”.

                Regardless of where the actual development of the project is, maintainers are still an active part of most software people install on linux distros. I would be very surprised if a large number of people were infected with some level of malware because they all installed some program from source.

        2. 3

          This isn’t true in the GitHub era. Newer devs don’t like mailing lists, Bugzilla, etc and won’t go out of their way to use them to speak to a middleman when the alternative is the familiar GH workflow.

          The article isn’t talking about developers reporting bugs; it’s talking about non-technical end users. Often one of the patches that distro maintainers will add to end-user applications is a menu option for reporting bugs to the distro bug tracker instead of to the upstream one.

          1. 3

            Expecting non-developers to use these tools (or IRC, from the example) is unrealistic.

            And that is why they are non-developers. :)

            If they want social coding, then they can put their toy projects on the carebear train that is NPM.

            Github is a nifty tool, and one I prefer when working with absolutely green developers, but for large and established projects (especially ones with proper bug tracking tools) moving to Github is not nearly as useful as just indoctrinating new devs.

            1. 1

              moving to Github

              I wasn’t advocating for projects to move to GitHub?