7 ms·

New Debian project leader talks open source careers, PPAs and more

79 points by Enindu 11y ago

tcdent 11y ago
Is employment via Open Source contribution really as widespread as he suggests? Any examples of (smaller than a distro) projects with known paid contributors?
- LukeShu 11y ago
  I know that one of the libsass developers is paid to work on it.
- rectang 11y ago
  Numerous Apache projects are developed primarily by paid contributors.
- EmanueleAina 11y ago
  Qt, LibreOffice, OpenStack, Linux itself, WebKit, GStreamer, Wayland just to name a few have both paid and freetime contributions (often from the same people too). Neil works for Collabora, we contribute to quite a few projects in our paid time. ;)
- warp 11y ago
  GNU MediaGoblin, MusicBrainz
yarrel 11y ago
PPAs are an antipattern. One of Debian's (many) advantages vs. Ubuntu is that there isn't an ecosystem of poorly maintained but easily found packages around the core. Lending Debian's reputation to such an ecosystem will not improve Debians' standing or user experience.
- AceJohnny2 11y ago
  As a Debian user for 15 years, I don't understand the hostility against PPAs. As a user, they provide me with a convenient and somewhat-traceable source of supported packages for my release. For example, at work we're stuck on Ubuntu 12.04 which has git 1.7.9, but there's a stable PPA that can give me a more up-to-date git which has better pull options and defaults. Easier, more trustworthy, and more reliable than compiling and packaging my own! Alternatively, I'm learning OCaml on Debian unstable, and the OPAM package manager was stuck at 1.1.0 for months after 1.2.0 came out, and to add insult to injury the Debian version was broken because of a silent incompatibility with a dependency. I realize that by using a PPA I'm going out of Ubuntu's (or eventually Debian's) well-tended garden of tested packages (and honestly, "well-tended" is a very relative term) and potentially exposing myself to risky sources, but that's my choice. I'm afraid this opposition to PPAs boils down to conservative dogmatism bred from decades of no good option for user package existing. There have been issues, yes, but don't throw out the baby with the bathwater.
  - amyjess 11y ago
    Agreed. One of the things I love about Arch and Gentoo is that if a package isn't in one of the official repos, it can be found in the AUR or an overlay, respectively.
    - vhost- 11y ago
      Lack of PPAs are one of the reasons I bounce back to Arch and Gentoo from Debian.
    - Alupis 11y ago
      The AUR is a little different than a PPA. Yes, both are user generated content not officially supported by the project. However at least in the AUR there is a centralized place for these packages, and an entity behind the AUR platform that can curate bad/malicious/negligent packages out. PPA's have a bad wrap for being, well... bad. Any user, anywhere. Here today, server gone tomorrow. Outdated blog posts from years ago with dead links, or bad advice/packages. It's not uncommon for a PPA to break a system. The AUR is more similar to rpmfusion repo or epel repo (centralized and somewhat governed). Where PPA's are just like tarballs on some random-joe's blog.
- chimeracoder 11y ago
  > One of Debian's (many) advantages vs. Ubuntu is that there isn't an ecosystem of poorly maintained but easily found packages around the core. Context: I'm a full-time Debian user. I firmly believe that the future is not around packaging as we've been conceiving of it for the last decade or so, but around packaging in the form of containers[0]. As a Debian user, I'd be really happy to see Debian keep an eye towards containerization as a a first-class citizen of the distribution, the way apt(itude) and dpkg are now. PPAs can either fit into this model or work against it, depending on how you look at it. They can either enable the creation of containers by virtue of being more flexible and more easily used inside container builds, or they can serve as a crutch for low-quality packaging standards. So, I'd be excited for PPAs in Debian, but I'd like to see them adopted as a tool to facilitate first-class containerization in Debian, rather than the way they are used in Ubuntu more as a place to hold unsupported or less-supported packages. [0] Not necessarily Docker or even Docker-like containers, but containers nonetheless.
  - dharma1 11y ago
    what do you think of https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/ https://developer.ubuntu.com/en/snappy/tutorials/build-snaps...
    - chris_wot 11y ago
      That's the tutorial - o you have a more detailed link?
      - dharma1 11y ago
        For an explanation of Snappy - or how to get/run/use it? Here is a couple of links for the former http://thenewstack.io/snappy-ubuntu-a-new-cloud-os-with-support-for-docker-in-a-post-shellshock-era/ http://thenewstack.io/snappy-ubuntu-a-new-cloud-os-with-supp... http://www.markshuttleworth.com/archives/1434 http://www.markshuttleworth.com/archives/1434
  - vezzy-fnord 11y ago
    packaging in the form of containers I don't really see that. Containers have mostly ingrained themselves into application deployment, but the trends in GNU/Linux packaging seem to be heading toward compressed bundles (combined with some form of access control like AppArmor or POSIX caps to get some form of sandboxing and resource isolation). At least that's what Ubuntu Snappy seems to be. This is similar to Klik, Autopackage, 0install, OS X bundles and even the Windows way of stuffing your DLLs into a single directory namespace (though with a common format and infrastructure). Nix and Guix are in leagues of their own that have nothing to do with containers specifically. Everyone else is sticking to the same conventional system package managers and I don't see that changing. The systemd developers are proposing their own odd scheme based on btrfs volumes that is still in its very early stages.
- EmanueleAina 11y ago
  The plan for Debian PPAs is for them to be quite different than the ones from Ubuntu, they will be available only for those that already have upload privileges. They will be a sort of compartimentalized experimental, with no different builders network and no need for a reupload to push to unstable/testing.
  - AceJohnny2 11y ago
    In which case, I don't understand what problem they're solving. We already have Experimental.
    - derefr 11y ago
      Packages equivalent to named long-term development branches of upstreams, without packaging the result under a separate name (thus confusing dependent packages)?
    - gizmo686 11y ago
      Experimental is an all or nothing proposition. With a PPA system it should be possible to keep most of your system on stable, and opt into newer versions of software on a case by case basis.
      - vacri 11y ago
        Doesn't apt-pinning solve that? Set a pin that never installs from Experimental unless manually specified, or only install that one package from Experimental? https://wiki.debian.org/DebianExperimental#APT_pinning https://wiki.debian.org/DebianExperimental#APT_pinning
        hoopd 11y ago
        Just a note for the uninitiated: when you pin from Stable you just gave up the guarantees that may have been the reason you were on Stable in the first place. This is an area where RTFM is in order: "WARNING: Use of apt-pinning by a novice user is sure call for major troubles. You must avoid using apt-pinning except when you absolutely need it." https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_tweaking_candidate_version https://www.debian.org/doc/manuals/debian-reference/ch02.en....
- FooBarWidget 11y ago
  You realize that if a package isn't in the repository (or is in the repo, but not the right version), the alternative is that the user compiles it from source, right? Now the user has all sorts of software scattered over his system, with no way to manage, update and uninstall them. How is that situation any better than using PPAs?
  - fletchowns 11y ago
    Use checkinstall? It's somewhere between installing from source and installing from a package. https://help.ubuntu.com/community/CheckInstall https://help.ubuntu.com/community/CheckInstall
  - 4ydx 11y ago
    Install to your own custom path? /opt ... /local ... /myfolder ... etc. Add the path to your user's $PATH. If you are familiar with linux this isn't really much harder to do. If it is a library that you are then compiling against it does get a bit more difficult, of course, but it is only a good thing to become familiar with these things. If you are ok with "polluting" your path, you can install each new binary + libs to its own custom path. You simply delete the folder in the future when you no longer need it anymore.
    - sirclueless 11y ago
      Not really an answer for packages that need configuration in /etc, add desktop entries to user's menus, or should be discoverable for example by systemd. Adding to everyone's PATH is invasive and not really an option for most multi-user systems.
      - 4ydx 11y ago
        I was responding to somebody who made the claim that installing software leaves things "scattered all over the system". I simply pointed out that that is not true if you plan carefully. Additionally you can ensure that all users on a system have a basic set of paths enabeled in their profile (is the default PATH any more invasive than a default path + "/opt/bin"? These things are not insurmountable if you actually know what you are talking about and know the scope of your problem. These complaints are coming from people who are not actually interested in managing a system, but would rather be able to click a button in a gui and not have to understand anything of what is actually going on. That being said compiling your own stuff in and of itself is not guaranteed to be a simple or "fun" task. It takes work and can lead to unexpected results: you immediately own anything that is custom on your system and become your own testing, debugging, and troubleshooting team. It isn't ideal.
- davexunit 11y ago
  Allowing users to easily extend the available packages is not an anti-pattern, it's practical software freedom!
- dman 11y ago
  The good part about PPA's are that they can be ignored completely. After being bitten once or twice, I have stuck to not installing anything that isnt in the core ubuntu repositories.
  - Touche 11y ago
    I don't know how you can subsist on Ubuntus severely outdated packages.
    - dman 11y ago
      Could you elaborate which packages you use from PPAs?
  - jnbiche 11y ago
    In my 6+ years of using Ubuntu and derivatives, and frequently installing PPAs, I've never had a problem or been bitten. And I've only exercised a little bit of caution. On the other hand, I ran into massive headaches when I used to try to pin apt repositories. No more of that for me. PPAs are the main reason I use Ubuntu distros now instead of Debian.
- tacone 11y ago
  The lack of PPA has hold the industry back for years. Outdated Apaches, outdated Mysqls, outdated PHPs. In a word, distro mantainers became gateway keepers, and bad ones, since they don't have the unlimited resources required to keep everything to date. While there definitely are cases when you want somebody to pick the versions for you, nowadays the industry is moving just to fast for keep most people satisfied. Of course there will be poor PPA's. Poor Github repositories also exists, bad NPM packages exist, bad Maven packages exist, but that does not stop people to search for the right ones and take charge of their own future.
radoslawc 11y ago
From: https://help.ubuntu.com/community/PPA https://help.ubuntu.com/community/PPA "Security PPAs have not undergone the same process of validation as regular ubuntu packages. End users install PPAs at their own risk. Although each key is cryptographically signed, in order to confirm an uploader, keys are not matched to specific individuals, except via their "launchpad" accounts. Subsequently, installing a PPA should be considered to be a low-security alternative as compared to the main repository, but marginally higher security than simply installing software at random from the internet. As part of adding a PPA, you trust the developer to not only install packages, but also to allow them to provide ongoing updates." This pretty much sums it all. It's not matter of hostility towards PPA or trying to keep things oldskool. With all effort towards signed, verified packages, reproductible builds etc. adding functionality like PPA is for me nothing more as installing "shareware" windows apps from random sites. Building packages by yourself is not that hard especially with fpm or checkinstall.
- ploxiln 11y ago
  You might gain some trust in a team which maintains a particular PPA. You import their key manually, and the key is not auto-updated or anything. Installing shareware windows apps from "random sites" seems riskier, they're not signed by a single uploader's key which you import just once.
  - radoslawc 11y ago
    You're right. I've trolled a little. But still, this brings security issues with it.

79 points by Enindu 11y ago

Is employment via Open Source contribution really as widespread as he suggests? Any examples of (smaller than a distro) projects with known paid contributors?

LukeShu 11y ago
I know that one of the libsass developers is paid to work on it.
rectang 11y ago
Numerous Apache projects are developed primarily by paid contributors.
EmanueleAina 11y ago
Qt, LibreOffice, OpenStack, Linux itself, WebKit, GStreamer, Wayland just to name a few have both paid and freetime contributions (often from the same people too). Neil works for Collabora, we contribute to quite a few projects in our paid time. ;)
warp 11y ago
GNU MediaGoblin, MusicBrainz

yarrel 11y ago

PPAs are an antipattern. One of Debian's (many) advantages vs. Ubuntu is that there isn't an ecosystem of poorly maintained but easily found packages around the core. Lending Debian's reputation to such an ecosystem will not improve Debians' standing or user experience.

AceJohnny2 11y ago
As a Debian user for 15 years, I don't understand the hostility against PPAs. As a user, they provide me with a convenient and somewhat-traceable source of supported packages for my release. For example, at work we're stuck on Ubuntu 12.04 which has git 1.7.9, but there's a stable PPA that can give me a more up-to-date git which has better pull options and defaults. Easier, more trustworthy, and more reliable than compiling and packaging my own! Alternatively, I'm learning OCaml on Debian unstable, and the OPAM package manager was stuck at 1.1.0 for months after 1.2.0 came out, and to add insult to injury the Debian version was broken because of a silent incompatibility with a dependency. I realize that by using a PPA I'm going out of Ubuntu's (or eventually Debian's) well-tended garden of tested packages (and honestly, "well-tended" is a very relative term) and potentially exposing myself to risky sources, but that's my choice. I'm afraid this opposition to PPAs boils down to conservative dogmatism bred from decades of no good option for user package existing. There have been issues, yes, but don't throw out the baby with the bathwater.
- amyjess 11y ago
  Agreed. One of the things I love about Arch and Gentoo is that if a package isn't in one of the official repos, it can be found in the AUR or an overlay, respectively.
  - vhost- 11y ago
    Lack of PPAs are one of the reasons I bounce back to Arch and Gentoo from Debian.
  - Alupis 11y ago
    The AUR is a little different than a PPA. Yes, both are user generated content not officially supported by the project. However at least in the AUR there is a centralized place for these packages, and an entity behind the AUR platform that can curate bad/malicious/negligent packages out. PPA's have a bad wrap for being, well... bad. Any user, anywhere. Here today, server gone tomorrow. Outdated blog posts from years ago with dead links, or bad advice/packages. It's not uncommon for a PPA to break a system. The AUR is more similar to rpmfusion repo or epel repo (centralized and somewhat governed). Where PPA's are just like tarballs on some random-joe's blog.
chimeracoder 11y ago
> One of Debian's (many) advantages vs. Ubuntu is that there isn't an ecosystem of poorly maintained but easily found packages around the core. Context: I'm a full-time Debian user. I firmly believe that the future is not around packaging as we've been conceiving of it for the last decade or so, but around packaging in the form of containers[0]. As a Debian user, I'd be really happy to see Debian keep an eye towards containerization as a a first-class citizen of the distribution, the way apt(itude) and dpkg are now. PPAs can either fit into this model or work against it, depending on how you look at it. They can either enable the creation of containers by virtue of being more flexible and more easily used inside container builds, or they can serve as a crutch for low-quality packaging standards. So, I'd be excited for PPAs in Debian, but I'd like to see them adopted as a tool to facilitate first-class containerization in Debian, rather than the way they are used in Ubuntu more as a place to hold unsupported or less-supported packages. [0] Not necessarily Docker or even Docker-like containers, but containers nonetheless.
- dharma1 11y ago
  what do you think of https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/ https://developer.ubuntu.com/en/snappy/tutorials/build-snaps...
  - chris_wot 11y ago
    That's the tutorial - o you have a more detailed link?
    - dharma1 11y ago
      For an explanation of Snappy - or how to get/run/use it? Here is a couple of links for the former http://thenewstack.io/snappy-ubuntu-a-new-cloud-os-with-support-for-docker-in-a-post-shellshock-era/ http://thenewstack.io/snappy-ubuntu-a-new-cloud-os-with-supp... http://www.markshuttleworth.com/archives/1434 http://www.markshuttleworth.com/archives/1434
- vezzy-fnord 11y ago
  packaging in the form of containers I don't really see that. Containers have mostly ingrained themselves into application deployment, but the trends in GNU/Linux packaging seem to be heading toward compressed bundles (combined with some form of access control like AppArmor or POSIX caps to get some form of sandboxing and resource isolation). At least that's what Ubuntu Snappy seems to be. This is similar to Klik, Autopackage, 0install, OS X bundles and even the Windows way of stuffing your DLLs into a single directory namespace (though with a common format and infrastructure). Nix and Guix are in leagues of their own that have nothing to do with containers specifically. Everyone else is sticking to the same conventional system package managers and I don't see that changing. The systemd developers are proposing their own odd scheme based on btrfs volumes that is still in its very early stages.
EmanueleAina 11y ago
The plan for Debian PPAs is for them to be quite different than the ones from Ubuntu, they will be available only for those that already have upload privileges. They will be a sort of compartimentalized experimental, with no different builders network and no need for a reupload to push to unstable/testing.
- AceJohnny2 11y ago
  In which case, I don't understand what problem they're solving. We already have Experimental.
  - derefr 11y ago
    Packages equivalent to named long-term development branches of upstreams, without packaging the result under a separate name (thus confusing dependent packages)?
  - gizmo686 11y ago
    Experimental is an all or nothing proposition. With a PPA system it should be possible to keep most of your system on stable, and opt into newer versions of software on a case by case basis.
    - vacri 11y ago
      Doesn't apt-pinning solve that? Set a pin that never installs from Experimental unless manually specified, or only install that one package from Experimental? https://wiki.debian.org/DebianExperimental#APT_pinning https://wiki.debian.org/DebianExperimental#APT_pinning
      - hoopd 11y ago
        Just a note for the uninitiated: when you pin from Stable you just gave up the guarantees that may have been the reason you were on Stable in the first place. This is an area where RTFM is in order: "WARNING: Use of apt-pinning by a novice user is sure call for major troubles. You must avoid using apt-pinning except when you absolutely need it." https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_tweaking_candidate_version https://www.debian.org/doc/manuals/debian-reference/ch02.en....
FooBarWidget 11y ago
You realize that if a package isn't in the repository (or is in the repo, but not the right version), the alternative is that the user compiles it from source, right? Now the user has all sorts of software scattered over his system, with no way to manage, update and uninstall them. How is that situation any better than using PPAs?
- fletchowns 11y ago
  Use checkinstall? It's somewhere between installing from source and installing from a package. https://help.ubuntu.com/community/CheckInstall https://help.ubuntu.com/community/CheckInstall
- 4ydx 11y ago
  Install to your own custom path? /opt ... /local ... /myfolder ... etc. Add the path to your user's $PATH. If you are familiar with linux this isn't really much harder to do. If it is a library that you are then compiling against it does get a bit more difficult, of course, but it is only a good thing to become familiar with these things. If you are ok with "polluting" your path, you can install each new binary + libs to its own custom path. You simply delete the folder in the future when you no longer need it anymore.
  - sirclueless 11y ago
    Not really an answer for packages that need configuration in /etc, add desktop entries to user's menus, or should be discoverable for example by systemd. Adding to everyone's PATH is invasive and not really an option for most multi-user systems.
    - 4ydx 11y ago
      I was responding to somebody who made the claim that installing software leaves things "scattered all over the system". I simply pointed out that that is not true if you plan carefully. Additionally you can ensure that all users on a system have a basic set of paths enabeled in their profile (is the default PATH any more invasive than a default path + "/opt/bin"? These things are not insurmountable if you actually know what you are talking about and know the scope of your problem. These complaints are coming from people who are not actually interested in managing a system, but would rather be able to click a button in a gui and not have to understand anything of what is actually going on. That being said compiling your own stuff in and of itself is not guaranteed to be a simple or "fun" task. It takes work and can lead to unexpected results: you immediately own anything that is custom on your system and become your own testing, debugging, and troubleshooting team. It isn't ideal.
davexunit 11y ago
Allowing users to easily extend the available packages is not an anti-pattern, it's practical software freedom!
dman 11y ago
The good part about PPA's are that they can be ignored completely. After being bitten once or twice, I have stuck to not installing anything that isnt in the core ubuntu repositories.
- Touche 11y ago
  I don't know how you can subsist on Ubuntus severely outdated packages.
  - dman 11y ago
    Could you elaborate which packages you use from PPAs?
- jnbiche 11y ago
  In my 6+ years of using Ubuntu and derivatives, and frequently installing PPAs, I've never had a problem or been bitten. And I've only exercised a little bit of caution. On the other hand, I ran into massive headaches when I used to try to pin apt repositories. No more of that for me. PPAs are the main reason I use Ubuntu distros now instead of Debian.
tacone 11y ago
The lack of PPA has hold the industry back for years. Outdated Apaches, outdated Mysqls, outdated PHPs. In a word, distro mantainers became gateway keepers, and bad ones, since they don't have the unlimited resources required to keep everything to date. While there definitely are cases when you want somebody to pick the versions for you, nowadays the industry is moving just to fast for keep most people satisfied. Of course there will be poor PPA's. Poor Github repositories also exists, bad NPM packages exist, bad Maven packages exist, but that does not stop people to search for the right ones and take charge of their own future.

radoslawc 11y ago

From: https://help.ubuntu.com/community/PPA https://help.ubuntu.com/community/PPA "Security PPAs have not undergone the same process of validation as regular ubuntu packages. End users install PPAs at their own risk. Although each key is cryptographically signed, in order to confirm an uploader, keys are not matched to specific individuals, except via their "launchpad" accounts. Subsequently, installing a PPA should be considered to be a low-security alternative as compared to the main repository, but marginally higher security than simply installing software at random from the internet. As part of adding a PPA, you trust the developer to not only install packages, but also to allow them to provide ongoing updates." This pretty much sums it all. It's not matter of hostility towards PPA or trying to keep things oldskool. With all effort towards signed, verified packages, reproductible builds etc. adding functionality like PPA is for me nothing more as installing "shareware" windows apps from random sites. Building packages by yourself is not that hard especially with fpm or checkinstall.

ploxiln 11y ago
You might gain some trust in a team which maintains a particular PPA. You import their key manually, and the key is not auto-updated or anything. Installing shareware windows apps from "random sites" seems riskier, they're not signed by a single uploader's key which you import just once.
- radoslawc 11y ago
  You're right. I've trolled a little. But still, this brings security issues with it.