Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

vitavonni.de

Post reply on HN
Print view View original

291–300 of 435 posts

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

#291

Post by dredmorbius »

zapita wrote: post #276
ex_amazon_sde wrote: post #63

Ex Amazon here. Most grumpy system engineers did not disappear: we got hired by Google/Amazon/etc to build large-scale infrastructure... and sometimes sell it back to you as a service. Believe me or not, most of the underlying infra does not run on the popular technology of the year. Far, far from it. That's why it works. Modern devops, with its million tools that break backward compatibility every month sometimes be…

> Modern devops, with its million tools that break backward compatibility every month sometimes becomes the running joke at lunch. Ironically, modern devops and its million broken tools are a primary source of revenue for cloud providers, helping pay for your lunch in the first place.

Risk arbitrage.

Present capability vs. future catastrophic risk.

Technology is debt.

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

#292

Post by jauer »

rootlocus wrote: post #266
gaius wrote: post #262

Earlier quoted context omitted.

It can reshape itself, and it most definitely understand network protocols It really, really can't! That quote about the Internet interpreting censorship as damage and routing around it? Or the one about information "wanting" to be free? Taken wildly out of context.

Then what about routing protocols such as RIP, OSPF, etc? I'm sorry, but I don't know what quotes you're referring to.

Routing protocols convey state information between routers, but really that is just table stakes.

So, what do network engineers do? Classically, Set up and troubleshoot those systems. Currently, transforming from manual work to building systems to deploy, monitor, and remediate routers and such. In other words, the same stuff sysadmins->(SRE|PE) folks do and undergoing a similar transition.

SRE methods are quite applicable to neteng: https://landing.google.com/sre/book/chapters/eliminating-toi...

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

#293

Post by megaman22 »

w4tson wrote: post #284
mcguire wrote: post #175

Earlier quoted context omitted.

" Wait a second and consider that maybe there is a reason why this incredibly large number of developers are using these tools. That perhaps they evaluated various different options and decided that what they are using is more suitable than make. Maybe you could find out. " Have you considered that perhaps the previous commentor is familiar with the other tools? Or perhaps that the large number of developers have str…

If the previous commenter was familiar was familiar with 47 build tools and has discounted a lot of them as extraneous. Is he advocating building an npm module with make? What about a jar? Nuget package? Cargo module? Its seems more likely that they’re frustrated about the sheer amount to learn and they probably know make quite well. But there are real advantages to these tools. There’s a lot of vanity libraries out…

My real issue is the constant wheel-making impulse, that leaves us with a shattered landscape of people tripping and falling over busted-ass and abandoned wheels. I have a JavaScript front-end project that uses three different package managers, and four different make-analog tools, plus some batch files sprinkled on top to orchestrate the common use cases of this monstrosity. Nothing that we are doing here is that complicated, except for this sea of shitty half-baked ecosystems around these tools, each of which was considered best-of-breed at one point.

What we want to do is slurp some text files up, apply some transformations to them, glob them together, run them through the minifier, and dump them into a final output. This is exactly what a decent makefile would fit well for. Instead, I got this, because apparently nobody wants to use anything that isn't the hot new way to do things, and so very few people have even had enough exposure to know that there are tested tools for these kinds of things that existed. The last time I was using make beyond trivial uses was a decade ago in college (incidentally, I actually did build jars with make, easier than fighting Eclipse...). But just knowing that something exists is more than half the battle, although the problem then is that it's frustrating as all hell watching the same ideas cycle round and round and round every couple years.

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

#294

Post by pvg »

cookiecaper wrote: post #251
pvg wrote: post #143

Earlier quoted context omitted.

The thing is that any separation in the roles in ineffective. [...] The right axis for separation is hardware v. software. Any separation is ineffective except along this one particular completely arbitrary dividing line? If that were true we'd still be hunting and gathering and nothing else.

> Any separation is ineffective except along this one particular completely arbitrary dividing line? If that were true we'd still be hunting and gathering and nothing else. Hardly arbitrary -- hardware is fixed at the time of manufacture. Hardware engineers should be well-acquainted with software concerns and needs, but the years-long feedback cycle and real expenses associated with hardware development creates a nat…

It's arbitrary when you claim there are no sensible divisions in software. I think your entire lengthy argument is a sort of elaborate fantasy about how much better the world would be if everyone was just like you or at least, just like you imagine yourself to be. It's fun but not a particularly realistic or constructive way to look at the world.

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

#295

Post by 15155 »

drbawb wrote: post #138
agentultra wrote: post #78

Earlier quoted context omitted.

I recall the idea of "devops" from this book: https://landing.google.com/sre/book.html The stated goal of putting both systems administrators and software engineers on the same team is to reduce friction and increase communication. One of the worst, productivity-killing situations you can find yourself in when developing network software and services is caused by the traditional "old school" mentality of separating t…

>Don't build your containers from public, un-trusted images! The author is complaining that you can't build these private trusted images. Software developers have got it in their head that containers are a way to package & distribute software. They're not, that's what the OS's package managers are for. If your software requires Docker as a build dependency, you have failed to properly package your software. As a conc…

Ubiquiti has always done this, even before containers were "hot."

If you install their rpms or debs for any of their properties, you're almost always getting a copy of Mongo or some other dependent service... and it is probably going to be incompatible with whatever version your package manager has or you're already running (version-constraints-wise, not actual compatibility-wise).

This is an indictment of Ubiquiti, not containers in general. If their software were properly built, they'd be shipping you a docker compose setup or something with N different containers that you could substitute out (at a network level) for your own.

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

#296

Post by 15155 »

WiseWeasel wrote: post #258
drbawb wrote: post #138

Earlier quoted context omitted.

>Don't build your containers from public, un-trusted images! The author is complaining that you can't build these private trusted images. Software developers have got it in their head that containers are a way to package & distribute software. They're not, that's what the OS's package managers are for. If your software requires Docker as a build dependency, you have failed to properly package your software. As a conc…

There are public trusted images, like the so-called official repositories on Docker Hub [1]. As long as you build your images based on official repo images, you're probably fine. Just don't depend on untrusted images; instead get their dockerfile/config files, and build the images yourself. To me, a Docker image seems like an ideal way to distribute some proprietary device management web software like Ubiquity UNMS,…

It is the ideal way to distribute this kind of software. They just bundled way too much into one container.

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

#297

Post by cesarb »

dullgiulio wrote: post #144
badloginagain wrote: post #99

Earlier quoted context omitted.

The point everyone seems to be missing, and the one I think most important, is that we're no longer building from trusted sources. Build systems just download and run random code from the internet without verifying that its the correct code, from the correct source. Its a ticking time bomb.

There is SSL/TLS, unless it's done wrong (invalid certificates get ignored by the dependencies manager), it's safer than the old "md5 of the file" systems. Now, some dependencies are fraudolent (especially true in the Javascript world because it eventually targets a lot of user browsers), but nobody ever checked the sources anyway...

TLS only verifies that have connected to the correct server. It can't verify whether the package on the server has been replaced by a malicious one. For that, you need a "md5 of the file" (these days, a sha256, because md5 has long been broken).

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

#298

Post by icedchai »

mcguire wrote: post #135
icebraining wrote: post #71

Earlier quoted context omitted.

I think that is the author's logic. Except it's not very logic, since Hadoop (or Bigtop) doesn't use either.

Picture this: you need to use Hadoop. Do you: A) work through building it yourself, or B) get a container that claims to have a running Hadoop and hope it works for you? If B wasn't on the table, what would happen?

Hadoop isn't even that difficult to set up. I've built it from source, and installed it from binaries.

Containers are totally unnecessary here, just as they are for most java apps.

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

#299

Post by w4tson »

megaman22 wrote: post #293
w4tson wrote: post #284

Earlier quoted context omitted.

If the previous commenter was familiar was familiar with 47 build tools and has discounted a lot of them as extraneous. Is he advocating building an npm module with make? What about a jar? Nuget package? Cargo module? Its seems more likely that they’re frustrated about the sheer amount to learn and they probably know make quite well. But there are real advantages to these tools. There’s a lot of vanity libraries out…

My real issue is the constant wheel-making impulse, that leaves us with a shattered landscape of people tripping and falling over busted-ass and abandoned wheels. I have a JavaScript front-end project that uses three different package managers, and four different make-analog tools, plus some batch files sprinkled on top to orchestrate the common use cases of this monstrosity. Nothing that we are doing here is that co…

I’ve wasted enough time tinkering with gulp, grunt and webpack to sympathize

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

#300

Post by batoure »

I don't disagree with the OP here per say.

However I do think OP made a mistake by using Hadoop as the example. Hadoop has much more in common with an OS at this point than a single application. The ability to download a single component of the eco system is mainly to support small scale testing and development.

You wouldn't build Debian by going and getting each piece of the linux kernel from its source building those building all the pieces of the middle ware up and so forth... that is the whole point of having Debian in the first place.

Do certain complex software eco systems need better support for fingerprinting their builds, Yes. Does all this mean the sky is falling... probably not.

Post reply on HN