Linus Torvalds released version 4.15 of the Linux Kernel on Sunday, again, and for a second version in a row, a week later than scheduled. The culprits for the late release were the Meltdown and Spectre bugs, as these two vulnerabilities forced developers to submit major patches well into what should have been the last cycle. Torvalds was not comfortable rushing the release, so he gave it another week.
Unsurprisingly, the first big bunch of patches worth mentioning were those designed to sidestep Meltdown and Spectre. To avoid Meltdown, a problem that affects Intel chips, developers have implemented Page Table Isolation (PTI) for the x86 architecture. If for any reason you want to turn this off, you can use the pti=off kernel boot option.
Spectre v2 affects both Intel and AMD chips and, to avoid it, the kernel now comes with the retpoline mechanism. Retpoline requires a version of GCC that supports the -mindirect-branch=thunk-extern functionality. As with PTI, the Spectre-inhibiting mechanism can be turned of. To do so, use the spectre_v2=off option at boot time. Although developers are working to address Spectre v1, at the moment of writing there is still not a solution, so there is no patch for this bug in 4.15.
The solution for Meltdown on ARM has also been pushed to the next development cycle, but there is a remedy for the bug on PowerPC with the RFI flush of L1-D cachefeature included in this release.
An interesting side affect of all of the above is that new kernels now come with a /sys/devices/system/cpu/vulnerabilities/ virtual directory. This directory shows the vulnerabilities affecting your CPU and the remedies being currently applied.
The issues with buggy chips (and the manufacturers that keep things like this secret) has revived the call for the development of viable open source alternatives. This brings us to the partial support for RISC-V chips that has now been merged into the mainline kernel. RISC-V is an open instruction set architecture that allows manufacturers to create their own implementation of RISC-V chips, and it has resulted in several open sourced chips. While RISC-V chips are currently used mainly in embedded devices, powering things like smart hard disks or Arduino-like development boards, RISC-V proponents argue that the architecture is also well-suited for use on personal computers and even in multi-node supercomputers.
The support for RISC-V, as mentioned above, is still incomplete, and includes the architecture code but no device drivers. This means that, although a Linux kernel will run on RISC-V, there is no significant way to actually interact with the underlying hardware. That said, RISC-V is not vulnerable to any of the bugs that have dogged other closed architectures, and development for its support is progressing at a brisk pace, as the RISC-V Foundation has the support of some of the industries biggest heavyweights.
Torvalds has often declared he likes things boring. Fortunately for him, he says, apart from the Spectre and Meltdown messes, most of the other things that happened in 4.15 were very much run of the mill, such as incremental improvements for drivers, support for new devices, and so on. However, there were a few more things worth pointing out:
To find out more, you can check out the write-ups at Kernel Newbies and Phoronix.
Learn more about Linux through the free “Introduction to Linux” course from The Linux Foundation and edX.
In the previous articles, we learned the basics of Docker terminology, how to install Docker on desktop Linux, macOS, and Windows, and how to create container images and run them on your system. In this last article in the series, we will talk about using images from DockerHub and publishing your own images to DockerHub.
First things first: what is DockerHub and why is it important? DockerHub is a cloud-based repository run and managed by Docker Inc. It’s an online repository where Docker images can be published and used by other users. There are both public and private repositories. If you are a company, you can have a private repository for use within your own organization, whereas public images can be used by anyone.
You can also use official Docker images that are published publicly. I use many such images, including for my test WordPress installations, KDE plasma apps, and more. Although we learned last time how to create your own Docker images, you don’t have to. There are thousands of images published on DockerHub for you to use. DockerHub is hardcoded into Docker as the default registry, so when you run the docker pull command against any image, it will be downloaded from DockerHub.
Please check out the previous articles in the series to get started. Then, once you have Docker running on your system, you can open the terminal and run:
$ docker images
This command will show all the docker images currently on your system. Let’s say you want to deploy Ubuntu on your local machine; you would do:
$ docker pull ubuntu
If you already have Ubuntu image on your system, the command will automatically update that image to the latest version. So, if you want to update the existing images, just run the docker pull command, easy peasy. It’s like apt-get upgrade without any muss and fuss.
You already know how to run an image:
$ docker run -it <image name> $ docker run -it ubuntu
The command prompt should change to something like this:
root@1b3ec4621737:/#
Now you can run any command and utility that you use on Ubuntu. It’s all safe and contained. You can run all the experiments and tests you want on that Ubuntu. Once you are done testing, you can nuke the image and download a new one. There is no system overhead that you would get with a virtual machine.
You can exit that container by running the exit command:
$ exit
Now let’s say you want to install Nginx on your system. Run search to find the desired image:
$ docker search nginx
As you can see, there are many images of Nginx on DockerHub. Why? Because anyone can publish an image. Various images are optimized for different projects, so you can choose the appropriate image. You just need to install the appropriate image for your use-case.
Let’s say you want to pull Bitnami’s Nginx container:
$ docker pull bitnami/nginx
Now run it with:
$ docker run -it bitnami/nginx
Previously, we learned how to create a Docker image, and we can easily publish that image to DockerHub. First, you need to log into DockerHub. If you don’t already have an account, please create one. Then, you can open terminal app and log in:
$ docker login --username=<USERNAME>
Replace <USERNAME> with the name of your username for Docker Hub. In my case it’s arnieswap:
$ docker login --username=arnieswap>
Enter the password, and you are logged in. Now run the docker images command to get the ID of the image that you created last time.
$ docker images
Now, suppose you want to push the ng image to DockerHub. First, we need to tag that image (learn more about tags):
$ docker tag e7083fd898c7 arnieswap/my_repo:testing
Now push that image:
$ docker push arnieswap/my_repo
The push refers to repository [docker.io/arnieswap/my_repo]
12628b20827e: Pushed 8600ee70176b: Mounted from library/ubuntu 2bbb3cec611d: Mounted from library/ubuntu d2bb1fc88136: Mounted from library/ubuntu a6a01ad8b53f: Mounted from library/ubuntu 833649a3e04c: Mounted from library/ubuntu testing: digest: sha256:286cb866f34a2aa85c9fd810ac2cedd87699c02731db1b8ca1cfad16ef17c146 size: 1569
Eureka! Your image is being uploaded. Once finished, open DockerHub, log into your account, and you can see your very first Docker image. Now anyone can deploy your image. It’s the easiest and fastest way to develop and distribute software. Whenever you update the image, users can simply run:
$ docker run arnieswap/my_repo
Now you know why people love Docker containers. They solve many problems that traditional workloads face and allow you develop, test, and deploy applications in no time. And, by following the steps in this series, you can try them out for yourself.
Learn more about Linux through the free “Introduction to Linux” course from The Linux Foundation and edX.