DEV Community: Yadunandan Bhat

UNIX Basics - Architecture of UNIX

Yadunandan Bhat — Thu, 05 Nov 2020 15:56:42 +0000

In my last post, I've talked about what is UNIX and it's history. In this second part of the UNIX Basics series, I'll be explaining the architecture of UNIX.

The whole architecture of UNIX can be divided into 4 different layers. They are

Hardware
Kernel
Shell
Applications

The hardware part is all the hardware in the computer, like memory, hard disk, input devices, output devices.

The kernel is the core of the UNIX operating system. This is the most powerful of all the four. The kernel is the one that interacts with the computer hardware. This is loaded into memory whenever the system starts up. The kernel provides a lot of support for the application program. It also does housekeeping jobs like process management, scheduling, file management, device management, network management, memory management, and other jobs that the user shouldn't bother about. It is always running, even if no program is currently running.

The shell's job is to act as an interpreter. When the user gives the command, the shell reads the commands, understands them, and then sends a request to execute the program. Then when the program is executed it again sends the request to display the program to the user on-screen. The shell is also like an interface between the user and the kernel. Even though there’s only one kernel running on the system, there could be several shells in action, one for each user who is logged in.

The applications are normal user applications or system applications. The applications can access the hardware using the special functions of kernel called System Calls. These are a set of routines mostly written in C, used to communicate with hardware directly.

While talking about UNIX architecture, we also talk about its filesystem. UNIX considers everything as a file, or more specifically, a stream of bytes. It means that everything in the system from processes, files, directories, sockets, pipes, etc., is represented by a file descriptor abstracted over the virtual filesystem layer in the kernel. The virtual filesystem is an interface provided by the kernel.

The whole architecture of UNIX is a deep concept, so I won't be going further. I think I've covered all the basic topics. I haven't started writing the next part in the UNIX Basics series, so I don't know what it will be about yet, but be sure to keep an eye for that.

If you find any errors or mistakes, please comment down below, I'll be sure to correct it.

UNIX Basics - What is UNIX and the History of UNIX

Yadunandan Bhat — Wed, 28 Oct 2020 17:18:13 +0000

If you've ever worked in the software field, you've probably come across Linux or any other Unix-like operating systems. You might've wondered what it is? Well, in this first part of the UNIX Basics series, I'll be deep-diving into what is UNIX, and how it came to be.

First of all, what is an Operating System?

An operating system is the software that manages the computer’s hardware and provides a safe environment for running programs. It acts as an interface between programs and the hardware resources that these programs access. It is loaded into memory when a computer is booted and remains active as long as the machine is up. It performs all the basic tasks like file management, memory management, process management, handling input and output, and controlling peripheral devices such as disk drives and printers.

UNIX and its history

Well, in the past many operating systems existed, but they were hardware-specific. And they were also proprietary because the assembler code developed on one machine, just wouldn't run on another. But all of this changed when Ken Thompson, Dennis Ritchie, and other developers at AT&T Bell Labs, developed UNIX in 1971. UNIX is the most powerful and popular multi-user and multi-tasking operating system out there. UNIX is nothing like its predecessors. It's written in C, instead of assembly language. This makes UNIX run on practically any hardware platform. Apart from the basic operating system functions, UNIX also includes a rich set of tools like editors, compiler, interpreters, etc., that aids users, programmers, and system administrators, in developing, debugging, and maintaining programs. That's why UNIX doesn't appeal to normal users.

The boom of UNIX started in the late 1970s when AT&T started licensing the UNIX source code to academic and research institutions. By using the UNIX source-code, the University of California, Berkeley, created its own flavor of UNIX and called it the Berkely Software Distribution, or more commonly known as BSD. BSD filled the holes in the original UNIX. It included additional software and capabilities, like the now-famous text editor vi, and csh. UCB had also created a better file system, a more versatile mail feature, and a better method of linking files. Later, they also offered TCP/IP with their distribution.

In addition to BSD, many other companies like Sun Microsystems, HP, IBM, etc. made their own distributions based on UNIX. This made the original UNIX lose its identity as a separate product, and at the same time, incompatibilities were also steadily growing. So to unify the many UNIX flavors and to create a single conforming standard, AT&T created the System V Interface Definition or SVID. This prompted the X/Open (now The Open Group) to create the X/Open Portability Guide or the XPG, and the systems following this specification were branded UNIX95, UNIX98, or UNIX03 depending on the version of the specification.

Even though there was already a standard for UNIX operating systems, IEEE developed another system of standards called as Portable Operating System Interface for Computer Environments or POSIX. POSIX was based on UNIX, even though it referred to operating systems in general. This existence of dual-standards made the X/Open to work with IEEE to create a unified standard that included elements of XPG and POSIX. This came to know as Single UNIX Specification, Version 3, or SUSV3. The main tagline for this standard was "write once, adopt everywhere", which means that any software developed on a POSIX-compliant system can be ported to run in any other POSIX-compliant system, with minimal to no modifications. This became a major milestone for UNIX.

Enter GNU/Linux

Since the mid-1980s, Richard Stallman was already looking to create an open-source alternative to the proprietary UNIX system. So he founded the GNU project (GNU is a recursive acronym for "GNU's not UNIX"). GNU was to be a complete, UNIX-compatible operating system made up of free software. And by the early-1990s, even though many programs and features were written, there wasn't a working kernel for the GNU, because the GNU Hurd kernel was supposed to be a microkernel, and it's development resulted in long delays (even as of today, there hasn't been a stable version of the GNU Hurd kernel). Without a kernel, the free and open-source operating system dream was far from realization. Then came the first version of Linux kernel, a UNIX clone that is developed from scratch by Linus Torvalds and team. It targeted POSIX compliance. The Linux kernel code was completely written from scratch, using GNU software like GCC, etc. This made Linux a perfect match for the GNU project and was chosen as the kernel for GNU. This made the completely free operating system dream come true, with Linux kernel, GNU software, and X-Window System. And the operating system was called GNU/Linux, though many people call it just Linux. The most popular GNU/Linux flavors include Ubuntu, Arch Linux, Fedora (formerly Red Hat), SuSE, Debian, and Mandriva. These distributions include a plethora of software, from C and C++ compilers to Java, interpreters like Perl, PHP, python, and tcl, browsers like Firefox, internet servers, and multimedia software. All the major computer vendors have committed to support GNU/Linux, and many of them have ported their software to this platform. Many operating systems today, including Android, Chrome OS, Steam OS, and a huge amount of embedded operating systems for devices, are based on GNU/Linux.

Then what are Unix-like operating systems?

"Unix-like" operating systems include systems which are based on UNIX and comply with Single UNIX Specifications. These include Linux, Free/Open/NetBSD, macOS (from 10.5), Solaris, etc. Solaris and macOS are POSIX certified, because these systems have passed the compliance check and are allowed by the Open Group to carry the UNIX name. But Linux, flavors of BSD, and many more operating systems "are" POSIX-compliant, but are not certified by the Open Group just because the foundations behind these operating systems didn't want to pay for the compliance check. These systems are "functionally" UNIX, but "are not" UNIX.

This wraps up the first part of the "UNIX Basics" series. I wanted to keep this post as short as possible, but it became a very large one as I kept on writing. Sorry about that! I'm already writing the second part in the series, so be on the lookout for that.

As I've referred many books and articles to write this post, there ought to some mistakes, so please comment down below if you've found any mistakes or errors. Thank you!

Areas where Python is not recommended

Yadunandan Bhat — Sat, 24 Oct 2020 10:56:13 +0000

Python might be the most popular programming language in the world, but that doesn't mean it can be used everywhere. I've listed some fields where using Python is not recommended.

Systems programming

This is because Python is very, very slow compared to something like C/C++, just because it is an interpreted language. These languages are processed at runtime. Every line is read, analyzed, and executed. This makes the interpreted code run 5 - 10 times slower than compiled code. Even JIT-compiled languages like Java can beat Python in terms of speed. This isn't to say that you can't write device drivers with Python and then use C or assembly language layer to communicate with hardware, but this route isn't generally used.

Mobile app development

While it serves as an excellent server-side language, Python is rarely seen on the client-side. Besides that, it is rarely ever used to develop mobile applications. Neither Android nor iOS support Python as an official programming language.

It is still possible to develop mobile applications in Python using Kivy, but it requires more time and effort on the part of the developer to deliver a rich user experience. That is why Kotlin and Swift are some of the preferred languages when it comes to mobile app development. And Java is commonly used for banking web applications due to its particular strength in security functionality and environment. Java includes access to certain security features such as cryptography, and advanced authentication and access control that keep your web application secure.

Game development

PyGame or Tkinter libraries are a good choice for beginners learning how to make simple games. But, the performance of Python isn't good enough for the resource-intensive parts of the game engine for higher-end games. Therefore for more resource-intensive games, developers consider the industry standard which is C# with Unity or C++ with Unreal. And most people getting into game development are looking for a robust platform that offers plenty of scalabilities. Unity and Unreal offer exactly that, and you need to know C# or C++ to use them. However, Python is used as a scripting language in some game engines.

Embedded Systems

Python needs more resource overhead and is also a lot slower. Especially in embedded devices, you can't have luxury like an automatic garbage collector. Once a program is written in C/C++, it can be converted into bytecode/instructions for a particular embedded platform and uploaded onto it, but you can't do that in Python as it is an interpreted language. C can also utilize the hardware to its maximum by multiprocessing and multithreading APIs provided by POSIX, but Python can't work like that because it has GIL.

If you find any errors, please feel free to comment down below!

How to install and setup GitHub CLI

Yadunandan Bhat — Thu, 22 Oct 2020 08:42:30 +0000

You know how painful it is to switch from terminal to browser, then again to the terminal while working with git repositories right? Then worry not, because GitHub CLI brings GitHub to your terminal.

GitHub has finally introduced its own command-line tool that brings pull requests, issues, and other GitHub concepts to the terminal next to where you are already working with git and your code. To quote GitHub it "reduces context switching, helps you focus, and enables you to more easily script and create your own workflows". Pretty cool right?

This post explains the installation and the setting-up of the GitHub CLI, hereby referred to as 'gh'.

Installation

Windows

gh can be installed on Windows using scoop or chocolatey package managers.

scoop



scoop bucket add github-gh https://github.com/cli/scoop-gh.git
scoop install gh

chocolatey



choco install gh

macOS

macOS users can use either Homebrew or MacPorts to install gh.

Homebrew



brew install gh

MacPorts



sudo port install gh

Linux

Debain-based



sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-key C99B11DEB97541F0
sudo apt-add-repository https://cli.github.com/packages
sudo apt update
sudo apt install gh

Fedora-based



sudo dnf config-manager --add-repo https://cli.github.com/packages/rpm/gh-cli.repo
sudo dnf install gh

Arch-based



sudo pacman -S github-cli

There are more distro-specific installation instructions here. Windows and macOS users can install using MSIs and downloadable binaries available on their releases page.

Setting up

After the installation, running any command will prompt you to login to GitHub.

Run 'gh auth login' to authenticate your GitHub account. It'll ask you to select the account type, either a normal account or an enterprise one. I'll select the normal account.

Then it'll ask you to select your preferred authentication method. You can choose to authenticate using your browser or using the GitHub authentication token. I'll select the browser method.

Then it'll display a one-time code, you should copy it or write it down.

And then pressing enter will open the browser. You should enter the one-time code here.

Then click on "Authorize github" to complete the authentication. You can safely close the browser now.

Now it'll ask you to select the default git protocol. You can select HTTPS or SSH. I'll be selecting SSH because I've already made an SSH key, and it's easy cloning and pushing to the repo using SSH.

Aaaand that's it. You've successfully installed and set up the GitHub CLI.
I'm also planning a post explaining all the gh commands and how to use it, so be on the lookout for that.