4 ms·

> I’m not complaining about old-school sysadmins. They know how to keep systems running, manage update and upgrade paths. Sadly these ways of olde didn't scale

> I’m not complaining about old-school sysadmins. They know how to keep systems running, manage update and upgrade paths. Sadly these ways of olde didn't scale. They could only do it for a handful of servers, change request took months and the systems were not to be 'touched'. > And since nobody is still able to compile things from scratch, everybody just downloads precompiled binaries from random websites. Often without any authentication or signature. Right, that would have never happened back then, when packages were not signed and freshmeat.net was still a thing. For some reason compiling C code from some website (`wget;./configure;make;make install`) seems to be more secure than `go install`, maybe because nobody understands automake anymore.

zeveb 7y ago
> They could only do it for a handful of servers, change request took months and the systems were not to be 'touched'. Those old ways of doing things were indeed slower than they needed to be in many cases, and I'm glad that we sped them up. I don't believe that we needed to throw the baby away with the bathwater though. The problem now is that we build systems which are unmanageable and unmanaged. 'Throw it in a container and let it run' is not scalable either: it scales neither security not maintainability. Instead of scaling, it just punts. Enabling one to do something one shouldn't do (i.e., deploy insecure software into production) is not a virtue.
- CathedralBorrow 7y ago
  > The problem now is that we build systems which are unmanageable and unmanaged Are all the systems out there in production actually unmanageable and unmanaged?
- cuillevel3 7y ago
  After a few decades it's no longer a baby ;) Software is becoming more complex and moving faster than ever. 'Controlling your dependencies' was always an illusion and a trade-off at best. Often a trade-off against security, inheriting the folder of JAR files from your predecessor and such. I think of containers and all these new tools as designs which are supposed to help us manage existing complexity. They don't create it, it's already there in the requirements and real-world deployments. The friction we feel, is that some of those tools are not very good (yet), but maybe better than the previous generation (sometimes). On the negative side, there is a lot of nostalgia ("ah, do you remember bare metal...") and unwillingness to change and learn.
  - wayoutthere 7y ago
    I think a lot of folks who have been through a few tech cycles just see us building the same tools over and over again adding complexity to the overall system. I think the main cause here is, ironically, the fact that businesses keep trying to remove sysadmin (as a discipline) from the IT value chain and replace it with subscription services. Sure, you can do it, but at some point things will break and you need someone who understands what is happening at the lowest levels of abstraction.

zeveb 7y ago

> They could only do it for a handful of servers, change request took months and the systems were not to be 'touched'. Those old ways of doing things were indeed slower than they needed to be in many cases, and I'm glad that we sped them up. I don't believe that we needed to throw the baby away with the bathwater though. The problem now is that we build systems which are unmanageable and unmanaged. 'Throw it in a container and let it run' is not scalable either: it scales neither security not maintainability. Instead of scaling, it just punts. Enabling one to do something one shouldn't do (i.e., deploy insecure software into production) is not a virtue.

CathedralBorrow 7y ago
> The problem now is that we build systems which are unmanageable and unmanaged Are all the systems out there in production actually unmanageable and unmanaged?
cuillevel3 7y ago
After a few decades it's no longer a baby ;) Software is becoming more complex and moving faster than ever. 'Controlling your dependencies' was always an illusion and a trade-off at best. Often a trade-off against security, inheriting the folder of JAR files from your predecessor and such. I think of containers and all these new tools as designs which are supposed to help us manage existing complexity. They don't create it, it's already there in the requirements and real-world deployments. The friction we feel, is that some of those tools are not very good (yet), but maybe better than the previous generation (sometimes). On the negative side, there is a lot of nostalgia ("ah, do you remember bare metal...") and unwillingness to change and learn.
- wayoutthere 7y ago
  I think a lot of folks who have been through a few tech cycles just see us building the same tools over and over again adding complexity to the overall system. I think the main cause here is, ironically, the fact that businesses keep trying to remove sysadmin (as a discipline) from the IT value chain and replace it with subscription services. Sure, you can do it, but at some point things will break and you need someone who understands what is happening at the lowest levels of abstraction.