And that’s why I’ve seeked the opportunity to switch up for some time with a colleague that felt in a similar way working on a different project within the Red Hat.

And that’s how I ended up for 2 quarters in the DNF Team working on dnf5. I’ll try to sum up my experience over the 2 quarters.

Agile processes​

As of the time of me switching from the Packit Team to the DNF Team, our organization has been in the process of hiring a dedicated Scrum Master.

It was my first time being a part of a team that has a dedicated agile practitioner. I was not used to this experience.

On one hand it feels nice to have someone having your back and handling most of the annoying stuff, e.g., Jira shenanigans, or calendar and such, and, in general, being in control of the whole agile process and ceremonies tied to it.

In Packit we are using a scrumban¹, so getting back to scrum kind of made me relive some of the annoyances of scrum by itself, e.g., the time constraint to 2 weeks.

Carrying tickets over to the next sprint is quite common and also pulling in tickets during the sprint too…

Meetings​

One thing that caught me by surprise was the low amount of meetings, partially contributed by the asynchronous stand ups².

Also the DNF team is spread across multiple time zones, so the meetings are set in the afternoon for the European folk.

Story points​

As always, estimation of size of tasks is quite relative thing. There are teams that measure the story points by days, weeks, etc.

In the Packit Team we’re using the Fibonacci scale with a few rules that give quite basic idea of the sizing.

After a quick glance through the DNF’s backlog I’ve noticed mostly higher points being assigned, which is totally OK, since it’s relative. However it also clashed a bit with my perception of sizing after 5 years in Packit 😁

Another difference to Packit was the fact that the story points were assigned by the colleagues that were triaging the new issues/tickets at the time. Because there was no agreement across the team on the difficulty assessment, the story points vary (IMO at least).

Technical perspective​

Developing for Linux on macOS can be challenging at times. One would expect that developing service revolving around Linux packaging and testing would be even worse, but it’s not that problematic in reality, since everything is nicely containerized.

Developing a package manager on the other hand… is also not an issue, unless you need to run the tests.

Development environment​

Setting everything up was a bit challenging. In the end I have settled for a Fedora Rawhide container where I mounted both sources and tests⁴.

Running the test suite based on behave was however not possible… Main cause of failure was coming from the fact there were some tests for testing architecture fields in specfiles which, of course, breaks the assumptions on the Macs. To be fair, the different architecture (Apple Silicon) is to blame, not the OS itself.

One of the other ARM⁵ quirks I hit, was not being able to utilize parallel builds. When I tried compiling with the classic make -j$(nproc) on Linux, it worked just fine. However from within the container on the Mac, it hit some race conditions that caused the build to fail.

First RHEL bug​

For the first time in 5 years, I have been assigned a task that affected RHEL directly…

Finding the issue and fixing it was probably the easiest part. Getting the fix all the way down to RHEL is where things complicate.

DNF Team handles the downstream patching in such way that they keep the RHEL branches on the upstream. To these branch you backport (most commonly simple git cherry pick) the fixes and then you can easily generate patches that are added to the RHEL specfile.

The whole process is simple and straightforward. Except… resolving the ticket consists of:

• fix in the source repo and test coverage (2 MRs, because tests are on its own)
• backporting both fix and tests (+2 MRs)
• then actually adjusting the specfile on downstream (+2 MRs; depends on how many releases is the fix propagated to)

Each of those MRs should be reviewed. Even if it has already been reviewed, cause, don’t forget, 2 of those are simple cherry picks and the specfiles, in the end, consist again of the already reviewed patches.

And even then it took me additional two merge requests, because neither I, nor my reviewer, have realized that I am missing part of the tests in the backport. Those have been added during the triage a long time before I got the ticket assigned.

Summary​

Overall it was a very pleasant experience trying to onboard a different project with different workflows and processes. Maybe I’m biased prior to my previous experience, but the way we set up agile in Packit feels a lot more intuitive.

I’m also content that I was able to contribute to the package manager that I use on a daily basis as a user.

Day 9: Movie Theater​

First part was pretty easy, very simple thing to literally brute-force. On the other hand… the second part was a bit worse.

My idea was a pretty primitive one, just do the same thing as in the first part and filter out the options that are not valid.

Turns out that the process of deciding what is and what is not valid is the problem.

In the end I have managed to refactor the solution into:

@Override
Long part1() {
  return getBiggestTriangle(_r -> true);
}

@Override
Long part2() {
  return getBiggestTriangle(this::isValidRectangle);
}

Changes to library​

“Queue consumer”​

This was the second day when I had to utilize the heap consumer¹, so I have decided to factor it out to the library. Since the method itself accepts an object implementing Queue<T> interface, I have renamed it to consumeQueue():

/**
 * Creates a stream that consumes elements from a queue.
 *
 * @param <T> the type of elements in the queue
 * @param queue the queue to consume elements from
 * @return a stream of elements from the queue, in the order they are polled,
 *     terminating when the queue becomes empty (when {@code poll()} returns
 *     {@code null})
 */
public static <T> Stream<T> consumeQueue(Queue<T> queue) {
  return Stream
    .iterate(queue.poll(), _it -> queue.poll())
    .takeWhile(it -> it != null);
}

pairs() and helpers​

For iterating over the possible choices, in this puzzle, I had to generate all possible pairs from an input. Overall it made sense to just implement a method that takes a stream and generates the pairs:

public static <T> Stream<Pair<T, T>> pairs(Supplier<Stream<T>> xs) {
  return zip(indices().boxed(), xs.get())
      .flatMap(p ->
        xs.get()
          .skip(p.first() + 1)
          .map(y -> Pair.of(p.second(), y)));
}

However, in the end, I needed some other helpers to get there… Namely it was easier to implement infinite indices() rather then iterate the stream twice.

Also you can notice that pairs() gets passed a Supplier<Stream<T>> rather than the stream itself. That's coming from the fact that streams can be iterated through only once, so I need to have a functional object that generates a new stream each time I need it.

Day 10: Factory​

This day… was a scam. For the first part you had to light up lights on the machine in a specific configuration. Part of the input were buttons that contain a list of lights that get toggled with each press.

A lot of people chose to go with integral representation of the lights and buttons and then just applying simple XOR.

I didn't try to simplify the inputs, so I've ended up with lists (or sets) of integers and used BFS for solving the first part.

And… second part is where the fun starts.

For the part 2 you have to find minimal number of presses to raise joltage to the seeked joltage…

The search space for this problem is enormous… I've tried a very naïve approach of preprocessing the buttons for each machine in such order that narrows the search space. This approach was relatively effective, but not effective enough 😄 To cut the story short, I've ended up with 97 % of the input processed, but got stuck there for 3.5 hours after which I killed it.

Once the solution has been running for about 30 minutes, I have started to pick away here and there to optimize bit by bit. And it was pretty effective! To sum it up:

• I had a method to generate counters (i.e., long[] of zeros); in the initial solution I used range().map().toArray(), switched it to simple new long[]

• for read-only operations, where possible, I've switched to parallel streams instead of sequential

• changed the strategy of exploring the search space; instead of going from minimum needed to maximum possible presses of a button, I've turned it around and went from maximum possible to minimum needed, which prunes the unreachable branches quicker

• and finally the recursive calls that get called for each button press… for each of this calls I create a separate “goal” joltage the search is supposed to address, that way I can paralelize those too

And this has gotten me from 3.5 hours (still missing the last 4 results) to 6 minutes.

Day 11: Reactor​

Relatively easy way to solve this. Can be done recursively, it's basically just going through the graph, trying to find a way to the goal. And at the same time counting how many ways there are…

I have to admit that I did not expect to get burnt at this Java-specific thing on the 11th day 😄 I've been teaching at Intro to programming for years that sometimes it's not a good idea to use niche features specific only to one or two languages, yet… At first I didn't realize at all that

if (from == sink) {
  return 1l;
}

does something totally different than

if (from.equals(sink)) {
  return 1l;
}

== compares references, and, as opposed to other languages like C++ or C#, cannot be overriden. However I noticed this mistake rather quickly, cause the graph traversal doesn't terminate, duh…

I expected to make this mistake during the beginning, not at the second to last day.

Day 12: Christmas Tree Farm​

At the first look, the problem looks extremely annoying. And it kinda is… The fun thing is that it is possible to solve simply by expecting a bit more area, as a buffer, to be occupied by the tiles and simply checking whether it could fit.

What's even more funny is the fact that the provided sample is quite picky about this, i.e., you need to account for 20 % buffer to make it pass. However the challenge input… that works without any buffer…

Final changes to the library​

Parser.of()​

I've tried to simplify the parser a bit, so I introduced a method Parser.of() to be able to construct instances of parsers without the need to use new and <> for type inference of the resulting types to be produced by parsing…

Summary​

Advent of Code itself​

I have a bit of mixed feelings. Thankfully, this year, there was only one day that was particularly obnoxious with regards to parsing.

There were only 12 days instead of the usual 25. I have tried to solve all days at 6am (CET) and… I'm not very used to writing Java at 6am to be honest 😄 So I definitely don't mind an early end on that front 👀 Though it is quite known that the complexity of the tasks grows towards the end of the AoC, so this year might seem a bit easy-going? I can understand the need for a bit of a challenge.

Java​

Even though Java is the first language I've learnt and also learnt to hate further on, it was quite pleasent experience in my opinion. I confess to abusing the streams and other FP-like “features”.

I definitely hate the boilerplate for each day… but looking back at it, it makes it quite customizable, so, for example, in day #8 I was able to simply add the constraint (which was different for sample and challenge input) to constructor and it allowed pretty easy testing and computing the challenge at the same time.

Toolchain​

I didn't feel comfortable working with either IDEA or VSCode. They each have their own quirks, e.g., not working completion (which is definitely helpful with streams and data structures), or issues running the puzzles in a way that would fit my workflow.

OTOH it was a quite pleasant experience with testing (apart from constructors in classes that are not instantiated) and also doc-generation. Though I feel that javadoc is still… bit obscure format for me.

Day 5: Cafeteria​

Pretty eazy to solve, given that you chose a good representation for the input. Even spotless thought it's a good idea to keep the solution for part 1 on one line 😉

I have also tried using the IDEA instead of the VSCode, but… I've hit different issues with the IDE 🤦‍♂️

• VSCode has trouble with the source dependencies defined by gradle and that's why any completion or type inference in the editor fails miserably :)

• as for the IDEA… type inference and completion works, but it has the same problem except for the fact that it »disassembles« compiled *.class files of the library and that's how it gets type inference and completion to work, but…

  still no javadoc and on top of that running the “app” is problematic, as I have not been able to get any output from the app in case it fails with an exception 😄 not even with --stacktrace… the output just vanishes

So in the end I've decided to revert back to the VSCode, as running the app is a bit more comfortable than fighting the runner in IDEA.

Parsing intermezzo #1​

This is the day when I decided to improve the parsing situation. From the previous years and other languages I've noticed some patterns, with Java… I did not notice any 👀

• For Rust there's a FromStr trait that allows you to use T::from_str() that can either return the parsed structure or an error.

• In Kotlin there was a funny “convention” of extending strings with a method .toSomething() which would allow you to do: "1,2".toPoint() or something similar.

• In C# there's a pretty good construct of

  public static bool TryParse(string? s, out T result);
  

  It seems a bit complex, but basically it allows you to get a result of the conversion as a return value (the bool indicates success or failure) and at the same time you can populate an out variable with the parsed data. Overall it can be combined into:

  var stringRepresentation = "1,2";
  if (Point.TryParse(stringRepresentation, out var point)) {
    Console.WriteLine($"Parsed point of x={point.x} y={point.y}");
  } else {
    Console.WriteLine($"Failed to parse: ‹{stringRepresentation}›");
  }
  

As I have not been able to find any convention about that in Java, apart from the parsing method for primitive data types: Integer.parseInt() or Long.parseLong(). I have decided to come up with something suitable for AoC myself:

public abstract class StringParser<T> {
  public abstract T from(String s);

  public Stream<T> from(Stream<String> xs) {
    return xs.map(it -> from(it));
  }

  public Stream<T> from(List<String> xs) {
    return from(xs.stream());
  }

  public Stream<T> from(String[] xs) {
    return from(Arrays.stream(xs));
  }
}

We have a few adapters over the unimplemented method, so it is easy to parse multiple values at once. And one abstract method that defines parsing from a single string.

During the testing I have found out that… it works well, but at the same time is quite verbose:

@Test
public void testParse() {
  try (var input = new Input(69, "regression")) {
    char[][] map =
        new char[][] {
          "123049575901212312312313".toCharArray(),
          "123123130999555554444433".toCharArray(),
          "000111100022222330000000".toCharArray(),
        };
    assertArrayEquals(
        map,
        input.parse(
            new StringParser<char[][]>() {
              @Override
              public char[][] from(String s) {
                return Arrays.stream(s.split("\n"))
                    .map(row -> row.trim().toCharArray())
                    .toArray(char[][]::new);
              }
            }));
  }
}

As you can tell there's a lot of boilerplate still… And that's where I got inspired by the higher-order functions in Java. Even though they accept “callable” objects, you don't that much boilerplate around them. And the reason why you don't is a functional interface.

Functional interface​

Given this annotation, I have converted StringParser<T> into:

@FunctionalInterface
public interface StringParser<T> {
  T from(String s);
}

And to be able to utilize the other methods, if needed:

public class Parser<T> implements StringParser<T> {
  private final StringParser<T> parser;

  public Parser(StringParser<T> parser) {
    if (parser == null) {
	      throw new IllegalArgumentException("‹parser› cannot be null");
    }
    this.parser = parser;
  }

  public T from(String s) {
    return parser.from(s);
  }

  public Stream<T> from(Stream<String> xs) {
    return xs.map(it -> from(it));
  }

  public Stream<T> from(List<String> xs) {
    return from(xs.stream());
  }

  public Stream<T> from(String[] xs) {
    return from(Arrays.stream(xs));
  }
}

And the parser above can now be written as:

@Test
public void testParse() {
  try (var input = new Input(69, "regression")) {
    char[][] map =
        new char[][] {
          "123049575901212312312313".toCharArray(),
          "123123130999555554444433".toCharArray(),
          "000111100022222330000000".toCharArray(),
        };
    assertArrayEquals(
        map,
        input.parse(
            s -> {
              return Arrays.stream(s.split("\n"))
                  .map(row -> row.trim().toCharArray())
                  .toArray(char[][]::new);
            }));
  }
}

Day 6: Trash Compactor​

For this day we also have a photo from this year's setup at 6am 😉

And the old Advent of Parsing is back…

123 328  51 64
 45 64  387 23
  6 98  215 314
*   +   *   +

Surely that whitespace around the numbers has no meaning, right? RIGHT?!?!

Part 1 was relatively OK, just treat the last row as special, since it has operators and then for the other rows, split on whitespace and trim all other whitespace.

As for the second part… that was not fun… had to rewrite almost all of the parsing. After making up an algorithm for handling the different representation of numbers (one column of digits being a number), and still getting wrong results, I noticed that the alignment from both sides matters 🤦‍♂️

However after the refactoring I got to a solution that accepts an operator and a stream of numbers, so it boiled down to one function doing “the math” and the two other (for each part) just passing a stream of numbers to it…

Day 7: Laboratories​

Part 1 was not the easiest to comprehend when reading it for the first time. However if you get what you're supposed to do (and do not try to be smart about it), it is rather easy to solve.

During the refactoring I've done several improvements, though… I have to admit that in the end I might've overdone it a bit and it's kinda… perverted.

Since you're splitting beams on the splitters, the initial solution contained a following bit of copy-paste:

if (manifold[y][x - 1] == '.') {
  // …
}

if (manifold[y][x + 1] == '.') {
  // …
}

Which I have managed to refactor into:

for (int dx : new int[] {-1, 1}) {
  if (manifold[y][x + dx] != '.') {
    continue;
  }
  // …
}

And I couldn't stop there… I have also decided to use switch-expressions where possible. For example the computation of possible timelines from part 2:

dp[y][x] =
    switch (manifold[y][x]) {
      case 'S', '|' -> get(y + 1, x);
      case '^' -> get(y, x - 1) + get(y, x + 1);
      default -> throw new IllegalStateException("no need to evaluate empty cells");
    };

Furthermore I have decided to convert the for-each-loop above into a stream… and once I got a knack for it… I have created an adapter for consuming the queue as a stream 🤦‍♂️

private <T> Stream<T> consumeHeap(Queue<T> heap) {
  return Stream.iterate(
      heap.poll(),
     _it -> heap.poll()
    )
    .takeWhile(it -> it != null);
}

Fun thing is, since the stream is lazily evaluated, you can add more elements to the heap while iterating through it. So it basically can work as a for-each-loop through the heap as long as there's something in it.

Changes to library​

Pair.of()​

For the cases where it is possible to use type inference, I have stolen a helper from @semuil to avoid unnecessary clutter, i.e., new and <>:

new Pair<>(x, y)
// turns into
Pair.of(x, y)

Day 8: Playground​

The core of this puzzle was to repeateadly connect the closest boxes together.

Now the first part was relatively easy to solve, though the abstraction hurt a bit here. More specifically we want to partition the boxes into subsets in such order that the one with the closest distance are together in one subset.

So… you need to be able to track to which partition each box belongs. Therefore the easiest solution was to simply keep indices in the heap and keep an array with “marks” for each partition.

And this is where I screwed up royally and was not able to find my mistake for some time 😄

To sum up what we're going to do:

We pick the closest two boxes from the queue, if they're already in the same partition, we can safely ignore and proceed. Otherwise we need to merge the partitions into one.

This should be achieved with the following code:

consumeHeap(queue)
  .limit(maxConnections)
  .forEach(
    it -> {
      var a = it.first();
      var b = it.second();

      if (mapping[a] == mapping[b]) {
        return;
      }

      for (var i = 0; i < mapping.length; ++i) {
        if (mapping[i] == mapping[b]) {
          mapping[i] = mapping[a];
        }
      }
    });

Except for one smaller issue… that I was not able to find for the longest time possible 😄

//      vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
        if (mapping[i] == mapping[b]) {
          mapping[i] = mapping[a];
        }
//      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

for-loop is supposed to take each box from the same partition as the latter box from the two closest ones and move it to the partition of the first box. And it does that… but once it wipes the mark of the original parition, cause it is equal to itself (duh…), we lose the track and everything from that point onwards stays in the original partition.

That was a rookie and quite stupid mistake that cost a lot of time…

As both parts are quite similar, I have managed to refactor the common logic into:

@Override
Long part1() {
  consumeHeap(queue).limit(maxConnections).forEach(this::connect);
  // construct the answer to part 1
}

@Override
Long part2() {
  Pair<Integer, Integer> it = null;
  while (sizes.size() != 1) {
    it = queue.poll();
    connect(it);
  }
  // construct the answer to part 2
}

Changes to library​

Euclidean distance​

Since the Euclidean distance used in this puzzle seemed handy, I moved it out to the library. Funnily as part of the optimization I've used the squared Euclidean distance throughout this puzzle, so the interface includes both actual distance and the distance squared.

Preparations​

As usual I prepare the repo for the year and also some kind of a library with helpers that I use regularly during the AoC challenges.

Library with helpers​

Library for AoC consists mostly of parsing helpers, as there's a long-going meme of referring to Advent of Code as Advent of Parsing. Additionally it's also helpful to have 2D/3D vectors and maybe math functions or iterators.

Basic list of helpers I've prepared for myself for the Advent of Code in Java:

• IO - for reading an input; as it has a common structure, the sample and the challenge input itself

• iterators - implementation of the column iterators that are usually needed for iterating over maps, if they occur in the challenge input

• streams - implementation of some algorithms that generate streams

• math - GCD and LCM implementations for now as they are not included in the Java itself

• vectors - as always…

static classes​

You can probably tell from the prrevious list of helpers that almost all of the required functionality does not depend on having an instance of a class itself.

For example the GCD and LCM doesn't need any instance, they're just simple functions.

Yet during the testing I've discovered that there's no easy way to deal with such thing. Classes in Java can be made static, but only if they're nested within some other class which makes them hidden from outside.

Generics for numerics​

One thing I hated the most about implementing the vectors is the fact that you cannot make the vectors generic…

This is caused by non-existing interface for primitive data types. Therefore it's not possible to create a generic class for vector.

I had to result to implementing two different classes that differ only in the underlying data type of the coordinates:

// Representing a 2D or 3D vector having the floating-point coordinates.
public class FVec {}

// Representing a 2D or 3D vector having the integral (as ‹Long›) coordinates.
public class IVec {}

Parsing input​

I have started with a simple class that allows me to read the input by lines and do very simple parsing.

try (var input = new Input(1, "sample")) {
  // read whatever you want
}

I will leave out the boring technical part and just show how the input class works:

public Stream<String> lines() {
  return bufferedReader.lines();
}

public String asString() {
  return lines()
    .reduce((a, b) -> String.format("%s\n%s", a, b))
    .orElse("");
}

public Stream<Integer> asInts() {
  return lines().map(Integer::parseInt);
}

public Stream<Integer> asCommaSeparatedInts() {
  return Arrays
    .stream(asString().split(","))
    .map(Integer::parseInt);
}

Stream helpers from LeetCode​

Also I've been able to snatch some Stream helpers after doing the LeetCode challenges. They cover the following functionality:

• range() that generates a stream in a similar fashion as the Python function, you might know, would

• indices() that returns a stream of indices over an array or a List<T>

• product() that takes two functions that can generate streams and returns a stream of cartesian product over said streams

• zip() that “zips” two streams; providing both customizable zipping and simple zip that just returns pairs of values

Abstract class for representing a day​

Each day runs in the same way, the only difference is in the parsing and solving the challenge itself. Each day has both parts, nowadays a sample input with provided answers for testing. Therefore I have created for myself an abstract class that takes care of these things:

abstract class Day<T1, T2> {
  abstract void precompute();

  abstract T1 part1();
  abstract T2 part2();

  abstract void runAll();
}

I have added a precompute() method in case there are some things that could be precomputed for both parts right after parsing.

Also with Java I've run into a limitation that doesn't allow me to test sample inputs and run for the challenge input without a lot of copy-paste, so I've created an abstract runAll() method which gets called when running the whole app and can be used in a following way:

@Override
void runAll() {
  new Day01("sample").test(42, 69);
  new Day01("input").run();
}

Still an annoying and technically a copy-paste, but somehow better.

Build system and whatnot​

Since it's Java and I have my own library in a separate repository there's a need to use some kind of a build system and also other tools.

gradle​

It has already been some years I had Java course at the university, where we used Maven. And I've read some stuff about gradle, also it was used in the AoC template for Kotlin done by the JetBrains, so it wasn't very hard to adapt.

Though there were some issues hit, I'll get to them later on.

spotless​

While writing the library I noticed that it's rather hard to have consistent formatting and the VSCode extensions don't do a very good job with formatting and cleaning up imports and such. I searched a bit on 🦆 and found spotless.

Looking at the git repository now I have to admit that it can be applied to a multitude of languages, so they must be doing something right…

testing​

For the library I've decided to use whatever was in the gradle template for Java library.

As for the puzzle solutions themselves… That's rough to decide:

• with Kotlin it was a matter of simple check() statements that throw an exception if the assertion fails

• with Rust I had a very good experience using my own macro machinery to create a mod with tests for each day; I have to admit that this setup together with bacon has been the best I've ever achieved

This time I have decided to go with two separate “runners” in the abstract class for each day:

• run() that simply runs and reports from each part:

  void run() {
    System.out.format("\n[TRACE] Running input:\t‹%s›\n", inputType);
  
    System.out.println("  [INFO] Running precompute()");
    precompute();
  
    System.out.print("  [INFO] Part 1:\t");
    System.out.println(part1());
  
    System.out.print("  [INFO] Part 2:\t");
    System.out.println(part2());
  }
  

• and test(x, y) that does basically the same, but also checks the results:

  void test(T1 answer1, T2 answer2) {
    System.out.format("\n[TRACE] Testing input:\t‹%s›\n", inputType);
  
    System.out.println("  [INFO] Running precompute()");
    precompute();
  
    if (answer1 != null) {
      System.out.print("  [INFO] Part 1:\t");
  
      var result1 = part1();
      if (!result1.equals(answer1)) {
        System.out.printf("[KO] Given answer: ‹%s› (expected ‹%s›)\n", result1, answer1);
      } else {
        System.out.println("[OK]");
      }
    }
  
    if (answer2 != null) {
      System.out.print("  [INFO] Part 2:\t");
  
      var result2 = part2();
      if (!result2.equals(answer2)) {
        System.out.printf("[KO] Given answer: ‹%s› (expected ‹%s›)\n", result2, answer2);
      } else {
        System.out.println("[OK]");
      }
    }
  }
  
  void test(T1 answer1) {
    test(answer1, null);
  }
  

Day 1: Secret Entrance​

I didn't expect to smack an enum class and record right away on the first day, but here we go.

Overall haven't hit any issues. Except for the fact that closures are something that Java has never been designed for… Which means that you cannot modify references of higher data types or values of primitive data types of variables from an outer scope of a closure… This is something that I don't really like and it kinda defeats a purpose of .reduce() or .forEach().

Day 2: Gift Shop​

You could choose to solve this by having “fun” with strings, or if you are capable of running the mental masturbation, you can also have fun with decimal numeral system.

Chosen the latter, though the adjustment for the second part was not that easy…

Leading zeroes were something that caused some trouble on my end, but I got over it.

Day 3: Lobby​

Part 1 was relatively easy… a lot of copy-paste in the first solution.

Part 2… that was not okay and it took some time to get over it. Probably had a bad sleep or something, I knew what I want to do, but I just couldn't write it in the code and always hit some problem, almost felt like a whack-a-mole.

Day 4: Printing Department​

Pretty straightforward for solving… Initial solution contained quite a lot of copy-paste, of course.

Trying to refactor the solution brought to surface first issues with Java… What I hate the most, is the fact that I am not able to make type aliases correctly. The closest I've gotten to a type alias is something like:

private class Index extends Pair<Integer, Integer> {}

However that creates issues on its own, because, well, it utilizes the inheritance to construct a type alias. And the properties of the inheritance are the issue here.

More specifically, as you may know from OOP, you can reference objects of Index as Pair<Integer, Integer> as they “extend” the latter type, but you cannot do that in the other way… Because Pair<Integer, Integer> doesn't have to, and usually doesn't, implement anything under the Index. Even though we don't add anything, there's not an easy way to tell…

This is the first day where I started to abuse the relatively new Stream features of Java 😉 More specifically, part 2 of the puzzle was to repeat part 1 until you run out of possible candidates. You can probably tell that the first go-to of anyone would be to go for do-while loop, which I did in the initial solution, but then I thought that it might be possible to just “abuse” the Stream 😈 so I did…

return Stream.iterate(
  removableRoles().toList(),
  indices -> !indices.isEmpty(),
  indices -> {
    indices.forEach(idx -> map[idx.first()][idx.second()] = 'x');
    return removableRoles().toList();
  })
  .mapToLong(roles -> roles.size())
  .sum();

Purpose and past​

After I've subscribed a VPS at vpsfree.cz for myself, I got an opportunity to drop using an old laptop for running a local “server”. At that point all I've had was self-hosted Gitea, some aliases on nginx and that was all. Out with the old laptop and let's begin experimenting with the Raspberry, right?

The first OS that got on the Raspberry was archLinux (BTW…). I've been using it for a long time and had the best experience with. I haven't hit any issues, but at the same time, you need to keep in mind we're running it off the SD card and they are known to get worn out quickly, especially if you write a lot which… guess what, is quite common with rolling and bleeding-edge distribution 😄 And the worst part is keeping up with the updates.

And that's how I migrated to openSUSE Leap :) I've been using openSUSE for at least 4 years during the high school and a bit more before and after… openSUSE is very user-friendly (YaST is amazing) distribution and honestly just works. However the cost lies in Cockpit not being available¹ and some weird design decision, e.g., networking stack is very fragile².

And I've got finished in the recent weeks with some issues during updates, but those can be, of course, blamed on me, cause I don't watch over it as I should :)

I should probably sum up the latest state of what was running before I decided to go for a merciless wipe. So here it is:

• local Gitea instance, just in case and out of habit
• Wireguard connection for easy administration
• Certbot & nginx; nginx is probably the biggest piece of work as it also provides reverse proxy for mikrotik router and Ubiquiti AP provided by ISP
• CUPS server that has joined the journey once the HP printer was too big of a pain in the 🍑 to handle via USB
• DDNS service, cause there's public, but dynamic IP from ISP

Choosing the next distro​

I had the switch in mind for some time, but I couldn't decide on the distribution… In the ideal world, I'd just slap CentOS Stream on it, but there's no Raspberry “support” for CentOS³. So the other choices were plain Debian and something else from the RHEL-family which could be either Fedora⁴, AlmaLinux or Rocky Linux.

I should admit that I'm not a big Debian fan 😄 Even though 12 bookworm is relatively on the same terms as anything that tries to match RHEL9, it still feels weird. That might be caused by the fact that I've switched RPM-based distributions a long time ago (including screwing around with archLinux and Jean Tux⁵) and never looked back (except for the desktop with NVIDIA GPU that's pain in the 🍑 and only Ubuntu runs reasonably… well).

Wearing the red fedora also ruled out the Rocky Linux 🙂 as I don't endorse nor support their way of operation

So AlmaLinux it is!

Installing AlmaLinux 9​

I'm going with AlmaLinux 9.4 on Raspberry Pi 3B. Opened the AlmaLinux's wiki and first thing I got slapped by is

original Raspberry Pi 3 (without "+" models) are not supported

GREAT! I took the risk, installed it. And it didn't boot 😁 It turns out that the WiFi kernel module caused a kernel panic on the boot. From some people on Reddit I found that it caused some issues, but worked, so I've just decided to pop the SD card back in a PC and deny the module from loading. Voilà! It boots!

Setting up the “local server”​

Both the Raspberry and my VPS are maintained in the caveman-style 😄 And that's why I've decided to start with the less painful one (the Raspberry) to write the Ansible playbooks for :)

I have already managed to migrate my dotfiles and “bootstrap” to be run via Ansible, so I've just proceeded to extend that and also reorganize it a bit, cause the roles grew in size 👀

And I have to admit that I've been mostly successful. Let's delve into details!

SELinux​

Yeah… that's something that hasn't been running on the openSUSE and I totally forgot that hardening the SSHD config (including port change) requires notifying SELinux about the port change :) Of course I managed to cut myself off 😄

Certbot​

Certbot was the service I feared the most, as there is no reasonable way to automate this. You need to run it manually at least the first time. But in the end, it was quite OK.

Cockpit​

One downside of caveman-style administration is the fact that you forget about the tweaking you do. Reverse proxy breaks Cockpit by default. I was reading through the documentation, but haven't managed to find the part that mentioned the specific settings I had to change. When I was about to open the PR with proposed changes, I noticed that it was in a different chapter 🤦‍♂️

CUPS​

Cups went rather smoothly… except for the fact that it doesn't work on the one and only Ubuntu desktop and there are no logs with reason why it fails to add the printer 🙂

Additionally installing the HP printer via hp-setup is very interesting experience… I would've never expected the CLI to have a progress bar that opens up at 0% and then just switches into terms & conditions… Yes, that progress bar stayed at 0% even though it was downloading a PPD file and progressing.

DDNS​

I had smallish issue with deciding how to run the DDNS service. I went with dropping my own buggy script and had to choose a DDNS client. Found inadyn (that isn't built at all for Fedora and family) and ddclient. The ddclient had some not very nice feedback, and the version that introduced the Cloudflare support I need, was not included, so I dropped that. inadyn is not packaged, so I've set it up as systemd timer spawning a container :)

Summary​

Overall I've had a very pleasant experience setting up the AlmaLinux on the Raspberry. Even though I took a gamble with the officially unsupported model of RPi, it works. And it also seems to be filling the purpose it has!

Day 1​

Let's start with the first day which was Thursday this year as opposed to the previous years when the conference started on Friday and finished on Sunday.

Let's start with the keynote. The keynote wasn't very interesting, at some of the slides actually felt like advertisement for other talks on the topic of the AI…

Next talk about event-driven Ansible was way more interesting. It allows you to run Ansible playbooks after provisioning hosts, or on certain events, such as discovered vulnerabilities. On one hand it feels like a very nice thing, but on the other one I can't help but to think how you need to write the playbooks, so that they are generic enough. One more example that's been given comes from the possibility to react to tickets, e.g., outages and this feels like something that could be abused to cause DoS.

Afterwards we've seen two lightning talks, one about choosing the right OpenShift size which was a pretty quick, but listed all of the possible ways you can deploy OpenShift in detail. This lightning talk was followed by the first AI (lightning) talk I've attended about rapid prototyping of the open-source AI models.

As someone who's involved in the automation of the RPM packaging and testing, of course, we had to attend Learning from Nix. Nix has a very intriguing concept which is pretty powerful, but painful at the same time. This can be summed up pretty nicely by Tsoding who got asked about some tips & tricks for someone who wants to try out NixOS:

Just don't.

And now we're moving into a section where everything revolves about the Packit Team :)

First talk about changelogs was an interactive session that was (probably) meant to share different approaches we take to handle this rather convoluted topic that involves changelogs on both upstream and also on downstream with no rules¹.

Next one was about static analysis done by OpenScanHub. I like the idea of running the static analysis that can uncover nasty bugs (as it has been even showed in the talk) at the same time as they are introduced. I gotta admit that after seeing the UI of the deployed OpenScanHub on the Fedora Infra, I couldn't help but to think about the United States Graphics Company 😄 The UI is to the point, no fancy annoying shit, you get what you need, it's hard to get lost. Just simplicity. Best kind of UI/UX in my opinion.

After the OpenScanHub talk we're getting to talks that were taken in a totally different direction from the usual talks you're used to 😉 First one was given title of “Indiana Jones and obsoleted projects” by Mirek. He talked about projects that got obsoleted, but started with projects that had no relation to IT field at all. I'd mark this talk as a stand up without any hesitation.

And finally we will wrap up the first day with the talk where speakers spoke the least… “Let the users speak!” that involved users of both Packit and Testing Farm who spoke about their use case and benefits they gained from using both services in a symbiosis.

Day 2​

On the second day I've attended less talks to not burn myself out :) I've started with an AI-related talk with title “AI: Open source will save us!”, even though this talk has been improvised, as the speakers from the schedule couldn't have attended, it provided a nice overview what InstructLab can do and how can you “feed” the relevant info into the language models by yourself.

After that I attended a “coffee enthusiasts Meetup” which was very nice and, of course, an organized chaos 😉

Before attending the social event I wrapped up the second day with a lightning talk about recent updates in Toolbx. I've used both toolbx and distrobox, so it's nice to see the improvements in progress and also that both projects are well and lively.

Day 3​

On the third day I've attended only in the afternoon. “Started” my day with a discussion “Leadership: Where people skills meet programmers” which was very nice for gaining an insight into how developer, manager and QE lead roles overlap.

That talk has been followed up by a talk about role rotation in our Packit Team. I would say it is a nice “upgrade” to the agile process which allows you to not create a single point of failure in the mundane and repetitive processes within your team.

And this day has been finished off with a talk about shifting left in Podman. It's nice to see how other teams utilize our Packit Service and also the services we rely on, such as Copr or Testing Farm. With the help of Cockpit tests they can catch breaking changes early on, or even bugs that have been introduced and break usage of the dependent projects.

Picks from the Packit Team​

On the Tuesday, during our Packit stand up, I have managed to abuse my Kanban Lead role to collect some of the talks that each of us would recommend:

• Rapid Prototyping with Open Source AI Models
• Do you like your changelogs?
• OpenScanHub - Static Analysis of a Linux Distribution
• Creating a Language Server for RPM Spec Files
• Containers and Kubernetes Made Easy: A 15-minute dive into Podman Desktop
• “Leadership: Where people skills meet programmers”

Wrap up​

I have to admit that these 3 days have been pretty exhaustive, including information overload 😄 but at the same time it was really nice to meet with the colleagues and at least some of our users who are not based in Brno.

Some corporations also profit from the support of the “big” distributions. Let's dive into the pros, cons and peculiarities of such business.

This post is inspired/triggered by the following Mastodon post:

Point of linux distributions​

First thing I'd like to point out is the point of the Linux distributions. What benefit do they provide? And why there are so many of them…

As it has been brought up many times by the rms¹, Linux by itself is not enough, it's just the kernel that does the underlying work. We need more software to utilize the hardware. That's the gap that Linux distributions bridge by providing the Linux and much more other software that we need.

Each distribution is unique in its own way. Some prefer different ways of handling the software (like Gentoo that allows you to compile it yourself) and others stable releases of software (like Debian).

In the end it mostly boils down to the packaging. I, as a user, want to do something like

$ sudo dnf5 install firefox

and not bother about anything else. I don't want to open browser to look the thing up, download it and then click mindlessly 500× “Next”. I just want to run one command and when the maintainers decide it's time to move on, another one to upgrade the software to the newer version.

Of course, for some use cases you want to minimize the latter. And even make sure that it's safe to do it when you need to. You don't want to break your production deployment just because someone decided it's time to push something out.

That's when the maintainers come in. They take upon themselves the responsibility of maintaining the packages. If you've ever used the Debian, you know very well how old the software is, but that's what you might need for your servers.

Pain of packaging​

Packaging software is not cost-free. You may as well have 80 % of packages that don't need much care and it's rather easy to push them forward, but those remaining, which are complicated and raise issues regularly, will make it up and take a lot of time and also pain.

Libraries are the most common example that might not need much work to be done. On the other hand, Linux kernel itself is a rather complicated machinery that is patched a lot and its build process is not simple either.

Even if you consider just those easily-maintainble packages, the process can be tedious, boring and overall time consuming.

Packaging whole ecosystems​

Now it's time to talk about whole ecosystems that have some kind of a packaging by themselves. Yes, I mean Python (with its continuous stream of different package managers), Rust, Go, etc.

Whole point of packaging is to have some form of gating. In other words, you want some kind of quality control when pushing changes into the Linux distros.

If you want to package some tool (or even library) from the aforementioned ecosystems, you need to package all of the dependencies to make sure something doesn't get updated in the meantime (and also that you can safely reproduce the builds, if need be).

I've tried to package some utilities for EPEL both in Rust and Go. Dependencies form a DAG² and in case of Rust, it's very similar to the way npm does its packaging.

I have no clue how do the Rust maintainers operate, but I'm tipping my fedora in their direction, since it must be a pain in the ass.

Paid distributions​

You can find few Linux distributions that are “paid”. I'm very well aware of the fact I've used quotes around the word, cause it's not that easy and not even same for all of the distributions that involve some kind of a payment.

One of the first non-free distributions I've come into contact was Zorin OS which basically tries to be the best transition solution when moving away from the Windows or macOS. If you have a look at the perks of its Pro version that's paid, you may as well decide they are rather questionable…

It's time to move into the Ubuntu Pro, RHEL and SLE territory. What's the point of those? They definitely offer different kind of, let's say, non-free experience.

With those you are paying mainly for the support and bug/security patches.

Repository structure​

As I have mentioned above, the three services³ I mentioned are providing support with regards to bugs and security vulnerabilites. Therefore it makes sense to have some kind of a process in place when you're pushing changes (either updates, patches or security patches) to the distribution. And yes, these processes are in place.

If you think about the amount of packages that is present in the community distributions like archLinux (14,830 packages) or Fedora (74,309 packages), it is safe to come to a conclusion that there's no way to support all of them.

That's why the Linux distributions have some structure to their repositories that contain packages. The way you go around this is rather simple, you choose some set of critical packages that you guarantee support for (like Linux kernel, openSSL, etc.) and maintain those with all the QA processes in place.

Ubuntu​

Ubuntu has pretty granular structure of their repositories, namely:

• main containing the “core” of the Ubuntu that is maintained by the Canonical,
• universe containing literally the “universe”, packages that everyone likes, but they're not crucial, this repo is maintained mostly by the community,
• multiverse containing packages with some license or copyright issues, and
• restricted containing proprietary packages like nvidia drivers and such.

By briefly checking my Ubuntu 23.10 installation, here are stats of packages in their respective repositories:

• main with 6,128 packages,
• universe with 63,380 packages,
• multiverse with 997 packages, and finally
• restricted with 784 packages.

As you can see, if we sum them up, they are relatively similar to the Fedora numbers.

CentOS​

CentOS on the other hand has a bit simpler structure with BaseOS for the base and AppStream for additional packages:

• baseos with 1,058 packages,
• appstream with 5,646 packages, and
• extras-common with 42 packages.

Overall they make up the similar number as the Ubuntu's main repository. And you can also notice that there are no additional repositories.

Ubuntu Pro​

Now it's time to get back to the Ubuntu Pro. There are multiple points that need to be taken in account to be either positive or negative about it…

We can start with the way Ubuntu is released and maintained. Ubuntu has regular 6-month release cycle and biannual LTS release. Releases are normally supported for 9 months with the exception of the LTS releases being supported for 5 years.

If you check out the Ubuntu Pro website, you can find the following statement:

Ubuntu Pro

The most comprehensive subscription for open-source software security

30-day trial for enterprises. Always free for personal use.

Overall if you try to find what is included in the Ubuntu Pro:

• high and critical patches,
• 10 years of maintenance, and
• (optional) 24/7 enterprise-grade support.

If we get back to the screenshot all the way at the beginning of the post:

and try to look up to which repository the packages mentioned in the screenshot belong, we will find out that they belong to universe repository which is maintained by the community. Not to mention nature of the packages: multimedia.

You may think about this as a scam, but considering repository consisting of 70k packages, it is not an easy task to do. And with LTS releases we're talking about 5+ years of support.

Common strategy, at this point, is to pull out the open-source. Yes, we are still dealing with the open-source, but keep in mind that you're trying to patch some issue in a version that's 5 years old, upstream definitely doesn't care anymore⁴, the development didn't stop 5 years ago, it's going on and fixing this issue in a release from 5 years is not the same as fixing it in the current release. At this point, if you are paying for such support, you are actually paying for someone to do software archaeology which can be non-trivial to do.

In the case of Ubuntu Pro we're talking about community support and best-effort support by Canonical for the paying customers. And that makes sense to me, running LTS distro for 5+ years on a desktop seems like an odd choice, even with the help of podman and distrobox or toolbx that allow us to use stable or LTS distro as a base and containerized development environments on top of that.

RHEL ecosystem​

RHEL ecosystem is much more complicated in this matter. However it's very similar to the way SUSE operates with few exceptions.

You can see a flow diagram here:

Key things to take and not to take from the flow diagram:

• getting from one upstream to its respective downstream is not as simple as the presence of an arrow and it's not the same process for all of them
• lengths of the arrows are not proportional, specifically:
  • Fedora Rawhide is supposed to consume updates as soon as possible,
  • depending on the decision of the maintainer they can, but don't have to be included in the currently supported Fedora releases (you can take Emacs as an example of such package), but Rawhide eventually becomes the next Fedora release,
  • CentOS Stream gets branched off a specific Fedora release, and then
  • ultimately CentOS Stream becomes the next minor release of RHEL.
• this diagram is simplified by a lot

Change in the model​

The flow I've shown above is in effect since late ‘20 and early ‘21. I hope you can see that it is quite similar to the way SUSE operates too. Before late ‘20 the flow was following:

CentOS was the last distribution in that “chain”. This provides some benefits and some negatives.

Before the change​

From the point of a developer, unless you have some kind of an early access to RHEL, you don't see the changes until they land and are already released. This impairs your ability to test and verify your software before shipping it to your clients that use RHEL.

From the point of a user, there is one positive, you basically get “free RHEL” without the support. This also allowed you to report bugs against the RHEL, since they were 1:1 distros (minus the branding and support). So you'd technically get RHEL free of charge.

Benefit of such project, except for the cost, is questionable. The main issue, which actually became even more apparent after changing the flow, is someone else repackaging your own product and selling it again.

After the change​

First of all, the current flow counters the issue mentioned above. You can test your projects against the next minor RHEL release. CentOS Stream is free, so you can freely incorporate it into your CI pipelines.

There are many people thinking that RHEL has become closed-source. It is not. The development happens out in the open, it's more open that it was before. However with the cost of not getting the exact same thing for free. You can get the next minor RHEL, not the same that's normally paid for. Packit is an example of a service that is deployed on the CentOS 9 Stream and even used to be deployed on Fedora, but the regular 6-month release cycle caused some minor issues here and there.

Production-ready is something that heavily depends on the context…

Open-source and paid support​

Overall I don't think that paying for the support of 5 years old non-critical packages is going against the open-source. It is a non-trivial work that, in majority of cases, cannot be included in the upstream, therefore the benefit is reapt only by the paying customers. I have to admit that in the case of the Ubuntu Pro it may seem a bit weird (hiding patches behind the paywall). However we're still talking about rather big set of packages that will affect a minority of server workloads, if any.

Glossary​

• rolling release - continuously released without “significant milestones”

  tip

  As an example of rolling distribution you can take archLinux, openSUSE Tumbleweed, Fedora Rawhide, or even CentOS 9 Stream.

  As en example of not rolling distribution you can take Ubuntu, openSUSE Leap or Fedora.

• bleeding edge - contains the latest versions as they are released on the upstream

  tip

  As an example you can take archLinux, openSUSE Tumbleweed or Fedora Rawhide. You can also notice how common it is to combine rolling release with bleeding edge.

• upstream & downstream

  You're most likely to meet these terms in the meaning of upstream being the project itself and downstream being the packaging of said project in some distribution.

  However this can also apply to distributions like openSUSE Tumbleweed with openSUSE Leap, Fedora with CentOS Stream, or even CentOS Stream with RHEL. This basically means that the packages/software is being released into the upstream (Tumbleweed, Fedora, or even CentOS) and then after being tested is taken further down into their respective downstreams (Leap, CentOS, RHEL).

Memory safety​

I'll start by kicking the biggest benefit of the language, the memory safety. Let's be honest here, majority of the checks rely on the static analysis, cause you can't do anything else during the compile-time, right? Therefore we can basically say that we are relying on the compiler to “solve” all of our issues.

Compiler​

I guess we can safely¹ agree on the fact that we 100% rely on the compiler to have our back. Is the compiler bug-free? I doubt it. This is not meant in an offensive way to the Rust compiler developers, but we need to be realistic here. It's a compiler, even older and larger projects like gcc or llvm can't avoid bugs to appear.

When I was trying out Rust for some of the LeetCode challenges I've stumbled upon the following warning:

Enforcing the safety​

One of the ways Rust enforces the safety is by restricting what you can do, like the example above. Aforementioned issue can happen, but doesn't have to. Rule of the thumb in the Rust compiler is to “block” anything that can be an issue, static analysis can't do much more, it cannot decide whether it's safe to do it or not.

Satisfying the Rust compiler is sometimes a brutal pain in the ass, because you cannot do things like you're used to, you need to work around them somehow.

Consequences​

Where are we heading with this approach of “if it compiles, it runs” though? In this aspect I have a rather similar opinion as with regards to the ChatGPT and its derivatives.

If you teach people to 100% depend on the compiler, they will do it, cause it's easy. All you need to do is make the compiler shut up². Giving up the intellectual masturbation about the memory safety will make you lose your edge over the time. When we get to the point of everyone being in the mindset mentioned above, who's going to maintain the compiler? This is the place where you need to think about the memory safety and furthermore in a much more general way than in your own projects, because it is the thing that everyone blindly believes in in the end.

I'm not saying that everyone should give up Rust and think about their memory management and potential memory issues. I'm just saying that going the easy way will make people dull and they should think about it anyways, that's how the issue above has been discovered. If everyone walked past and didn't think about it, no one would discover this issue till it bit them hard.

// SAFETY: …

Development & design​

Development of Rust is… very fast. One positive is that they're trying to be as backward compatible as possible at least by verifying against all the published crates in the process. Of course, you cannot be backward compatible about fixing the bugs that have been found, but such is life.

Fast development cycle​

One of the negatives of the fast development cycle is the fact that they're using the latest features already in the next release of Rust. Yes, it is something that you can use for verifying and testing your own changes, but at the same time it places a requirement of the latest release to compile the next one.

One of the other negatives is the introduction of bugs. If you're pushing changes, somewhat mindlessly, at such a fast pace, it is inevitable to introduce a bunch bugs in the process. Checking the GitHub issue tracker with

is:issue is:open label:C-bug label:T-compiler

yields 2,224 open issues at the time of writing this post.

RFCs​

You can find a lot of RFCs for Rust. Some of them are more questionable than the others. Fun thing is that a lot of them make it to the nightly builds, so they can be tested and polished off. Even the questionable ones… I'll leave a few examples for a better understanding.

One of such features is the do yeet expression:

#![feature(yeet_expr)]

fn foo() -> Result<String, i32> {
    do yeet 4;
}
assert_eq!(foo(), Err(4));

fn bar() -> Option<String> {
    do yeet;
}
assert_eq!(bar(), None);

It allows you to “yeet” the errors out of the functions that return Result or Option.

One of the more recent ones is the ability to include Cargo manifests into the sources, so you can do something like:

#!/usr/bin/env cargo
---
[dependencies]
clap = { version = "4.2", features = ["derive"] }
---

use clap::Parser;

#[derive(Parser, Debug)]
#[clap(version)]
struct Args {
    #[clap(short, long, help = "Path to config")]
    config: Option<std::path::PathBuf>,
}

fn main() {
    let args = Args::parse();
    println!("{:?}", args);
}

I would say you can get almost anything into the language…

Community and hype train​

Rust community is a rather unique thing. A lot of people will hate me for this, but I can't help, but to compare them to militant vegans. I'll go through some of the things related to it, so I can support my opinion at least.

Rust is the best language. It is not. There is no best language, each has its own positives and negatives, you need to choose the language that's the most suitable for your use case. There are areas where Rust excels, though I have to admit it's very close to being a universal hammer regardless of how suitable it is. There is a very steep learning curve to it, beginnings in Rust are very painful.

Rewrite everything in Rust. Just no. There are multiple feedbacks on doing rewrites, it is very common to fix N bugs with a rewrite while introducing N + 1 other bugs in the process. It doesn't solve anything unless there are some strong reasons to go with it. Majority of such suggested rewrites don't have those reasons though.

Language ‹x› is bad, though in Rust… Cherry-picking one specific pain point of one language and reflecting how it is better in other language can go both ways. For example it is rather easy to pick the limitations imposed by Rust compiler and show how it's possible in other languages 🤷‍♂️

I don't mind any of those opinions, you're free to have them, as long as you don't rub them in my face which is not the usual case… This experience makes it just worse for me, part of this post may be also influenced by this fact.

Rust in Linux​

It took years of work to even “incorporate” Rust into the Linux codebase, just to get the “Hello World!”. I don't have anything against the idea of writing drivers in Rust, I bet it can catch a lot of common mistakes, but still introducing Rust to the kernel is another step to enlarge the monster.

I have to admit though that the Apple GPU driver for Linux written in Rust is quite impressive. Apart from that there are not so many benefits, yet…

Packaging​

I'll divide the packaging into the packaging of the language itself and the programs written in Rust.

Let's start with the cargo itself though. Package managers of the languages usually get a lot of hate (you can take npm or pip as examples³). If you've ever tried out Rust, I bet you already know where I'm going with this. Yes, I mean the compilation times, or even Cargo downloading whole index of crates just so you can update that one dependency (and 3 millions of indirect deps). When I was doing AoC ‘22 in Rust, I've set up sccache right away on the first day.

Let's move to the packaging of the Rust itself, it's tedious. Rust has a very fast development cycle and doesn't even try to make the builds backward compatible. If there is a new release of Rust, there is a very high chance that you cannot build that release with anything other than the latest Rust release. If you have ever touched the packaging, you know that this is something that can cause a lot of problems, cause you need the second-to-latest version to compile the latest version, don't forget that this applies inductively… People running Gentoo could tell you a lot about this.

I cannot speak about packaging of Rust programs in other than RHEL-based distros, though I can speak about RHEL ecosystem. Fedora packaging guidelines specify that you need to build each and every dependency of the program separately. I wanted to try out AlmaLinux and install Alacritty there and I failed miserably. The solution that worked, consisted of ignoring the packaging guidelines, running cargo build and consuming the binaries afterwards. Dependencies of the Rust programs are of a similar nature as JS dependencies.

I'm tipping my fedora¹ in the general direction of the maintainers of Rust packages in RHEL ecosystem. I wouldn't be able to do this without losing my sanity.

Likes​

If you've come all the way here and you're a Rustacean, I believe I've managed to get your blood boiling, so it's time to finish this off by stuff I like about Rust. I doubt I will be able to cover everything, but I can try at least. You have to admit it's much easier to remember the bad stuff as opposed to the good. 😉

Workflow and toolchain​

I prefered using Rust for the Advent of Code and Codeforces as it provides a rather easy way to test the solutions before running them with the challenge input (or test runner). I can give an example from the Advent of Code:

use aoc_2023::*;

type Output1 = i32;
type Output2 = Output1;

struct DayXX {}
impl Solution<Output1, Output2> for DayXX {
    fn new<P: AsRef<Path>>(pathname: P) -> Self {
        let lines: Vec<String> = file_to_lines(pathname);

        todo!()
    }

    fn part_1(&mut self) -> Output1 {
        todo!()
    }

    fn part_2(&mut self) -> Output2 {
        todo!()
    }
}

fn main() -> Result<()> {
    DayXX::main()
}

test_sample!(day_XX, DayXX, 42, 69);

This was the skeleton I've used and the macro at the end is my own creation that expands to:

#[cfg(test)]
mod day_XX {
    use super::*;

    #[test]
    fn part_1() {
        let path = DayXX::get_sample(1);
        let mut day = DayXX::new(path);
        assert_eq!(day.part_1(), 42);
    }

    #[test]
    fn part_2() {
        let path = DayXX::get_sample(2);
        let mut day = DayXX::new(path);
        assert_eq!(day.part_2(), 69);
    }
}

When you're solving the problem, all you need to do is switch between cargo test and cargo run to check the answer to either sample or the challenge input itself.

Introduce bacon and it gets even better. Bacon is a CLI tool that wraps around the cargo and allows you to check, run, lint or run tests on each file save. It's a very pleasant thing for a so-called compiler-assisted development.

Speaking of linting from within the bacon, you cannot leave out the clippy. Not only it can whip your ass because of errors, but it can also produce a lot of helpful suggestions, for example passing slices by borrow instead of borrowing the Vec itself when you don't need it.

Standard library​

There's a lot included in the standard library. It almost feels like you have all you need⁴. I like placeholders (like todo!(), unreachable!(), unimplemented!()) to the extent of implementing them as exceptions in C++.

You can find almost anything. Though you can also hit some very weird issues with some of the nuances of the type system.

unsafe​

This might be something that people like to avoid as much as possible. However I think that forming a habit of commenting posibly unsafe operations in any language is a good habit, as I've mentioned above. You should be able to argue why you can do something safely, even if the compiler is not kicking your ass because of it.

Excerpt of such comment from work:

# SAFETY: Taking first package instead of specific package should be
# safe, since we have put a requirement on »one« ‹upstream_project_url›
# per Packit config, i.e. even if we're dealing with a monorepo, there
# is only »one« upstream. If there is one upstream, there is only one
# set of GPG keys that can be allowed.
return self.downstream_config.packages[
    self.downstream_config._first_package
].allowed_gpg_keys

Traits​

One of the other things I like are the traits. They are more restrictive than templates or concepts in C++, but they're doing their job pretty good. If you are building library and require multiple traits to be satisfied it means a lot of copy-paste, but that's soon to be fixed by the trait aliases.

Rust's trait < Haskell's type class < C++'s concept

You can also hit some issues, like me when trying to support conversions between underlying numeric types of a 2D vectors or support for using an operator from both sides (I couldn't get c * u to work in the same way as u * c because the first one requires you to implement the trait of a built-in type).

impl SomeTrait for SomeStruct {
    // implementation goes here
}

Influence of functional paradigm​

You can see a big influence of the functional paradigm. Not only in iterators, but also in the other parts of the language. For example I prefer Option<T> or Result<T, E> to nulls and exceptions. Pattern matching together with compiler both enforces handling of the errors and rather user-friendly way of doing it.

Not to mention .and_then() and such. However spending most of the time with the AoC you get pretty annoyed of the repetitive .unwrap() during parsing, since you are guaranteed correct input.

Macros​

Macros are a very strong pro of Rust. And no, we're not going to talk about the procedural macros…

As I've shown above I've managed to “tame” a lot of copy-paste in the tests for the AoC by utilizing a macro that generated a very basic template for the tests.

As I have mentioned the traits above, I cannot forget to give props to derive macro that allows you to “deduce” the default implementation. It is very helpful for a tedious tasks like implementing Debug (for printing out the structures) or comparisons, though with the comparisons you need to be careful about the default implementation, it has already bitten me once or twice.

Summary​

Overall there are many things about the Rust I like and would love to see them implemented in other languages. However there are also many things I don't like. Nothing is exclusively black and white.

When I “reserved” my VPS¹ back in June '20, I slapped Fedora on it without thinking. I bet 99% of people would say that I'm crazy for doing such thing², BUT I've been using Fedora on my PCs for some time already and it felt very stable and natural to just use, even for VPS.

One of the first things I've done was setting up a mail server. You may guess what's the fun part about having a mail server… Yes, it's all the spam you receive and only then you realize how much “crap” gets filtered on free mail services. To battle this problem I chose to use rspamd that had CentOS support, but someone had a Copr repository that I used to install it.

How does Copr repositories work?​

If you have ever used Ubuntu, you might be familiar with the concept since it is very close to PPAs.

tl;dr of the whole process consists of

1. enabling the Copr repository, and
2. installing the desired package.

So in shell you would do

# dnf copr enable ‹copr-repository›
# dnf install ‹package-from-the-repository›

And… that's it! Nothing else needed! Simple, right? And literally same process as you would do for the PPA.

My issue​

Now you might wonder how would I use it on my VPS. It's rather simple, once in 6 months a new Fedora release comes out. And you need to upgrade to newer release… You don't need to do it right away and for such setup it probably isn't even recommended.

Fast-forward 2 years in the future, new Fedora release came out (October '22) and I was doing an upgrade. Dependencies of the rspamd have been updated and rspamd builds in Copr have failed and no one fixed it. Cool, so now I can upgrade, but can either ignore the dependencies or uninstall the rspamd…

How can Copr help?​

I have managed to find specfile for the rspamd package that they use for CentOS. There were some files apart from the specfile, so I had to make an SRPM locally and then… I just uploaded the SRPM to the Copr to build an RPM.

I have switched the previous Copr repository for rspamd with my own and happily proceeded with the upgrade.

Conclusion​

Copr is heavily used for testing builds on the upstream with Packit. However, as you can see, it is possible to use it very well for packaging your own stuff and avoiding issues (such as the one I have described above), if need be.

Day 22: Monkey Map​

Solution​

It seems like a very simple problem to solve, but with very obnoxious changes in the 2nd part and also it's relatively hard to decompose »properly«.

Column iterator​

In the first part of the problem it was needed to know the boundaries of each row and column, since I stored them in Vec<Vec<char>> and padded with spaces to ensure I have a rectangular 2D “array”. However when you wanted to go through each row and column to determine the boundaries, it was very easy to do for the rows (cause each row is a Vec element), but not for the columns, since they span multiple rows.

For this use case I have implemented my own column iterator:

pub struct ColumnIterator<'a, T> {
    map: &'a [Vec<T>],
    column: usize,

    i: usize,
}

impl<'a, T> ColumnIterator<'a, T> {
    pub fn new(map: &'a [Vec<T>], column: usize) -> ColumnIterator<'a, T> {
        Self { map, column, i: 0 }
    }
}

impl<'a, T> Iterator for ColumnIterator<'a, T> {
    type Item = &'a T;

    fn next(&mut self) -> Option<Self::Item> {
        if self.i >= self.map.len() {
            return None;
        }

        self.i += 1;
        Some(&self.map[self.i - 1][self.column])
    }
}

Given this piece of an iterator, it is very easy to factor out the common functionality between the rows and columns into:

let mut find_boundaries = |constructor: fn(usize) -> Orientation,
                           iterator: &mut dyn Iterator<Item = &char>,
                           upper_bound,
                           i| {
    let mut first_non_empty = iterator.enumerate().skip_while(|&(_, &c)| c == ' ');
    let start = first_non_empty.next().unwrap().0 as isize;

    let mut last_non_empty = first_non_empty.skip_while(|&(_, &c)| c != ' ');
    let end = last_non_empty.next().unwrap_or((upper_bound, &'_')).0 as isize;

    boundaries.insert(constructor(i), start..end);
};

And then use it as such:

// construct all horizontal boundaries
(0..map.len()).for_each(|row| {
    find_boundaries(
        Orientation::horizontal,
        &mut map[row].iter(),
        map[row].len(),
        row,
    );
});

// construct all vertical boundaries
(0..map[0].len()).for_each(|col| {
    find_boundaries(
        Orientation::vertical,
        &mut ColumnIterator::new(&map, col),
        map.len(),
        col,
    );
});

Walking around the map​

Once the 2nd part got introduced, you start to think about a way how not to copy-paste a lot of stuff (I haven't avoided it anyways…). In this problem, I've chosen to introduce a trait (i.e. interface) for 2D and 3D walker.

trait Wrap: Clone {
    type State;

    // simulation
    fn is_blocked(&self) -> bool;
    fn step(&mut self, steps: isize);
    fn turn_left(&mut self);
    fn turn_right(&mut self);

    // movement
    fn next(&self) -> (Self::State, Direction);

    // final answer
    fn answer(&self) -> Output;
}

Each walker maintains its own state and also provides the functions that are used during the simulation. The “promised” methods are separated into:

• simulation-related: that are used during the simulation from the .fold()
• movement-related: just a one method that holds most of the logic differences between 2D and 3D
• final answer: which extracts the proof of solution from the implementation-specific walker

Both 2D and 3D versions borrow the original input and therefore you must annotate the lifetime of it:

struct Wrap2D<'a> {
    input: &'a Input,
    position: Position,
    direction: Direction,
}
impl<'a> Wrap2D<'a> {
    fn new(input: &'a Input) -> Wrap2D<'a> {
// …

Problems​

I have used a lot of closures for this problem and once I introduced a parameter that was of unknown type (apart from the fact it implements a specific trait), I got suggested a “fix” for the compilation error that resulted in something that was not possible to parse, cause it, more than likely, violated the grammar.

In a similar fashion, I have been suggested changes that led to a code that didn't make sense by just looking at it (there was no need to try the changes), for example one suggested change in the closure parameter caused disapperance of the parameter name. 😄

Clippy​

I have to admit that Clippy was rather helpful here, I'll include two examples of rather smart suggestions.

When writing the parsing for this problem, the first thing I have spotted on the char was the .is_digit() function that takes a radix as a parameter. Clippy noticed that I use radix = 10 and suggested switching to .is_ascii_digit() that does exactly the same thing:

-                .take_while(|c| c.is_digit(10))
+                .take_while(|c| c.is_ascii_digit())

Another useful suggestion appeared when working with the iterators and I wanted to get the $n$-th element from it. You know the .skip(), you know the .next(), just “slap” them together and we're done for 😁 Well, I got suggested to use .nth() that does exactly the combination of the two mentioned methods on iterators:

-            match it.clone().skip(skip).next().unwrap() {
+            match it.clone().nth(skip).unwrap() {

Day 23: Unstable Diffusion​

Solution​

There's not much to mention since it's just a cellular automaton simulation (even though the AoC rules for cellular automatons usually get out of hand 😉).

Although I had a need to determine boundaries of the elves' positions and ended up with a nasty DRY violation. Knowing that you you're looking for maximum and minimum that are, of course, exactly the same except for initial values and comparators, it looks like a rather simple fix, but typing in Rust is something else, right? In the end I settled for a function that computes both boundaries without any duplication while using a closure:

fn get_bounds(positions: &Input) -> (Vector2D<isize>, Vector2D<isize>) {
    let f = |init, cmp: &dyn Fn(isize, isize) -> isize| {
        positions
            .iter()
            .fold(Vector2D::new(init, init), |acc, elf| {
                Vector2D::new(cmp(acc.x(), elf.x()), cmp(acc.y(), elf.y()))
            })
    };

    (f(isize::MAX, &min::<isize>), f(isize::MIN, &max::<isize>))
}

This function returns a pair of 2D vectors that represent opposite points of the bounding rectangle of all elves.

You might ask why would we need a closure and the answer is that positions cannot be captured from within the nested function, only via closure. One more fun fact on top of that is the type of the comparator

&dyn Fn(isize, isize) -> isize

Once we remove the dyn keyword, compiler yells at us and also includes a way how to get a more thorough explanation of the error by running

$ rustc --explain E0782

which shows us

Trait objects must include the dyn keyword.

Erroneous code example:

trait Foo {}
fn test(arg: Box<Foo>) {} // error!

Trait objects are a way to call methods on types that are not known until runtime but conform to some trait.

Trait objects should be formed with Box<dyn Foo>, but in the code above dyn is left off.

This makes it harder to see that arg is a trait object and not a simply a heap allocated type called Foo.

To fix this issue, add dyn before the trait name.

trait Foo {}
fn test(arg: Box<dyn Foo>) {} // ok!

This used to be allowed before edition 2021, but is now an error.

Day 24: Blizzard Basin​

Solution​

You are given a map with blizzards all over the place and you're supposed to find the minimum time it requires you to walk through the basin without getting in any of the blizzards.

Breakdown​

Relatively simple, yet a bit annoying, approach can be taken. It's technically a shortest-path algorithm implementation with some relaxation restrictions and being able to stay on one position for some time, so each vertex of the graph is determined by the position on the map and the timestamp. I have chosen to use Vector3D<usize>, since x and y attributes can be used for the position and, well, let's use z for a timestamp, cause why not, right? 😉

Evaluating the blizzards​

The blizzards move along their respective directions in time and loop around in their respective row/column. Each vertex holds position and time, so we can just index the basin with the vertex itself, right? Yes, we can 😈

I'll skip the boring parts of checking bounds and entry/exit of the basin 😉 We can easily calculate positions of the blizzards using a modular arithmetics:

impl Index<Position> for Basin {
    type Output = char;

    fn index(&self, index: Position) -> &Self::Output {
        // ‹skipped boring parts›

        // We need to account for the loops of the blizzards
        let width = self.cols - 2;
        let height = self.rows - 2;

        let blizzard_origin = |size, d, t, i| ((i - 1 + size + d * (t % size)) % size + 1) as usize;
        [
            (
                index.y() as usize,
                blizzard_origin(width, -1, index.z(), index.x()),
                '>',
            ),
            (
                index.y() as usize,
                blizzard_origin(width, 1, index.z(), index.x()),
                '<',
            ),
            (
                blizzard_origin(height, -1, index.z(), index.y()),
                index.x() as usize,
                'v',
            ),
            (
                blizzard_origin(height, 1, index.z(), index.y()),
                index.x() as usize,
                '^',
            ),
        ]
        .iter()
        .find_map(|&(y, x, direction)| {
            if self.map[y][x] == direction {
                Some(&self.map[y][x])
            } else {
                None
            }
        })
        .unwrap_or(&'.')
    }
}

As you can see, there is an expression for calculating the original position and it's used multiple times, so why not take it out to a lambda, right? 😉

I couldn't get the rustfmt to format the for-loop nicely, so I've just decided to go with iterating over an elements of a slice. I have used, once again, a combination of two functions (find_map in this case) to do 2 things at once and at the end, if we haven't found any blizzard, we just return the empty space.

I think it's a very nice (and naughty) way how to use the Index trait, don't you think?

Shortest-path algorithm​

For the shortest path you can choose and adjust any of the common shortest-path algorithms, in my case, I have decided to use A* instead of Dijkstra's algorithm, since it better reflects the cost function.

Cost function is, of course, a closure 😉

let cost = |p: Position| p.z() as usize + exit.y().abs_diff(p.y()) + exit.x().abs_diff(p.x());

And also for checking the possible moves from the current vertex, I have implemented, yet another, closure that yields an iterator with the next moves:

let next_positions = |p| {
    [(0, 0, 1), (0, -1, 1), (0, 1, 1), (-1, 0, 1), (1, 0, 1)]
        .iter()
        .filter_map(move |&(x, y, t)| {
            let next_p = p + Vector3D::new(x, y, t);

            if basin[next_p] == '.' {
                Some(next_p)
            } else {
                None
            }
        })
};

Min-heap​

In this case I had a need to use the priority queue taking the elements with the lowest cost as the prioritized ones. Rust only offers you the BinaryHeap and that is a max-heap. One of the ways how to achieve a min-heap is to put the elements in wrapped in a Reverse (as is even showed in the linked docs of the BinaryHeap). However the wrapping affects the type of the heap and also popping the most prioritized elements yields values wrapped in the Reverse.

For this purpose I have just taken the max-heap and wrapped it as a whole in a separate structure providing just the desired methods:

use std::cmp::{Ord, Reverse};
use std::collections::BinaryHeap;

pub struct MinHeap<T> {
    heap: BinaryHeap<Reverse<T>>,
}

impl<T: Ord> MinHeap<T> {
    pub fn new() -> MinHeap<T> {
        MinHeap {
            heap: BinaryHeap::new(),
        }
    }

    pub fn push(&mut self, item: T) {
        self.heap.push(Reverse(item))
    }

    pub fn pop(&mut self) -> Option<T> {
        self.heap.pop().map(|Reverse(x)| x)
    }
}

impl<T: Ord> Default for MinHeap<T> {
    fn default() -> Self {
        Self::new()
    }
}