Author: Sahil Suri

Introduction Google CLoud like it’s popular contemporary cloud vendors offers a means to manage cloud resources via the command line. The folks at GCP refer to this command line interface as cloud shell and it uses the gcloud sdk. One of the benefits of using cloud shell is that it can be launched directly from the Google Cloud console. In this post, we’ll demonstrate how to familiarize yourself with cloud shell while explaining some Google Cloud terminology along the way. Activate Cloud Shell Cloud Shell is a virtual machine that is loaded with development tools. It offers a persistent 5GB home directory and runs on the Google Cloud. Cloud Shell provides command-line access to your Google Cloud resources. In the Cloud Console, in the top right tool bar, click the Activate Cloud Shell button and click Continue when prompted. It takes a few moments to provision and connect to the environment. When you are connected, you are already authenticated, and the project is set to your PROJECT_ID. What is a project? Any Google Cloud resources that you allocate and use must belong to a project. You can think of a project as the organizing entity for what you’re building. A project is made up of the settings, permissions, and other metadata that describe your applications. Resources within a single project can work together easily. gcloud is the command-line tool...

Introduction We have been using the yum or rpm package management tools for a while for managing packages in Redhat, Centos and other distributions which have been forked from RHEL. Yum has been the default package manager since Redhat Enterprise Linux 5 onwards. Before yum, RHEL systems had been using the up2date software management program. The DNF package manager was introduced in Fedora 18 and became the default package manager for the Fedora distribution for operating system version Fedora 22 onwards and is intended to be a replacement for yum. In this article, we will compare these package managers to provide some perspective as to when and why you should consider using one over the other.   Sno                    DNF               YUM                                     RPM 1 Written in C and Python Written in python Written in C and Perl 2 DNFs uses libsolv for dependency resolution which was created and maintained by SUSE YUM uses public API for dependency resolution RPM does not provide dependency resolution 3 Dependency resolution is fast and easy making installation of groups of packages very simple Dependency resolution is slower as compared to dnf but is still fairly straightforward Due to lack of dependency...