12 ms·

So, basically, replace yum, apt, etc. with a 'stateless package management system'. That seems to be the gist of the argument. Puppet, Chef and Ansible (he left

So, basically, replace yum, apt, etc. with a 'stateless package management system'. That seems to be the gist of the argument. Puppet, Chef and Ansible (he left out Salt and cfengine!) have little to do with the actual post, and are only mentioned briefly in the intro. They would all still be relevant with this new packaging system. For some reason, this came to mind: https://xkcd.com/927/ https://xkcd.com/927/

NyxWulf 13y ago
Yeah that xkcd came to my mind as well. I'm amazed at the timeless truths he captures in those comics. Creating another version which may be better isn't the hard part. Gaining consensus and getting people to give up the other ones is the hard part.
- talkingquickly 13y ago
  And in a way which so many people relate to. As soon as I saw "xkcd" I knew which one was going to be linked to...
  - saraid216 13y ago
    I still want to do a thing where response codes are returned the way they are for HTTP. Query: Why are you screwing around? Response: XKCD 303.
- sdegutis 13y ago
  As existing solutions get more painful, people quickly adopt less painful (i.e. generally better) solutions. So it's tied just as much to how much the old ways suck as to how good the new ways are.
bryanlarsen 13y ago
True, but: `sudo apt-get install nginx` just works. Perhaps they're doing it "wrong", but there are thousands of people who are making sure it just works. I have some of the problems described in the article, but it only happens when I can't use the package manager. It happens when I have to compile from scratch, or move things around or mess with config files, et cetera. For me, phoenix servers and docker are the solutions. Maybe they're not as pretty as what he describes, but there is a solution that works.
- josegonzalez 13y ago
  `sudo apt-get install nginx` does not just work if: - The repo is down - External network doesn't work - You are missing a dependency not in your apt-cache - It conflicts with another package due to a dependency All of which are possible and happen.
  - rmc 13y ago
    There are lots of people ensuring that doesn't happen. Sure it's possible, but it's unlikely. There are loads of debian/ubuntu apt mirrors. apt-get (or aptitude) downloads dependencies, package maintainers ensure that there aren't those conflicts.
    - haberman 13y ago
      This reminds me of a particularly devious C preprocessor trick: #define if(x) if ((x) && (rand() < RAND_MAX * 0.99)) Now your conditionals work correctly 99% of the time. Sure it's possible for them to fail, but unlikely. Now you might object that C if() statements are far more commonly executed than "apt-get install". This is true, but to account for this you can adjust "0.99" above accordingly. The point is that there is a huge difference between something that is strongly reliable and something that is not. Things that are unreliable, even if failure is unlikely, lead to an endless demand for SysAdmin-like babysitting. A ticket comes in because something is broken, the SysAdmin investigates and found that 1 out of 100 things that can fail but usually doesn't has in fact failed. They re-run some command, the process is unstuck. They close the ticket with "cron job was stuck, kicked it and it's succeeding again." Then go back to their lives and wait for the next "unlikely but possible" failure. Some of these failures can't be avoided. Hardware will always fail eventually. But we should never accept sporadic failure in software if we can reasonably build something more reliable. Self-healing systems and transient-failure-tolerant abstractions are a much better way to design software.
      - lmm 13y ago
        That difference goes away at the point where other risk factors are higher. How high is my confidence that there isn't a programming bug in Nix? Above 99%, perhaps, but right now it's less than my confidence that apt-get is going to work. Most of us happily use git, where if you ever get a collision on a 128-bit hash it will irretrievably corrupt your repository. It's just not worth fixing when other failures are so much more likely.
berkay 13y ago
Author's point is that we are focusing on the wrong place (puppet, chef, etc.), hence potentially making the problem worse by attempting to deal with the symptoms instead of addressing the root cause. Puppet/Chef etc. may indeed still be relevant and potentially even more widely used as it would become much simpler to develop recipes, etc.
- geerlingguy 13y ago
  I think the takeaway is that package management is ripe for improvement, but CM tools (and more flexible tools like Ansible) do so many more things besides automating package management that I question the author's mention of them for anything besides a hook to get more pageviews. This article has little to do with config management. A better title would be "apt, yum and brew aren't good enough; we can do better".
  - girvo 13y ago
    No, NixOS and NixOps tackle both, and you can't have the latter without the former. They are all intertwined, hence talking about both in the article :)
cwp 13y ago
No. Well, yes, replace yum, apt, etc. But once you have a functional package management system, you don't need Puppet, Chef or Ansible, because the same stateless configuration language can be used to describe cluster configurations as well as packages. So build a provisioning tool based on that, instead. That provisioning tool is called NixOps. The article links to it, but doesn't really go into detail about NixOps as a replacement for Puppet et al.
- lmm 13y ago
  That's just as true without Nix. I've worked somewhere that applied changes to its clusters by building debs; all you need is something that regularly executes apt-get and you're golden. (Of course, whether something's a good language for expressing particular kinds of tasks is another question)
- jes5199 13y ago
  am I going to switch distros just to use a different provisioning tool?
  - sparkie 13y ago
    Yes... Eventually. The Nix model is the only sane model going into the future where complexity will continue to increase. Nobody is forcing you to switch distros now, but hinting that you'll probably want to look into this, because the current models might well be on their way to obsolescence.
    - westurner 13y ago
      * Unique PREFIX; cool. Where do I get signed labels and checksums? * I fail to see how baking configuration into packages can a) reduce complexity; b) obviate the need for configuration management. * How do you diff filesystem images when there are unique PREFIXes in the paths? A salt module would be fun to play around with. How likely am I to volunteer to troubleshoot your unique statically-linked packages?
      - deleted 13y ago

NyxWulf 13y ago

Yeah that xkcd came to my mind as well. I'm amazed at the timeless truths he captures in those comics. Creating another version which may be better isn't the hard part. Gaining consensus and getting people to give up the other ones is the hard part.

talkingquickly 13y ago
And in a way which so many people relate to. As soon as I saw "xkcd" I knew which one was going to be linked to...
- saraid216 13y ago
  I still want to do a thing where response codes are returned the way they are for HTTP. Query: Why are you screwing around? Response: XKCD 303.
sdegutis 13y ago
As existing solutions get more painful, people quickly adopt less painful (i.e. generally better) solutions. So it's tied just as much to how much the old ways suck as to how good the new ways are.

bryanlarsen 13y ago

True, but: `sudo apt-get install nginx` just works. Perhaps they're doing it "wrong", but there are thousands of people who are making sure it just works. I have some of the problems described in the article, but it only happens when I can't use the package manager. It happens when I have to compile from scratch, or move things around or mess with config files, et cetera. For me, phoenix servers and docker are the solutions. Maybe they're not as pretty as what he describes, but there is a solution that works.

josegonzalez 13y ago
`sudo apt-get install nginx` does not just work if: - The repo is down - External network doesn't work - You are missing a dependency not in your apt-cache - It conflicts with another package due to a dependency All of which are possible and happen.
- rmc 13y ago
  There are lots of people ensuring that doesn't happen. Sure it's possible, but it's unlikely. There are loads of debian/ubuntu apt mirrors. apt-get (or aptitude) downloads dependencies, package maintainers ensure that there aren't those conflicts.
  - haberman 13y ago
    This reminds me of a particularly devious C preprocessor trick: #define if(x) if ((x) && (rand() < RAND_MAX * 0.99)) Now your conditionals work correctly 99% of the time. Sure it's possible for them to fail, but unlikely. Now you might object that C if() statements are far more commonly executed than "apt-get install". This is true, but to account for this you can adjust "0.99" above accordingly. The point is that there is a huge difference between something that is strongly reliable and something that is not. Things that are unreliable, even if failure is unlikely, lead to an endless demand for SysAdmin-like babysitting. A ticket comes in because something is broken, the SysAdmin investigates and found that 1 out of 100 things that can fail but usually doesn't has in fact failed. They re-run some command, the process is unstuck. They close the ticket with "cron job was stuck, kicked it and it's succeeding again." Then go back to their lives and wait for the next "unlikely but possible" failure. Some of these failures can't be avoided. Hardware will always fail eventually. But we should never accept sporadic failure in software if we can reasonably build something more reliable. Self-healing systems and transient-failure-tolerant abstractions are a much better way to design software.
    - lmm 13y ago
      That difference goes away at the point where other risk factors are higher. How high is my confidence that there isn't a programming bug in Nix? Above 99%, perhaps, but right now it's less than my confidence that apt-get is going to work. Most of us happily use git, where if you ever get a collision on a 128-bit hash it will irretrievably corrupt your repository. It's just not worth fixing when other failures are so much more likely.

berkay 13y ago

Author's point is that we are focusing on the wrong place (puppet, chef, etc.), hence potentially making the problem worse by attempting to deal with the symptoms instead of addressing the root cause. Puppet/Chef etc. may indeed still be relevant and potentially even more widely used as it would become much simpler to develop recipes, etc.

geerlingguy 13y ago
I think the takeaway is that package management is ripe for improvement, but CM tools (and more flexible tools like Ansible) do so many more things besides automating package management that I question the author's mention of them for anything besides a hook to get more pageviews. This article has little to do with config management. A better title would be "apt, yum and brew aren't good enough; we can do better".
- girvo 13y ago
  No, NixOS and NixOps tackle both, and you can't have the latter without the former. They are all intertwined, hence talking about both in the article :)

cwp 13y ago

No. Well, yes, replace yum, apt, etc. But once you have a functional package management system, you don't need Puppet, Chef or Ansible, because the same stateless configuration language can be used to describe cluster configurations as well as packages. So build a provisioning tool based on that, instead. That provisioning tool is called NixOps. The article links to it, but doesn't really go into detail about NixOps as a replacement for Puppet et al.

lmm 13y ago
That's just as true without Nix. I've worked somewhere that applied changes to its clusters by building debs; all you need is something that regularly executes apt-get and you're golden. (Of course, whether something's a good language for expressing particular kinds of tasks is another question)
jes5199 13y ago
am I going to switch distros just to use a different provisioning tool?
- sparkie 13y ago
  Yes... Eventually. The Nix model is the only sane model going into the future where complexity will continue to increase. Nobody is forcing you to switch distros now, but hinting that you'll probably want to look into this, because the current models might well be on their way to obsolescence.
  - westurner 13y ago
    * Unique PREFIX; cool. Where do I get signed labels and checksums? * I fail to see how baking configuration into packages can a) reduce complexity; b) obviate the need for configuration management. * How do you diff filesystem images when there are unique PREFIXes in the paths? A salt module would be fun to play around with. How likely am I to volunteer to troubleshoot your unique statically-linked packages?
    - deleted 13y ago