4 ms·

This seems to less a complaint about packages and more a debate over Rolling vs Non-Rolling Distro's The Author seems to take the opinion that Rolling is alway

This seems to less a complaint about packages and more a debate over Rolling vs Non-Rolling Distro's The Author seems to take the opinion that Rolling is always better for Security because he selected a few "web" packages and found vulnerabilities in the shipping versions. Ofcourse for the people running mission critical enterprise applications they probally are not running phpmyadmin on that server so they could care less if the repo for their stable version of debian contains that older software. I agree it is problem, but the solution to that problem can not simply be rolling all the time. I use Arch on my Desktop system, but I would never run my employers mission critical database on Arch... I need stability and security, not simply security. Ultimately I think we need a better way to define the Core OS, vs "User Applications" Things like glibc, the kernel, etc are clearly coreOS, things like phpmyadmin are User Applications. Where it get grey is databases, webserver etc. Do you lable them a Core product or a User App, if I was running a mission critical applications I would not want my mariaDB system just upgraded to the lastest version with new features and possible breaking (removing) older features that my app may still need. Enterprises move slow, I still have enterprise applications that require Java 6, I have some things that still have software that only run on Windows 2000. This idea that Rolling to the latest version of software all the time is a workable plan highlights the authors ignorance of how enterprises actually work.

kchoudhu 11y ago
The FreeBSD folks have made a pretty good separation between "base" (what you call Core OS) and "ports" (what you call user applications). It works wonderfully. This isn't a new observation, and I'm kind of surprised it hasn't made it into mainline linux packaging philosophy yet.
- the_ancient 11y ago
  My knowlege of FreeBSD is limited, but from what I understand this still does not resolve the issue. While they have seperated the base OS, they have not resolve the issues of applications that can be mission critical, thus warrant to be frozen like the base os is. Things like apache, mysql, etc etc etc. If you treat them like user apps then they will be updated when maybe I did not want them to be, but if you treat them like base os then you have the problem the author outlines. Fruther my understanding is the ports system only supports the lastest version of FreeBSD, meaning if you want to use ports you always have to update to the latest version when released. I have CentOS and RHEL Servers running version 5, if it were FreeBSD I would not be able to use this 2 release old version of FreeBSD and ports, I would have to upgrade.
  - kchoudhu 11y ago
    >> Things like apache, mysql, etc etc etc. That's well beyond the remit of the OS developers who are only responsible for FreeBSD, but the ports team has happily provided us with `pkg lock` to prevent edits to ports once they are installed. >> my understanding is the ports system only supports the lastest version of FreeBSD I believe the the ports tree will be compiled for a given branch until the underlying branch is EOL. FreeBSD 8, for example, had binary packages built from 2009(?) until the branch was EOL'd last year. That's six years of support for 3rd party software, after which you can maintain/build your own pkg repository. I understand the desire for longer environment lifecycles in FreeBSD (I hate the continuous upgrade cycle myself), but without a company stepping up and providing long term commercial support, I'm not seeing how a volunteer project as small as FreeBSD can do more for longer.
    - the_ancient 11y ago
      >>That's well beyond the remit of the OS developers who are only responsible for FreeBSD, That is exactly the point the author is making by declaring that "packages are not secure". they are not maintained by the OS, but are distributed as "official" thus giving some users the illusion they are supported or "in the remit" of the OS Developers
technion 11y ago
Enterprises also tend to buy products with well defined supported platforms. It's fine to say "Debian version x". Who's going to advertise their product as "supported with Arch, whatever updates are going" ?

kchoudhu 11y ago

The FreeBSD folks have made a pretty good separation between "base" (what you call Core OS) and "ports" (what you call user applications). It works wonderfully. This isn't a new observation, and I'm kind of surprised it hasn't made it into mainline linux packaging philosophy yet.

the_ancient 11y ago
My knowlege of FreeBSD is limited, but from what I understand this still does not resolve the issue. While they have seperated the base OS, they have not resolve the issues of applications that can be mission critical, thus warrant to be frozen like the base os is. Things like apache, mysql, etc etc etc. If you treat them like user apps then they will be updated when maybe I did not want them to be, but if you treat them like base os then you have the problem the author outlines. Fruther my understanding is the ports system only supports the lastest version of FreeBSD, meaning if you want to use ports you always have to update to the latest version when released. I have CentOS and RHEL Servers running version 5, if it were FreeBSD I would not be able to use this 2 release old version of FreeBSD and ports, I would have to upgrade.
- kchoudhu 11y ago
  >> Things like apache, mysql, etc etc etc. That's well beyond the remit of the OS developers who are only responsible for FreeBSD, but the ports team has happily provided us with `pkg lock` to prevent edits to ports once they are installed. >> my understanding is the ports system only supports the lastest version of FreeBSD I believe the the ports tree will be compiled for a given branch until the underlying branch is EOL. FreeBSD 8, for example, had binary packages built from 2009(?) until the branch was EOL'd last year. That's six years of support for 3rd party software, after which you can maintain/build your own pkg repository. I understand the desire for longer environment lifecycles in FreeBSD (I hate the continuous upgrade cycle myself), but without a company stepping up and providing long term commercial support, I'm not seeing how a volunteer project as small as FreeBSD can do more for longer.
  - the_ancient 11y ago
    >>That's well beyond the remit of the OS developers who are only responsible for FreeBSD, That is exactly the point the author is making by declaring that "packages are not secure". they are not maintained by the OS, but are distributed as "official" thus giving some users the illusion they are supported or "in the remit" of the OS Developers

technion 11y ago

Enterprises also tend to buy products with well defined supported platforms. It's fine to say "Debian version x". Who's going to advertise their product as "supported with Arch, whatever updates are going" ?