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

311–320 of 324 posts

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

#311

Post by celticmusic »

maple3142 wrote: post #298
celticmusic wrote: post #293

Earlier quoted context omitted.

I can't speak to the others, but if you've installed rubygems on Windows, you've installed mingW, and you have access to those tools. This is because rubygems will not build source gems against microsofts toolchain, but against the gcc toolchain ala mingW. If you prefer using Powershell on Windows, great (or bat if you're a masochist). The point was that being in Ruby doesn't automatically invalidate the use of make…

Yeah, maybe it is true for Ruby development on Windows, but not for others, says Node.js. Developing Node.js on Windows is (comparatively) easy to do so, usually you only need to install `node` and `npm`, then optionally install `yarn` and `windows-build-tools`. None of these steps will give you GNU toolchain, so it won't available until you install it. That is ehy I prefer OS-agnostic tools such as npm or npm+gulp f…

make IS an OS-agnostic tool, it's just not available by default on Windows. But it can absolutely be installed. Or you can bring the mingW/ binaries along with you. Even something as simple as installing git for windows will give you access to a decentish unix environment.

staying inside rake, et al is fine if your software is simple enough to get away with it (by simple I mean self-contained without too many moving parts). But quite often you can't get away with that, and make becomes a good choice.

I would also argue that if you're developing ruby on windows you're doing it wrong. You can do it, but I would personally never target Windows for a ruby app. been there, done that, have the scars to prove it.

I would also add that installing all of that for node doesn't really seem to be simpler than using make, but that's just my old timer sensibilities coming into play.

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

#312

Post by majkinetor »

celticmusic wrote: post #293
maple3142 wrote: post #225

Earlier quoted context omitted.

Wouldn't it just be like a build.sh? And makefile is not cross platform enough, especially on Windows.

I can't speak to the others, but if you've installed rubygems on Windows, you've installed mingW, and you have access to those tools. This is because rubygems will not build source gems against microsofts toolchain, but against the gcc toolchain ala mingW. If you prefer using Powershell on Windows, great (or bat if you're a masochist). The point was that being in Ruby doesn't automatically invalidate the use of make…

Here is how to use tools on Windows via my chocolatey packages without WSL, mingW etc.

    cinst ruby                        # install ruby
    cinst msys2 --params "/NoUpdate"  # install msys2 without 
    system update
    Update-SessionEnvironment         # refresh environment vars
    ridk install 2 3
See notes on https://chocolatey.org/packages/msys2

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

#313

Post by peterwwillis »

dividedbyzero wrote: post #280
peterwwillis wrote: post #230

Earlier quoted context omitted.

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 o…

If a little downtime here and there doesn't matter, then either customers don't care about the product, or the company doesn't care about the customer. Ops's job is to keep customers happy by keeping the applications from going down; it's not like they think a dev can't set up a service in AWS themselves. But you're right, you don't need a dedicated ops person if a dev has the time and knowledge to maintain a service reliably.

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

#314

Post by marmaduke »

lmm wrote: post #89
marmaduke wrote: post #86

Earlier quoted context omitted.

No I don't. I use Debian derivatives because I can apt get all my stuff without thinking hard, because those package maintainers have done the hard work.

Well, clearly not, since you can't install Hadoop. Before you blame that on Hadoop, remember that it only requires some really quite basic things from its package manager, which apt is nevertheless completely unable to do: use libraries in the normal recommended way, play nice with Java, work cross-platform.

I don't need Hadoop because I have find, xargs, GNU parallel, Slurm etc etc

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

#315

Post by winrid »

eckza wrote: post #194
winrid wrote: post #193

Earlier quoted context omitted.

Easiest thing to do to solve this would be to have something like artifactory or even squid in front of npm and use exact version numbers. Front end devs are going to use NPM. Solve the other problems separately like you would with any other build system.

Sure. And then when something unexpected happens, you have two problems.

You mean clearing a cache? I don't understand. Using a proxy to protect yourself from missing dependencies/down servers is a bad thing now?

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

#316

Post by rumanator »

lmm wrote: post #286
rumanator wrote: post #121

Earlier quoted context omitted.

> jealous, insisting that every language has to conform to their way of doing things Let's ignore for a moment all your baseless assertions and focus on the following question: how do you ensure that a build is reproducible if you have no control on which required dependencies are downloaded by a build system which requires root access? Is jealousy the only explanation that comes up to you?

Reproducible builds were a non-goal for apt for most of its existence.

> Reproducible builds were a non-goal for apt for most of its existence.

Your comment sounds very disingenuous, as Debian was first released in 1993 (about 26 years ago) and has been pushing for reproducible builds since 2000.

https://wiki.debian.org/ReproducibleBuilds/History

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

#317

Post by int_19h »

rumanator wrote: post #260
int_19h wrote: post #258

Earlier quoted context omitted.

For Linux distros, the primary responsibility for packaging is actually with the distro maintainers, since packaging is distro-specific. That said, a well-written app should not present any difficulty for the package maintainer.

> For Linux distros, the primary responsibility for packaging is actually with the distro maintainers, since packaging is distro-specific. No it is not. Although distros might pick and adopt some packages and include them in their official repository, it's obvious to anyone that as a distro maintainer you are not responsible for packaging each and every software package under the sun. Moreso, linux distros such as De…

How many packages in the Debian repos are packaged by their authors, rather than maintainers that are affiliated with the Debian project?

(I'm including volunteer maintainers in the latter category, unless they submit the package to the original author rather than directly to Debian.)

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

#318

Post by lmm »

soraminazuki wrote: post #294
lmm wrote: post #286

Earlier quoted context omitted.

Reproducible builds were a non-goal for apt for most of its existence.

That doesn't dismiss its immense benefits. Besides, what's the source of your claim? Package quality, ease of install, and security were always high-priority topics for Debian AFAICT.

Decades of experience using Debian. Package quality and ease of install were indeed always a priority (and security may have been claimed as one), but reproducible builds were not seen as necessary for any of those.

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

#319

Post by lmm »

rumanator wrote: post #316
lmm wrote: post #286

Earlier quoted context omitted.

Reproducible builds were a non-goal for apt for most of its existence.

> Reproducible builds were a non-goal for apt for most of its existence. Your comment sounds very disingenuous, as Debian was first released in 1993 (about 26 years ago) and has been pushing for reproducible builds since 2000. https://wiki.debian.org/ReproducibleBuilds/History

Your own comment is extremely disingenuous. Your own link states that there was very little enthusiasm for reproducible builds when mentioned in 2000 and 2007, and the first serious effort towards reproducible builds started in 2013.

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

#320

Post by lmm »

rumanator wrote: post #306
lmm wrote: post #289

Earlier quoted context omitted.

An OS is a tool for running applications, not vice versa. Packaging an application should indeed be the responsibility of people working on that application, which is why language package managers like maven are successful. Debian explicitly rejected this philosophy in favour of one where OS maintainers are responsible for packaging all applications (thus the OS-specific packaging format and closed-world assumption o…

> Debian explicitly rejected this philosophy in favour of one where OS maintainers are responsible for packaging all applications That assertion is quite wrong. Just because the OS has its official package repository, and just because OS maintainers volunteer their time to package some software projects, obviously that does not mean that maintainers are responsible for anything. You are confusing offering a convenien…

> packages are proposed and adopted by volunteers, thus what you've described as "OS maintainers" is pretty much any random person who simply wants a software to be available for download in the distro's official repositories

The entirety of the Debian project are volunteers, random people who simply wanted xyz. And Debian's raison d'etre is as a "distribution" of existing software.

More to the point, Debian packagers explicitly overrule "upstream" application developers; see the history of cdrecord or the ssh key generation bug for particularly spectacular examples. How can you say it's the responsibility of those working on the software project when they don't get to make the final decisions?

> packaging systems such as Debian's apt supports private package repositories, where anyone can make available their packages to the world.

Not really, because apt's approach to dependencies requires a central naming authority. In practice any private repository is necessarily a dead end: you can package additional software that depends on software from the central system, but not vice versa.

Post reply on HN