Live data from Hacker News

The sad state of sysadmin in the age of containers (2015)

vitavonni.de

271–280 of 324 posts

Re: The sad state of sysadmin in the age of containers (2015)

#271
post #69

Earlier quoted context omitted.

I know you're taking some flack for making it about age, but I do think there's some merit there. I'm 34. I feel like I'm in the middle in terms of software developer / sysadmin age. Lots of bright minds came before me and there are lots of bright minds out there right now in their early 20s. A key difference is I can remember a time when network connectivity was flaky. When it was hardly a given. Even when it was av…

I'm 36 and recently was assigned to mentor a new employee in his 20s. We had a moment of miscommunication when I asked him to use git to clone a local repository. He was confused when he couldn't find it on github.com (what I'd sent him was a path to our private network share). I had to explain that, yes you can use the github.com client if you want, but "git" is different from "github". I honestly couldn't tell if h…

> I had to explain that, yes you can use the github.com client if you want, but "git" is different from "github".

To be fair, this is largely the result of a concerted effort by GitHub to muddy the difference. If you didn’t know any better, you might think Google is the internet too.

Re: The sad state of sysadmin in the age of containers (2015)

#272
post #69
post #19

I recently had a similar discussion with people using npm for building a CSS framework library. I tried to explain the concept of getting a pre-downloaded tarball and using "make" (or similar) to produce target artifacts from source files in a deterministic, repeatable and reliable manner, without relying on any third-party servers being available and without pulling in dependencies that might have changed. It seems…

I know you're taking some flack for making it about age, but I do think there's some merit there. I'm 34. I feel like I'm in the middle in terms of software developer / sysadmin age. Lots of bright minds came before me and there are lots of bright minds out there right now in their early 20s. A key difference is I can remember a time when network connectivity was flaky. When it was hardly a given. Even when it was av…

> A key difference is I can remember a time when network connectivity was flaky.

I’m young enough for this to not be something I have experienced, but I don’t have to have to understand that depending on things you don’t have control over can be a bad idea.

Re: The sad state of sysadmin in the age of containers (2015)

#273
post #49

Standard Makefiles are really under appreciated today. They are simple and can be used with most any language, version controlled and have been around for decades.

Makefiles are problematic on Windows, though. There's no Make out of the box, there's a bunch of incompatible makes that are subtly different in different ways, and then most Makefiles tend to assume sh and POSIX at some point.

Re: The sad state of sysadmin in the age of containers (2015)

#274
post #69

Earlier quoted context omitted.

I know you're taking some flack for making it about age, but I do think there's some merit there. I'm 34. I feel like I'm in the middle in terms of software developer / sysadmin age. Lots of bright minds came before me and there are lots of bright minds out there right now in their early 20s. A key difference is I can remember a time when network connectivity was flaky. When it was hardly a given. Even when it was av…

I'm 36 and recently was assigned to mentor a new employee in his 20s. We had a moment of miscommunication when I asked him to use git to clone a local repository. He was confused when he couldn't find it on github.com (what I'd sent him was a path to our private network share). I had to explain that, yes you can use the github.com client if you want, but "git" is different from "github". I honestly couldn't tell if h…

That's funny. That same situation (not understanding that git and github are different things) has happened to me a couple of times but with older engineers.

Re: The sad state of sysadmin in the age of containers (2015)

#275
post #87
post #77

You've got to look at this in a context where platform package managers like apt are simultaneously 1) platform-specific 2) jealous, insisting that every language has to conform to their way of doing things and 3) fundamentally not very good, having very limited ability to do things like install packages for a single user or install multiple versions of the same package. Platform package managers like maven have been…

That's quite a negative view of the situation. The debian maintainers definitely don't insist that everything has to do things the apt-way. They only insist that packages for the official repos do so, which seems sensible enough to me. Everyone is still free to build their own deb packages or distribute their applications through install scripts or app images or any one of a hundred thousand different ways to distrib…

Here here. And the only thing that makes Debian an interesting brand is the quality consistency of the official repository.

If someone doesn't like apt & the main repository they shouldn't use Debian because that is pretty much the only big thing separating Debian from the tens to hundreds of other distros out there. Take apt and the main repo out of Debian and it is basically Linux From Scratch with a bigger team of bugtesters. Distributions aren't 'jealous' about packet management, they are the packet management. It is right there in the name "Debian distribution". The Debian brand, and all linux distro brands, are deeply linked to how they execute packet management to distribute software.

Re: The sad state of sysadmin in the age of containers (2015)

#276
post #162

Earlier quoted context omitted.

Without a deterministic build I don't know what I check in actually works across environment, or if the deployment artifact works. Actually that's mostly a given in JS land. Many bright minds worked hard for it to be this level of idiot-proof.

I recently discovered that in node 10.10 (IIRC), you need oracledb I may be a better idiot.

Oh, that.

Weird that it didn't complain during building or installation.

Anyway I had one project where I couldn't use `async` `await`, because apparently this feature requires Babel 7, which in turn requires a version of node fresh enough to support generators.

This tends to happen, but it's rare to discover such an issue only after starting the application.

Re: The sad state of sysadmin in the age of containers (2015)

#277

Earlier quoted context omitted.

Language-specific package managers are also "jealous" as you put it. They insist that every platform conform to their way of doing things. They're also promiscuous, in the sense that most have really poor dependency management ("let's build the internet today just in case") and practically no security. The computing world would be a better place if the people forcing their language-specific idioms on the rest of the…

So, what would 'pip install s3cmd' look on Windows or macOS?

   choco install s3cmd

   brew install s3cmd
https://formulae.brew.sh/formula/s3cmd

Re: The sad state of sysadmin in the age of containers (2015)

#278

So nearly 5 years later, is any of this any better? Also, why haven't Linux vendors standardized on a single package manager that is the default for ALL Linux distros? This seems like the equivalent hell that npm gives to NodeJS.

> why haven't Linux vendors standardized on a single package manager that is the default for ALL Linux distros?

The two distro package managers that "matter" (apt and rpm) are similar enough that this isn't a problem in practice. You can have fpm spit out a deb or rpm or arch pkg with just one flag change, and host it on your own website.

The real differences aren't just mechanical packaging differences, but more a question of philosophies, there are a lot of differences in upstream distro packaging policies themselves. Debian isn't going to let you upload it directly unless it is a good citizen on their distro, stays up-to-date with their versions of all dependencies (so that you only end up with one python, libjpeg etc on your system) and is certifiably free software down to the bones. Whereas Arch will take literally anything in the AUR, and the fast way into CentOS is to be employed by RH (paraphrasing).

(I tried to package a certain app in RPM, but it turns out that OpenSuSE and CentOS have different names for the tzdata package, and until very recently rpm didn't even have a system for specifying alternate dependencies.)

Re: The sad state of sysadmin in the age of containers (2015)

#279
post #177

Earlier quoted context omitted.

Something Java and the Java ecosystem is terrible at. I've had project where we needed all of 7,8,9 and 10 [0] for the data stack: Hadoop, Scala, Spark, HDFS, zookeeper, pyspark. Good luck setting that up on a single machine, containers all the way. The java path nightmares I still have. I'm probably one of the few people in the word who know this much about the JVM without ever having written any Java. [0] We should…

> I've had project where we needed all of 7,8,9 and 10 [0] for the data stack: Hadoop, Scala, Spark, HDFS, zookeeper, pyspark. I suspect that a big reason was due to using Scala, which is notorious for not maintaining binary backward compatibility across minor releases.

To be fair, most languages don't maintain backward binary compatibility.

In fact, this is so common that some package managers don't even bother distributing binaries: go modules, cargo, conan, etc.

Re: The sad state of sysadmin in the age of containers (2015)

#280
post #157

I agree the last decade has been really tough for sysadmins, but the payoff is developers have had a great time and I dont have to rely on those guys any more.

This is a weird mentality that I think comes from being disconnected from ops. It's like you're a mechanical engineer building a truck, and now that you have a 3D Printer that can make any part, you think you don't have to rely on or communicate with the people driving the trucks on the road.

As long as what you're doing isn't too involved, I guess running without ops is completely realistic nowadays. If all you need is a database and a relatively simple monolithic app plus stuff like logging, metrics, and if a little downtime here and there isn't the end of the world, there's lots and lots of managed/cloud offerings that'll cut down ops to a point where it's very much manageable for capable devs. A lot of small shops run like this and do so successfully.
Post reply on HN