7 ms·

> Staying away from it is still not the best strategy There's a whole generation of sysadmins that use docker so that they can stay away from foundational know

by latch 5y ago

> Staying away from it is still not the best strategy There's a whole generation of sysadmins that use docker so that they can stay away from foundational knowledge. We interview experienced devops who do not know/understand how to build basic packages from source (e.g. they don't understand the ./configure, make, make install chain) and who only have basic knowledge of the underlying operating system.

eru 5y ago
To be honest, I know how to type `./configure`, `make` and `make install`. And I know more about Gnu Make than I would admit in a job interview (for fear of someone expecting me to work with Make). But so far, life has been too short for me to waste my time on Gnu Autoconf. And I don't feel guilty about this, or like someone who doesn't know fundamentals. Autoconf is by all accounts a horrible system. Gnu Make ain't much better. So I can't fault people for trying to avoid this mess.
- dmix 5y ago
  All software is fundamentally helping deal with abstractions as this.
  - eru 5y ago
    Build systems in general can be ok, or even elegant and fun. Autoconf is just really terrible.
    - arp242 5y ago
      Autoconf is one of those programs that solved real problems when it was created, in a way that was actually fairly reasonable at the time too. There's a reason it became so popular. But it's now 30 years later, and what was reasonable then is a liability now. Sendmail is another great example of this phenomenon.
      - eru 5y ago
        Oh, yes, Autoconf was somewhat defensible when it was created. Just like PHP and COBOL solved real problems back in their heyday. They are just not something anyone should be using nowadays. (Btw, Facebook's Hack is a surprisingly pleasant language. Probably the best one they could have made, coming from PHP.)
        arp242 5y ago
        > They are just not something anyone should be using nowadays. I guess it depends, take Vim for example: been around since the early 90s, the developers are familiar with autoconf, and it seems to work well for them. Why fix something if it ain't broke? Switching build systems is not necessarily an easy task. Also, as a user I always found cmake quite hard to deal with. Actually, as a user, I actually prefer autotools in spite of its shortcomings. I think there's still quite a bit to win here. Either way, I personally wouldn't really call autoconf "terrible".
        rsj_hn 5y ago
        It's like the saying "the shortest path between two points is the one you know" - the simplest build system is the one that exposes the least complexity to you, which is usually the one that is already deployed and working to your satisfication.
        eru 5y ago
        Unless you want to make a change or fix a bug, that is.
        eru 5y ago
        Well, cmake ain't exactly my favourite piece of software either. And, yes, switching an existing system is a different proposition from starting from scratch. Though see what the Neovim people have been doing to remove some of the accumulated cruft from Vim, if you are interested.
- funcDropShadow 5y ago
  I wholeheartedly agree, that I spend to much time of my live with GNU autoconf and make. But docker is on completely other level. After spending years and years of working with and around docker and speaking with others that do the same, I came to the conclusion that I will recommend docker only for one use-case in the future: Making easy examples to startup a system in one line.
- ex_amazon_sde 5y ago
  > So I can't fault people for trying to avoid this mess. Ex-Amazon here. Being deeply familiar with OS fundamentals and internals, "low level" tools, and so on is crucial. A lot of candidates show to interviews with CVs filled with names of popular frameworks and fancy devops tools and often don't understand what really happens behind the curtain. People are becoming less familiar with the basics and tend to reinvent the wheel. In many teams this does not get you hired.
  - mtberatwork 5y ago
    I'm not saying you are wrong but this sounds like it is in part a hiring problem. > Being deeply familiar with OS fundamentals and internals, "low level" tools, and so on is crucial. ...needs to be front and center on the job description then. Far too often these kinds of things are hidden on the initial job descriptions and it just wastes everyone's time. I get that HR/recruiters want to throw a big net but vague job descriptions are often part of the problem.
    - ex_amazon_sde 5y ago
      I cannot generalize for the whole company. When writing jobspecs in my team we never made lists of the "popular frameworks of the month".

by latch 5y ago

eru 5y ago

To be honest, I know how to type `./configure`, `make` and `make install`. And I know more about Gnu Make than I would admit in a job interview (for fear of someone expecting me to work with Make). But so far, life has been too short for me to waste my time on Gnu Autoconf. And I don't feel guilty about this, or like someone who doesn't know fundamentals. Autoconf is by all accounts a horrible system. Gnu Make ain't much better. So I can't fault people for trying to avoid this mess.

dmix 5y ago
All software is fundamentally helping deal with abstractions as this.
- eru 5y ago
  Build systems in general can be ok, or even elegant and fun. Autoconf is just really terrible.
  - arp242 5y ago
    Autoconf is one of those programs that solved real problems when it was created, in a way that was actually fairly reasonable at the time too. There's a reason it became so popular. But it's now 30 years later, and what was reasonable then is a liability now. Sendmail is another great example of this phenomenon.
    - eru 5y ago
      Oh, yes, Autoconf was somewhat defensible when it was created. Just like PHP and COBOL solved real problems back in their heyday. They are just not something anyone should be using nowadays. (Btw, Facebook's Hack is a surprisingly pleasant language. Probably the best one they could have made, coming from PHP.)
      - arp242 5y ago
        > They are just not something anyone should be using nowadays. I guess it depends, take Vim for example: been around since the early 90s, the developers are familiar with autoconf, and it seems to work well for them. Why fix something if it ain't broke? Switching build systems is not necessarily an easy task. Also, as a user I always found cmake quite hard to deal with. Actually, as a user, I actually prefer autotools in spite of its shortcomings. I think there's still quite a bit to win here. Either way, I personally wouldn't really call autoconf "terrible".
        rsj_hn 5y ago
        It's like the saying "the shortest path between two points is the one you know" - the simplest build system is the one that exposes the least complexity to you, which is usually the one that is already deployed and working to your satisfication.
        eru 5y ago
        Unless you want to make a change or fix a bug, that is.
        eru 5y ago
        Well, cmake ain't exactly my favourite piece of software either. And, yes, switching an existing system is a different proposition from starting from scratch. Though see what the Neovim people have been doing to remove some of the accumulated cruft from Vim, if you are interested.
funcDropShadow 5y ago
I wholeheartedly agree, that I spend to much time of my live with GNU autoconf and make. But docker is on completely other level. After spending years and years of working with and around docker and speaking with others that do the same, I came to the conclusion that I will recommend docker only for one use-case in the future: Making easy examples to startup a system in one line.
ex_amazon_sde 5y ago
> So I can't fault people for trying to avoid this mess. Ex-Amazon here. Being deeply familiar with OS fundamentals and internals, "low level" tools, and so on is crucial. A lot of candidates show to interviews with CVs filled with names of popular frameworks and fancy devops tools and often don't understand what really happens behind the curtain. People are becoming less familiar with the basics and tend to reinvent the wheel. In many teams this does not get you hired.
- mtberatwork 5y ago
  I'm not saying you are wrong but this sounds like it is in part a hiring problem. > Being deeply familiar with OS fundamentals and internals, "low level" tools, and so on is crucial. ...needs to be front and center on the job description then. Far too often these kinds of things are hidden on the initial job descriptions and it just wastes everyone's time. I get that HR/recruiters want to throw a big net but vague job descriptions are often part of the problem.
  - ex_amazon_sde 5y ago
    I cannot generalize for the whole company. When writing jobspecs in my team we never made lists of the "popular frameworks of the month".