Live data from Hacker News

Software Developers Should Have Sysadmin Experience

blog.professorbeekums.com

391–400 of 424 posts

Re: Software Developers Should Have Sysadmin Experience

#391
post #388

Earlier quoted context omitted.

> I said it elsewhere, but personally I'm a Debian stable evangelist. There is one major upgrade every 2 years or so. It often goes without friction. The rest is mostly security updates. Breakage between major upgrades is very rare. That's fine for an OS, but what do you think business customers would say if you said "sorry, that feature won't be added until the next release in 2 years time"?. That's were tools like…

So what exactly are the latest-and-greatest libraries that you absolutely need to implement your own business critical features? Please list more than only one. It's simple to make exceptions for exceptional requirements.

Well for me, all of the libraries I use because none of them exist as packages for any OS.

With most of them security fixes will only go into the latest version though, so once you get behind your system is insecure.

Applications aren't something you build and forget. An unmaintained project is a dead one.

Re: Software Developers Should Have Sysadmin Experience

#392
post #391

Earlier quoted context omitted.

So what exactly are the latest-and-greatest libraries that you absolutely need to implement your own business critical features? Please list more than only one. It's simple to make exceptions for exceptional requirements.

Well for me, all of the libraries I use because none of them exist as packages for any OS. With most of them security fixes will only go into the latest version though, so once you get behind your system is insecure. Applications aren't something you build and forget. An unmaintained project is a dead one.

> Well for me, all of the libraries I use because none of them exist as packages for any OS.

In conclusion you don't use any libraries that are packaged for any OS.

What libraries?

Also assuming that some libraries you use don't exist for your OS, that doesn't mean that you absolutely need the latest and greatest in a business critical way. So, not approved.

All in all, not too fond of the reasoning and the evidence you provide.

Re: Software Developers Should Have Sysadmin Experience

#393
post #391

Earlier quoted context omitted.

Well for me, all of the libraries I use because none of them exist as packages for any OS. With most of them security fixes will only go into the latest version though, so once you get behind your system is insecure. Applications aren't something you build and forget. An unmaintained project is a dead one.

> Well for me, all of the libraries I use because none of them exist as packages for any OS. In conclusion you don't use any libraries that are packaged for any OS. What libraries? Also assuming that some libraries you use don't exist for your OS, that doesn't mean that you absolutely need the latest and greatest in a business critical way. So, not approved. All in all, not too fond of the reasoning and the evidence…

Your logic would prevent any app from just about any non-c ecosystem running. Java, ruby, python, dotnet, rust, go, they all have their own library management and very few of those libraries will be available in an apt repository (let alone a compatible one).

Your policy may work in a university, but you'd be fired from any real business.

Re: Software Developers Should Have Sysadmin Experience

#394

Earlier quoted context omitted.

>Because he maintains that installation and you don't? So why is that an acceptable mentality for "in-house" developed software but if you buy something proprietary from a third party where you have zero say over what lib/langs are used, it's A-OK? >Check for conflicts of this version of this library with other software currently in use (by other developers maybe, or even by the same developer). That's not the case w…

I see your point, and like I said I agree this is why Docker was invented and it's the best-in-breed at what it does (namely, being a tourniquet for a self-inflicted wound). My biggest concern really isn't "my problem" since I'm in ops: it's the leftpad worry. I still have teams starting Dockerfiles with "FROM centos:latest" because that's just the mindset they have: "Latest will fix any problems" rather than "Latest…

At my organization, leftpad is not a reason for SRE to tell developers they can't use dependencies. Instead, leftpad is a reason for SRE to run internal package mirrors for all our supported packaging systems (debian, pip, glide, Maven, etc) and ship forks of the build tools so that when you reference a 3rd party dependency, the URL is rewritten to one at our internal mirror. The internal mirror, in turn, goes out and downloads anything it doesn't already have.

They also maintain the base docker images that we're expected to use, as well as the docker build infrastructure.

Facilitation with guardrails, not blockers.

Re: Software Developers Should Have Sysadmin Experience

#395
post #393

Earlier quoted context omitted.

> Well for me, all of the libraries I use because none of them exist as packages for any OS. In conclusion you don't use any libraries that are packaged for any OS. What libraries? Also assuming that some libraries you use don't exist for your OS, that doesn't mean that you absolutely need the latest and greatest in a business critical way. So, not approved. All in all, not too fond of the reasoning and the evidence…

Your logic would prevent any app from just about any non-c ecosystem running. Java, ruby, python, dotnet, rust, go, they all have their own library management and very few of those libraries will be available in an apt repository (let alone a compatible one). Your policy may work in a university, but you'd be fired from any real business.

You are still not providing evidence.

You're also making bold claims ("any app from just about any...") that my personal experience can just not validate. It's very easy to write applications without fancy dependencies. Recently I did algorithms, systems and applications in C, C++, python, sdl, alsa, X11, Unix shell scripting, lp_solve, and some web programming in python, javascript, sqlite3. All rock solid and stable - all will probably run on any Linux box from the last 5-10 years (python3 came only in about 2008; forget about the lp_solve bindings and just use the command-line tool).

There are 2050 python3-* packages on my system. Not that I think it's a good idea to use most of them. What's "compatible"?

So what are the libraries you absolutely need? What is this week's secret sauce?

Re: Software Developers Should Have Sysadmin Experience

#396

Earlier quoted context omitted.

Pick your poison. If you run into a bug or problem with a 3rd party component (open source library, commercial tool, whatever), one of the first things they are going to ask you to do is upgrade. The fact you're on an old version of some library is an easy (and sometimes correct) scapegoat for problems. Put yourself in the 3rd party's shoes: if you spend a bunch of time trying to fix a problem that turns out to be a…

Upgrading the version of the library wouldn't be a problem if the concept of stable ABI's were as prevalent as it was 15 years ago. Back then, the major.minor version number system was used as a signal that it was safe to upgrade to a newer version of a library without worrying that the entire application stack was going to come falling down around itself because the developer of said library decided to rework some p…

> Put another way, a sysadmin could feel confident that moving from 1.52->1.53 would be a painless and transparent operation

This is what Semantic Versioning [1] aims to achieve, but as you highlighted, it still requires the maintainer(s) of the project to actually deliver stable software, regardless of what the version is. I think some people took "move fast and break things" a bit too literally.

A project following SemVer and that has good automated test coverage is definitely on the right track though, and in generally should be a pretty safe upgrade (of course it's important to know their track record).

"Move fast and break things ... in a separate branch with continuous integration running an extensive test suite" isn't quite as catchy but is what should be happening.

[1] http://semver.org/

Re: Software Developers Should Have Sysadmin Experience

#397

Earlier quoted context omitted.

>There is no difference between a "developer" and a "sysadmin" Ridiculous. Many developers have specialties that take years to gain proficiency. If there were no difference we could just replace a math PhD doing computer graphics with a sysadmin. Sometimes it's possible, but the blanket statement does not hold up. >I would be a bad developer if I did not understand how the systems my code runs on work I agree, but so…

> Why are you so against that word? Because, to be frank: it makes you sound like a tool. That's what 'greglindahl was referring to in his post, 'cause I said exactly that before I edited it to assume good faith and be nice about it. But leading off your reply with "ridiculous" confirmed that you're okay with that. I'm not gonna play this game with you; I'm having way more interesting and way better conversations in…

That's unfortunate it came across that way. I did not intend to do anything other than make a good faith (and maybe passionate) argument.

Re: Software Developers Should Have Sysadmin Experience

#398
post #393

Earlier quoted context omitted.

Your logic would prevent any app from just about any non-c ecosystem running. Java, ruby, python, dotnet, rust, go, they all have their own library management and very few of those libraries will be available in an apt repository (let alone a compatible one). Your policy may work in a university, but you'd be fired from any real business.

You are still not providing evidence. You're also making bold claims ("any app from just about any...") that my personal experience can just not validate. It's very easy to write applications without fancy dependencies. Recently I did algorithms, systems and applications in C, C++, python, sdl, alsa, X11, Unix shell scripting, lp_solve, and some web programming in python, javascript, sqlite3. All rock solid and stabl…

.net MVC, nUnit 3, jquery, knockoutjs, and nHibernate to name a few. I could name a dozen similar tools on the java stack. Pretty soon I'll be experimenting with rust with libui.

>There are 2050 python3-* packages on my system. Not that I think it's a good idea to use most of them. What's "compatible"?

2000 of them are random versions someone made a package for that are unknown to the core team and probably not receiving updates.

Your list of projects sounds like typical academic ones, not tools used by businesses that employ most software developers.

You're also missing the other benefit of these tools, that we develop against the deployed version. There are no compatibility issues because we develop on ubuntu and host production on redhat.

Re: Software Developers Should Have Sysadmin Experience

#399
post #219

Earlier quoted context omitted.

Sure, but those are still all very different from software development.

Of course. (In my opinion, /high software/ has more in common with mathematics, music, theatre-film-dance, and architecture than it has with engineering, and /low software/ is begining to resemble boiler room operations.) But here, as example is my BSEE a.m.: http://eng.rpi.edu/academics And to this day, we hear about "software engineers" and "software engineering". Per my OP: "It seems either your conclusion is held…

Process engineering (~manufacturing) and logistics (~supply-chain) are not dissimilar to modern software workflow. The basic tools (modular management of complexity, discrete processing, statistics, monitoring, redundancy in processes/providers, feedback) are equivalent. In fact, I feel like a huge part of a successful software career is learning to see the similarities in disparate fields and draw from them positive architectural benefits, while keeping other-profession-spire-dwellers properly onside/placated.

Re: Software Developers Should Have Sysadmin Experience

#400

Earlier quoted context omitted.

Honestly, I've heard worse out of sysadmins in some places.

Question: What must go wrong for a build to be 180x slower on a server than on a laptop?

Maybes: Packaging latency in archive formats (compress before upload, decompress after). Network latency on the upload/download. Block IO performance on the server. Virtualization overhead. Memory or processor constraints. Assumption of equivalence is spurious (eg. server is doing multi-architecture builds and full suites of tests including eg. regression tests). Yep, something like that.
Post reply on HN