From ZeroVer to SemVer: A Comprehensive List of Versioning Schemes in Open Source

date: 2024-10-21 · Tags: #dev, #til

In the past, versioning was a relatively chaotic situation. As time goes by, I prefer the Semantic Versioning (SemVer) MAJOR.MINOR.PATCH for libraries and dependencies due to clear and predictable (breaking) changes in software projects. For end-to-end applications, I favor Calendar Versioning (CalVer) YYYY.MM.DD/YY.0W because of its human-readable and understandable indication of the release date.

It's still fun to know that there are so many other ways¹ to version a release.

Footnotes

1. From ZeroVer to SemVer: A Comprehensive List of Versioning Schemes in Open Source ↩

How we made Haskell search strings as fast as Rust

date: 2024-10-20 · Tags: #haskell, #algorithm

Channable shares a post on how they made Haskell search strings as fast as Rust¹.

Footnotes

1. How we made Haskell search strings as fast as Rust: In this post, we will describe our quest to create Alfred–Margaret, the fastest Haskell implementation of the Aho–Corasick string searching algorithm, which powers string search in Channable. ↩

No More Orphans

date: 2024-10-20 · Tags: #scala, #dev

Recently, I read a blog post about the orphan¹ import statement in Scala. It's quite interesting to read because I also have the same feeling about the import statement in Scala.

But I today I want to talk about the import statement in Scala.

Yeah, when starting with Scala, I really hate the import statement like import cats.implicits._ or import cats.syntax.all._ because it's not clear what they are importing. I have to go to the documentation to see what they are importing.

But unfortunately, Scala community is also notorious for incomplete documentations and tutourials. So, I have to go to the source code to see what they are importing.

Even after a while, I still don't understand what they are importing. I have to go to the source code to see what they are importing.

And it's quite funny that do things like this in tutorials. People come here to learn how to use, and you write orphans import statement to assume that they know that they are familiar or an expert with the library.

When you have a well setup IDE, you can just hover over the import statement to see what they are importing. But I don't have a well setup IDE. I use Vim and Coc.nvim. I have to go to the source code to see what they are importing.

• I have to go to the source code to see what they are importing.
• I have to go to the source code to see what they are importing.
• I have to go to the source code to see what they are importing.

What I only accept is implcit or prelude import like import cats._ or import cats.effect._ because they are clear what they are importing.

And I strongly suggest libraries maintainers to write what would happen while import above import statement. It's not hard to write a comment above the import statement.

Eplicit import is a pretty code smell like Python Zen² says:

Explicit is better than implicit.

Footnotes

1. No More Orphans ↩

2. The Zen of Python ↩

io_uring and seccomp

date: 2024-10-13 · Tags: #system-programming

Till now I just known that io_uring is not enabled by default while using container (in the past day XD).

A side effect is that io_uring effectively bypasses the protections provided by seccomp filtering — we can't filter out syscalls we never make! This isn't a security vulnerability per se, but something you should keep in mind if you have especially paranoid seccomp rules. ¹

Fortunately, moby and containerd have already added allow list for io_uring in seccomp filters. ²³

But @tgross still suggest to to check up on if you're expecting seccomp filtering to harden your applications.

Footnotes

1. io_uring and seccomp | 0x74696d ↩

2. seccomp: whitelist io-uring related system calls #39415 ↩

3. seccomp: allow io-uring related system calls #4493 ↩