5 ms·

This kind of thing happens when the base system is ubiquitous and therefore hard to change. It's easier to layer something on top of the base, where people can

This kind of thing happens when the base system is ubiquitous and therefore hard to change. It's easier to layer something on top of the base, where people can "opt in" and there's a large preexisting compatible audience. Changing the base layer itself at a minimum requires people to upgrade, and now you don't have that advantage of the preexisting audience anymore. If your improvement requires a breaking change, then you're in a real pickle. So people will stack on more and more until it becomes more or less unbearable.

user5994461 10y ago
There is an advantage in layering components, or building new software on top of existing components. However, a minor improvement or bugfix should be done in the component that is responsible for it. Creating another layer instead of fixing the problem is just creating more problems.
- numbsafari 10y ago
  You can go whole hog with "containers" by just adopting unikernels. But, unless you are willing to abandon Linux/Unix, this is kinda where you are left.
  - hueving 10y ago
    How would that work when containers make kernel calls?
    - sp332 10y ago
      Where containers would make kernel calls, unikernels make calls to the VM hypervisor. (Not exactly, but kinda.)
omgam 10y ago
A useful analogy for understanding meatspace ecosystems. Software is a bit like pond scum.
duncan_bayne 10y ago
Which is why highly flexible, powerful base systems are usually preferable to less flexible base systems optimised towards specific goals. Common Lisp is my go to example of this. It's possible to extend the language to support entirely new paradigms without breaking it, because of the power of the macro system.
slackingoff2017 10y ago
The reason a new layer is being built is because people don't want vendor lock in and VM's aren't portable anymore. You can't take an AWS VM and fire it up on DigitalOcean without trial by fire. VM's should be portable but they're not because cloud providers don't want them to be. For a while everyone was locked into AWS but now that there's other options some companies want to hedge their bets, or even run parts of their workload locally. Since the VM space is all proprietary now people are moving one level up and building a consistent environment above it. I fully expect docker to become proprietary in a couple years and the cycle will begin again.
- rsync 10y ago
  "You can't take an AWS VM and fire it up on DigitalOcean without trial by fire. VM's should be portable but they're not because cloud providers don't want them to be." You can't ? I have never used DO, but I have deployed linux and FreeBSD systems on EC2 and moving them to bare metal was just a tar command away ... you can even pipeline 'dd' over ssh if you want to be fancy ...
  - fapjacks 9y ago
    You could say that it's as easy as using 'rsync'...
  - slackingoff2017 10y ago
    My friend pointed out today that he can't see my comments on HN. I think we're both hellbanned, just letting you know.

user5994461 10y ago

There is an advantage in layering components, or building new software on top of existing components. However, a minor improvement or bugfix should be done in the component that is responsible for it. Creating another layer instead of fixing the problem is just creating more problems.

numbsafari 10y ago
You can go whole hog with "containers" by just adopting unikernels. But, unless you are willing to abandon Linux/Unix, this is kinda where you are left.
- hueving 10y ago
  How would that work when containers make kernel calls?
  - sp332 10y ago
    Where containers would make kernel calls, unikernels make calls to the VM hypervisor. (Not exactly, but kinda.)

omgam 10y ago

A useful analogy for understanding meatspace ecosystems. Software is a bit like pond scum.

duncan_bayne 10y ago

Which is why highly flexible, powerful base systems are usually preferable to less flexible base systems optimised towards specific goals. Common Lisp is my go to example of this. It's possible to extend the language to support entirely new paradigms without breaking it, because of the power of the macro system.

slackingoff2017 10y ago

The reason a new layer is being built is because people don't want vendor lock in and VM's aren't portable anymore. You can't take an AWS VM and fire it up on DigitalOcean without trial by fire. VM's should be portable but they're not because cloud providers don't want them to be. For a while everyone was locked into AWS but now that there's other options some companies want to hedge their bets, or even run parts of their workload locally. Since the VM space is all proprietary now people are moving one level up and building a consistent environment above it. I fully expect docker to become proprietary in a couple years and the cycle will begin again.

rsync 10y ago
"You can't take an AWS VM and fire it up on DigitalOcean without trial by fire. VM's should be portable but they're not because cloud providers don't want them to be." You can't ? I have never used DO, but I have deployed linux and FreeBSD systems on EC2 and moving them to bare metal was just a tar command away ... you can even pipeline 'dd' over ssh if you want to be fancy ...
- fapjacks 9y ago
  You could say that it's as easy as using 'rsync'...
- slackingoff2017 10y ago
  My friend pointed out today that he can't see my comments on HN. I think we're both hellbanned, just letting you know.