5 ms·

As I wrote previously, the question is for the founder of Docker and him alone, but since you volunteered your opinion, I am extremely pleased to inform you tha

by Annatar 10y ago

As I wrote previously, the question is for the founder of Docker and him alone, but since you volunteered your opinion, I am extremely pleased to inform you that I love making OS packages and performing configuration management at scale that way. I especially enjoy being able to ask the operating system's software management subsystem exactly which configuration changes have been done to it, and get a precise response back. I enjoy it even more when I am able to perform mass in-place upgrades of configuration, on tens of thousands of systems, in parallel, because I'm performing configuration management using operating system packages, or simply destroy the system's boot block, reboot it, and have the network instantiate it, from bare metal to fully configured virtual servers ready to serve data, by just using Kickstart, JumpStart(TM), or SDC, without any additional code. No Chef. No Puppet. No cfxengine. No Salt. No Ansible. No Docker. No KVM. No XEN. No Kubernetes. No Mesos. No extra software or daemons required or needed, other than what ships with the OS. Fully isolated, virtualized UNIX servers. Servers are cattle, not pets. Deployments in up to 25 seconds. That was the challenge. And it was fun to solve. Have fun maintaining OS packages. Oh I am! It's incredibly satisfying to be able to run systems where no human has ever logged into, and no file has ever been manually modified, and all the files and all the changes are accounted for by the operating system. See also, not quite the same, but very much related and relevant to your comment: http://www.perkin.org.uk/posts/building-packages-at-scale.html http://www.perkin.org.uk/posts/building-packages-at-scale.ht... https://blog.nimbleci.com/2016/10/11/how-to-deploy-jenkins-completely-pre-configured/ https://blog.nimbleci.com/2016/10/11/how-to-deploy-jenkins-c... https://news.ycombinator.com/item?id=12750685 https://news.ycombinator.com/item?id=12750685 Configuration management at scale, using an operating system's software management subsystem is the old, new-new thing. It is the foundation and the future of even more massive cloud computing. Now you'll be able to say someday in the future: "ha! I read that on Hacker News years ago!", and point to this post.

tinco 10y ago
So what are you bugging shykes for? You have achieved everything Docker offers, and you had fun in the process. Seems like you're smart enough to realize that. Anyway, someday in the future I might look back on this and think "ha! someone put all that effort in even though NixOS already existed".
- Annatar 10y ago
  So what are you bugging shykes for? All I did was ask a question. Is critical thinking, even just asking questions, undesirable now, unless someone is being praised to high heavens? Is that what we're down to now? "ha! someone put all that effort in even though NixOS already existed" SmartOS virtualization is based on Solaris zones, which existed long before people on GNU/Linux even realized that containers were the way to go. The groundwork, and my own work was laid down long before any of this became hype. Project Kevlar, nee zones was started around the same time as NixOS, and another participant already mentioned that large companies did large scale deployments and configuration management via OS packages, which is both true and correct.
  - tinco 10y ago
    You did not just ask a question as a form of critical thinking. You asked a question leading into a lecture on the technology you prefer. Docker is just a simple wrapper that reduces the amount of knowledge needed to run a containerized process. It did not become hype because of any technological advantage, it became hype because this old technology became accessible not just for the kind of people/companies that don't (can't) run enterprise class Solaris deployments, but also the kind that don't have 20 years of experience in making robust well managed deployments. Your process might seem easy and straightforward to you. But for the average developer and Linux enthousiast, there's not much that can the simplicity of the Dockerfile. Systemd or a more specialized system like Kubernetes to run the containers, and a simple script to provision your machine is all you need. You can pick all of this tech up in a few days and steadily grow into more advanced subjects like monitoring, logging, security. Anyway, you're not helping anyone by just saying "SmartOS is better than Docker+(list of redundant and unrelated other tech)", maybe instead show us a one-page tutorial on how to set up a SmartOS system with a webapp stack (i.e. LAMP, MEAN or RoR) that can be executed by a newbie without a creditcard, registration, trial or phone call.
    - Annatar 10y ago
      You did not just ask a question as a form of critical thinking. Yes I did. You asked a question leading into a lecture on the technology you prefer. Only after you left your Good luck with packaging everything, which I have good reason to believe was cynical sarcasm. It did not become hype because of any technological advantage, it became hype because this old technology became accessible not just for the kind of people/companies that don't (can't) run enterprise class Solaris deployments, Performing configuration management at scale with OS packaging has nothing to do with Solaris - it works on any operating system which has a Bourne-family shell, AWK, and sed. but also the kind that don't have 20 years of experience in making robust well managed deployments. Then it would be a good idea for such people to actively seek mentors. But for the average developer and Linux enthousiast, there's not much that can the simplicity of the Dockerfile. That's what distinguishes the average developer. A true enthusiast will go out of their way to become a master of the art, so the assertion doesn't apply to them. It's easy to hack several hundred thousand files together and deliver them via Docker. But, what happens when it's time for upgrades? Go through the entire hackfest again? Every time? Anyway, you're not helping anyone that depends on what your mentality is: if you're a true enthusiast, you're probably reading a lot, and when you stumble upon crumb trails like mine, the light bulb might go off reading what I wrote, and it might just be the clue you need (that's the idea). And you wouldn't be the first or the last person that happened to. As for me, I'd gladly show how to do what interests you, only I have no blog, and no time to set one up, fight spam, hack attempts, and so on. I can afford one short answer like this, but I cannot afford months of engineering implementing the infrastructure for a blog and hardening it. And by the way, nice stab at Joyent on your part, but SmartOS is free, open source software, and the entire ecosystem + the 14,000 packages never cost a penny. Even their cloud on a laptop ("COAL") preconfigured image is gratis. As for packaging being hard... there is such an abundance of packaging documentation for any popular operating system... all you have to do is sit down and "warm up the chair" by reading it. Do you think I learned it some other way?
ex_amazon_sde 10y ago
> by just using Kickstart, JumpStart(TM), or SDC, without any additional code. No Chef. No Puppet. No cfxengine. No Salt. No Ansible. No Docker. No KVM. No XEN. No Kubernetes. No Mesos. Thank you for saying this! Building OS packages and OS images and provisioning servers was done automatically 10 to 12 years ago with much less work. It's still the preferred choice for many large tech companies and nobody talks about it because it just works and it's nothing new. Fast deployments, immutable infrastructure, modularity.
- tinco 10y ago
  Much less work than what?
  - Annatar 10y ago
    Much less work than messing with Docker, Mesos, Kubernetes, Chef, Puppet, Rkt, Salt, Ansible, cfengine, etcetera... it's much, much simpler to build OS packages and keep the metadata needed to build them under revision control (git, Mercurial, Bitkeeper, ...) And as a bonus, it is designed to plug into the change management process from the ground up, and not as an afterthought. (Deployment automation and configuration management are not enough for complete lifecycle management.)

by Annatar 10y ago

tinco 10y ago

So what are you bugging shykes for? You have achieved everything Docker offers, and you had fun in the process. Seems like you're smart enough to realize that. Anyway, someday in the future I might look back on this and think "ha! someone put all that effort in even though NixOS already existed".

Annatar 10y ago
So what are you bugging shykes for? All I did was ask a question. Is critical thinking, even just asking questions, undesirable now, unless someone is being praised to high heavens? Is that what we're down to now? "ha! someone put all that effort in even though NixOS already existed" SmartOS virtualization is based on Solaris zones, which existed long before people on GNU/Linux even realized that containers were the way to go. The groundwork, and my own work was laid down long before any of this became hype. Project Kevlar, nee zones was started around the same time as NixOS, and another participant already mentioned that large companies did large scale deployments and configuration management via OS packages, which is both true and correct.
- tinco 10y ago
  You did not just ask a question as a form of critical thinking. You asked a question leading into a lecture on the technology you prefer. Docker is just a simple wrapper that reduces the amount of knowledge needed to run a containerized process. It did not become hype because of any technological advantage, it became hype because this old technology became accessible not just for the kind of people/companies that don't (can't) run enterprise class Solaris deployments, but also the kind that don't have 20 years of experience in making robust well managed deployments. Your process might seem easy and straightforward to you. But for the average developer and Linux enthousiast, there's not much that can the simplicity of the Dockerfile. Systemd or a more specialized system like Kubernetes to run the containers, and a simple script to provision your machine is all you need. You can pick all of this tech up in a few days and steadily grow into more advanced subjects like monitoring, logging, security. Anyway, you're not helping anyone by just saying "SmartOS is better than Docker+(list of redundant and unrelated other tech)", maybe instead show us a one-page tutorial on how to set up a SmartOS system with a webapp stack (i.e. LAMP, MEAN or RoR) that can be executed by a newbie without a creditcard, registration, trial or phone call.
  - Annatar 10y ago
    You did not just ask a question as a form of critical thinking. Yes I did. You asked a question leading into a lecture on the technology you prefer. Only after you left your Good luck with packaging everything, which I have good reason to believe was cynical sarcasm. It did not become hype because of any technological advantage, it became hype because this old technology became accessible not just for the kind of people/companies that don't (can't) run enterprise class Solaris deployments, Performing configuration management at scale with OS packaging has nothing to do with Solaris - it works on any operating system which has a Bourne-family shell, AWK, and sed. but also the kind that don't have 20 years of experience in making robust well managed deployments. Then it would be a good idea for such people to actively seek mentors. But for the average developer and Linux enthousiast, there's not much that can the simplicity of the Dockerfile. That's what distinguishes the average developer. A true enthusiast will go out of their way to become a master of the art, so the assertion doesn't apply to them. It's easy to hack several hundred thousand files together and deliver them via Docker. But, what happens when it's time for upgrades? Go through the entire hackfest again? Every time? Anyway, you're not helping anyone that depends on what your mentality is: if you're a true enthusiast, you're probably reading a lot, and when you stumble upon crumb trails like mine, the light bulb might go off reading what I wrote, and it might just be the clue you need (that's the idea). And you wouldn't be the first or the last person that happened to. As for me, I'd gladly show how to do what interests you, only I have no blog, and no time to set one up, fight spam, hack attempts, and so on. I can afford one short answer like this, but I cannot afford months of engineering implementing the infrastructure for a blog and hardening it. And by the way, nice stab at Joyent on your part, but SmartOS is free, open source software, and the entire ecosystem + the 14,000 packages never cost a penny. Even their cloud on a laptop ("COAL") preconfigured image is gratis. As for packaging being hard... there is such an abundance of packaging documentation for any popular operating system... all you have to do is sit down and "warm up the chair" by reading it. Do you think I learned it some other way?

ex_amazon_sde 10y ago

> by just using Kickstart, JumpStart(TM), or SDC, without any additional code. No Chef. No Puppet. No cfxengine. No Salt. No Ansible. No Docker. No KVM. No XEN. No Kubernetes. No Mesos. Thank you for saying this! Building OS packages and OS images and provisioning servers was done automatically 10 to 12 years ago with much less work. It's still the preferred choice for many large tech companies and nobody talks about it because it just works and it's nothing new. Fast deployments, immutable infrastructure, modularity.

tinco 10y ago
Much less work than what?
- Annatar 10y ago
  Much less work than messing with Docker, Mesos, Kubernetes, Chef, Puppet, Rkt, Salt, Ansible, cfengine, etcetera... it's much, much simpler to build OS packages and keep the metadata needed to build them under revision control (git, Mercurial, Bitkeeper, ...) And as a bonus, it is designed to plug into the change management process from the ground up, and not as an afterthought. (Deployment automation and configuration management are not enough for complete lifecycle management.)