DEV Community: IROSH PERERA

The Terminal Is a Tool, Not a Personality

IROSH PERERA — Tue, 06 Oct 2026 10:46:29 +0000

The Terminal Is a Tool, Not a Personality

One of the first things many people notice about Linux is the terminal.

There are commands for almost everything:

Viewing files
Checking processes
Installing software
Managing services
Inspecting logs
Testing network connections
Monitoring system resources

Because of this, a strange idea has developed in the Linux community:

The more terminal commands someone uses, the more serious they are as a developer.

I do not agree with that.

The terminal is a tool.

It is not a personality, a skill competition, or proof that someone is a better developer.

The terminal is powerful

The terminal is excellent when we need:

Repeatable actions
Automation
Remote server access
Fast navigation
Scripting
Detailed system information
Command-line pipelines

When managing a Linux VPS, checking Nginx, inspecting logs, or deploying a backend application, the terminal is often the most practical interface.

It works well over SSH. It consumes very few resources. It can be combined with scripts and automation.

For experienced users, the terminal can feel incredibly efficient.

But the terminal is not always the best interface

A command-line interface is not automatically better for every task.

A graphical interface can provide:

Visual context
Clear navigation
Discoverability
Easier system exploration
Better feedback for beginners
More accessibility for some users

Imagine a new Linux user trying to understand CPU usage, storage, processes, services, and logs.

Giving that person a long list of commands may not be the best introduction.

A visual dashboard can help them understand the system first. After that, they may become more comfortable using the terminal.

The goal should be understanding—not forcing everyone to use the same interface.

Copying commands is not the same as learning Linux

A beginner may copy a command from a tutorial and get the expected result.

But if they do not understand the command, they may struggle when:

The output is different
The file path changes
A permission error appears
The service has another name
The command is unavailable
They are using another distribution

The terminal becomes much more useful when users understand the concepts behind it.

Knowing what a process, port, service, permission, or log is matters more than memorizing a command.

This is one reason I am building Linuvera

I am building Linuvera, an open-source Linux developer and system-support toolkit using Java and JavaFX.

The goal is not to replace the terminal.

The goal is to make useful Linux information easier to understand through a focused graphical interface.

Linuvera explores areas such as:

CPU and memory usage
Processes
Storage
Ports
Systemd services
Logs
Developer tools
Linux system health

The current direction focuses on read-only inspection for Ubuntu and Debian-based systems.

You can explore the project here:

github.com/IroshPerera/linuvera

A GUI can help someone discover the system. The terminal can help them control and automate it.

These approaches do not need to fight each other.

Choose the right interface for the job

I use both graphical tools and the terminal.

For remote server work, automation, and deployment, the terminal is usually the right choice.

For system exploration, visual monitoring, and helping new users understand what is happening, a graphical interface can be more effective.

Good software should respect both experienced users and beginners.

Linux does not need a culture where users feel embarrassed for preferring a GUI.

It needs tools that help people learn, explore, and become more confident.

The terminal is powerful.

But using a graphical interface does not make someone less technical.

Which Linux tasks do you prefer to do in the terminal, and which ones do you prefer to do through a graphical interface?

Should Every Backend Developer Learn Linux Before Docker?

IROSH PERERA — Mon, 28 Sep 2026 03:55:25 +0000

Should Every Backend Developer Learn Linux Before Docker?

Docker has changed the way developers build and deploy applications.

With a few commands, we can run databases, message brokers, backend services, and complete development environments. Docker makes many difficult setup tasks feel simple.

But this convenience has created an interesting question:

Should every backend developer learn Linux before learning Docker?

My short answer is: developers do not need to master Linux first, but every backend developer should understand the Linux concepts that Docker is hiding.

Docker does not remove Linux

Docker feels like an independent tool, but containers still depend on the operating system underneath them.

A container is not a small virtual machine. It is a process running with isolation and resource restrictions.

When a container stops, a process has exited.

When a port is unavailable, something else may already be listening on that port.

When a file cannot be written, permissions may be involved.

When a container is slow, the host machine may be running out of memory or CPU.

Docker makes these things easier to manage, but it does not remove them.

Port mapping is easier when you understand networking

Many developers have used commands like:

docker run -p 8080:8080 my-app

But what does this actually mean?

The application inside the container must listen on the expected port. The host port must be available. The application may need to listen on the correct network interface.

When everything works, Docker feels simple.

When it fails, a basic understanding of Linux networking becomes extremely useful.

Understanding ports, interfaces, localhost, processes, and firewalls can save a lot of debugging time.

Containers still have files and permissions

Volumes are another good example.

A database container may need to write data to a mounted directory. A backend container may need to read configuration files. A build process may create files owned by a different user.

If the permissions are incorrect, the application may fail even though the Docker configuration looks correct.

Adding more permissions is not always the correct solution.

Understanding Linux ownership and access permissions helps developers solve the real problem instead of hiding it.

Logs are still essential

Docker provides commands such as docker logs, but developers still need to understand what they are looking at.

Is the application failing?

Is the database unavailable?

Did the process stop?

Is the container restarting repeatedly?

Is the problem inside the container or on the host machine?

The container is only one part of the system. Linux processes, services, memory, storage, and network connections may all affect the result.

What Linux knowledge is enough?

Backend developers do not need to understand every kernel subsystem before using Docker.

However, these concepts are extremely valuable:

Processes and signals
Files and permissions
Ports and networking
Environment variables
Logs
CPU and memory usage
Services and background processes
Basic shell commands

This is not about creating a barrier for beginners.

It is about giving developers enough knowledge to understand what happens when the abstraction fails.

Docker is still a great starting point

I do not think developers should avoid Docker until they become Linux experts.

Docker is an excellent learning tool. It helps developers run real services, experiment with environments, and understand deployment workflows.

The problem starts when Docker becomes a complete replacement for understanding the operating system.

Abstraction is useful when it saves time.

It becomes dangerous when we cannot debug beyond the abstraction.

As a Java and Spring Boot developer, I use Linux with PostgreSQL, Nginx, Docker, and other backend tools. The more I work with real applications and Linux servers, the more I understand that Docker and Linux are not competing skills.

They complement each other.

Docker helps us package and run applications.

Linux helps us understand the environment where those applications actually live.

Did Docker make Linux easier for you, or did it help you avoid learning Linux?

Linux Is Not Difficult — Most Tutorials Explain It Poorly

IROSH PERERA — Tue, 22 Sep 2026 10:53:07 +0000

Linux Is Not Difficult — Most Tutorials Explain It Poorly

Linux is often described as difficult.

You need to use the terminal. You need to understand permissions. You need to manage packages. Sometimes a command fails, and the error message looks more confusing than the original problem.

I understand why many beginners feel this way.

But after using Ubuntu for Java and Spring Boot development, working with Linux servers, PostgreSQL, Nginx, Docker, and building my own Linux tool, I have started to see the problem differently.

Linux is not necessarily difficult.

Most Linux tutorials simply explain it poorly.

The problem is not Linux. The problem is the learning path.

Many beginner tutorials start like this:

sudo apt update
sudo apt install something

But they do not explain:

What apt actually does
Why sudo is required
Where the package is installed
What happens if the command fails
How this relates to the rest of the operating system

A beginner can copy the command successfully and still learn almost nothing.

Good tutorials should not only show commands. They should explain the ideas behind those commands.

Linux is a collection of useful ideas

To understand Linux, beginners do not need to memorize hundreds of commands.

They need to understand a few important concepts:

Files and directories
Users and permissions
Processes
Services
Packages
Logs
Networking
Environment variables

Once these concepts become familiar, many commands start to make sense.

For example, systemctl status nginx is not just a command to memorize. It is a way to ask Linux about the current state of a service.

journalctl -u nginx is not random syntax. It is a way to inspect the logs created by that service.

The commands become easier when the mental model comes first.

Permissions are not an unnecessary obstacle

File permissions are one of the first things that confuse new Linux users.

A command fails because the current user does not have permission. The common reaction is to add sudo immediately.

Sometimes that works. But using sudo without understanding the reason can create bigger problems.

Permissions exist for a good reason. They protect files, processes, services, and the entire system from accidental or unauthorized changes.

Instead of teaching beginners to use sudo everywhere, tutorials should explain:

Who owns the file
Which user is running the command
What read, write, and execute permissions mean
Why a service may need different access
When elevated privileges are actually necessary

The error message is not always the enemy. Sometimes it is Linux explaining the boundary.

Package management is one of Linux’s strengths

Installing software manually can become difficult when dependencies, updates, and versions are involved.

On Ubuntu and Debian-based systems, package managers help organize this process. They provide a consistent way to install software, resolve dependencies, receive updates, and remove packages cleanly.

That does not mean package management is perfect. Different distributions use different tools, and beginners may become confused by package formats and repositories.

But the idea itself is powerful.

The problem is that many tutorials show package commands without explaining the package ecosystem. Beginners learn what to type, but not what is happening.

Linux feels close to production

As a backend developer, one of the biggest advantages of Linux is that it feels close to the environments where many applications run.

I use technologies such as Java, Spring Boot, PostgreSQL, Nginx, Docker, and Git. These tools are common in Linux-based development and server environments.

When the local development environment and the production server use similar tools and conventions, there are fewer surprises.

This does not remove every deployment problem. It does not guarantee that everything will work immediately.

But Linux helps developers understand what is happening underneath the application:

Which process is running
Which port is open
Which service failed
Where the logs are stored
Which environment variables are available
How the operating system interacts with the application

That knowledge becomes extremely valuable when debugging real systems.

GUI and terminal should not be enemies

There is also an unnecessary debate between graphical interfaces and the terminal.

Some people believe serious Linux users should only use the terminal. Others avoid Linux because they think everything requires commands.

I do not think either position is helpful.

A good graphical interface can help beginners understand the system. The terminal can provide speed, automation, and deeper control.

This is one of the reasons I started building Linuvera, an open-source Linux developer and system-support toolkit using Java and JavaFX.

The idea is to make important Linux information easier to see without hiding the system behind unnecessary complexity. It explores areas such as CPU and memory usage, processes, storage, ports, services, logs, and developer tools.

You can find the project here:

github.com/IroshPerera/linuvera

For me, the goal is not to replace the terminal. It is to make Linux easier to understand while still respecting how the system works.

What Linux tutorials should do better

In my opinion, beginner-friendly Linux tutorials should:

Explain the goal before showing the command.
Use safe and understandable examples.
Explain the output, not only the input.
Show common errors and how to recover from them.
Explain when sudo should and should not be used.
Connect terminal actions with the graphical interface.
Teach concepts instead of encouraging blind copy-and-paste.

Linux does not need to hide everything to become beginner-friendly.

It needs a better learning path.

The more I use Linux, the more I appreciate the control and transparency it provides. But I also understand why beginners feel lost when they are given commands without context.

Linux is not difficult because it is badly designed.

Sometimes, it is difficult because we teach it as a list of commands instead of a system of ideas.

What was the first Linux concept that confused you when you started using Linux—permissions, packages, the terminal, services, or something else?

I Built a Spring Boot Starter to Handle Duplicate API Requests

IROSH PERERA — Sun, 20 Sep 2026 07:24:07 +0000

A client sends a request to create an order. The server processes it, but the connection drops before the response reaches the client.

The client retries. How can the API recognise that retry and avoid creating another order?

This is the problem my open-source Spring Boot Idempotency Starter aims to address.

What is idempotency?

For an API operation, idempotency means that repeating the same logical request should not produce additional side effects.

An idempotency key lets the client identify that logical request. It should reuse the same key when retrying and generate a new key for a new operation.

What the starter provides

The starter supports:

An @Idempotent annotation for protected endpoints.
An Idempotency-Key request header.
Request body hash validation.
Caching and replaying completed responses.
In-memory and Redis storage.
Configurable record expiry and processing timeout.
Spring Boot auto-configuration.

Here is how to get started.

1. Add the Maven dependency

Requirements: Java 17+, Spring Boot 3.x, and Maven 3.8+.

<dependency>
    <groupId>io.github.iroshperera</groupId>
    <artifactId>spring-boot-idempotency-starter</artifactId>
    <version>0.1.0</version>
</dependency>

2. Annotate an endpoint

Add @Idempotent to the endpoint you want to protect:

import lk.irosh.idempotency.annotation.Idempotent;

@Idempotent
@PostMapping("/orders")
public OrderResponse createOrder(
        @RequestBody OrderRequest request
) {
    return orderService.create(request);
}

This snippet belongs inside your controller. OrderRequest, OrderResponse, and orderService represent your application's own types and service.

3. Configure the starter

For a local example, add the following to application.yml:

idempotency:
  enabled: true
  storage: memory
  required: true
  header-name: Idempotency-Key
  default-expiry: 24h
  processing-timeout: 5m
  cache-response: true
  reject-different-request-hash: true

This configuration requires a key, enables response caching, and rejects reuse of a key with a different request body.

4. Send a request with a key

Assuming your endpoint is available at /orders and accepts the example payload:

curl -X POST http://localhost:8080/orders \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-request-001" \
  -d '{"item":"Laptop","quantity":1}'

Retry the same request with the same key and body.

The documented behaviour is:

Scenario	Behaviour
First request	Executes the controller and saves the response
Retry after completion, with the same key and body	Returns the saved response without executing the controller again
Same key with a different body	Returns `409 Conflict`
Missing key when a key is required	Returns `400 Bad Request`

Use a fresh key when creating a genuinely new order.

Choosing a storage option

In-memory storage is a starting point for development, testing, and single-instance applications. Its records are local to the running application and do not survive a restart.

For shared records across application instances, the starter also provides Redis storage:

idempotency:
  storage: redis

spring:
  data:
    redis:
      host: localhost
      port: 6379

Merge these settings into your configuration and make sure Redis is running.

Things to consider before production use

Idempotency records have a limited lifetime. Once a record expires, you should not assume that an old key will still prevent duplicate processing.

Shared storage is also only one part of a distributed solution. Concurrent requests, failures during processing, and the relationship between business transactions and stored responses need careful testing.

For critical operations, keep appropriate database constraints and business-level safeguards in place. An idempotency layer should not be treated as a blanket guarantee of exactly-once execution.

What’s next?

The project roadmap includes:

JDBC and PostgreSQL storage.
MongoDB storage.
Distributed locking improvements.
Metrics and monitoring.
Additional integration tests.

Try it and share your feedback

The project is open source under the MIT License.

👉 View Spring Boot Idempotency Starter on GitHub

Feedback, bug reports, and contributions are welcome—especially around concurrency and failure scenarios.

How do you handle duplicate requests in your Spring Boot applications?

I Built a Java Library to Transliterate Sinhala Text into Latin Characters

IROSH PERERA — Sun, 20 Sep 2026 07:16:07 +0000

I’m sharing Sinhala Transliterator, an open-source Java library I built to convert Sinhala script into Latin characters using predefined mapping rules.

If you’re building a Java application that works with Sinhala text, this library provides a simple way to add transliteration.

What does it do?

Transliteration represents text in another writing system. It does not translate the meaning into English.

For example:

සිංහල → siṁhala

The library includes mappings for Sinhala vowels, consonants, and diacritics.

Add it to your project

Add this dependency to your Maven pom.xml:

<dependency>
    <groupId>io.github.iroshperera</groupId>
    <artifactId>sinhala-transliterator</artifactId>
    <version>1.1.0</version>
</dependency>

Try it in Java

import com.webmotech.transliterator.SinhalaToLatinTransliterator;

public class Main {
    public static void main(String[] args) {
        String input = "සිංහල";
        String result =
                SinhalaToLatinTransliterator.transliterate(input);

        System.out.println(result);
    }
}

Expected output, as shown in the project README:

siṁhala

Where could you use it?

Potential uses include displaying Latin-script versions alongside Sinhala text and experimenting with Sinhala text-processing tools.

Because the conversion uses predefined rules, test it with your application's actual text samples to check whether the output matches your needs.

Feedback and contributions

The project is available under the Apache License 2.0.

I’d welcome feedback on transliteration accuracy, edge cases, and documentation. If you find an unexpected result, please open a GitHub issue with the input, actual output, and expected output.

👉 Explore Sinhala Transliterator on GitHub

Have you worked with Sinhala text in Java? What challenges did you encounter?