DEV Community: Alexandru Năstase

Editing Linux kernel parameters with kernelstub

Alexandru Năstase — Thu, 14 Aug 2025 20:51:25 +0000

I recently played the gamble of getting a very new processor for my new work laptop, the AMD Ryzen AI 9 HX 370. Even the drivers for Windows seem problematic so I expected there could be some minor hiccups for Linux as well. Luckily the only issue I encountered was one related to the GPU rendering that could be fixed temporarily by updating a kernel parameter. I'm mainly writing this to have a future reference for this kind of change and document some of the things I found out along the way.

Why kernelstub is the safer choice

The simplest way I found to update kernel parameters is by using kernelstub. I remember doing this some years ago without it and I remember the process being a lot more unclear and prone to error, and especially when it comes to this kind of sensitive things I prefer to be on the safe side.

Unlike manually editing boot configurations or directly modifying EFI entries, kernelstub provides a more reliable interface that handles the complexities of modern UEFI boot systems. It automatically updates the correct boot entries and maintains consistency across different boot scenarios.

Basic kernelstub commands

Before making any changes, it's always good practice to use the --dry-run parameter to see what kernelstub would do without actually applying the changes:

sudo kernelstub --dry-run -a "parameter_name=value"

To add a kernel parameter you can use:

sudo kernelstub -a "parameter_name=value"

For example, to add the AMD GPU debug mask parameter that fixed my rendering issues:

sudo kernelstub -a "amdgpu.dcdebugmask=0x12"

You can verify changes by checking the current configuration:

sudo kernelstub -p

Alternatively, you can directly check the boot configuration file:

sudo cat /boot/efi/loader/entries/Pop_OS-current.conf

To remove a kernel parameter use:

sudo kernelstub -d "parameter_name=value"

After making changes, reboot and test that your system behaves as expected.

Tested using

Pop!_OS 22.04 LTS
Kernel version: 6.12.10
AMD Ryzen™ AI 9 HX 370 processor
kernelstub version: 3.1.4

Links

If this guide becomes outdated or if you have any issues with any of the steps, feel free to reach out.

Strategy Pattern in Symfony using attributes

Alexandru Năstase — Mon, 04 Dec 2023 12:00:00 +0000

One of the design patterns that I find myself most often implementing is the Strategy Design pattern. Oftentimes it helps decouple logic and allows better separation of concerns.

In previous versions of Symfony, it was of course possible to implement the pattern, but there was a bit more friction involved, like the need to fiddle with yaml files. This has dissapeared meanwhile thanks to the introduction of the attributes in PHP8. Now that we have the TaggedIterator and AutoconfigureTag attributes at our disposal, it has never been so effortless to implement the strategy pattern using Symfony framework.

In this post, we'll go through a concrete example of how to do this, in which we'll highlight the main components.

Case Study

Let's suppose we're building a Payment Gateway Software that supports most major credit/debit card providers (Visa, Mastercard, and American Express).

To keep things simple we will ignore lots of important elements like the credit card number, CVV, and so on and of course, there won't be any request to external entities.

Acceptance criteria:

Create a POST endpoint called /card-payments that accepts the following JSON payload:

{
  "amount": "12.22",
  "currency": "EUR",
  "provider": "visa|mastercard|amex"
}

The endpoint should return a JSON response containing a transactionId property that has as a prefix the name of the payment provider passed in the input and is followed by some "random" string similar to the example below:

 {
  "transactionId": "visa_asd22kjlkoiposd"
 }

The assumption is that other logic should be dealt for each provider so generating the transactionId should be separated for each card payment provider

An example implementation

Note, that a lot of important aspects like validation, exception handling, and code structuring have not been considered in detail as the focus is on the strategy pattern itself.

First we'll start out by building the CardPaymentController, where we get the payload, deserialize it to a CardPaymentDto, and pass it further to a CardPaymentService which is responsible for finding the correct strategy and retrieving the transactionId from the strategy.

...
class CardPaymentController
{
   ...
    #[Route('/card-payments', methods: ['POST'])]
    public function index(Request $request): Response
    {
        $paymentDto = $this->serializer->deserialize($request->getContent(), CardPaymentDto::class, 'json');

        $paymentResponse = $this->cardPaymentService->handleCardPayment($paymentDto);

        return new JsonResponse($this->serializer->serialize($paymentResponse, 'json'), json: true);
    }
}

After the controller is created we will implement the strategy interface:

#[AutoconfigureTag(CardPaymentStrategyInterface::class)]
interface CardPaymentStrategyInterface
{
    public function isPaymentProviderSupported(string $paymentProvider);

    public function handlePayment(CardPaymentDto $payment): CardPaymentResponseDto;
}

Note the use of the AutoconfigureTag here. Usually, it's more common to use a string here as the service tag, but I prefer using the name of the interface to minimize the chance of typos.

As the interface is defined we can start creating the strategy implementations:

class VisaCardPaymentStrategy implements CardPaymentStrategyInterface
{
    public function isPaymentProviderSupported(string $paymentProvider): bool
    {
        return $paymentProvider === PaymentProvider::VISA;
    }

    public function handlePayment(CardPaymentDto $payment): CardPaymentResponseDto
    {
        // Call Visa payment provider
        // More logic

        $transactionId = PaymentProvider::VISA . uniqid();
        return new CardPaymentResponseDto($transactionId);
    }
}

and similar for the other payment providers:

class MastercardCardPaymentStrategy implements CardPaymentStrategyInterface
{
    public function isPaymentProviderSupported(string $paymentProvider): bool
    {
        return $paymentProvider === PaymentProvider::MASTERCARD;
    }

    public function handlePayment(CardPaymentDto $payment): CardPaymentResponseDto
    {
        // Call Mastercard payment provider
        // More logic

        $transactionId = PaymentProvider::MASTERCARD . uniqid();
        return new CardPaymentResponseDto($transactionId);
    }
}

When the supported strategies are defined we can start implementing the CardPaymentService:

class CardPaymentService implements CardPaymentServiceInterface
{
    /**
     * @param iterable<CardPaymentStrategyInterface> $cardPaymentStrategies
     */
    public function __construct(
        #[TaggedIterator(CardPaymentStrategyInterface::class)]
        private readonly iterable $cardPaymentStrategies,
    ) {
    }

    public function handleCardPayment(CardPaymentDto $paymentDto): CardPaymentResponseDto
    {
        $paymentStrategy = $this->getStrategy($paymentDto->getProvider());

        return $paymentStrategy->handlePayment($paymentDto);
    }

    public function getStrategy(string $paymentProvider): CardPaymentStrategyInterface
    {
        $pickedPaymentStrategy = null;
        foreach ($this->cardPaymentStrategies as $paymentStrategy) {
            if ($paymentStrategy->isPaymentProviderSupported($paymentProvider)) {
                $pickedPaymentStrategy = $paymentStrategy;
            }
        }

        if (is_null($pickedPaymentStrategy)) {
            throw UnsupportedPaymentStrategyException::createForPaymentProvider($paymentProvider);
        }

        return $pickedPaymentStrategy;
    }
}

Note the TaggedIterator attribute here. It allows us to collect all the classes that were auto-configured using the CardPaymentStrategyInterface and have them available as an iterable.
Here we simply find the correct strategy and call it using the PaymentDto and return the result of the picked strategy, which should contain the transactionId.

Make sure that service autoconfiguration is enabled in order for this setup work properly.

Conclusion

Applying the strategy pattern is really straightforward using the latest versions of Symfony and PHP (Symfony 6.4 and PHP 8.2 in the given example).

Apart from keeping the code much more decoupled, it offers the benefit of keeping the code open to extension but closed to modifications. So for example, if we were to add other payment providers, we wouldn't need to touch any of the existing logic thus avoiding the risk of breaking anything there.

To see the entire implementation feel free to check out the git repository.
Additionally from the code shown above, the repository contains a docker-compose setup and some basic tests that you can play around with.

References:

Cross-posted from my blog: The joy of implementing strategy pattern in Symfony

The Developer's Guide to Updating npm Packages

Alexandru Năstase — Fri, 24 Feb 2023 06:46:22 +0000

TLDR: How to upgrade npm packages?

The simplest way is to install npm-check-updates, run npx ncu, followed by npx ncu -u to update the package.json followed by npm install to update packages in package.lock and node_modules.

Vanilla npm approach

npm comes with the tools to upgrade your packages out of the box. When running npm outdated you can get a list of packages that have available updates:

We can update individual packages by running npm update {package-name}. Let's try it for the last package on the list:

npm update sass

Now if we run npm outdated again we can (as seen in the image below) that the package was indeed updated. One thing to note is that while package.lock was updated package.json remains untouched.

Now we could do the same for all the packages and if you have a production-critical application, you probably want to pay close attention to the packages that you upgrade and the implications that an upgrade could have.

Upgrades using npm-check-updates

Another option, that I find slightly more convenient, especially for more low-risk projects is using the npm-check-updates package. To install it simply run:

npm install -g npm-check-updates

After it's installed we can check for updates by running:

npx ncu

Similar to npm outdated this gives us a list of all available updates:

In order to update one single package we can run:

npx ncu -uf sass

followed by:

npm install

Now if we run npx ncu again we see the sass package was updated:

What is nice about the npm-check-updates package is that we can also update all of the packages if we choose so by running:

npx ncu -u

followed again by

npm install

Now if we run npx ncu again we get:

Now both package.json and package.lock were updated, so this makes it clearer what version of the packages we have without the need to look into the package.lock file.

Conclusion

If you want to easily upgrade all your packages you can use the npm-check-updates npm package with the commands shown above, otherwise, you can also use npm's built-in commands npm outdated and npm update.

References:

Cross-posted from my blog: How to upgrade npm packages

What's the meaning of .PHONY in a Makefile?

Alexandru Năstase — Thu, 02 Feb 2023 15:40:51 +0000

TLDR: What does .PHONY actually do?

.PHONY is used to mark a target as phony. That means a target that doesn't take into consideration for execution any file that matches its name.

Let's say we have a target called clear-cache, which removes the cache of an application

clear-cache:
    rm -rf cache/*

Which results in the following command:

The cache removal cli command will be run fine most of the time, but let's check what happens if we add a file with the same name as the target at the same level as the Makefile

Now when running make clear-cache again we get:

The Makefile says basically that it has the target file already and doesn't need
to execute

This default behavior is not what we expect in this case and we want to override it. This is when the .PHONY directive comes to the rescue. Let's update our example to use it

.PHONY: clear-cache
clear-cache:
    rm -rf cache/*

After marking the target as phony, the command behaves as expected

Pro tip: Another way to mark the targets as phony is to have them all in place list rather than above each of them like:

clear-cache:
    rm -rf cache/*
clear-build:
    rm -rf build/*

.PHONY: clear-cache clear-build

Conclusion

In order to override the default behavior in Makefile and use some targets like command runners you can use .PHONY.

References:

GNU Make Manual

Cross-posted from my blog : What's the meaning of .PHONY in a Makefile

Building a simple PHP dockerized environment

Alexandru Năstase — Mon, 09 May 2022 07:02:55 +0000

Unlike other ecosystems like .NET or Java in which containerizing an application for local development might seem more like a burden than a feature when it comes to PHP this is a necessity as well as a welcome bonus of mirroring the production environment very closely.

Some applications might require a PHP extension that is not present on the local system or there might be some specific php.ini configuration that is set on the production server, which is considered as part of the infrastructure rather than the application itself but can cause problems because of the inconsistency (I had this happen to me several years ago). Using Docker can solve these types of problems and has also the added benefit of being a really good way to develop applications, an argument for this being the good support for remote debugging in IDEs.

Overview

I will go through setting up the entire stack, that is PHP 8.1 with fpm, nginx and, mysql as the database and at the end, we will do basic Symfony installation to test everything together.

If you don't just want to check out the repo with the entire setup you can find it on Github

Setting up docker-compose configuration

There are two files that tell docker-compose what to spin up. The first is docker-compose.yml and the other is docker-compose.override.yml. The override file is responsible for exposing the host using the hostname dockerhost. This is useful for both debugging and for referencing other containers more easily.

version: '3.5'

services:
  devbox:
    container_name: devbox-nginx
    build:
      context: ./docker/nginx
      dockerfile: Dockerfile
    ports:
      - "9001:80"
    volumes:
      - .:/app:cached
    restart: unless-stopped
    depends_on:
      - devbox-service

  devbox-service:
    container_name: devbox-service
    build:
      context: .
    volumes:
      - .:/app:cached
      - ./docker/service/php.ini:/usr/local/etc/php/conf.d/99-app.ini
      - ./docker/service/www.conf:/usr/local/etc/php-fpm.d/www.conf
    restart: unless-stopped
    environment:
      XDEBUG_CONFIG: ${XDEBUG_CONFIG}
      APP_ENV: ${APP_ENV}
      APP_DEBUG: ${APP_DEBUG}
      APP_SECRET: ${APP_SECRET}
    env_file:
      - .env
      - .env.local
    depends_on:
      - mysql

  mysql:
    image: mysql:8.0
    container_name: devbox-mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: database
    ports:
      - "3308:3306"
    volumes:
      - database-volume:/var/lib/mysql

volumes:
  database-volume:
    driver: "local"

Adding the Dockerfiles

There are two Dockerfiles used. One for php-fpm and the other for nginx. The one for the app itself is the php-fpm one and it's found in the root of the project and the other one is found in docker/nginx/Dockerfile. The nginx Dockerfile just copies the nginx configuration defined in default.conf into the container. The nginx configuration is quite apart from the fact that the name of the service defined in docker-compose was specified

Dockerfile for nginx

FROM nginx:stable

COPY default.conf /etc/nginx/conf.d/default.conf

Dockefile for php-fpm

FROM php:8.1-fpm-alpine

LABEL maintainer="alexandrunastase@github"
LABEL description="Devbox Docker image"

# User build args
ARG APP_ENV="prod"
ARG APP_DEBUG="0"
ARG APP_LOG="php://stdout"

# Environment variables
ENV APP_ENV=${APP_ENV}
ENV APP_DEBUG=${APP_DEBUG}
ENV APP_LOG=${APP_LOG}

ENV XDEBUG_CONFIG=""
ENV COMPOSER_NO_INTERACTION=1

# Add PHP user
ARG PHP_USER_ID=1000
ARG PHP_GROUP_ID=1000
RUN set -x \
    && addgroup -g $PHP_GROUP_ID -S php \
    && adduser -u $PHP_USER_ID -D -S -G php php

# Install dependencies
RUN set -ex \
    && docker-php-source extract \
    && apk add --update --no-cache \
    ${PHPIZE_DEPS} \
    curl \
    # Runtime deps
    icu-dev icu-libs \
    libzip-dev zlib-dev \
    libxml2-dev \
    oniguruma-dev \
    && pecl install xdebug \
    && docker-php-ext-install intl opcache pdo_mysql zip bcmath mbstring sockets pcntl soap sockets ctype > /dev/null \
    && docker-php-ext-enable intl opcache pdo_mysql zip bcmath mbstring sockets pcntl soap sockets ctype \
    && apk del ${PHPIZE_DEPS} \
    && docker-php-source delete

# Copy configuration files
COPY ./docker/service/www.conf /usr/local/etc/php-fpm.d/www.conf
COPY ./docker/service/php.ini $PHP_INI_DIR/conf.d/99-app.ini
COPY ./docker/service/xdebug.ini $PHP_INI_DIR/conf.d/docker-php-ext-xdebug.ini

# Install composer
COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

COPY --chown=php . /app

WORKDIR /app

USER php

Creating the Makefile

I find a Makefile a useful addition to any docker-compose setup, as it makes it much easier to access the common commands without needing to remember how a container was named or needed to search to the shell history.

Note: When editing Makefiles make sure to always use tabs instead of spaces especially when indenting commands

.PHONY: run
run:
    @if [ ! -e ".env.local" ]; then\
        cp .env .env.local; \
    fi
    @docker-compose up -d
    @echo "Service is running on http://localhost:9001"

.PHONY: install
install:
    @docker-compose exec --user="php" -T devbox-service composer install

.PHONY: stop
stop:
    @docker-compose stop

.PHONY: enter
enter:
    @docker-compose exec --user="php" devbox-service /bin/sh

.PHONY: enter-as-root
enter-as-root:
    @docker-compose exec --user="root" devbox-service /bin/sh

.PHONY: test
test:
    @docker-compose exec --user="php" -T devbox-service /bin/sh -c 'APP_ENV="test" ./bin/phpunit --testdox'

.PHONY: destroy
destroy:
    @docker-compose down --rmi local

Adding Symfony and testing everything

To test the entire setup we can setup a Symfony application. You can find instructions to do so here: https://symfony.com/doc/current/setup.html . I went with the LTS version which is 5.4 at the time of the writing.

Note: I also updated the composer file to make sure the database is created. You can skip this if you have another way to make that happen.

Setting up xDebug

Debugging can be enabled by uncommenting the contents of the file ./docker/service/xdebug.ini

These are the steps to configure xDebug on PHPStorm:

Choose PHP Remote Debugging as CLI interpreter. Make sure local interpreter is removed
Choose Docker Compose as the configuration type and devbox-service as the service
Lifecycle should be Connect to existing container

Working demo

In the docker-compose the port 9001 is mapped for the localhost so you can check everything is working after running:

 make run

to se tup the containers

 make install

to install all the composer packages.

There is one endpoint defined called http://localhost:9001/healthz which should return a 200 status code

In order to run the tests, you can use

 make test

and for running other ad-hoc commands like requiring another composer package you can do

 make enter

Tested using

Ubuntu 21.10
docker version : 20.10.14
docker-compose version : 1.29.1

cross-posted from my blog: Building a simple php dockerized environment

How to install .NET core SDK with ASP.NET on Manjaro Linux

Alexandru Năstase — Sat, 26 Sep 2020 07:18:11 +0000

I recently switched from Fedora to Manjaro as my main Linux distribution and since I use .NET core from time to time I wanted to install it. It turns out that since at the time of this writing, it's not officially supported, as it was the case with Fedora, there was a bit more trial and error involved in the process.

My first attempt was to try to install it using snap, since it mentions Manjaro in the supported list. I had some issues when I installed it like this, among which the biggest was that the official C# extension in VS Code, OmniSharp, was not working.

The good news is that there are official Arch Linux packages with the .NET Core SDK now.

Steps to install

Install dotnet-sdk with asp.net runtime:

sudo pacman -S dotnet-sdk aspnet-runtime

In order to have the needed environment variables and the dotnet root in PATH, create a/etc/profile.d/dotnet.sh file with the following contents:

export DOTNET_ROOT=/usr/share/dotnet
export MSBuildSDKsPath=$DOTNET_ROOT/sdk/$(${DOTNET_ROOT}/dotnet --version)/Sdks
export PATH=${PATH}:${DOTNET_ROOT}

Note: After this step, a reboot or re-login is required.

Depending on what shell you use, append to the .bashrc or .zshrc configuration files the following:

# Adds dotnet tools to the PATH variable
export PATH="$PATH:/home/[[USER_NAME]]/.dotnet/tools"

This allows tools like dotnet watch or dotnet ef to be available globally
Although some people suggest also adding DOTNET_CLI_TELEMETRY_OPTOUT=1, I would advice against it for now, given the fact the Arch Linux is not officially supported and Microsoft might also take into account the usage statistics when prioritizing bug fixes or support for certain Linux distributions.

Tested using :

Manjaro version: 20.1
Kernel version: 5.8.6-1-MANJARO
dotnet version: 3.1.107

Links:

If this guide becomes outdated or if you have any issues with the any steps feel free PM me on Twitter .