I have been using Facebook for the last years to fill every dead time:waiting for the bus, ads on TV, compiling, etc. The quality of the information coming from Facebook is inferior to any other social network, at least to my experience (it can be I follow/know the wrong people), though the part of the brain that controls procrastination seems addicted to this lower quality information and the chattering there. Also, I don’t want to simply delete my Facebook account and move on, most of the people I know are present only there, neither I want to be more “asocial”.
The Android market has always a solution. An app let you define rules on how long are you permitted to use each app. I am self limiting myself to ten minutes per day of Facebook. Second day and the rule is still in place without exceptions!
git rebase is one of my favorite git commands. It allows to update a set of local patches against another git branch and also to rework, trough the -i flag some previous patches.
The problem I had to deal with was quite simple, rename a function called notProperPythonCode to proper_python that was defined in the first patch and be sure that all other patches are using the correct name. The –exec flag allows to run a custom script after each patch is applied, so that I could run sed to process the Python files and replace the old function name with the new one. The process is quite simple, except that such changes would trigger a lot of merge conflicts, trivial to solve but quite annoying.
Fortunately git rebase allows to choose what merge strategy must be adopted for solving conflicts, the theirs strategy in case of a conflict, will take the previous version of the patch and silently use it. That is fine for this simple substitution case, where we process each file ending by *.py in the repository.
In the end, the final command looked like this:
git rebase -X theirs -i \
--exec "sh -c \"git ls-files *.py \
| xargs sed --follow-symlinks -i -e \
&& git commit --amend -a -C HEAD" origin/master
The main reason behind system containers was the inability to run Flannel in a Docker container as Flannel is required by Docker itself. CoreOS solved this chicken and egg problem by using another instance of Docker (called early-docker) that is used to setup only Etcd and Flannel.
Differently, Atomic system containers will be managed by runc and systemd.
The container images, even though being served through the Docker v2 registry, are slighty different than a regular Docker container in order to be used by Atomic. The installer expects that some files are present in the container rootfs under /exports, the OCI spec file for running the Runc container and the unit file for Systemd. Both these files are templates and some values are replaced by the installer.
The communication with the Docker registry is done through Skopeo, that is used internally by the atomic cli tool.
The demo shows the current status of the project, these features are not still part of any release and most likely there will be more changes before they will be released.
I wanted to give a try to asciinema, this is the result:
The images used in the demo are maintained here: https://github.com/giuseppe/atomic-oci-containers/
More details on the current design can be found here: https://github.com/projectatomic/atomic/issues/298.