Every program running on a Linux system is a process. The shell you type into is a process. The web server serving a page is a process. The kernel’s background workers, the login session, the editor, the compiler — all processes. When something is slow, or a service is not responding, or a program is…
Installing software is only half of package management. The other half is taking it away and keeping it current. Removing a package is not the reverse of installing it — configuration files are preserved by default, dependencies that were installed automatically are left behind, and packages that other packages depend on cannot be removed without…
Installing packages is the daily work of Linux administration. The previous chapter covered what package managers are and the full set of operations. This chapter is about the install operation specifically — the command, what happens when it runs, how dependency resolution works, the difference between installing from a repository and installing a local file,…
Software on a Linux system does not arrive as a single downloaded installer, the way it does on Windows or macOS. It arrives as a package: a file that contains the program’s binaries, its configuration templates, its documentation, and a manifest of what it needs to run. A package manager is the tool that finds…
Permissions decide what can be done to a file. Ownership decides who the permissions apply to. Every file has an owner and a group, set when the file is created to the creating user and their primary group. When a file needs to belong to someone else — a web server that runs as www-data,…
The previous chapter introduced Observables and the operator pipeline. This chapter goes deeper into the two largest categories of operators: transformation and filtering. Transformation operators change the values that flow through the stream — map converts each value, scan accumulates, switchMap and its siblings flatten inner Observables. Filtering operators decide which values continue — filter…
RxJS is the reactive layer underneath Angular. Every HTTP call, every router event, every form value change, and every signal-based computation that Angular exposes is an Observable underneath. An Observable is a description of a stream — a sequence of values that arrive over time. Unlike a Promise, which produces exactly one value and resolves…
Logging is the practice of recording what an application did. Observability is the broader discipline of understanding what an application is doing — through logs, metrics, traces, and the context that ties them together. In a front-end application, observability is often treated as an afterthought, because the developer’s console is right there and errors are…
Errors are not exceptional. They are a normal part of every application that talks to a network, parses user input, or depends on code it does not control. A robust Angular application treats error handling as a design concern, not an afterthought. Errors appear at four distinct levels: within a component’s synchronous logic, within asynchronous…
Every HTTP request an Angular application makes can pass through a series of functions that inspect it, modify it, or handle its response. These functions are interceptors. They are the mechanism for cross-cutting concerns — authentication, logging, error handling, caching, loading indicators, retry logic — that would otherwise be duplicated in every service method. Instead…