5 ms·

Things are becoming more like the unix philosophy, modular and shared. Even though feature creep is increasing on modular systems, as long as the core component

Things are becoming more like the unix philosophy, modular and shared. Even though feature creep is increasing on modular systems, as long as the core components are simple to understand and introduced first, extra features do not necessarily decrease utility. For example tmux, if you look at a cheat sheet you might be overwhelmed, but when I teach people to use it they find it extremely simple. I just tell them ctrl-c to create a new window, and ctrl-w to switch windows. They only need 2 commands to get value, even though there are hundreds of features, and later they can incrementally learn about them. This is the same way I learned programming, the people learn emacs and vim. You start with the MVP feature set that will make it functional and you learn about features from there. Even AWS, Google Cloud, Azure, even though they're mega services of now insane size and feature breadth, they're creating single services that are easy to understand and compose together. You don't need to understand a lot to copy files in and out of AWS s3 for example, and you can compose many services together even after a basic understanding. You can slowly learn about more features as you work. In the future, things like apache arrow will also help as you can retain services as modular but potentially share memory when composing services. This idea of service composition is also common in Haskell and other functional languages, where if it's possible to do lazy evaluation you can avoid redundant work. Now that the unix philosophy is being more widely adopted, although renamed to microservice fundamentals, these ideas of lazy evaluation and protected data sharing probably be the next level of services research.

gerbilly 7y ago
> Things are becoming more like the unix philosophy, modular and shared. I sure hope you are right. Just look at kubernetes which wraps UNIX in a big complicated opaque 'opinionated' wet blanket.
- weberc2 7y ago
  Kubernetes is the operating system in this analogy, and it’s quite a modular operating system at that. Specifically, it schedules the programs that themselves should adhere to the Unix philosophy. I don’t think the Unix philosophy ever extended to the OS (although microkernels seem to be driving in that direction).
  - gerbilly 7y ago
    If you say so. To me kubernetes wishes it was an operating sytem. It just puts an opaque YML fronted on a bunch of stuff I already know how to install configure and troubleshoot myself: firewalls proxies, web servers etc... It dawned on me that people probably use it because they haven't done much sysadmin, but they want to deploy production systems. As a sysadmin/programmer of 20+ years (what full stack used to mean I guess) it just mystifies me why someone would want to layer a barely documented front end on top of their infrastructure. To me k8 feels kind of like a monster hybridization of cpanel & webshpere.
    - weberc2 7y ago
      Yeah, veteran sysadmins probably aren't its target audience. Orgs probably want to be able to enable their dev teams to deploy/operate production infrastructure without hiring a legion of sysadmins with decades of experience. Kubernetes, like all technology, is meant to lower the bar.
  - 0xFACEFEED 7y ago
    > Specifically, it schedules the programs that themselves should adhere to the Unix philosophy Containers are not programs. And even they were, they absolutely do not adhere to the Unix philosophy. > Kubernetes is the operating system in this analogy I've heard this enough times and seen enough K8s systems in production that I'm labeling this "fluff". K8s is an operating system in the same way that "everything is everything". K8s is software that manages containers and their resources. I think of it more like a virtual environment than an operating system. From Wikipedia: > An operating system (OS) is system software that manages computer hardware, software resources, and provides common services for computer programs. You can generalize "software resources" as container resource limits. You can generalize "common services" as the network and filesystem layers. And you can generalize "computer hardware" as kernel configuration on the control plane. All of these are purpose built abstractions built on top of the real operating systems. By that logic you could call any virtual environment or virtual machine an operating system. And if that's the true then the comparison isn't useful at all.
0xFACEFEED 7y ago
Might you be looking at this through rose tinted glasses? I'm still a VIM user to this day, but my learning experience was hardly a clean incremental process. VIM has no MVP if you're using it to program computers. Early on, I spent hours getting sucked into making the editor do what I wanted. I only stuck with it because I believed the investment of time was worth it (and it was). > You don't need to understand a lot to copy files in and out of AWS s3 for example, and you can compose many services together even after a basic understanding. You can slowly learn about more features as you work. This is dangerous though. You might unknowingly become a victim of vendor lock-in. Or you might have to throw out all of your work because you didn't understand the constraints of the system. Subjectively, my evidence is how I (an experienced person) evaluates software and tools today. Step 1 is learning the architecture, Step 2 is finding the limits/constraints, etc (there's more but you get the idea). When I was evaluating Git I spent a couple hours researching the internals. This sold me on Git but it also made Git much easier to use down the road. It's not a very big time investment most of the time. This kind of evaluation has been so important when evaluating complex stuff like databases and SaaS products. > Now that the unix philosophy is being more widely adopted, although renamed to microservice fundamentals, these ideas of lazy evaluation and protected data sharing probably be the next level of services research. Microservices have been a disaster. The majority of implementations I've seen are brittle/buggy/convoluted messes. Complexity that was previously managed in code has been pushed to infrastructure -- and no one knows how to do infrastructure! Most people that I talk to don't really understand what made the Unix philosophy work. Everyone cites "programs that do one thing and do it well". That's certainly the fun part, but it isn't what makes Unix programs so great. It's how programs do I/O (text and pipes). In other words, it's not enough to build tiny modular single-use programs. You need an equally elegant system the combines the programs together. The programs need to strictly adhere to this system otherwise everything breaks down. Containers are not it. K8s is not it.
- disqard 7y ago
  This is an important point, and I'll (re)state it: the pieces have to be modular, AND the "glue" has to afford that modularity.
- dragonwriter 7y ago
papln 7y ago
Quite the opposite. Modern security models (which are to an extent necessary on the hostile Internet) are reserving modular sharing to the elite professional developer class, and preventing users and aftermarket developers from remixing their systems. Things like Greasemonkey are being smothered and blocked by walled-garden native apps, signatures, and browser lockdowns.

gerbilly 7y ago

> Things are becoming more like the unix philosophy, modular and shared. I sure hope you are right. Just look at kubernetes which wraps UNIX in a big complicated opaque 'opinionated' wet blanket.

weberc2 7y ago
Kubernetes is the operating system in this analogy, and it’s quite a modular operating system at that. Specifically, it schedules the programs that themselves should adhere to the Unix philosophy. I don’t think the Unix philosophy ever extended to the OS (although microkernels seem to be driving in that direction).
- gerbilly 7y ago
  If you say so. To me kubernetes wishes it was an operating sytem. It just puts an opaque YML fronted on a bunch of stuff I already know how to install configure and troubleshoot myself: firewalls proxies, web servers etc... It dawned on me that people probably use it because they haven't done much sysadmin, but they want to deploy production systems. As a sysadmin/programmer of 20+ years (what full stack used to mean I guess) it just mystifies me why someone would want to layer a barely documented front end on top of their infrastructure. To me k8 feels kind of like a monster hybridization of cpanel & webshpere.
  - weberc2 7y ago
    Yeah, veteran sysadmins probably aren't its target audience. Orgs probably want to be able to enable their dev teams to deploy/operate production infrastructure without hiring a legion of sysadmins with decades of experience. Kubernetes, like all technology, is meant to lower the bar.
- 0xFACEFEED 7y ago
  > Specifically, it schedules the programs that themselves should adhere to the Unix philosophy Containers are not programs. And even they were, they absolutely do not adhere to the Unix philosophy. > Kubernetes is the operating system in this analogy I've heard this enough times and seen enough K8s systems in production that I'm labeling this "fluff". K8s is an operating system in the same way that "everything is everything". K8s is software that manages containers and their resources. I think of it more like a virtual environment than an operating system. From Wikipedia: > An operating system (OS) is system software that manages computer hardware, software resources, and provides common services for computer programs. You can generalize "software resources" as container resource limits. You can generalize "common services" as the network and filesystem layers. And you can generalize "computer hardware" as kernel configuration on the control plane. All of these are purpose built abstractions built on top of the real operating systems. By that logic you could call any virtual environment or virtual machine an operating system. And if that's the true then the comparison isn't useful at all.

0xFACEFEED 7y ago

Might you be looking at this through rose tinted glasses? I'm still a VIM user to this day, but my learning experience was hardly a clean incremental process. VIM has no MVP if you're using it to program computers. Early on, I spent hours getting sucked into making the editor do what I wanted. I only stuck with it because I believed the investment of time was worth it (and it was). > You don't need to understand a lot to copy files in and out of AWS s3 for example, and you can compose many services together even after a basic understanding. You can slowly learn about more features as you work. This is dangerous though. You might unknowingly become a victim of vendor lock-in. Or you might have to throw out all of your work because you didn't understand the constraints of the system. Subjectively, my evidence is how I (an experienced person) evaluates software and tools today. Step 1 is learning the architecture, Step 2 is finding the limits/constraints, etc (there's more but you get the idea). When I was evaluating Git I spent a couple hours researching the internals. This sold me on Git but it also made Git much easier to use down the road. It's not a very big time investment most of the time. This kind of evaluation has been so important when evaluating complex stuff like databases and SaaS products. > Now that the unix philosophy is being more widely adopted, although renamed to microservice fundamentals, these ideas of lazy evaluation and protected data sharing probably be the next level of services research. Microservices have been a disaster. The majority of implementations I've seen are brittle/buggy/convoluted messes. Complexity that was previously managed in code has been pushed to infrastructure -- and no one knows how to do infrastructure! Most people that I talk to don't really understand what made the Unix philosophy work. Everyone cites "programs that do one thing and do it well". That's certainly the fun part, but it isn't what makes Unix programs so great. It's how programs do I/O (text and pipes). In other words, it's not enough to build tiny modular single-use programs. You need an equally elegant system the combines the programs together. The programs need to strictly adhere to this system otherwise everything breaks down. Containers are not it. K8s is not it.

disqard 7y ago
This is an important point, and I'll (re)state it: the pieces have to be modular, AND the "glue" has to afford that modularity.
dragonwriter 7y ago

papln 7y ago

Quite the opposite. Modern security models (which are to an extent necessary on the hostile Internet) are reserving modular sharing to the elite professional developer class, and preventing users and aftermarket developers from remixing their systems. Things like Greasemonkey are being smothered and blocked by walled-garden native apps, signatures, and browser lockdowns.