Hacker News new | past | comments | ask | show | jobs | submit login

But it won't solve the problem of developers' unwillingness to learn how to make operating system packages now will it?

I don't get it: people like that will sink and waste hundreds of hours learning useless garbage like Puppet, Ansible, Chef, Docker or Kubernetes without batting an eyelash or even thinking twice about it, but they'll argue and fight back like hell come time to deliver their software as clean OS packages because they don't want to learn the technology. Technology which exists for them first and foremost: OS packaging is meant to be a developer's tool and best friend.




Because those providing the said technology cannot agree what it means to be a GNU/Linux OS, and we have limited time on our life to bother with thousand variants of it.


Linux is just a kernel, so every distribution is a somewhat similar yet completely different operating system.

Reality is, most software targets CentOS / RHEL, OpenSUSE / SLES and Debian / Ubuntu. That's exactly two packaging formats, RPM and DPKG.

Now, let's presume for the purpose of illustration that learning both of those takes 100 hours (it takes much less): to learn Chef, Puppet, Docker, Ansible and Kubernetes to any degree of proficiency takes about 1,000 hours. Where's the business value?


Try to install a random RPM package targeted to Red-Hat on SLES to see how far you will go.


That's again due to incompetence and not a fault of RPM. My own spec files build cleanly across both without any additional effort. It's not rocket science but insight.


Ah, like the C based security exploits are the fault of programmer and not the lack of safety features to start with.


Absolutely correct. Those who do not understand the hardware on the register and machine code level should go master that first before dabbling with C.

One has to learn to walk before one attempts to run. Working on and with computers requires competence and insight; no technology can replace that nor ameliorate it.


Nice point of view, then you wonder why devs prefer package managers that abstract OSes.


I do, because in long term sight their approach is irrational and expensive.


But you don't have limited time to re-invent the wheel over and over again by inventing new programming languages, learning new frameworks and re-implementing what already exists? How many headlines here were of the "why do it inefficiently? Because I can!" type? The limited time argument is a fallacy in this context.


A language package manager works everywhere, regadless of the OS.

Thankfully modern languages are mostly OS agnostic due to their rich runtimes and library eco-systems.


A language package manager is system administrator's enemy and her or his nightmare.

Now you explain to me why and how that is the case.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: