4 ms·

> Containers are great and all, they solve many problems but they're not the only solution and theyre definitely not the best solution to every problem. There

> Containers are great and all, they solve many problems but they're not the only solution and theyre definitely not the best solution to every problem. There a large number of developers around now who've never done traditional (RPM, DEB, SysV) packaging and don't understand it. So while the large distros like Redhat and Debian push on with it, the development community only sees Dockerfiles, Snaps, Flatpaks etc.

thejosh 5y ago
Most packaging for software was done by the distro and not the actual software authors though right?
- nickelpro 5y ago
  Yes, packaging has always been a distro issue never an upstream issue. At the extreme end of this you can look at Arch's saga with Visual Studio Code, since the Arch packagers want to disentangle the .asar app from the specific Electron version it ships inside of (they view Electron as a system library).
  - pabs3 5y ago
    Chromium (and thus Electron, although they deliberately lag behind Chromium) has very frequent security updates. While clearly not all of those affect Electron, and not all of those affect every Electron app, some of them will affect Electron and some will affect some Electron apps. While some Electron apps will follow the (deliberately lagging) Electron security update cycle, most developers probably do not update their app for every Electron security update. So it makes sense for distros like Arch to want to ship the security supported Electron version and have every Electron app use that, but maybe all the changes in Electron are breaking apps that use it, so maybe it makes sense to ship one Electron version per Electron app, but then you get an unknown amount of security issues with each app, depending on how out of date the app's Electron version is. So the choice is between a working app with an unknown amount of security issues, or a regularly broken app with fewer security issues. Neither seem like great options to me. Perhaps Electron needs an LTS version to solve this issue.
KronisLV 5y ago
> There a large number of developers around now who've never done traditional (RPM, DEB, SysV) packaging and don't understand it. I'm one of these developers (at least as far as my day job is concerned) and the only methods of delivery in a professional context that i've seen have been: - delivering .jar or .war application files (Java), mostly through FTP or even e-mail - delivering other files, like documentation etc., mostly through FTP or even e-mail - using containers and pushing images to registries (mostly due to my initiative) This is across ~5 years of software development and while looking at projects from multiple companies in my country - not once have i seen a DEB or RPM package repository be used. To me, it seems like previously people opted for the simplest solution in their eyes, which was just shuffling a bunch of files around through FTP, i guess since that doesn't lock you down to using a particular distro or even OS. However, streamlining that process on our end and eventually migrating over to containers, to where both the CI and CD are automated (or at least based on a manually invoked pipeline, when we're sure about making a release) seemed to be a no-brainer. Suddenly delivering software isn't something that takes an hour - even if needless cruft (making Jira issues manually etc.) is still there, any automation and getting rid of the human factor makes things safer and easier. That said, it surprises me that previously no one bothered to set up their own DEB or RPM repositories, since then the clients could use the package management solutions that they're already familiar with. Any idea what are some of the reasons for it? Why doesn't everyone just make it so that their software can be installed and updated through apt/yum/...?
- pmontra 5y ago
  Somebody replied to a post of mine in a thread like this years ago stating that he was converting every Ruby gem in his dependencies into a .deb and he was installing them with apt. That was the right way to do and everybody else is doing it wrong. I don't remember if I replied but the sheer amount of work is astounding.
  - jbboehr 5y ago
    I did this once. It was a terrible idea. Nix solves the same problem of wanting better control of system-level dependencies but without all the manual packaging.
strzibny 5y ago
You are not wrong. But if you make an RPM, you can then easily make a container containing the said RPM ;)

thejosh 5y ago

Most packaging for software was done by the distro and not the actual software authors though right?

nickelpro 5y ago
Yes, packaging has always been a distro issue never an upstream issue. At the extreme end of this you can look at Arch's saga with Visual Studio Code, since the Arch packagers want to disentangle the .asar app from the specific Electron version it ships inside of (they view Electron as a system library).
- pabs3 5y ago
  Chromium (and thus Electron, although they deliberately lag behind Chromium) has very frequent security updates. While clearly not all of those affect Electron, and not all of those affect every Electron app, some of them will affect Electron and some will affect some Electron apps. While some Electron apps will follow the (deliberately lagging) Electron security update cycle, most developers probably do not update their app for every Electron security update. So it makes sense for distros like Arch to want to ship the security supported Electron version and have every Electron app use that, but maybe all the changes in Electron are breaking apps that use it, so maybe it makes sense to ship one Electron version per Electron app, but then you get an unknown amount of security issues with each app, depending on how out of date the app's Electron version is. So the choice is between a working app with an unknown amount of security issues, or a regularly broken app with fewer security issues. Neither seem like great options to me. Perhaps Electron needs an LTS version to solve this issue.

KronisLV 5y ago

> There a large number of developers around now who've never done traditional (RPM, DEB, SysV) packaging and don't understand it. I'm one of these developers (at least as far as my day job is concerned) and the only methods of delivery in a professional context that i've seen have been: - delivering .jar or .war application files (Java), mostly through FTP or even e-mail - delivering other files, like documentation etc., mostly through FTP or even e-mail - using containers and pushing images to registries (mostly due to my initiative) This is across ~5 years of software development and while looking at projects from multiple companies in my country - not once have i seen a DEB or RPM package repository be used. To me, it seems like previously people opted for the simplest solution in their eyes, which was just shuffling a bunch of files around through FTP, i guess since that doesn't lock you down to using a particular distro or even OS. However, streamlining that process on our end and eventually migrating over to containers, to where both the CI and CD are automated (or at least based on a manually invoked pipeline, when we're sure about making a release) seemed to be a no-brainer. Suddenly delivering software isn't something that takes an hour - even if needless cruft (making Jira issues manually etc.) is still there, any automation and getting rid of the human factor makes things safer and easier. That said, it surprises me that previously no one bothered to set up their own DEB or RPM repositories, since then the clients could use the package management solutions that they're already familiar with. Any idea what are some of the reasons for it? Why doesn't everyone just make it so that their software can be installed and updated through apt/yum/...?

pmontra 5y ago
Somebody replied to a post of mine in a thread like this years ago stating that he was converting every Ruby gem in his dependencies into a .deb and he was installing them with apt. That was the right way to do and everybody else is doing it wrong. I don't remember if I replied but the sheer amount of work is astounding.
- jbboehr 5y ago
  I did this once. It was a terrible idea. Nix solves the same problem of wanting better control of system-level dependencies but without all the manual packaging.

strzibny 5y ago

You are not wrong. But if you make an RPM, you can then easily make a container containing the said RPM ;)