Linux

The Linux kernel is the core of the operating system: the layer that manages hardware and resources, on which user space programs are built. The project describes it as a Unix clone aiming towards POSIX compliance, under GPLv2.

On its own the kernel is not a usable system. What we run is a distribution: the kernel plus the user space built around it, with package management, an init system and update channels. kernel.org draws the line explicitly: if uname -r shows anything after the dash, you are running a distribution kernel, which kernel.org does not support.

Releases and updates

Releases follow a predictable cadence: a new mainline kernel every 9-10 weeks, after a two week merge window and seven weeks of stabilization. Fixes are then backported from mainline into the stable branch, usually weekly, while longterm branches keep older trees alive with important fixes and published end of life dates.

The stable rules are narrow: a fix must already exist in mainline, be correct and tested, stay under 100 lines, and address a real problem such as an oops, a hang, data corruption or a security issue. Cosmetic cleanups and theoretical races are rejected, so an older branch receives fixes, not features. Updates travel as signed packages: repository signatures are checked against known public keys, and hashes prove the packages were unaltered.

• An update is not immediate. A new kernel image does not replace the running kernel; it takes effect at the next boot, chosen by the bootloader.
• Building a kernel needs current tools. Outdated build dependencies can cause indirect failures, hence the documented minimums.

Services and init

systemd is the init system: it runs as the first process (PID 1), bringing up and maintaining services. Control happens through units: service units start daemons, target units group them, socket units allow on demand activation, and boot finishes at default.target, usually the console multi-user.target.

systemd places every service in its own control group, so accounting stays traceable per unit. systemctl shows and changes state, journalctl holds the logs; restarting a service means restarting a unit.

Permissions: users, root, sudo

Permissions rest on user and group identifiers: every process carries real, effective and saved IDs, and file access depends on those and its groups. The privileged root account has user ID 0. /etc/passwd is readable by all users because tools map identifiers from it, but only the superuser may write it; password hashes live in a separate, protected file.

root bypasses every permission check, which is why Linux has split the superuser’s traditional privileges into capabilities since 2.2, each granted independently. sudo is the daily tool: it runs a command as another user, usually root, validating the invoking user’s credentials rather than root’s. The policy lives in /etc/sudoers, authorization is cached per terminal for five minutes, and attempts are logged.

• A sudoers mistake is serious. A syntax error can take away privileged access itself, so edits belong in visudo.
• Permissions are the widest surface. Narrow capability sets and service accounts are the workable direction.

Where it fits in our stack

Our hosts run Linux, the workstations stay on Windows. Containers, databases and background services live on that host, wired to the Windows side for agent work. Containers run under Docker, the service layer is held by the init system, automation goes through n8n, and agents are organized around Hermes Agent.

At CyberElectro the server side stands on this layer: Linux hosts, narrow permissions, and updates through the distribution channels.

Further reading

• Active kernel releases - mainline, stable and longterm branches and end of life dates.
• The Linux Kernel documentation - the kernel’s own documentation.
• Linux man pages - the man-pages project, including sudo and systemd.