3 ms·

> Suppose I used entirely off-the-shelf puppet code. Nothing custom, just modules I found. And I erased my repo which contains my puppet modules. How would I re

> Suppose I used entirely off-the-shelf puppet code. Nothing custom, just modules I found. And I erased my repo which contains my puppet modules. How would I rebuild it and get the same thing that I had before? Well, there's Blueprint (http://devstructure.com/blueprint/ http://devstructure.com/blueprint/) which purports to reverse engineer servers and spit out Chef / Puppet modules. But... I'm not sure I understand the question. It seems akin to asking "I deleted all of my source code, how do I rebuild what I had before?" That's why we have version control. That's why we have backups. I also don't understand this rant in the context of Rust and its Cargo package manager. There are several distinct domains involved, and it seems pretty reasonable for each to have its own management tool. Puppet, Chef, Ansible, or Salt for handling machine configuration. Yum or APT for handling system-level packages and services. Pip, Gem, NPM, or Cargo for application-level dependencies. Seems pretty reasonable to me. If you need it to instantiate brand new machines, you can get into VMs (VirtualBox / VMware) or containers (Docker), each of which can also be trivially scripted (Vagrantfiles / Dockerfiles). The whole array of tooling seems more complementary than competitive.

jzwinck 13y ago
> Yum or APT for handling system-level packages and services. Pip, Gem, NPM, or Cargo for application-level dependencies. That's the thing: what is the distinction between "system-level" and "application-level"? Has it really gotten to the point where the only thing we can use /usr/bin/python for is to run other things in /usr/bin? This may very well be the case, but it strikes me as slightly strange given that we never used to be afraid of linking against /usr/lib or running our scripts under /bin/bash. What happened in the past 10-15 years that changed the world so much that whereas before we ran our applications on top of the system, now we seem to want to run them in individual sandboxes, often inside of other sandboxes inside of other sandboxes? Was it really so bad to yum install and gcc -lwhatever without having special paths everywhere for everything?
- danielweber 13y ago
  I have run into this "system-level" versus "application-level" problem before. Maybe my OS's package manager installed foo-fred.tgz but then foo has its own manager and it wants to install a different version of fred, but I have absolutely no idea who maintains it, besides it magically pulling stuff off the webtubes from God-knows-where. And how do I verify the integrity of those packages? It's a nightmare. I just plug my nose and dive in and hope that whenever things go really bad it won't be on a day when I'm busy.
- ermintrude 13y ago
  Have you ever worked with other people who use different OSes, or need different versions of libraries installed?
- callahad 13y ago
  > what is the distinction between "system-level" and "application-level"? I think it mostly comes back to scope or encapsulation. I expect my host to provide facilities external to my program (databases, sendmail, a webserver), and I expect to have control over the software libraries internal to my program. Perhaps you're also asking why APT or Yum, which are great at managing system-level package availability and versioning, couldn't be adapted for local use by applications. I'm not sure there's a good answer for that. Maybe it's just portability? If BlubLang runs on 9 platforms, then BlubPM needs to run on those same 9 platforms. It's probably easier to get there if BlubPM is written in BlubLang. > What happened in the past 10-15 years that changed the world so much that whereas before we ran our applications on top of the system, now we seem to want to run them in individual sandboxes, often inside of other sandboxes inside of other sandboxes? VMs? I once heard a terrible analogy to the effect that we used to treat servers like pets: we gave them cute names and we nursed them back to health when they got sick. Now we treat them like livestock: if one gets sick, you shoot it and get a new one. There's a hilarious send-up of hand-maintained systems in the "DevOps is Ruining My Craft" article at http://tatiyants.com/devops-is-ruining-my-craft/ http://tatiyants.com/devops-is-ruining-my-craft/ The more you isolate the applications from the host, the easier it is to redeploy them.

jzwinck 13y ago

> Yum or APT for handling system-level packages and services. Pip, Gem, NPM, or Cargo for application-level dependencies. That's the thing: what is the distinction between "system-level" and "application-level"? Has it really gotten to the point where the only thing we can use /usr/bin/python for is to run other things in /usr/bin? This may very well be the case, but it strikes me as slightly strange given that we never used to be afraid of linking against /usr/lib or running our scripts under /bin/bash. What happened in the past 10-15 years that changed the world so much that whereas before we ran our applications on top of the system, now we seem to want to run them in individual sandboxes, often inside of other sandboxes inside of other sandboxes? Was it really so bad to yum install and gcc -lwhatever without having special paths everywhere for everything?

danielweber 13y ago
I have run into this "system-level" versus "application-level" problem before. Maybe my OS's package manager installed foo-fred.tgz but then foo has its own manager and it wants to install a different version of fred, but I have absolutely no idea who maintains it, besides it magically pulling stuff off the webtubes from God-knows-where. And how do I verify the integrity of those packages? It's a nightmare. I just plug my nose and dive in and hope that whenever things go really bad it won't be on a day when I'm busy.
ermintrude 13y ago
Have you ever worked with other people who use different OSes, or need different versions of libraries installed?
callahad 13y ago
> what is the distinction between "system-level" and "application-level"? I think it mostly comes back to scope or encapsulation. I expect my host to provide facilities external to my program (databases, sendmail, a webserver), and I expect to have control over the software libraries internal to my program. Perhaps you're also asking why APT or Yum, which are great at managing system-level package availability and versioning, couldn't be adapted for local use by applications. I'm not sure there's a good answer for that. Maybe it's just portability? If BlubLang runs on 9 platforms, then BlubPM needs to run on those same 9 platforms. It's probably easier to get there if BlubPM is written in BlubLang. > What happened in the past 10-15 years that changed the world so much that whereas before we ran our applications on top of the system, now we seem to want to run them in individual sandboxes, often inside of other sandboxes inside of other sandboxes? VMs? I once heard a terrible analogy to the effect that we used to treat servers like pets: we gave them cute names and we nursed them back to health when they got sick. Now we treat them like livestock: if one gets sick, you shoot it and get a new one. There's a hilarious send-up of hand-maintained systems in the "DevOps is Ruining My Craft" article at http://tatiyants.com/devops-is-ruining-my-craft/ http://tatiyants.com/devops-is-ruining-my-craft/ The more you isolate the applications from the host, the easier it is to redeploy them.