DEV Community: Altair Lage

35 years of Linux!

Altair Lage — Mon, 31 Aug 2026 14:18:47 +0000

On 25 August 1991, Linus Torvalds announced a new operating-system project, describing it as “just a hobby, won’t be big and professional”.

Years later, Linux has become one of the most important foundations of modern IT infrastructure. It runs servers, cloud platforms, data centers, embedded systems, billions of smartphones, and many of the services companies around the world depend on every day.

I am personally grateful for Linux. Knowing Linux was the differential that enabled me to find work and take on new roles at the beginning of my career. For me, it is not only the interface I use every day on my computer, but also a reliable companion throughout my professional journey. Wherever I go, it is there, enabling me to do my best work.

Thank you, Linux!

How to explain your PM adding more devs won't make everything faster

Altair Lage — Tue, 21 Jul 2026 15:11:47 +0000

This is for sure a joke, I think the market has already moved beyond that idea: Adding more developers doesn’t automatically make software development faster.
New team members need context, onboarding, support, and time to understand the codebase. More developers also mean more communication, coordination, reviews, dependencies, processes, and the more important: MORE MANAGEMENT.
More people can increase capacity, but only with the right planning, architecture, and timing.
Also, I believe some tasks simply can’t be split.

Now that AI is part of the development process, the equation is even more complex. AI can improve productivity, but it doesn’t replace technical judgment, clear requirements, good architecture, or effective teamwork.
Speed still doesn't mean just about adding more people. It’s about creating the right environment for the team to deliver.

Docker vs Podman

Altair Lage — Tue, 21 Jul 2026 15:06:44 +0000

When we talk about containers, Docker is still the most well-known tool in the market. However, in recent years, many companies have started evaluating Podman as an alternative, mainly due to licensing, governance, and security concerns.

Docker remains free for personal use, education, open-source projects, and small businesses. However, larger organizations need paid Docker Desktop subscriptions to stay compliant with licensing requirements.

Podman, on the other hand, is a fully open-source project, maintained by the community and Red Hat, with no need for commercial licenses for its use.

Key differences:
Docker
• Mature ecosystem
• Widely adopted by the market
• Docker Desktop with a graphical interface
• Commercial licensing for certain companies
• Daemon-based architecture using dockerd

Podman
• 100% open source
• No licensing costs
• Daemonless architecture, with no central service
• Rootless execution by default, improving security
• Compatible with Docker commands in most cases

Both use images compatible with OCI, the Open Container Initiative.

When should you consider Podman?

Corporate environments with licensing restrictions
Organizations that prioritize open-source software
Environments with high security requirements
Linux servers where a graphical interface is not required
In the end, both solve the problem of packaging and running applications very well. The choice depends more on governance, compliance, cost, and security requirements than on the technology itself.

JWT (JSON Web Token) flow

Altair Lage — Tue, 21 Jul 2026 15:04:39 +0000

Authentication and authorization are the foundation of modern web security. They prove who a user is and ensure they can only access what they are allowed to.

The traditional session-based authentication stored this login information in servers. While this worked well for simple websites, it became slow and complicated when apps grew to use multiple servers, as sharing that session data across them was difficult.

JSON Web Tokens (JWTs) solve this by being stateless and self-contained. A JWT acts like a digital ID card that carries all the user's information inside it, so servers can instantly verify the user without needing to constantly check a database.

Today, JWTs are the standard way to identify logged-in users, issued by a login server and checked by your APIs or frontend apps.

Authentication and authorization are the foundation of modern web security. They ensure that users are who they claim to be and that they can only access resources they are allowed to.

Traditional session-based authentication stores user information on the server. While this worked well for early monolithic apps, it introduced scaling challenges in distributed systems, where maintaining session state across multiple servers or microservices quickly became complex and inefficient.

JSON Web Tokens (JWTs) solve this by being stateless, self-contained, and easily verifiable. A JWT acts like a digital ID card that carries all the user's information inside it, eliminating the need for frequent database lookups and enabling fast, scalable authentication across APIs, mobile apps, and microservices.

JWTs are most commonly used to identify authenticated users, issued by an authentication server and consumed by your APIs or frontend applications.

A JWT is a standard for authentication and information exchange defined by RFC 7519. It allows for the secure and compact storage of JSON objects. This token is a Base64-encoded string and can be signed using a secret or a public/private key pair.

RabbitMQ vs Kafka

Altair Lage — Wed, 08 Jul 2026 19:53:07 +0000

RabbitMQ and Kafka are frequently compared as similar systems, but they are not interchangeable tools.

Both were designed to handle the communication between systems, but they solve different architectural problems.

RabbitMQ is a great fit when you need reliable message delivery, low latency, routing flexibility, and task distribution between services.

Kafka is better when you need high throughput, event retention, replayability, real-time analytics, and scalable event streaming.

A simple way to think about it:

RabbitMQ delivers messages.
Kafka stores and distributes events.

Choosing the right one depends less on popularity and more on the problem your system needs to solve.

Examples:

RabbitMQ:
Order processing in an e-commerce system, or Sending e-mails asynchronously.

Kafka:
Tracking clicks on a website, Tracking delivery status, or Saving payment events.

Programming languages and their IDEs

Altair Lage — Mon, 01 Jun 2026 19:48:34 +0000

Choosing the right IDE/editor can make your development workflow faster, cleaner, and more productive.

Of course these are not the only options. Many developers use different editors depending on their project, workflow, team standards, and personal preference.

The best IDE is the one that helps you code better.

Which language and IDE/editor do you use the most?

Docker Compose: Speed Up Your Workflow with Profiles, Extends, and Depends_on

Altair Lage — Fri, 08 May 2026 20:53:10 +0000

If you are reading this article, probably you have already found yourself wrestling with a docker-compose.yml file.

Whether you are a backend developer, DevOps engineer, cloud engineer, or just getting started with Docker, it is common for Docker Compose to become more challenging in day-to-day work as a project grows. Maybe you have services that are only needed occasionally, like debugging or testing tools, repeated configuration across different services, or errors caused by one container starting before another one is actually ready.

Fortunately, Docker Compose provides advanced features to help with these scenarios and make your development environment more organized and flexible. Three of the main features are profiles, extends, and depends_on. That is what we will explore in this article.

In this article, we will look at each of these features with explanations and practical examples. You will learn how to use profiles to enable or disable optional services when needed, extends to prevent redundancy and repeated code by following the DRY principle (Don’t Repeat Yourself) and depends_on to manage the container startup sequence.

We will also cover a few best practices and how these features can simplify the workflow of development teams.

Profiles: Controlling Optional Services

In many projects, besides the main services, such as your web application and database, there are auxiliary services used only in specific situations, like an integration testing container, a monitoring tool, or a debugging utility. Including all these services in your Docker Compose file and starting them every time can waste resources and time. This is where Docker Compose profiles come in.

The profiles feature allows you to enable services selectively. We can assign one or more profiles to specific services, making them start only when the corresponding profile is enabled. Services without a defined profile always start by default, while services assigned to a profile only start when you explicitly request that profile. This is excellent for keeping both essential services and optional debugging, testing, or tooling services in the same Docker Compose file, without having them running all the time.

Imagine you have a main application and a database that should always run in development, but you also have a container for running integration tests and another one for a fake SMTP server, used to capture emails in development. These extra services are not essential. We can mark them as optional:

version: "3.9"  
services:  
  app:  
    image: my-application:1.0  
    # ... (web application settings, ports, volumes, etc.) Example:  
    # ports:  
    #   - "8000:8000"  
    # depends_on:  
    #   - db  

  db:  
    image: postgres:15  
    environment:  
      - POSTGRES_DB=mydatabase  
      - POSTGRES_USER=user  
      - POSTGRES_PASSWORD=password  
    # Database service always required during development  

  tests_runner:  
    image: my-tests:latest  
    profiles: ["test"]  
    # Non-essential service for running integration tests on demand  

  mailhog:  
    image: mailhog/mailhog  
    profiles: ["devtools"]  
    # Optional service for capturing and viewing emails sent by the app in development

In the YAML above, app and db do not have a profile, so they will always be started. tests_runner, on the other hand, is associated with the "test" profile, and mailhog with the "devtools" profile. This means that, by default, these two services are not executed unless you explicitly specify them.

In practice, you can control this through the Docker Compose command line:

Running docker compose up without profiles would start only the default services: app and db.
Running docker compose --profile test up would start app, db, and also the tests_runner service, because the test profile was enabled.
Running docker compose --profile devtools up would start app, db, and mailhog. You can also enable multiple profiles at once, for example: docker compose --profile test --profile devtools up to include both, or use docker compose --profile "*" to start all services from all profiles.

This way, profiles allow you to keep a single Docker Compose file with everything your project may need, while turning services on or off depending on the situation. This makes your development environment lighter and faster for everyday work. For example, one team member may run docker compose up and focus only on the essentials, while another, debugging a specific problem, may enable the devtools profile to inspect detailed logs or capture emails.

Important best practices:

Do not put your main containers inside a profile. Leave them without a profile so they always start by default. Reserve profiles for optional components or scenario-specific services, such as testing, debugging, monitoring, and so on.

Name profiles clearly: Choose names that make their purpose obvious, such as test, dev, debug, monitoring, or ci. Avoid generic terms so everyone on the team understands when to use them. Document the available profiles and how to enable them in the project README.

Reusing Configuration with extends and Removing Repetition

As your Docker Compose configuration grows, you may notice that several services share common settings. For example, imagine we have two services inside a web application: a web service and a background processing worker service. Both use the same base image, mount the same volume, and need the same environment variables, such as database connection strings, credentials, and so on. Repeating identical configuration blocks for each service makes the Compose file longer, more repetitive, and harder to maintain. Every change requires editing multiple places, which goes against the DRY (Don’t Repeat Yourself) principle.

To avoid duplication, Docker Compose allows you to extend common configuration across services. The extends feature works like inheritance: you define a base service, which may even live in another file, with the shared options, and then other services “inherit” that base while overriding or adding parameters as needed. In YAML, we can also use anchors and aliases to achieve a similar effect in a simple way inside the same file.

Example

We have two services, web and worker, which share a large part of their configuration. Let’s create a reusable base configuration and apply it to both.

# We define a YAML anchor with the shared settings  
x-base-service: &common_config    
  image: my-application:1.0  
  volumes:  
    - .:/app  # mounts the current directory into the container (useful for development)  
  environment:  
    - DATABASE_URL=postgres://user:password@db:5432/mydatabase  
  restart: "always"  
  # ... (any other shared option, e.g., network, log settings, etc.)  

services:  
  web:  
    <<: *common_config      # Imports all settings defined in common_config  
    command: npm start     # Specific command to run the web application  
    depends_on:  
      - db                 # (example: web depends on db being running)  

  worker:  
    <<: *common_config      # Reuses the same base configuration  
    command: npm run worker  # Specific command to run the background worker  

  db:  
    image: postgres:15  
    # ... (database settings)

In the code snippet above, we use a special key, x-base-service, at the top of the YAML file to define a shared configuration block identified by &common_config.

Then, in the web and worker services, we use <<: *common_config to merge those shared settings into each service.

As a result, both services get identical image, volumes, environment, and restart values from the template, and we only add what changes in each one. In this case, the specific command and, in the web service, the database dependency.

If tomorrow you need to change an environment variable or a logging option for all services, you only need to edit one place, the anchor block, and the web and worker containers will automatically receive the update. Much simpler than remembering to change the same setting in two or three different places.

It is worth noting that Compose also supports the native **extends** directive. With it, you could, for example, have a common-services.yml file that defines a base service and then, in your docker-compose.yml, make a service extend that external definition. The effect is the same: configuration reuse. It also allows you to override some values when needed.

Example:

Imagine the common-services.yml file in this example has the following configuration:

services:  
  webapp:  
    build: .  
    ports:  
      - "8000:8000"  
    volumes:  
      - "/data"

You could then extend these settings in your docker-compose.yml using the extends directive in the desired services:

services:  
  web:  
    build: alpine  
    command: echo  
    extends:  
      file: common-services.yml  
      service: webapp  
  webapp:  
    extends:  
      file: common-services.yml  
      service: webapp

Result

You will get exactly the same result as if you had written a docker-compose.yaml file with the same build, ports, and volumes configuration values defined directly, or hardcoded.

Use the approach you prefer: YAML anchors are great within a single file, while extends shines when splitting Compose files across multiple files.

Benefits for the workflow

By removing duplication, you reduce errors and keep your Compose code cleaner. In development teams, this means all members share consistent settings. If several microservices use the same image or variables, you make sure they are all using exactly the same values. The file also becomes smaller and easier to understand. New developers can quickly identify what is common to all services and what is specific to each one.

Orchestrating Startup Order with depends_on

Another classic challenge in multi-container environments is making sure certain services only start when others are already ready. Imagine your web API depends on a database. If the API container starts before the database is up, the application will probably fail when trying to connect, and its startup may even be compromised. These situations are frustrating, but Docker Compose helps us with the depends_on parameter.

depends_on allows you to declare explicit dependencies between services, making Compose start containers in the correct order. In the short syntax, you simply list the names of the services that another service depends on, and Compose will make sure to start the dependency containers first and stop them last. For example:

services:  
  api:  
    image: my-api:latest  
    depends_on:  
      - db  
      - redis  
  db:  
    image: mysql:8.0  
  redis:  
    image: redis:7-alpine

In the example above, when running docker compose up, Compose will first start the db and redis services, and only then start the api container. Likewise, when stopping the containers, it would stop api first before shutting down db and redis. This helps avoid many startup and shutdown ordering problems.

But what if we want to make sure the database is really ready for connections before starting the API?

The good news is that newer versions of Compose support the long syntax for depends_on, which includes conditions. We can specify a condition such as service_healthy to indicate that the dependency service only counts as “ready” when its healthcheck is OK. Let’s improve the example by adding a healthcheck to the database:

services:  
  api:  
    image: my-api:latest  
    depends_on:  
      db:  
        condition: service_healthy   # waits for the db healthcheck to pass  
      redis:
        condition: service_started   # waits for redis to start (container started only)  
    # ... (remaining API config, ports, etc.)  

  db:  
    image: mysql:8.0  
    healthcheck:  
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]  # checks whether MySQL responds  
      interval: 5s  
      timeout: 5s  
      retries: 5  

  redis:  
    image: redis:7-alpine  
    # (we can also include a healthcheck here if we want to monitor readiness)

Now Compose will wait for the MySQL healthcheck to return success. In this case, the mysqladmin ping command indicates that the server is responding before starting the api service.

For Redis, we use service_started simply to make sure the container has started. There is no wait for a “Healthy” status, because we may not have defined a healthcheck for it.

This configuration reflects a common scenario: waiting for the database to become available and also making sure the Redis cache has started before the application goes online. In practice, api only starts initializing when Compose verifies that db is healthy and redis is already running, avoiding immediate “could not connect to the database” failures.

Important tips:

To use condition: service_healthy, make sure to define an appropriate healthcheck on the dependency service. Otherwise, Compose will have no way to know its health status and will treat the container as ready as soon as the process starts.

In the example, we use a native MySQL command, mysqladmin ping, to check availability. For PostgreSQL, for example, there is pg_isready.

Also keep in mind that, although Compose waits for the healthcheck OK, it is still recommended that your application have connection retry logic.

This gives you extra robustness if an unexpected condition occurs, such as a slight delay even after the healthcheck or a temporary connection loss. In short, depends_on handles the initial orchestration, and it already helps a lot, but good resilience practices in the application are never too much.

In a team development context, using depends_on, especially with healthchecks, standardizes how everyone starts the environment. New developers do not need to “guess” the order for starting each service manually or run wait scripts. A simple docker compose up already does everything in the right sequence. This greatly reduces the kind of “it works on my machine” errors caused by startup race conditions, making everyone’s workflow more reliable.

How do these features speed up teamwork?

Profiles

Flexibility for different scenarios: They allow each team member to run only the set of services needed for their task. This speeds up the development cycle.

For example, running integration tests without starting the entire stack, or running debugging tools only when they are actually needed. Teams can define standard profiles, such as dev, test, and debug, and avoid the need for multiple Compose files for environment variations. The result is a customizable environment that is still centralized in a single file.

Extends

Consistent configuration and less repeated code: By reusing settings with extends or anchors, you make sure related services share identical parameters where it makes sense: the same base image, the same credentials, the same logging policies, and so on.

This prevents discrepancies that could cause “it works here but not there” problems. Reducing repetition also makes editing the Compose file faster. A change to a shared port or variable is reflected everywhere, saving time and avoiding forgotten updates. In teams, this consistency means fewer configuration bugs and smoother onboarding for anyone reading or editing the Compose file for the first time.

Depends_on

Ordered startup and fewer failures: With dependencies properly defined and healthcheck conditions used when applicable, starting the environment becomes much more reliable. Developers do not need to perform manual steps to make sure “the database is already up” before running the application, for example. In CI pipelines and local demos, everything starts in the right order automatically. This reduces time wasted on silly troubleshooting like “oh, never mind, I just had to start service X first…” and keeps the focus on the application logic.

In short, these advanced Docker Compose features work as small productivity multipliers for teams: less time spent adjusting configuration and more time working on the application itself.

tha-tha-tha-that's all, folks!

Docker Compose can look simple at first, but features like profiles, extends, and depends_on make a real difference when a project starts to grow. With profiles, you keep optional services under control. With extends and YAML anchors, you reduce repetition and make configuration easier to maintain. With depends_on and healthchecks, you make local and team environments more predictable.

Used together, these features help keep your Compose files cleaner, your development workflow faster, and your team less exposed to avoidable configuration problems. And that is exactly the kind of small improvement that pays off every day.

Essential Linux Commands Map

Altair Lage — Wed, 15 Apr 2026 13:12:52 +0000

Essential Linux Commands Map

With the evolution of operational systems visual environments, the majority of users don't ever need to use the command terminal for their daily activities. Most users do not execute any advanced system tasks, and when they do it, the configuration apps are more than enough. You probably know some Windows users that never opened the "black screen" for anything.
The same happens with Linux. It evolved its visual environments, also known as Desktop environments (DEs), to a point that the terminal is not necessary for almost 100% of an average user needs. The most popular choices, GNOME, KDE, and XFCE, allow system configurations and troubleshooting from the UI. But when you need advanced troubleshooting and system administration, the terminal is always your best friend.

You may feel intimidated the first time you open a Linux terminal. That black screen with thousands of commands, many options, and sometimes, many ways to do the same thing. Beginners often feel lost, and even experienced users sometimes fall back on the same small set of commands every day.

That's why a visual command map like the main image of this article is useful. It is superficial, but focuses on the commands people use most often in real life. The main image organizes the commands into functional groups to make it easier to understand the kind of tasks they solve. Further in this article, all the groups and commands are explained briefly for reference.

In practice, most terminal work is the same you perform on a UI. You move through folders, inspect files, edit content, check running processes, review system details, manage users, troubleshoot networks, and install software. Once you understand that terminal and a visual interfaces are only faces of the same coin, Linux terminal feels more practical and less overwhelming.

A list of commands is not a good way to learn something. People remember things better when they make associations with other things, happenings or feelings. Grouping it by purpose works better because you create associations, for an example, "I have no internet connection" relates to networking, which can relate to IP misconfiguration, so maybe ipconfig command may help to diagnose the issue. That is what makes the presented map helpful. It gives structure to the learning process.

Instead of thinking, “I need to memorize all Linux commands”, you can think “I need these few commands for files, a few for processes, and a few for networking”.
It reflects real life. Most users do not need hundreds of commands every day. They need a small set they can use with confidence for the day-by-day tasks, the same way most users don't need to know and perform multiple advanced tasks via the UI. Once that core is familiar, learning more advanced tools becomes much easier.

File and Directory Management

These commands allow you move/browse around the filesystem and manage files and folders.

ls - List files and directories in the current location.
- Example: ls -la: Lists all files (including hidden ones) in long format, showing permissions, owner, size, and modification date.
pwd - Show the full path of the current working directory.
- Example output: # /home/myuser/projects/my-app.
- Useful when you've navigated deep into a directory tree and need to confirm where you are.
cd - Change, or moves, from one directory to another.
- Examples:
- cd /var/log # Move to an absolute path
- cd .. # Move one level up
- cd ~ # Move to the current user home directory
mkdir - Create a new directory.
- Examples:
- mkdir my-folder # Create the "my-folder" folder in current directory
- mkdir -p parent/child/grandchild # Create nested directories in one go
  - The -p flag creates intermediate directories as needed, so you don't have to create each level manually.
rmdir - Remove an empty directory.
- Example: rmdir old-folder
- This only works if the directory is completely empty. If it contains files, you'll need rm -r instead.
touch - Create an empty file or updates a file timestamp.
- Examples:
- touch notes.txt # Create a new empty file
- touch existing-file.log # Update the modification timestamp to now
cp - Copie files or directories.
- Examples:
- cp report.txt report-backup.txt # Copy the report.txt file and name it to report-backup.txt
- cp -r src/ src-backup/ # Copy the src directory recursively
- The -r (recursive) flag is required when copying directories, otherwise cp will skip them.
mv - Move or renames files and directories.
- Examples:
- mv old-name.txt new-name.txt # Rename a file
- mv file.txt ~/Documents/ # Move a file to another directory
- Unlike cp, mv works on directories without needing any extra flags.
rm - Remove files or directories.
- Examples:
- rm unwanted-file.txt # Remove the file
- rm -r old-project/ # Remove a directory and everything inside it
- rm -ri important-folder/ # Remove recursively but ask for confirmation on each file
- Be careful with rm -r there is no trash can in the terminal. Once removed, files are gone for good.

These are often the first commands people learn, and for good reason. They are the foundation of daily terminal use. If you think about it, this is also the most frequent actions you perform in a visual interface, like Windows.

File Viewing and Editing

Once you find a file, the next step is usually to read or edit it. These commands handle these actions.

cat - Print file content directly in the terminal.
- Examples:
- cat server.log # Display the entire file in the terminal
- cat -n server.log # Display with line numbers
- cat file1.txt file2.txt > combined.txt # Concatenate two files into a new one
less - Open a file for scrolling and reading page by page.
- Examples:
- less /var/log/syslog # Open a log file for browsing (use q to quit)
- less -N app.log # Open with line numbers shown
- dmesg | less # Pipe command output into less for easy scrolling
more - Display file content one screen at a time.
- Examples:
- more readme.txt # View the file one screenful at a time
- more -10 config.yaml # Display 10 lines at a time
- ls -la /etc | more # Pipe a long directory listing through more
nano - A simple terminal-based text editor.
- Examples:
- nano notes.txt # Open (or create) a file for editing
- nano +15 script.sh # Open a file and jump directly to line 15
- nano -B /etc/hosts # Open a file and automatically create a backup before editing
vim - A powerful terminal-based text editor with advanced features.
- Examples:
- vim deploy.sh # Open a file for editing (press i to enter insert mode, Esc then :wq to save and quit)
- vim +42 main.py # Open a file and jump to line 42
- vim -d file-v1.txt file-v2.txt # Open two files side by side in diff mode
gedit - A graphical text editor often found on desktop Linux systems.
- Examples:
- gedit todo.txt # Open a file in the graphical editor
- gedit +25 app.conf # Open a file and place the cursor on line 25
- gedit file1.txt file2.txt # Open multiple files in separate tabs

This group is useful for everything from reading logs to editing config files.

Process Management

Linux is always running processes in the background and foreground. These commands help you inspect and control them. It is similar to the Windows Task Manager, but in text mode.

ps - Show a snapshot of running processes.
- Examples:
- ps aux # List all running processes with detailed info
- ps -ef | grep nginx # Find all processes related to nginx
- ps -u jdoe # Show all processes owned by user jdoe
top - Display live system activity and active processes.
- Examples:
- top # Launch the interactive process viewer
- top -u www-data # Show only processes owned by the www-data user
- top -p 1234,5678 # Monitor only specific PIDs
kill - Send a signal to stop or control a process by PID.
- Examples:
- kill 1234 # Gracefully terminate process with PID 1234 (sends SIGTERM)
- kill -9 1234 # Force-kill a stubborn process (sends SIGKILL)
- kill -STOP 1234 # Pause a running process without ending it
killall - Stop processes by name.
- Examples:
- killall firefox # Terminate all Firefox processes
- killall -9 node # Force-kill all Node.js processes
- killall -u jdoe python # Kill all Python processes owned by user jdoe
pstree - Display processes in a tree structure.
- Examples:
- pstree # Show all processes as a tree from init/systemd
- pstree -p # Show the tree with PIDs next to each process
- pstree -u jdoe # Show the process tree for a specific user
htop - An interactive process viewer with a cleaner interface than top.
- Examples:
- htop # Launch the interactive viewer with color-coded output
- htop -u www-data # Filter to show only a specific user's processes
- htop -p 1234,5678 # Monitor only specific PIDs in the interactive viewer

When a system is slow or an app freezes, this is usually where you start troubleshooting.

System Information

These commands help you learn more about the machine itself, including hardware, storage, and memory usage.

uname - Show basic system information such as kernel and OS name and version.
- Examples:
- uname -a # Display all system info (kernel, hostname, architecture, etc.)
- uname -r # Show only the kernel release version
- uname -m # Print the machine hardware architecture (e.g., x86_64)
df - Report disk space usage by filesystem.
- Examples:
- df -h # Show disk usage in human-readable format (GB, MB)
- df -h /home # Check available space on the /home partition
- df -T # Include the filesystem type in the output (ext4, xfs, etc.)
du - Estimate disk usage for files and directories.
- Examples:
- du -sh /var/log # Show total size of the /var/log directory in human-readable format
- du -h --max-depth=1 /home # Show sizes of immediate subdirectories under /home
- du -ah /tmp | sort -rh | head -10 # Find the 10 largest files and folders in /tmp
free - Display memory and swap usage.
- Examples:
- free -h # Show RAM and swap usage in human-readable format
- free -m # Display memory values in megabytes
- free -h -s 5 # Refresh memory stats every 5 seconds
lscpu - Show CPU architecture details.
- Examples:
- lscpu # Display full CPU info (cores, threads, model, cache, etc.)
- lscpu | grep "Model name" # Show only the CPU model name
- lscpu | grep "CPU(s)" # Check the total number of CPUs/cores available
lshw - List detailed hardware information.
- Examples:
- sudo lshw -short # Show a compact summary of all hardware components
- sudo lshw -class network # Display only network adapter details
- sudo lshw -class memory # Show RAM module details (size, speed, slots)
lsblk - Display block devices such as disks and partitions.
- Examples:
- lsblk # List all block devices in a tree view
- lsblk -f # Include filesystem type and UUIDs in the output
- lsblk -o NAME,SIZE,TYPE,MOUNTPOINT # Show only specific columns for a cleaner view

This category is especially helpful for troubleshooting and performance checks.

User and Group Management

Linux is built around users, groups, and permissions. These commands support account administration.

passwd - Changes a user password.
- Examples:
- passwd # Change the password for the currently logged-in user
- sudo passwd jdoe # Reset the password for user jdoe (requires root)
- passwd -e jdoe # Force user jdoe to change password on next login
useradd - Creates a new user account.
- Examples:
- sudo useradd jdoe # Create a new user with default settings
- sudo useradd -m -s /bin/bash jdoe # Create a user with a home directory and bash shell
- sudo useradd -G developers,docker jdoe # Create a user and add them to multiple groups
userdel - Deletes a user account.
- Examples:
- sudo userdel jdoe # Remove the user account but keep the home directory
- sudo userdel -r jdoe # Remove the user and delete their home directory
- sudo userdel -f jdoe # Force removal even if the user is currently logged in
usermod - Modifies an existing user account.
- Examples:
- sudo usermod -aG docker jdoe # Add user jdoe to the docker group without removing other groups
- sudo usermod -s /bin/zsh jdoe # Change the default shell for user jdoe
- sudo usermod -l jsmith jdoe # Rename the user account from jdoe to jsmith
groupadd - Creates a new group.
- Examples:
- sudo groupadd developers # Create a new group called developers
- sudo groupadd -g 1500 devops # Create a group with a specific GID
- sudo groupadd --system appusers # Create a system group for service accounts
groupdel - Deletes a group.
- Examples:
- sudo groupdel developers # Remove the developers group
- sudo groupdel old-team # Delete a group that is no longer needed
- sudo groupdel temp-project # Clean up a temporary project group
groups - Shows the groups a user belongs to.
- Examples:
- groups # Show the groups for the currently logged-in user
- groups jdoe # List all groups that user jdoe belongs to
- groups root # Check which groups the root user is a member of
id - Displays user ID, group ID, and related group information.
- Examples:
- id # Show UID, GID, and groups for the current user
- id jdoe # Display the full identity info for user jdoe
- id -gn jdoe # Print only the primary group name of user jdoe

Specially if you manage shared systems or servers, you will use these commands very often.

Network Configuration and Monitoring

Networking is a big part of Linux administration. These commands help you inspect connections and test communication.

ifconfig - Displays or configures network interfaces on older systems.
- Examples:
- ifconfig # Show all active network interfaces and their IPs
- ifconfig eth0 # Display details for a specific interface
- sudo ifconfig eth0 down # Disable the eth0 network interface
ip - Modern command for viewing and managing network interfaces, routes, and addresses.
- Examples:
- ip addr show # List all interfaces with their IP addresses
- ip route show # Display the routing table
- ip link set eth0 up # Bring the eth0 interface up
ping - Test the connectivity to another host.
- Examples:
- ping google.com # Continuously ping Google to check internet connectivity
- ping -c 4 192.168.1.1 # Send exactly 4 ping packets to a host
- ping -i 2 server.local # Ping every 2 seconds instead of the default 1 second
netstat - Show network connections, routing tables, and interface stats.
- Examples:
- netstat -tulnp # Show all listening TCP/UDP ports with process names
- netstat -an | grep :80 # Check if anything is listening on port 80
- netstat -r # Display the kernel routing table
ss - Display socket and network connection information, often faster than netstat.
- Examples:
- ss -tulnp # List all listening ports with associated processes
- ss -s # Show a summary of socket statistics
- ss -t state established # Display only established TCP connections
traceroute - Show the path packets take to reach a destination.
- Examples:
- traceroute google.com # Trace the route to Google showing each hop
- traceroute -n 8.8.8.8 # Trace without resolving hostnames (faster output)
- traceroute -m 15 example.com # Set a maximum of 15 hops
ssh - Connect securely to a remote machine.
- Examples:
- ssh jdoe@192.168.1.50 # Connect to a remote host as user jdoe
- ssh -p 2222 jdoe@server.com # Connect using a non-default SSH port
- ssh -i ~/.ssh/mykey.pem ec2-user@10.0.0.5 # Connect using a specific private key
nc - Netcat, a flexible tool for testing ports, sending data, and debugging network services.
- Examples:
- nc -zv server.com 443 # Test if port 443 is open on a remote host
- nc -l 8080 # Listen for incoming connections on port 8080
- nc -zv 192.168.1.10 20-100 # Scan a range of ports on a host

This is the part of Linux that becomes essential the moment something stops connecting.

Package Management

Linux distributions use package managers to install, update, and remove software. The exact tool depends on the distro.

apt-get - Package management tool used on Debian-based systems.
- Examples:
- sudo apt-get update # Refresh the list of available packages
- sudo apt-get install nginx # Install the nginx web server
- sudo apt-get remove --purge nginx # Remove nginx and its configuration files
apt - A more user-friendly package command for Debian-based systems.
- Examples:
- sudo apt update && sudo apt upgrade # Update package list and upgrade all packages
- sudo apt install git curl wget # Install multiple packages at once
- apt search image editor # Search for packages related to image editing
yum - Older package manager for RPM-based distributions.
- Examples:
- sudo yum install httpd # Install the Apache web server
- sudo yum update # Update all installed packages
- yum list installed # Show all currently installed packages
dnf - Modern package manager used in newer RPM-based distributions.
- Examples:
- sudo dnf install nodejs # Install Node.js
- sudo dnf upgrade --refresh # Refresh metadata and upgrade all packages
- dnf search python3 # Search for packages matching python3
rpm - Low-level tool for managing RPM packages directly.
- Examples:
- sudo rpm -ivh package.rpm # Install a local RPM package file
- rpm -qa | grep java # List all installed packages containing "java"
- rpm -qi nginx # Show detailed info about an installed package
dpkg - Low-level tool for managing Debian packages directly.
- Examples:
- sudo dpkg -i package.deb # Install a local .deb package file
- dpkg -l | grep python # List installed packages matching "python"
- dpkg -L nginx # Show all files installed by the nginx package
snap - Installs and manages snap packages across supported distributions.
- Examples:
- sudo snap install code --classic # Install VS Code as a snap package
- snap list # Show all installed snap packages
- sudo snap refresh # Update all installed snaps to their latest versions
zypper - Package manager used on openSUSE and SUSE systems.
- Examples:
- sudo zypper install git # Install git on an openSUSE system
- sudo zypper refresh # Refresh all configured repositories
- zypper search docker # Search for packages related to docker

Not every Linux system uses all of these, but knowing the distro family you use will help you to know which commands to use.

Start Learning

Start learning the commands in small groups:

Start with navigation: pwd, ls, cd.
Then learn file handling: touch, cp, mv, rm.
Add file reading and editing: cat, less, nano.
Move into process and system checks: ps, top, df, free.
Finish with network basics: ip, ping, ssh.

Th-Th-That's all, folks!

Linux becomes much easier once you stop seeing it as a wall of commands and start seeing it as a set of tools for clear tasks. This map is a good reminder that the terminal is not about complexity for the sake of complexity. It is about control, speed, and understanding what your system is doing.

You do not need to master every command today. Learn the ones that solve the problems in front of you. Use them often. Repeat them in real situations. That is how confidence grows.

And after a while, the terminal stops feeling technical and starts feeling natural.

Apache Kafka tutorial – What is Apache Kafka?

Altair Lage — Tue, 14 Apr 2026 22:18:13 +0000

Apache Kafka is an open-source distributed event streaming platform used by thousands of companies to publish, store, and process streams of records in real time. It was originally developed by LinkedIn before moving into the open-source world in early 2011. It was built because LinkedIn needed a better way to handle massive amounts of data to track site events, like page views and user clicks, and to gather all their log data in one place.

Kafka is designed for distributed high throughput systems. Kafka tends to work very well as a replacement for a more traditional message broker. In comparison to other messaging systems, Kafka has better throughput, built-in partitioning, replication and inherent fault-tolerance, which makes it a good fit for large-scale message processing applications.
In this tutorial, we are going to dive into what Kafka actually is and walk through the most common definitions you'll run into when working with it.

Who is using Kafka?

Twitter uses Kafka to power its mobile application performance management and analytics platform. In 2015, this system was already handling around five billion sessions per day.
Netflix relies on Kafka as the messaging backbone for its Keystone pipeline, a unified platform for publishing, collecting, and routing events across both batch and stream processing. As of 2016, Keystone included more than 4,000 brokers running entirely in the cloud, handling over 700 billion events every single day.
Tumblr uses Kafka as a core part of its event processing pipeline. In 2012, it was already capturing up to 500 million page views per day through this system.
Square uses Kafka as its central data bus. It supports stream processing, website activity tracking, metrics collection, monitoring, log aggregation, real-time analytics, and complex event processing.
Pinterest runs Kafka as part of its real-time advertising platform. The system includes over 100 clusters and more than 2,000 brokers deployed on AWS. It processes more than 800 billion events per day, with peaks reaching up to 15 million events per second.
Uber is one of the most well-known Kafka adopters. The company processes over a trillion events per day using Kafka, mainly for data ingestion, event stream processing, database changelogs, log aggregation, and general-purpose publish-subscribe messaging.

Kafka architecture

Kafka is a publish/subscribe system built around event data. It involves four main actors: producers, consumers, brokers, and ZooKeeper nodes.

Broker nodes: These handle most of the I/O work and are responsible for durable data storage within the cluster. A Kafka broker receives messages from producers and writes them to disk, organizing them by partition and indexing them with a unique offset. Consumers can then fetch messages by topic, partition, and offset. Brokers also work together to form a Kafka cluster, sharing information either directly or indirectly through ZooKeeper.
ZooKeeper nodes: Kafka relies on ZooKeeper to manage the overall state of the cluster. It keeps track of broker health, maintains metadata about topics, and helps coordinate cluster operations.
Producers: Producers are responsible for sending messages to Kafka brokers, typically organized by topic.
Consumers: Consumers are client applications that read messages from Kafka topics.

In the diagram above, a topic is divided into three partitions:

Partition 1 contains two offsets: 0 and 1
Partition 2 contains four offsets: 0, 1, 2, and 3
Partition 3 contains a single offset: 0

A replica is simply a copy of a partition, including the same data, offsets, and partition ID.

Now, consider a scenario where the replication factor is set to 3. Kafka will create three identical copies of each partition and distribute them across the cluster to ensure availability and fault tolerance. In the example shown, the replication factor is 1, meaning each partition has only one copy.

To balance load across the cluster, partitions are distributed among brokers, and each broker can store one or more partitions. At the same time, multiple producers and consumers can publish and read messages concurrently, making Kafka highly scalable and efficient.

Kafka component concepts

Broker nodes

A broker acts as the middle layer between producers and consumers, helping move data across the system. It stores messages in partitions and ensures that data is safely persisted for a configurable amount of time. This design also helps Kafka handle failure scenarios without losing data.

In Kafka, a broker is a key unit of scalability. By increasing the number of brokers in a cluster, you can improve I/O throughput, availability, and overall durability. Brokers also coordinate with each other and communicate with ZooKeeper to maintain cluster state and consistency.

In most setups, each server runs a single broker. While it is technically possible to run multiple brokers on the same server, this is generally not recommended in production environments.

Topic

A Kafka Topic is where messages sent by producers are stored. Topics are split into partitions, and each topic has at least one partition. Each partition contains messages in an immutable and ordered sequence. Once a message is written, it cannot be changed. A partition is internally implemented as a set of segment files of equal sizes. So we can imagine a topic as a logical aggregation of partitions. By splitting a topic into multiple partitions, Kafka can process data in parallel, which improves performance and scalability.

When a producer publish a record, the producer automatically select a partition based on the record’s key. A producer will digest the byte content of the key using a hash function (Kafka uses murmur2 for this purpose).

The process works like this:

The key is hashed using murmur2.
The highest-order bit is masked to ensure the result is a positive integer.
The final partition number value is calculated using modulo with the number of partitions. This process determines the target partition for the record.

As a result, records with the same key will always be routed to the same partition, ensuring ordering for that key. However, if the number of partitions changes, the hash result will also change. This means Kafka may assign the same key to a different partition after the change.

The topic structure, contents, and how producers interact with partitions are depicted below.

This is the nature of hashing: Records with different hashes may still end up in the same partition due to hash collisions.

Consumer groups and load balancing

Kafka’s producer-topic-consumer topology adheres to a flexible and highly scalable model. A multipoint-to-multipoint model, which means multiple producers and multiple consumers can interact with the same topic at the same time.

A consumer is a process (or thread) that attaches to a Kafka cluster using a client library. When multiple consumers subscribe to a topic and belong to the same consumer group, Kafka distributes the partitions among the consumer in the group. Each consumer reads from a different subset of partitions in the topic.

Let’s walk through an example.

Suppose we have a topic called T1 with four partitions. If we create a single consumer C1 in group G1 and subscribe it to topic T1, then C1 will receive messages from all four partitions.

But, if we add a second consumer C2 to the same group G1, Kafka will rebalance the partitions. Each consumer will now read from two partitions. For example:

C1 reads from partitions 0 and 2
C2 reads from partitions 1 and 3

If we keep adding more consumers to the same group G1, and the number of consumers exceeds the number of partitions, some consumers will remain idle. This happens because Kafka guarantees that each partition is assigned to only one consumer within a group.

Now, if a new consumer group G2 is introduced, with a single consumer. This consumer will receive all messages from topic T1, completely independent of what group G1 is doing.

If G2 has multiple consumers, Kafka will again split the partitions among them, just like it does for G1. However, the key point is that each consumer group receives the full stream of messages, regardless of other groups.

This works because of how Kafka manages offsets:

Offsets are managed by consumers, but they are stored in a special Kafka topic called __consumer_offsets.
Offsets are tracked per (consumer group, topic, partition) combination.
This combination is used as the key when storing offsets, which allows Kafka to:
- Keep offsets organized in the same partition of the __consumer_offsets topic.
- Use log compaction to remove outdated offset records.
- Efficiently manage progress tracking for each consumer group.

By default, the __consumer_offsets topic is configured with 50 partitions.

Th-th-that's all, folks!

Apache Kafka is much more than just a messaging system. It is a distributed event streaming platform designed to handle large-scale data with high throughput, reliability, and scalability.

The key takeaway is simple: Kafka is built for movement, durability, and scalability of data. Once you understand these core concepts, everything else, from stream processing to real-time analytics, becomes much easier to reason about.

If you're starting with Kafka, these fundamentals are the base for everything you will build on top of it.

Essential AWS services every engineer should know

Altair Lage — Mon, 13 Apr 2026 19:48:38 +0000

When we start learning AWS, the number of services feels overwhelming. But we don't need to learn everything at once. A strong foundation usually starts with a few key groups, like compute, storage, databases, networking, security, monitoring, etc.

This chart is a simple way to see how the AWS ecosystem is organized. It brings together core services in one place.

My advice is to start with the basics. Then connect the dots as long as you need.

A practical start could look like this:

Create and manage your networking with VPC.
Run apps with EC2, Lambda, or ECS.
Store data in S3.
Store your servers data with EBS, or EFS.
Use RDS and Aurora for your relational databases.
Refer DynamoDB for your NoSQL DBs.
Secure access with IAM, KMS, and Secrets Manager.
Monitor everything with CloudWatch, and troubleshoot with CloudTrail.
Automate delivery with CodePipeline, CodeBuild, and CodeDeploy.
Make your apps to talk with each other with SQS and SNS.
Manage your resources with Infrastructure as Code with CloudFormation.

AWS gets much easier when you stop seeing isolated services and start seeing how they work together.

DevOps Engineer Routine

Altair Lage — Mon, 13 Apr 2026 14:45:05 +0000

Every DevOps knows this feeling

On one side, there’s:

Infrastructure melting down at 2 AM.
CI/CD pipelines stuck in "pending" forever.
Mysterious server crashes with zero warning.

On the other side:

"Is it safe to push to production today?".
“Why did the app get so slow all of a sudden?”.
“But everything was fine in staging…”.

That’s the job, really. DevOps isn't about learning and using the latest fashion tools.
It's about staying calm under fire, bringing order to chaos, and designing systems resilient enough to handle reality, not just theory.

What really helps in practice:

Monitoring that raises the flag before users feel the impact.
CI/CD pipelines clean and simple enough for anyone to follow and trust.
Automation for repetitive work, so people spend time fixing problems instead of clicking through tasks.
Clear ownership and documentation that stays useful over time (instead of relying on tribal knowledge).
Blameless postmortems that turn outages and mistakes into concrete improvement.

If you're a DevOps, SRE, Cloud, or Platform Engineer, you already know this feeling. We all spend time dealing with fires. But the real goal is not just becoming better at reacting. It’s designing systems where fewer fires happen at all.

New tutorial, folks!

Altair Lage — Mon, 30 Mar 2026 17:38:18 +0000

Altair Lage

Mar 30

RabbitMQ Management Interface

#webdev #devops #programming #tutorial

12 min read