How to Display a Configuration File Without Empty Lines and Comments in Linux

~ tadmin ~ Leave a comment

When administering Linux servers, you often need to quickly inspect a configuration file while excluding empty lines and comments from the output. This is especially useful when working with large configuration files for Nginx, Apache, MySQL/MariaDB, PHP, SSH, and other services.

For example, instead of scrolling through dozens or hundreds of lines of documentation and commented-out options, you can display only the active configuration.

The Simplest Option with 

grep

For configuration files where comments begin with the 

#

character, you can use:

grep -vE '^[[:space:]]*(#|$)' /etc/example.conf

For example:

grep -vE '^[[:space:]]*(#|$)' /etc/ssh/sshd_config

This command removes:

  • empty lines;
  • lines containing only spaces or tabs;
  • lines beginning with 
    #

    ;

  • comment lines preceded by whitespace.

The 

-v

option inverts the match, so 

grep

displays lines that do not match the specified pattern.

The 

-E

option enables extended regular expressions.

The expression:

^[[:space:]]*(#|$)

can be read as follows: from the beginning of the line, allow any number of whitespace characters, followed either by 

#

or immediately by the end of the line.

Using 

sed

The same result can be achieved with 

sed

:

sed -e '/^[[:space:]]*#/d' -e '/^[[:space:]]*$/d' /etc/example.conf

The first expression removes comment lines:

/^[[:space:]]*#/d

The second removes empty lines and lines containing only whitespace:

/^[[:space:]]*$/d

Using 

awk

Another compact option is:

awk '!/^[[:space:]]*(#|$)/' /etc/example.conf

The result is similar: 

awk

prints only lines that are neither empty nor begin with 

#

.

If Comments Begin with 

;

Some configuration formats, especially INI-style files, use 

;

as the comment character.

In that case:

grep -vE '^[[:space:]]*(;|$)' /path/to/config.ini

If the file may use both 

#

and 

;

for comments:

grep -vE '^[[:space:]]*([#;]|$)' /path/to/config.ini

Viewing a Large Configuration File

If the output does not fit on one screen, you can pipe it to 

less

:

grep -vE '^[[:space:]]*(#|$)' /etc/example.conf | less

On modern Linux systems, 

less

is generally more convenient than 

more

for interactive viewing. It allows you to scroll both forward and backward, search with 

/

, and quickly navigate between matches.

To exit 

less

, press:

q

Why You Should Not Simply Use 

grep -v "#"

An older version of this command often looks like this:

cat /etc/example.conf | sed '/^$/d' | grep -v "#" | more

It works, but it has several drawbacks.

First, 

cat

is unnecessary here because both 

grep

and 

sed

can read files directly.

Second:

grep -v "#"

removes every line containing 

#

, not just comment lines.

For example:

password=my#secret

would also be hidden, even though 

#

may be part of the actual value.

For this reason, it is safer to check specifically for comments at the beginning of a line:

grep -vE '^[[:space:]]*#'

What About Inline Comments?

Suppose a configuration file contains:

Port 22
PermitRootLogin no    # Disable root login
PasswordAuthentication no

The previous commands will keep the second line unchanged because it does not begin with 

#

.

In theory, you can remove inline comments with 

sed

, for example:

sed 's/[[:space:]]#.*$//' /etc/example.conf

However, this approach should be used carefully.

The 

#

character may be part of a valid configuration value:

password="abc#123"

Comment syntax depends on the specific configuration file format. Therefore, blindly removing everything after 

#

is not always safe.

A Practical Command to Remember

For most Unix/Linux configuration files where full-line comments begin with 

#

, this single command is usually enough:

grep -vE '^[[:space:]]*(#|$)' /path/to/config

For larger files:

grep -vE '^[[:space:]]*(#|$)' /path/to/config | less

This is a simple way to quickly inspect active configuration parameters without unnecessary visual noise.

Important: this command only filters the text for easier viewing. It does not determine whether a configuration option is actually active or applied by the service. Configuration files may contain 

include

directives, overridden parameters, conditional sections, or default values. To inspect the effective configuration, use service-specific tools such as 

nginx -T

, 

sshd -T

, 

apachectl -S

, and similar commands.

Happy 35-th Birthday, Linux: The Operating System That Changed the World

~ tadmin

Happy 35-th Birthday Linux: The Operating System That Changed the World — A Story of Linus Torvalds and Open Source Revolution

August 25, 1991, became one of the most important dates in the history of modern computing. On this day, a young Finnish computer science student named Linus Torvalds announced a small personal project that would eventually become the foundation of countless servers, smartphones, supercomputers, and embedded systems around the world.

That project was called Linux.

My very thirst experice working with OS Linux was Red Hat Enterprice server we had with our factory CAD server. It was a new and very intreresting experience from the system administration perspective.

What started as a hobby operating system written by a university student grew into one of the most successful examples of open source collaboration in human history.

The Beginning: A Student Project Becomes a Global Movement

In 1991, Linus Torvalds was studying at the University of Helsinki. He was interested in understanding how operating systems worked and was using MINIX, a small Unix-like operating system created for educational purposes by Andrew Tanenbaum.

However, Linus wanted more control and flexibility. He started developing his own kernel — the core component of an operating system responsible for managing hardware, memory, processes, and communication between software and the machine.

On August 25, 1991, Linus shared a famous message with the MINIX community:

“I’m doing a (free) operating system (just a hobby, won’t be big and professional like GNU)…”

At that moment, nobody could predict how significant this hobby project would become.

The first versions of Linux were simple and limited. They ran only on Intel 386 processors and were mainly interesting to developers and enthusiasts. But the decision to release the source code publicly changed everything.

Linux was not built behind closed doors. Anyone could study the code, modify it, improve it, and share their changes.

That idea became the foundation of the open source movement.

Who Is Linus Torvalds?

Linus Torvalds is a Finnish-American software engineer best known as the creator of the Linux kernel and the original developer of Git.

Unlike many technology founders, Linus did not create Linux as a commercial product. His motivation was curiosity and the desire to build something better for himself.

His development philosophy became famous:

  • Keep the system practical.
  • Prefer simple solutions.
  • Let good engineering decisions win.
  • Allow developers to improve the project through collaboration.

Linus continued leading Linux kernel development for decades, reviewing contributions from thousands of developers around the world.

Today, the Linux kernel contains millions of lines of code and is maintained by a global community that includes individual developers and major technology companies.

Linux Is Everywhere

Many people think Linux is only a server operating system used by programmers. In reality, Linux powers a huge part of the modern digital world.

You probably interact with Linux every day without realizing it.

Servers and Cloud Infrastructure

Most internet services run on Linux servers.

Websites, APIs, databases, cloud platforms, and enterprise systems rely heavily on Linux because it provides:

  • stability;
  • security;
  • flexibility;
  • excellent performance;
  • powerful automation capabilities.

Companies such as Google, Amazon, Microsoft, and countless others use Linux extensively in their infrastructure.

Android Smartphones

The Android operating system is built on top of the Linux kernel.

Billions of smartphones around the world use Linux-based technology every day.

Supercomputers

For many years, almost all of the world’s fastest supercomputers have used Linux because of its performance, customization possibilities, and scalability.

Embedded Devices and IoT

Linux runs inside:

  • routers;
  • smart TVs;
  • industrial systems;
  • automotive systems;
  • security devices;
  • Internet of Things platforms.

The flexibility of Linux makes it suitable for almost any type of hardware.

Why Linux Became So Successful

The success of Linux was not only about technology. It was also about philosophy.

Traditional software development often followed a closed model: companies created software internally and users received only the finished product.

Linux introduced a different approach:

Thousands of people can collaborate on the same project, improve it, find bugs, and create solutions together.

This model demonstrated that open collaboration can compete with — and sometimes outperform — traditional proprietary development.

Linux also inspired many other successful open source projects:

  • Apache Web Server;
  • PostgreSQL;
  • Kubernetes;
  • Docker;
  • Git;
  • countless programming languages and frameworks.

Linux and Developers

For many developers, Linux is more than an operating system. It is a learning environment.

Working with Linux teaches important engineering skills:

  • understanding how computers actually work;
  • managing servers;
  • automating tasks with shell scripts;
  • debugging complex problems;
  • understanding networking;
  • building secure systems.

Linux encourages curiosity. It gives developers the ability to look under the hood and understand every layer of the system.

The Linux Philosophy

One of the most beautiful things about Linux is that it represents a different idea about technology.

Software does not have to be a mysterious black box.

People can learn from it.
People can improve it.
People can build something together.

Linux proves that a simple idea shared with the world can grow into something much bigger than its creator originally imagined.

A small project created by a student in Finland became the foundation of modern computing.

Happy Birthday, Linux! 🎂

Today we celebrate not only an operating system but also the people and values behind it.

Linux represents curiosity, collaboration, freedom, and the power of open source.

Thank you, Linus Torvalds, for starting this incredible journey.

And thank you to millions of developers, maintainers, administrators, and enthusiasts who continue improving Linux every day.

The world of technology would look completely different without Linux.

Happy 35-th, Linux O.S. Birthday! 🐧

What does sed -n ‘BEGIN,ENDp’ /path/to/file.txt Linux shell command do?

~ tadmin

🐧 What does this Linux command do?

sed -n 'BEGIN,ENDp' /path/to/file.txt

At first glance, it looks simple. But this small command can save a lot of time when working with logs and large text files.

Let’s break it down:

  • sed

    — a stream editor for processing text;

  • -n

    — disables automatic output of every line;

  • BEGIN,END

    — defines the range of lines to process;

  • p

    — prints only the selected lines.

Example:

sed -n '100,150p' application.log

This will print only lines from 100 to 150 of the log file.

You can also use text patterns:

sed -n '/ERROR BEGIN/,/ERROR END/p' application.log

This extracts everything between two markers:

ERROR BEGIN
...
ERROR END

A very useful technique when you need to quickly inspect a specific part of a huge log file without opening it in an editor.

For example:

  • debugging production issues;
  • analyzing application errors;
  • investigating server logs;
  • checking deployment output.

Small Linux commands are often the tools that make engineers faster.

Do you use 

sed

in your daily workflow? 👨‍💻

🎥 Watch the video tutorial on YouTube

If you’d like to see these sed examples demonstrated
on a real Linux system, watch my full YouTube tutorial.

Subscribe to my Linux Tutorials YouTube channel.

PHP 31-th Anniversary — A Quick Look at the Evolution of the Language Code from Version 7.4 to 8.4

~ tadmin

🎉 PHP 31-th Anniversary — A Quick Look at the Evolution of the Language from 7.4 to 8.4

PHP has come a long way — from a simple scripting tool to a powerful modern language with JIT, async capabilities, enums, readonly classes, and property hooks.
Today, on June 8, 2026, (31-th PHP programming language birthday) the anniversary of PHP’s creation, let’s take a look at how the language has evolved over the last seven years, and what features were introduced in each version.

🟦 PHP 8.4 — Property Hooks, Async, Immutable Classes

PHP 8.4 (2024) became one of the most innovative releases in recent years.

Key features:

  • Property hooks (getters/setters directly in property declarations)
  • Async functions — native asynchronous support
  • Standalone null/true/false types
  • Improved DOM API
  • Immutable classes (an extension of the readonly concept)

✔ Example: Property Hooks

class Locale {
    public string $countryCode {
        set(string $value) {
            $this->countryCode = strtoupper($value);
        }
    }

    public string $combinedCode {
        get => "{$this->languageCode}_{$this->countryCode}";
        set(string $value) {
            [$this->languageCode, $this->countryCode] = explode('_', $value);
        }
    }

    public function __construct(
        public string $languageCode,
        public string $countryCode
    ) {}
}

$loc = new Locale('uk', 'ua');
$loc->countryCode = 'pl'; // PL
echo $loc->combinedCode;  // uk_PL

🟩 PHP 8.3 — Typed Class Constants, Granular Exceptions

PHP 8.3 (2023) is a stabilization release, but still an important one.

Key features:

  • Typed class constants
  • Granular DateTime exceptions
  • Fallback values for environment variables in INI

✔ Typed Class Constants

class Status {
    public const string ACTIVE = 'active';
    public const string BLOCKED = 'blocked';
}

🟧 PHP 8.2 — Readonly Classes, DNF Types, New Random API

PHP 8.2 (2022) made the language significantly stricter and more robust.

Key features:

  • Readonly classes
  • DNF types (Disjunctive Normal Form types)
  • true/false/null as standalone types
  • New Random API

✔ Readonly Class

readonly class UserData {
    public function __construct(
        public string $name,
        public int $age
    ) {}
}

$user = new UserData('Taras', 30);
// $user->name = 'Ivan'; // Fatal error

🟨 PHP 8.1 — Enums, Fibers, Readonly Properties

PHP 8.1 (2021) is one of the most important releases of the decade.

Key features:

  • Enums
  • Fibers (foundation for async)
  • Readonly properties
  • Intersection types
  • never type

✔ Enums

enum Status: string {
    case Draft = 'draft';
    case Published = 'published';
}

function publish(Status $status) {
    if ($status === Status::Draft) {
        echo "Publishing...";
    }
}

🟦 PHP 8.0 — JIT, Union Types, Match, Named Arguments

PHP 8.0 (2020) was a revolutionary release.

Key features:

  • JIT compilation
  • Union types
  • Match expression
  • Named arguments
  • Constructor property promotion

✔ Match Expression

$status = 'pending';

$message = match ($status) {
    'pending' => 'Waiting...',
    'done'    => 'Completed!',
    default   => 'Unknown',
};

🟫 PHP 7.4 — Typed Properties, Arrow Functions

PHP 7.4 (2019) — the final release of the 7.x branch.

Key features:

  • Typed properties
  • Arrow functions
  • Null‑coalescing assignment (??=)
  • OpCache improvements

✔ Arrow Function

$numbers = [1, 2, 3];
$squares = array_map(fn($n) => $n * $n, $numbers);

📌 Feature Comparison Table

Version Key Features
PHP 8.4 Property hooks, async, immutable classes
PHP 8.3 Typed constants, granular exceptions
PHP 8.2 Readonly classes, DNF types, Random API
PHP 8.1 Enums, Fibers, readonly properties
PHP 8.0 JIT, union types, match, named args
PHP 7.4 Typed properties, arrow functions

🎯 Conclusion

Over the past years, PHP has transformed into a modern, type‑safe, high‑performance language with async support, strict typing, enums, readonly structures, and JIT.
It is no longer the “old PHP,” but a fully capable language for high‑load systems, microservices, and complex domain models.

Gates vs Policies in Laravel: What’s the Difference and When Should You Use Each?

~ tadmin

Laravel provides two main mechanisms for handling authorization: Gates and Policies. Both determine whether a user is allowed to perform a specific action — but they serve different purposes, scale differently, and fit different architectural needs.

In this post, we’ll break down the differences, show real PHP examples, and give practical guidance on when to use each tool.

What Is a Gate?

A Gate is essentially a simple closure‑based authorization check.
It returns 

true

or 

false

and is not tied to any specific model.

Gates are perfect for global permissions or one‑off checks.

Example: Allow only admins to access the admin panel

app/Providers/AuthServiceProvider.php

use Illuminate\Support\Facades\Gate;

public function boot()
{
    Gate::define('view-admin-panel', function ($user) {
        return $user->role === 'admin';
    });
}

Using a Gate in a controller

public function index()
{
    Gate::authorize('view-admin-panel');

    return view('admin.dashboard');
}

Using a Gate in Blade

@can('view-admin-panel')
<a href="/admin">Admin Panel</a>
@endcan

When Gates make sense

  • The permission is not tied to a model
  • The logic is simple
  • You need one or two checks, not a whole system

What Is a Policy?

A Policy is a dedicated class that contains authorization logic for a specific model.
It’s structured, scalable, and ideal for CRUD‑style permissions.

Creating a Policy

php artisan make:policy PostPolicy --model=Post

Example 

PostPolicy

class PostPolicy
{
    public function view(User $user, Post $post)
    {
        return true; // anyone can view
    }

    public function update(User $user, Post $post)
    {
        return $user->id === $post->user_id;
    }

    public function delete(User $user, Post $post)
    {
        return $user->id === $post->user_id;
    }
}

Registering the Policy (if Laravel doesn’t auto‑discover it)

protected $policies = [
    Post::class => PostPolicy::class,
];

Using a Policy in a controller

public function update(Request $request, Post $post)
{
    $this->authorize('update', $post);

    $post->update($request->all());
}

Using a Policy in Blade

@can('update', $post)
<button>Edit</button>
@endcan

When Policies make sense

  • The permission is tied to a specific model
  • You have multiple actions (view, create, update, delete)
  • The project is large and needs structure

Gates vs Policies: Side‑by‑Side Comparison

Feature Gates Policies
Model‑specific ❌ No ✅ Yes
Scalability Low High
Structure Single functions Organized class
Best for Global checks CRUD permissions
Typical use case Admin panel access Managing posts, orders, invoices

When Gates Are a Bad Fit

Avoid Gates when:

  • You have many checks for the same model
  • Authorization logic is growing
  • You start duplicating conditions across controllers

At that point, a Policy is the right tool.

When Policies Are Overkill

Avoid Policies when:

  • You only need one simple check
  • The permission is not related to a model
  • You don’t need a whole class for a single rule

In those cases, a Gate is perfect.

Real‑World Example: Using Both Together

Imagine a blog system:

  • Gate: access to the admin dashboard ( 
    view-admin-panel

    )

  • Policy: permissions for managing posts ( 
    PostPolicy

    )

This is the recommended pattern:

  • Global actions → Gates
  • Model actions → Policies

Conclusion

Laravel gives you two powerful authorization tools — and each has a clear purpose.

  • Gates are simple, global, and great for quick checks.
  • Policies are structured, scalable, and ideal for model‑based permissions.

If your project grows, Policies will keep your authorization logic clean and maintainable.
If you just need a quick global rule, a Gate is the fastest solution.

🔍 Do You need help with Laravel, web applications architecture or PHP code?

I help businesses and developers:

  • to find solutions for a complex business logic;
  • to improve system’s architecture (Laravel / PHP);
  • to identify and eliminate performance bottlenecks.

(online, one-on-one, hands-on)

How to Create a tar+bzip2 Website Archive While Ignoring VCS Folders (.git and others)

~ tadmin

🗄️ How to Create a tar+bzip2 Website Archive While Ignoring VCS Folders (.git and others)

When backing up web projects, you often need to create a compact archive without including version‑control system directories such as .git, .svn, .hg, or .bzr.
These folders can take up hundreds of megabytes and are completely unnecessary in a production backup.

On Linux, this is very easy — you just need to use
tar
with the
–exclude-vcs
option.

🔍 Why You Should Exclude VCS Directories

Folders like

.git/

contain:

  • full commit history
  • temporary files
  • caches
  • internal indexes

As a result:

  • your archive becomes 5–20× larger than needed
  • you waste storage space
  • backup creation and transfer take longer

For production backups, it’s best to leave them out.

🧰 The

–exclude-vcs

Option in tar

GNU Tar provides a special option:

--exclude-vcs

It automatically excludes all standard version‑control directories:

  • .git
  • .svn
  • .hg
  • .bzr
  • _darcs
  • CVS

This is the most convenient way to create a clean archive.

🧩 Example: Creating a tar.bz2 Website Archive Without VCS Folders

Let’s say your website is located at:

/home/taras/websites/shkodenko.com/

You want to create an archive in your home directory under

_backups

, with a timestamp in the filename.

✔️ Ready‑to‑use command:

cd /home/taras/websites/shkodenko.com/
tar --exclude-vcs -cpjf ~/_backups/_shkodenko.com__no_vcs__$(date +'%Y-%m-%d_%H-%M').tar.bz2 ./

What this command does:

  • cd ...

    — moves into the website root

  • tar

    — runs the archiver

  • --exclude-vcs

    — excludes all VCS directories

  • -c

    — create an archive

  • -p

    — preserve file permissions

  • -j

    — use bzip2 compression (better than gzip)

  • -f

    — specify the output filename

  • $(date +'%Y-%m-%d_%H-%M')

    — adds date and time to the filename

  • ./

    — archives the current directory

The resulting file will look like:

_shkodenko.com__no_vcs__2026-05-03_15-20.tar.bz2

📦 Why bzip2?

tar.bz2

archives usually:

  • compress better than gzip ( 
    .tar.gz

    )

  • work slower, but produce smaller files

For website backups, this is often the ideal choice.

🧪 Verifying the Archive

List archive contents:

tar -tjf archive.tar.bz2

Extract the archive:

tar -xpjf archive.tar.bz2

📝 Conclusion

Creating a clean website backup without

.git

and other VCS directories is simple.
Just use

tar

with the

--exclude-vcs

option, and you’ll get a neat, compact, and production‑ready archive.

🐳 Basic Docker Workflow Using PHP + MySQL + Laravel

~ tadmin

Docker has become a standard tool for local development: it isolates environments, makes projects reproducible, and eliminates the classic “works on my machine” problem. In this post, I’ll walk you through a basic Docker workflow using a simple PHP + MySQL + Laravel stack.

🎯 What We Want to Achieve

  • A PHP container (e.g., PHP 8.2) to run Laravel
  • A MySQL container
  • An optional but recommended Nginx container
  • A single 
    docker-compose.yml

    to orchestrate everything

  • A minimal set of commands for daily development

📦 Project Structure

A typical structure looks like this:

project/
 ├─ src/              # Laravel project
 ├─ docker/
 │   ├─ php/
 │   │   └─ Dockerfile
 │   └─ nginx/
 │       └─ default.conf
 └─ docker-compose.yml

⚙️ PHP Dockerfile

docker/php/Dockerfile

:

FROM php:8.2-fpm

RUN apt-get update && apt-get install -y \
git zip unzip curl libpq-dev libzip-dev \
&& docker-php-ext-install pdo pdo_mysql zip

COPY –from=composer:2 /usr/bin/composer /usr/bin/composer

WORKDIR /var/www/html

This gives you a minimal PHP-FPM image with Composer and required extensions.

🗄️ MySQL Configuration

Inside 

docker-compose.yml

:

services:
  mysql:
    image: mysql:8.0
    container_name: mysql
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: laravel
      MYSQL_USER: laravel
      MYSQL_PASSWORD: secret
    ports:
      - "3306:3306"
    volumes:
      - db_data:/var/lib/mysql

🌐 Nginx Configuration

docker/nginx/default.conf

:

server {
listen 80;
root /var/www/html/public;

index index.php index.html;

location / {
try_files $uri $uri/ /index.php?$query_string;
}

location ~ \.php$ {
fastcgi_pass php:9000;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
}

🧩 docker-compose.yml

version: '3.8'

services:
  php:
    build:
      context: .
      dockerfile: docker/php/Dockerfile
    container_name: php
    volumes:
      - ./src:/var/www/html
    depends_on:
      - mysql

  nginx:
    image: nginx:latest
    container_name: nginx
    ports:
      - "8080:80"
    volumes:
      - ./src:/var/www/html
      - ./docker/nginx/default.conf:/etc/nginx/conf.d/default.conf
    depends_on:
      - php

  mysql:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: laravel
      MYSQL_USER: laravel
      MYSQL_PASSWORD: secret
    volumes:
      - db_data:/var/lib/mysql

volumes:
  db_data:

🚀 Starting the Project

1. Create a Laravel project

docker compose run --rm php composer create-project laravel/laravel .

2. Start all containers

docker compose up -d

3. Check in the browser

http://localhost:8080

🔄 Basic Daily Workflow

1. Install dependencies

docker compose exec php composer install

2. Run migrations

docker compose exec php php artisan migrate

3. Run Artisan commands

docker compose exec php php artisan tinker

4. View logs

docker compose logs -f php
docker compose logs -f nginx
docker compose logs -f mysql

5. Restart a service

docker compose restart php

🧹 Useful Tips

  • Don’t install PHP, MySQL, or Nginx locally — Docker replaces all of them.
  • Keep configs in separate files ( 
    docker/php/Dockerfile

    , 

    docker/nginx/default.conf

    ) for easier maintenance.

  • Use a volume for MySQL to avoid losing data.
  • Run Composer inside the container, not on your host machine.

🎉 Conclusion

This basic stack is a great starting point for any PHP/Laravel project. It’s simple, transparent, and easy to extend: Redis, Horizon, Queue Workers, Mailhog — all of these can be added with just a few lines in 

docker-compose.yml

.

🎉 Happy Birthday, Linus Torvalds!

~ tadmin

🎉 Happy Birthday, Linus Torvalds!

Today we celebrate the birthday of a person whose ideas quietly reshaped the digital world. Linus Torvalds didn’t just write code — he changed how software is built, shared, and trusted.

This short post is both a birthday greeting and a compact journey through the history of Linux and Git — two pillars of modern computing.

🐧 A Brief History of Linux

In 1991, a Finnish computer science student named Linus Torvalds started a personal project: a free Unix-like operating system kernel for his own PC. He shared it online with a simple message that would become legendary:

“I’m doing a (free) operating system (just a hobby, won’t be big and professional like GNU)…”

That “hobby” became Linux.

Why Linux mattered

  • Open source by design – anyone could read, modify, and improve the code
  • Community-driven development – merit over hierarchy
  • Portability and stability – from servers to smartphones

Over time, Linux evolved from a kernel into the foundation of:

  • Most of the internet’s servers
  • Android smartphones
  • Cloud platforms, containers, DevOps tooling
  • Embedded systems, routers, supercomputers

Linux proved that open collaboration could outperform closed, proprietary models — at global scale.

🌱 From Kernel Chaos to Git

By the early 2000s, Linux had thousands of contributors. Managing kernel development became a serious technical challenge.

After losing access to a proprietary version control system in 2005, Linus did what he does best:

he built a new tool — Git — in a matter of weeks.

Git’s core ideas (revolutionary at the time)

  • Distributed version control (no single point of failure)
  • Fast and local operations
  • Integrity via cryptographic hashes
  • Branching as a first-class citizen

Git was not designed to be “user-friendly.”

It was designed to be correct, fast, and scalable — and it succeeded.

Today, Git is the backbone of:

  • GitHub, GitLab, Bitbucket
  • Open-source collaboration worldwide
  • CI/CD pipelines and modern DevOps workflows

🔧 One Mindset, Two Revolutions

Linux and Git share a common philosophy:

  • Tools should be simple at the core
  • Systems should scale with human collaboration
  • Trust the community, but verify with strong technical guarantees

Linus Torvalds showed that engineering excellence and pragmatic thinking can beat hype, bureaucracy, and complexity.

🙌 Thank You, Linus

On your birthday, the global tech community says thank you — for:

  • Empowering developers
  • Democratizing software
  • Proving that open source can power the world

Happy Birthday, Linus.

Your “just a hobby” changed everything.

 

If you enjoy deep dives into Linux, Git, and backend engineering — you’re in the right place 🚀

Role-Based Access Control (RBAC) in Modern Laravel

~ tadmin

A Practical Guide for PHP & Back-End Developers

Modern Laravel applications almost always serve multiple user roles: administrators, managers, editors, customers, API clients, and more.
Hard-coding access checks quickly turns into a maintenance nightmare.

That’s why Role-Based Access Control (RBAC) remains one of the most effective and scalable authorization models — especially in Laravel-based backends.

This article is a hands-on guide to implementing RBAC in modern Laravel, focusing on:

  • clean architecture
  • real database migrations
  • practical authorization checks
  • security best practices

What Is RBAC (Quick Recap)

RBAC is an authorization model where:

User → Role → Permissions
  • A user has one or more roles
  • A role groups permissions
  • A permission represents a single allowed action

Instead of checking who the user is, the system checks what they are allowed to do.

Why RBAC Fits Laravel So Well

Laravel’s architecture aligns naturally with RBAC:

  • Middleware for route-level protection
  • Policies for domain-level rules
  • Gates for fine-grained permissions
  • Cache-friendly authorization checks
  • Clean separation from business logic

RBAC also integrates well with:

  • REST APIs
  • SPA backends
  • Admin panels
  • Multi-tenant systems

RBAC Data Model (Laravel-Friendly)

Core Tables

We’ll use a classic, explicit schema — no magic, easy to reason about.

users
roles
permissions
role_user
permission_role

Database Migrations

Roles Table

Schema::create('roles', function (Blueprint $table) {
    $table->id();
    $table->string('name')->unique(); // admin, editor, manager
    $table->string('description')->nullable();
    $table->timestamps();
});

Permissions Table

Schema::create('permissions', function (Blueprint $table) {
    $table->id();
    $table->string('name')->unique(); // posts.create, users.manage
    $table->string('description')->nullable();
    $table->timestamps();
});

Pivot: role_user

Schema::create('role_user', function (Blueprint $table) {
    $table->foreignId('user_id')->constrained()->cascadeOnDelete();
    $table->foreignId('role_id')->constrained()->cascadeOnDelete();
    $table->primary(['user_id', 'role_id']);
});

Pivot: permission_role

Schema::create('permission_role', function (Blueprint $table) {
    $table->foreignId('permission_id')->constrained()->cascadeOnDelete();
    $table->foreignId('role_id')->constrained()->cascadeOnDelete();
    $table->primary(['permission_id', 'role_id']);
});

Eloquent Models & Relationships

User Model

class User extends Authenticatable
{
    public function roles()
    {
        return $this->belongsToMany(Role::class);
    }

    public function hasRole(string $role): bool
    {
        return $this->roles->contains('name', $role);
    }

    public function canDo(string $permission): bool
    {
        return $this->roles->flatMap->permissions
            ->contains('name', $permission);
    }
}

Role Model

class Role extends Model
{
    protected $fillable = ['name', 'description'];

    public function permissions()
    {
        return $this->belongsToMany(Permission::class);
    }
}

Permission Model

class Permission extends Model
{
    protected $fillable = ['name', 'description'];
}

Authorization via Gates (Laravel Way)

Define permissions once — use them everywhere.

AuthServiceProvider

public function boot()
{
    Gate::before(function (User $user, string $ability) {
        return $user->canDo($ability) ?: null;
    });
}

Now Laravel automatically resolves:

$user->can('posts.update');

Route Protection with Middleware

Route::middleware('can:users.manage')->group(function () {
    Route::resource('users', UserController::class);
});

✔️ Clean
✔️ Declarative
✔️ Easy to audit

RBAC with Policies (Recommended)

PostPolicy Example

class PostPolicy
{
    public function update(User $user, Post $post): bool
    {
        return $user->can('posts.update');
    }

    public function delete(User $user, Post $post): bool
    {
        return $user->can('posts.delete');
    }
}

Usage in controller:

$this->authorize('update', $post);

This keeps authorization logic out of controllers.

Seeding Roles & Permissions

Seeder Example

$admin = Role::create(['name' => 'admin']);
$editor = Role::create(['name' => 'editor']);

$permissions = [
    'posts.create',
    'posts.update',
    'posts.delete',
    'users.manage',
];

foreach ($permissions as $perm) {
    Permission::create(['name' => $perm]);
}

$admin->permissions()->sync(Permission::all());
$editor->permissions()->sync(
    Permission::whereIn('name', ['posts.create', 'posts.update'])->get()
);

Performance: Cache Permissions

Authorization runs a lot.

Best practice:

  • Eager load roles & permissions on login
  • Cache permission lookups
  • Invalidate cache on role updates

Example:

Cache::remember(
    "user_permissions_{$user->id}",
    now()->addHour(),
    fn () => $user->roles->flatMap->permissions->pluck('name')
);

Common RBAC Mistakes in Laravel

❌ Checking roles directly in controllers
❌ Mixing authentication with authorization
❌ Using role names in business logic
❌ Not testing policies
❌ No audit trail for permission changes

When RBAC Alone Is Not Enough

RBAC answers “can the user do X?”
It does NOT answer:

  • Does the user own this resource?
  • Is this allowed at this time?
  • Is this allowed in this context?

Combine RBAC with policy conditions:

$user->can('posts.update') && $post->author_id === $user->id

Final Thoughts

RBAC in Laravel is not about libraries — it’s about clean architecture.

A well-designed RBAC system gives you:

  • Predictable security
  • Clean controllers
  • Scalable authorization
  • Confidence during audits

If you’re building serious backend systems, RBAC is not optional — it’s foundational.

New Digital Product: Creational Design Patterns (GoF) for Modern PHP Developers

~ tadmin

Over the years of working with PHP — from small scripts to large production systems — I’ve noticed one recurring issue:
object creation logic tends to get messy very quickly.

At first, everything looks simple:

$user = new User();

But as applications grow, this turns into:

  • too many new operators scattered across the codebase
  • tight coupling between classes
  • complex constructors with many dependencies
  • code that’s hard to test and even harder to change

This is exactly the problem space where creational design patterns shine.

Why Creational Design Patterns Matter

Creational design patterns help answer fundamental questions:

  • Who should be responsible for creating objects?
  • How can we decouple business logic from instantiation?
  • How do we create complex objects without unreadable constructors?
  • How do we keep code flexible and testable as requirements change?

These patterns are part of the classic Gang of Four (GoF) catalog and remain highly relevant today — especially for PHP developers working with frameworks, DI containers, and layered architectures.

What I’ve Created

I’ve just released a new digital guide:

Creational Design Patterns (GoF):
A Practical Guide for Modern PHP Developers

This is a concise, practical guide focused on understanding and applying the five GoF creational patterns:

  • Factory Method
  • Abstract Factory
  • Builder
  • Prototype
  • Singleton (including when not to use it)

The goal of this guide is simple:

Help PHP developers understand when and why to use these patterns — not just how to implement them.

What’s Inside the Guide

✔ Clear explanations without unnecessary theory
✔ Modern PHP-oriented examples
✔ Real-world context (not academic diagrams only)
✔ Decision guidance: use it / don’t use it
✔ Clean structure suitable for learning or quick reference

The product includes:

  • 📘 PDF version (ready to read and share)
  • 📝 Markdown source files (editable, reusable, future-proof)

Delivered as a ZIP bundle.

Who This Is For

This guide is useful if you are:

  • a junior or middle PHP developer building architectural foundations
  • a senior developer or team lead mentoring others
  • preparing for technical interviews
  • trying to write cleaner, more testable PHP code
  • working with frameworks like Laravel, Symfony, or custom architectures

Where to Get It

You can find the product here:

👉 https://ko-fi.com/s/e4858bc015

If you decide to check it out — feedback is always welcome.
This kind of work evolves best through real developer experience and discussion.