redsymbol

A lot of people posting here are being unreasonable, demanding, and childish. Recognize that for what it is, don't let it affect you, and just continue moving forward based on the constructive part of the feedback.

http://migrateup.com/whats-really-new-in-python-3/

(Actually, maybe not, because it doesn't have code examples.)

Perhaps I missed it, but how exactly do you implement the timestamp logging? Do you use your normal application logging, or some other mechanism?

I fully agree that "rerun the config tool on a pre-existing container" is an anti-pattern, and it's best to avoid it if at all possible. I can see how what you are proposing would be a great step in a positive direction.

I'm not convinced CM systems don't have a role, still. They are very flexible and powerful at accommodating many specialized system setup scenarios. But I think that's independent of what you're really focused on here.

Anyway, excellent and well-written article!

1) Run a base docker image.

2) Run the config management tool on/in this image, (ansible playbook, chef cookbook, etc.)

3) Commit the container to the new image

Dockerfiles are very convenient and easy, and are great as far as they go. They also don't have idempotent actions built-in. As a result, a minor change requires one to rebuild the entire image from scratch.

In contrast, the CM systems mentioned above operate by letting you declare the desired system state - i.e., what it is, instead of how to create it. This lets the CM system runtime automatically skip unnecessary steps. For example, in (say) an Ansible playbook, instead of (in the Dockerfile):

  RUN mkdir -p /path/to/some/dir

   - file:
       state: directory
       path: /path/to/some/dir

It also helps a lot with surgical updates. For example, suppose my Dockerfile for a web service container contains the following:

  RUN apt-get install -y apache2 php5 libapache2-mod-php5

   - apt:
       name: "{{ item }}"
       state: present
     with_items:
       - apache2
       - php5
       - libapache2-mod-php5

1) Run the previous docker image.

2) Run the config management tool with the surgical-update action.

3) Commit the container to create an updated image.

The Ansible version of the update would be as simple as:

   - apt:
       update_cache: yes
       name: apache2
       state: latest

Using a CM system like this doesn't solve all the problems outlined in the article - actually, I don't think it even solves a majority of them. But I can't figure out why so many smart people are focused on reinventing parts of it poorly, or thinking in terms of "docker vs. ansible/chef/puppet/salt". I know they're not idiots. Am I missing something? If so I'd sincerely like to know.

I am not an investor and don't fully understand how startup financing works even in SV, and certainly not anywhere in Europe. However, it seems to me that if you're an angel or VC, there is a remarkable opportunity in places like Bulgaria. Potentially a great deal of investment demand (i.e. entrepreneurial tech talent), compared to investment supply. Lots of new challenges, I'm sure, but competing with other investors apparently isn't one of them.

(Hmmm... if you're an SV [EDIT: American] angel/VC and are thinking the same, email me as well. In the event I meet some promising BG entrepreneurs in the next week, it's possible I might be able to make some meaningful introductions.)

  #!/bin/bash
  items=(
      'a'
      'b c'
      "d\te"
      "f\ng"
  )
  
  echo "Unquoted:"
  for item in ${items[@]}; do
      echo -e ".  $item"
  done
  
  echo "Quoted:"
  for item in "${items[@]}"; do
      echo -e ".  $item"
  done
  
  set -euo pipefail
  IFS=$'\n\t'
  echo "Unquoted strict mode:"
  for item in ${items[@]}; do
      echo -e ".  $item"
  done

  Unquoted:
  .  a
  .  b
  .  c
  .  d    e
  .  f
  g
  Quoted:
  .  a
  .  b c
  .  d    e
  .  f
  g
  Unquoted strict mode:
  .  a
  .  b c
  .  d    e
  .  f
  g

(GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu))

My first thought: It seems like only $@, $* and variables read from the environment could be possible attack vectors. But since shell scripts can't be setuid, it's hard for me to immediately imagine how unquoting could enable a new exploit.

EDIT: the most dangerous example I can think of right now is a script like this, where a webapp invokes the script and passes a GET param as an argument:

  #!/bin/bash
  exec $1

  ./badscript.sh 'some-benign-command ; cat /etc/passwd'

(And if "cat /etc/password" itself can be passed as $1, then quoting won't help...)

It's unfortunate the semantics of bash don't have variable references behave like they are quoted by default. I really wish it did.

After reading it, I thought it was really insightful and useful, and concluded you're clearly a good SW engineer - was surprised by the excess criticism here. Anyway, thank you for writing and publishing this.

Is the data you've seen internal Google data, or is any of it available to us non-Googlers? Would be interesting to know the ratio of usage, how it varies by time of day, by activity, etc.

Second, the VPE must have a larger focus - seeing what's good for the entire company, not just what's good for engineering, and certainly more than what's good for the current projects. Often a straight up engineer will be (quite properly) focused mainly on whatever their current project is, and may not even have the business knowledge to fully grok how it fits in the big picture.

Lastly, the VPE needs exceptional management and leadership skills. A tech lead will have this too, but it must be much stronger at the veep level.

Not sure what "spends no time at HN" means. Martin is an unusually excellent software engineer by almost any measure, as evidenced by his years of impactful open-source development - 0MQ being just one example.

And Haskell wouldn't make sense for a project like this, only because of some of his goals with the project - which include: to eventually have it integrated in the Linux kernel; to make it easily usable by code in any language; to have it easily and universally cross-platform; etc.

(Dang... did I just feed a troll?)

RUSSELL TICE: ...The NSA were targeting individuals. In that case, they were judges like the Supreme Court. I held in my hand Judge Alito's targeting information for his phones and his staff and his family.

If true, that's... mind boggling. What possible valid reason could the NSA have to secretly monitor the calls of a US Supreme Court justice? And his staff, AND family?

I really hope this allegation is false.

It would be hilarious if Snowden and his companions tried to get seats on that flight, but could not, because it was already fully booked by these proactive journalists.

So it's strange that some in congress still support the current patent situation. I want to believe those who serve there are generally smart and competent, regardless of whether their opinion on something agrees with mine. But the pro-troll arguments seem massively short-sighted.

Allowing the current situation to continue would be massively harmful to our descendants. I'm grateful there seems to be swelling bipartisan support to end it.

This is perhaps the most insightful comment I've encountered about computer literacy (and, maybe, literacy in general). Thank you for posting it and enlightening me a bit.