4 ms·

Wise man once said the only thing new is the history you don't already know. The process is a perfectly good unit of distribution, does not require orchestratio

Wise man once said the only thing new is the history you don't already know. The process is a perfectly good unit of distribution, does not require orchestration, integrates nicely with PID1, leverages OS services for getting work done, can talk over the network, start other processes, etc. The reason containers have taken a foothold is not because the process is not a good unit of abstraction and distribution. The reason is dependencies have gotten out of hand. Ask anyone that deploys fat jars to run on the JVM. They've been leveraging containers for ages now. Ask the golang folks how they like deploying single binaries. The OS is not going away. Better process isolation is the future so I'm gonna say the author has a slightly too futuristic view of things. The current container ecosystem and the churn around it is a half-measure for better process management.

xenadu02 10y ago
The history of virtualization has shown us that it is far easier to containerize existing software than rewrite it to support strict isolation. Most OSes (sans macOS) aren't really setup for sandbox-by-default either. The mainframe industry already went through this years ago. They invented virtualization and leveraged it to transition through major new CPU architectures, complete re-designs of IO stacks, and switching out entire operating systems. None of these are new arguments. Virtualization won then and it will win again. You could say the entire history of the industry is increasing levels of abstraction; containers and virtualization are just another step along that path.
pjmlp 10y ago
The day I moved from C++ back to Java and other languages with richer runtimes at work, was when I stopped caring about the underlying OS. A JEE container, is already a full OS adding the remaining services that a plain JSE installation might still lack, it doesn't need yet another layer to waste resources and add more administration work in maintenance and security.
- sqeaky 10y ago
  I write in C++ and I do not care about the underlying 98% of the time anyway. That 2% of the time I might write something that needs a kernel call, but I will make a class or some other abstraction that represents it and put all my different implementations in there. For code that cares about word size or something similarly pervasive but platform dependent there are templates and constepxr to have the compiler evaluate things. I won't be putting constants like 32 or 64 in my I will do things like "align_to(system_details::cache_line_size)" and let my compiler handle the details.
  - pjmlp 10y ago
    Which is kind of true if you can stick with the standard library and control which compiler gets used. Back in those days, we were deploying code across heterogeneous OSes (not all POSIX), using the OS vendor provided compilers, which were still catching up with C++98, let alone C++03. So this really restricts how much you can make use of the standard library and which third party libraries to use in a portable way. Then is time for #ifdef party.
    - sqeaky 10y ago
      I covered exactly this. I write code for windows/Linux/Mac OS X. Write a class to contain those ifdef. I did this before C++11 as well. This isn't a new technique, but for some reason people adopting C++11 and C++14 seem more willing to do it than people who wish C++ was really just C with classes. Also, write unit tests to test the class. Run the Tests in CI on every platform and a variety of configs. It is not hard and there great free or cheap tools Like Jenkins, TravisCI and Appveyor.
      - pjmlp 10y ago
        > This isn't a new technique, but for some reason people adopting C++11 and C++14 seem more willing to do it than people who wish C++ was really just C with classes. This was exactly part of the problem. Most of the enterprise code I used to deal with was not even that, rather compiling C with C++ compiler. However my point with rich runtimes was that you shouldn't bother to even do that, the runtime is the OS, kind of.

xenadu02 10y ago

The history of virtualization has shown us that it is far easier to containerize existing software than rewrite it to support strict isolation. Most OSes (sans macOS) aren't really setup for sandbox-by-default either. The mainframe industry already went through this years ago. They invented virtualization and leveraged it to transition through major new CPU architectures, complete re-designs of IO stacks, and switching out entire operating systems. None of these are new arguments. Virtualization won then and it will win again. You could say the entire history of the industry is increasing levels of abstraction; containers and virtualization are just another step along that path.

pjmlp 10y ago

The day I moved from C++ back to Java and other languages with richer runtimes at work, was when I stopped caring about the underlying OS. A JEE container, is already a full OS adding the remaining services that a plain JSE installation might still lack, it doesn't need yet another layer to waste resources and add more administration work in maintenance and security.

sqeaky 10y ago
I write in C++ and I do not care about the underlying 98% of the time anyway. That 2% of the time I might write something that needs a kernel call, but I will make a class or some other abstraction that represents it and put all my different implementations in there. For code that cares about word size or something similarly pervasive but platform dependent there are templates and constepxr to have the compiler evaluate things. I won't be putting constants like 32 or 64 in my I will do things like "align_to(system_details::cache_line_size)" and let my compiler handle the details.
- pjmlp 10y ago
  Which is kind of true if you can stick with the standard library and control which compiler gets used. Back in those days, we were deploying code across heterogeneous OSes (not all POSIX), using the OS vendor provided compilers, which were still catching up with C++98, let alone C++03. So this really restricts how much you can make use of the standard library and which third party libraries to use in a portable way. Then is time for #ifdef party.
  - sqeaky 10y ago
    I covered exactly this. I write code for windows/Linux/Mac OS X. Write a class to contain those ifdef. I did this before C++11 as well. This isn't a new technique, but for some reason people adopting C++11 and C++14 seem more willing to do it than people who wish C++ was really just C with classes. Also, write unit tests to test the class. Run the Tests in CI on every platform and a variety of configs. It is not hard and there great free or cheap tools Like Jenkins, TravisCI and Appveyor.
    - pjmlp 10y ago
      > This isn't a new technique, but for some reason people adopting C++11 and C++14 seem more willing to do it than people who wish C++ was really just C with classes. This was exactly part of the problem. Most of the enterprise code I used to deal with was not even that, rather compiling C with C++ compiler. However my point with rich runtimes was that you shouldn't bother to even do that, the runtime is the OS, kind of.