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 -a "parameter_name=value" --dry-run

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

• kernelstub GitHub repository
• Kernel parameters documentation
• AMD GPU kernel parameters

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

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 an imaginary Payment Gateway Software that supports some of the 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 requests 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 attribute 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:

• https://symfony.com/doc/6.4/service_container/tags.html
• https://symfony.com/doc/current/service_container.html#the-autoconfigure-option

If you're using Symfony for a while, you're probably aware of the SYMFONY_DEPRECATIONS_HELPER environment variable that you can set in phpunit.xml config. The variable is part of the https://packagist.org/packages/symfony/phpunit-bridge and comes with most default Symfony PHP Framework installs.

I personally found the naming of the options not very intuitive, and until I played around to figure out the behavior, I didn't really get how they were supposed to be working.

The options

• max[total]
• max[self]
• max[direct]
• max[indirect]
• verbose
• ignoreFile
• logFile
• quiet

max

The max option is used to set a threshold on the number of deprecation notices, either based on their type (direct, indirect) or total number, after which the command line returns an error exit code.

There are several types of suboptions for max:

• max[total] - sets a threshold on the total number of deprecations, both direct and indirect
• max[direct] - puts a threshold on deprecations that resulted directly from your code
• max[indirect] - sets a threshold for on the number of deprecations caused by dependencies
• max[self] - used for libraries that use the depreaction system themselves and cannot afford to use any of the other configurations from above

SYMFONY_DEPRECATIONS_HELPER="max[total]=100" ./vendor/bin/phpunit

vebose

The verbose option is used to get more details about the exact files in which the depreaction notices were triggered. It's often used in a url encoded manner with other options:

SYMFONY_DEPRECATIONS_HELPER="max[total]=100&verbose=1" ./vendor/bin/phpunit

ignoreFile

The ignoreFile option can be used to define inside a file a list of deprecation notices that should be ignored. Note that this feature was introduced starting with Symfony 6.1

SYMFONY_DEPRECATIONS_HELPER="ignoreFile=./tests/ignoreFile.txt" ./vendor/bin/phpunit

ignoreFile.txt :

`Serializer`
`EntityManager`
`Entity`

Basically each row represents a pattern of the files that should be ignored.

generateBaseline & baselineFile

In order to create a baseline file you can use the generateBaseline and baselineFile options as follows:

SYMFONY_DEPRECATIONS_HELPER='generateBaseline=true&baselineFile=./tests/baseline-file.json' ./vendor/bin/phpunit

After the baseline file is generated you could run the tests without the generation option like:

SYMFONY_DEPRECATIONS_HELPER='baselineFile=./tests/baseline-file.json' ./vendor/bin/phpunit

logFile

If you prefer turning off verbose output and write all of the deprecation notices in a file you can use the logFile option. Note that this option also hides the count of deprecation notices at the end of the test run.

SYMFONY_DEPRECATIONS_HELPER='logFile=./var/log/deprecations.log' ./vendor/bin/phpunit

quiet

The quiet option allows to change the verbosity more granularly than vebose and does so per type of deprecation. For example if you want to hide all indirect deprecation notices you could use something like:

SYMFONY_DEPRECATIONS_HELPER='quiet[]=indirect' ./vendor/bin/phpunit

One important thing to note about quiet is that, similarly to vebose, it just hides the details of the deprecations but doesn't change the exist code of the command in any way if the number of threshold deprecations was reached.

Unlike logFile, when using quiet, the count of deprecation notices is still shown.

References:

• https://symfony.com/doc/current/components/phpunit_bridge.html
• https://github.com/symfony/phpunit-bridge

Takeaway 1

• We have the tendency to be bad at evaluating the potential benefits of novel ways of doing things, like using community support instead of paid commercial support.

  "They didn't care that it works in practice because they already knew it didn't work in theory"

Takeaway 2

• How much people in a certain community care about helping each other can be a better predictor for the longevity of a project than the business model

Takeaway 3

• Since the internet emerged, there is a pattern of aggregating care into something long-lasting. Some well known examples are probably Linux and Wikipedia, but there are also some examples where people got together on platforms like MySpace or flickr.

Since the video is from 2007, and I'm writing this in 2023, I wanted to check if the assumption still holds up. So while comp.lang.perl.misc newsgroup doesn't seem that active, also because of the fall in popularity of Usenet, it does seem that the Perl community on reddit is alive and kicking with over 16k members. Same applies for stackoverflow

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.

Option 1: Classic 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.

Option 2: npm-check-updates approach

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:

• https://www.npmjs.com/package/npm-check-updates
• https://docs.npmjs.com/cli/v7/commands

.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/*

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

After doing this, the command behaves as expected

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

One situation where choosing the right perspective is quite important is during Code Review. A lot of times people have different levels of knowledge and familiarity with certain code bases and there is the tendency to be some sort of a disconnect between people's expectations of "how things should be done". There is also different styles of Software Developers, some favoring more implementation and speed, while others favoring more detailed planning and questioning current abstractions.

Another case in which I noticed perspective can play an important role is in politics, and more exactly how people's views of politics are. I think this can be observed from the political debates, but also from how the media covers the topics of the day. I've had the chance to live in two quite different societies (Romania and Germany) and what I saw is that when people tend to favor Perspective 2, there is also a tendency towards more nuance in debates and going deeper in some topics, which can lead to better decisions, that are more in-line with what most of the population is thinking.

One thing that helped me nudge myself more towards Perspective 2 was the Stoic idea of the focusing on the things that you can control. Generally in life there are things that we can control and do something about and there are things that we have no power over. A lot of times we waste our time focusing on the things that we can't control, becoming frustrated in the process, when we could instead just focus what is up to us without focusing on the rest.

So for example when it comes to code review, I can focus on understanding the problem, writing a clear comment and offering a good alternatives where I think improvements are needed, but expecting the other person to listen 100% to my suggestions is unrealistic and entirely out of my control, so I should probably skip that.

When it comes to politics, many have the tendency to expect the Goverment to fix all the problems, and when these expectations fall short, people tend to gravitate towards parties with more radical views, which usually don't have real solutions and bring the state of affairs to an even worse state. What we could do instead would be to try to do all that is up to us for the concrete issues that we want fix. We can report the issues, we can call, email or go talk directly to people that can change things, but that's where our task ends. That's not to say we should be soft on the representatives and allow them to ignore our complaints, but having the unrealistic expectations of things getting fixed immediately doesn't help anybody, neither ourselves, neither our family and friends that have to tolerate our bad mood.

I guess what I'm trying to say is that when giving feedback to other people, keep in mind what you can control and what you cannot. It's healthier for everyone involved.

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:

1. Choose PHP Remote Debugging as CLI interpreter. Make sure local interpreter is removed
2. Choose Docker Compose as the configuration type and devbox-service as the service
3. 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 setup 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 run

 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

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

• Manjaro dotnet setup
• Arch Linux .NET Core
• How to install dotnet core in Manjaro Linux

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