DEV Community: arhuman

I compressed timestamps before zstd and got up to 26.5% smaller log archives

arhuman — Sun, 17 May 2026 07:05:52 +0000

This morning, I had fun compressing time.

But before you picture me as a theoretical physics genius or a crackpot in need of a straitjacket, let me explain.

I am currently working on Metarc, a metacompression tool.

By metacompression, I mean: applying smart transformations to certain structures before handing the data to a classical compressor like zstd.

Dates are a great playground for understanding this idea.

They look like text, but they actually contain a very dense structure that can be exploited.

And by exploiting this structure, Metarc can achieve compression gains of up to 26.5% compared to tar+zstd on some log datasets.

General-purpose compressors see bytes, not dates

Consider this date: 2026-05-11 10:36:19 That is 19 bytes of text.

For a general-purpose compressor, this is not fundamentally a date. It is a sequence of characters.

It can exploit pattern repetitions, but not the fact that this string represents a precise instant, with a known structure:

year
month
day
hour
minute
second

This difference in perspective changes everything.

Where a general-purpose compressor sees characters, Metarc can recognize a structure:

an instant
a format
sometimes a timezone
sometimes a precision in milliseconds or nanoseconds

That is the core idea.

Compress the structure before compressing the bytes.

Logs are the obvious test ground

To test this idea, log files were the obvious ground.

They contain many dates, in various formats, with a very concrete constraint: you must be able to restore exactly the original text.

Effectively compressing a date while keeping enough information to restore it in its original textual format imposes three constraints:

limit the complexity of detection and compression;
minimize the size of format metadata;
compress the most frequent formats first.

The last point is crucial.

The more formats I support, the more information I must store to distinguish them.

Up to 256 formats, one byte is enough.

Beyond that, two are needed.

The size/variety trade-off is permanent.

While looking for the most common formats on my laptop — RFC 3339, ISO 8601, macOS logs — I quickly understood that the standards hid a forest of variants:

ISO 8601 with nanoseconds UTC
ISO 8601 UTC
ISO 8601 with offset
RFC 3339 with nanoseconds and offset
and many more

To validate the principle, I did not need to be exhaustive.

A sufficiently widespread reduced subset should already allow compression on many encountered cases.

From there, the transformation applied by Metarc can be understood in three steps.

Step 1 — Reduce the instant

A dated moment is a point on a timeline.

If you choose an origin, in computing often January 1st 1970, it can be represented by a simple distance to that origin.

For example, this date: 2026-05-11 10:36:19
can be represented as a Unix timestamp.

Metarc encodes the instant in fixed numeric form on 8 bytes, with a granularity sufficient for the modern log formats targeted.

So we transform a textual string of 19 bytes into a fixed numeric block of 8 bytes.

Even if the date appears only once in the file.

This has two important consequences:

part of the gain comes from understanding the structure, not just from repetition;
unlike classical statistical compression, a unique date can already be reduced efficiently.

That is already useful.

But it is only half of the problem.

Step 2 — Restore the exact original format

The same instant can be written in dozens of ways:

2026-05-11 10:36:19
Mon May 11 10:36:19 2026
11/May/2026:10:36:19
2026/05/11T10:36:19Z

Not to mention timezones, milliseconds or nanoseconds.

In reality, the number of possible formats is almost infinite.

To restore the date identically, Metarc must store both the timestamp and enough information about the original format.

The trade-off is therefore permanent:

detect fast;
encode fast;
store little;
remain more compact than the original date.

The first versions worked well.

But not always better than zstd alone.

That forced me to dig deeper.

Step 3 — Help zstd by ordering bytes by entropy

Once the timestamp and the format were encoded, a problem remained in the structure of the compressed format:

the order of the bytes.

A naive layout looked like this:

[0x00][fmt_byte][uint64 timestamp][int16 tz_min][uint8 subsec_digits]
\__ Low ___/    \___ HIGH ___/    \___________ Low ________________/

The timestamp changes a lot.

The format, timezone and precision usually change much less.

So by reorganizing the format to group low-entropy data at the beginning, we create a longer repetitive sequence that zstd can compress better:

[0x00][fmt_byte][int16 tz_min][uint8 subsec_digits][uint64 timestamp]
\____________________ Low ________________________/ \___ HIGH ___/

Metacompression acts here in two ways:

it compresses the date itself;
it optimizes the byte ordering for the downstream compressor.

The knowledge of the structure — what changes a lot and what changes little — enables this double gain.

That is the interesting part.

Not just replacing text with binary.

Preparing the data so that zstd sees a better byte stream.

Results on Loghub

For my tests, I used Loghub, a corpus containing real log files produced by standard software.

Metarc archives files by applying metacompression transformations and then compresses with zstd by default.

That is why I compare it with:

tar --zstd -cvf xxx.tar.zstd xxx

and:

marc archive xxx.marc xxx

On the Loghub corpus, with the formats currently recognized by log-date-subst/v2, Metarc gains up to 26.5% compared to tar+zstd.

On unrecognized formats, the gain is logically 0%.

Dataset	Directory size	tar+zstd size	Metarc size	Metacompression benefit
Mac	844K	136K	100K	26.5%
OpenStack	1.3M	136K	104K	23.5%
HDFS	708K	136K	112K	17.6%
BGL	776K	136K	116K	14.7%
Spark	500K	36K	32K	11.1%
OpenSSH	580K	40K	36K	10.0%
HealthApp	472K	44K	40K	9.1%
Android	736K	52K	48K	7.7%
Zookeeper	648K	52K	48K	7.7%
Apache	432K	28K	28K	0.0%
Hadoop	920K	44K	44K	0.0%
HPC	372K	56K	56K	0.0%
Linux	548K	36K	36K	0.0%
Proxifier	592K	52K	52K	0.0%
Thunderbird	768K	64K	64K	0.0%
Windows	684K	32K	32K	0.0%

For recognized formats, the size gain brought by metacompression is **14% on average.

The gain depends directly on the proportion of dates recognized in the corpus.

When Metarc detects a format, it reduces the temporal information and reorganizes it for zstd.

When it detects none, the file simply follows the standard compression path.

You can check the detail of the gain per archive with the --explain flag:

time marc archive --explain mac.marc Mac

Example output:

--- Plan Summary ---
Total entries:      4
Transforms applied: 1
Estimated gain:     104.0 KB

Breakdown by transform:
  log-date-subst/v2        1 applied      0 skipped  ~104.0 KB saved
  raw                      0 applied      3 skipped  ~0 B saved

What still needs improvement

Implementing more formats without degrading performance remains an obvious axis for improvement.

Adding a format can sometimes come down to encoding a simple variant, such as the date separator: / or -.

But more often, it requires detecting a new pattern in a new set of log files.

The real work is therefore to broaden coverage without blowing up the detection cost.

There are also still many optimizations to implement.

For example, some compressed storage formats could be specialized.

No point keeping timestamps in uint64 format for formats that do not need nanoseconds.

The current implementation validates the principle.

It does not exhaust the idea.

The real point: metacompression

The real result of this exploration is not, for me, the average 14% compression gain.

The interest of date compression is that it illustrates metacompression in its most complete form:

an upstream compression that adds to and optimizes downstream byte stream compression.

That was Metarc’s bet:

compress the structure before compressing the bytes.

The next step will not play out on a hand-picked example, but on real data:

code repositories
logs
technical archives
heterogeneous corpora

That is how an intuition becomes a tool.

If you have real logs with timestamp formats that Metarc does not handle yet, I would be very interested in testing them.

Try Metarc, compare it to tar+zstd, and share your results:

And if you like the concept of metacompression and want to give the project some visibility, a GitHub star is always appreciated.

Structure Before Bytes: How Metarc Beats tar+zstd on Real Code

arhuman — Wed, 06 May 2026 01:35:12 +0000

tar+zstd is very hard to beat.

So I stopped trying to beat it as a byte compressor.

Instead, I tried something else:

compress the structure first, then compress the bytes.

That is the idea behind Metarc, a small experimental archiver written in Go.

It explores what I call metacompression: reducing structural and semantic redundancy across a source tree before applying a standard compressor such as zstd.

And on my current source-code benchmark corpus, Metarc is now smaller than tar+zstd on every tested repository.

The problem: tar sees a stream, not a project

Traditional archive pipelines are usually built around a simple idea:

directory tree → tar stream → compressor

This is robust, portable, simple, and battle-tested.

But it also means that by the time compression starts, a rich source tree has already been flattened into a byte stream.

A source-code repository is not just bytes.

It contains structure:

repeated files
duplicated licenses
common boilerplate
generated content
repeated JSON structures
logs with predictable patterns
similar files across directories
semantic redundancy that is easier to see before everything becomes a stream

A byte-level compressor can still find many patterns, of course.

zstd is excellent.

But some redundancy is easier to detect when the input is still a file tree.

That is the core idea of Metarc.

What is metacompression?

Metacompression means compressing information above the byte-stream level.

Instead of asking only:

how can we compress this sequence of bytes?

Metarc also asks:

what does this directory tree contain, and what redundancy exists before we turn it into a stream?

The current approach is roughly:

text source tree → scan files → analyze content → detect redundancy → apply structural / semantic transforms → store catalog + blobs → apply zstd → .marc archive

Metarc does not try to replace zstd.

It tries to give zstd a better input.

Current result

On the current benchmark corpus, Metarc produces smaller archives than tar+zstd on every tested source-code repository.

A few examples:

Repository	tar+zstd	marc	Gain
Kubernetes	81.1M	75.3M	7.2% smaller
React	18.5M	17.3M	6.4% smaller
Redis	8.9M	8.4M	5.6% smaller
NumPy	18.4M	17.7M	3.8% smaller

Across the tested repositories, the gain is currently around 3–7% compared to tar+zstd.

That may sound modest.

But beating tar+zstd at all on real source-code repositories is already interesting, because the final compression step still uses a standard compressor.

The difference comes from what happens before that final compression step.

Why this matters

A 3–7% improvement is not revolutionary by itself.

The interesting part is not the number alone.

The interesting part is that the improvement comes from changing the layer where compression starts.

Most compression pipelines treat the file tree as something to serialize before compression.

Metarc treats the file tree as something to analyze before compression.

That opens the door to transforms that byte-stream compression does not naturally model:

global file deduplication
semantic normalization
repeated structure detection
content-aware storage decisions
corpus-aware compression strategies

This is especially relevant for source-code repositories, where repetition often exists at a higher level than raw bytes.

Speed results

Metarc is also faster than tar+zstd in my current cold-cache benchmark runs.

But I want to be precise here:

the speedup is not the core meta-compression claim.

The speed difference mostly comes from implementation choices:

parallel scanning
parallel hashing
BLAKE3
lightweight transforms
avoiding some traditional archive pipeline costs

The main claim of meta-compression is about archive size.

The speed results are interesting, but they should not be confused with the compression idea itself.

What these benchmarks do not prove

These results do not prove that Metarc is universally better than tar+zstd.

They do not prove that this approach wins on every kind of data.

They do not prove that .marc should replace .tar.zst.

They show something narrower and, I think, more interesting:

on the tested source-code repositories, there is enough structural redundancy outside the byte stream to make meta-compression measurable.

Different datasets may behave very differently.

For example, I would not expect the same kind of gains on:

already compressed media
random binary blobs
encrypted data
image-heavy repositories
small directories with little repetition
corpora where zstd already captures most of the redundancy

This project is still experimental.

The goal is not to declare victory over tar.

The goal is to explore what happens when compression starts from a richer model of the input.

Benchmark methodology

The benchmark is designed to compare Metarc against a realistic baseline:

text tar + zstd

The current benchmark methodology uses:

real open-source repositories
pinned repository revisions
the same machine for all runs
median of multiple runs
cold cache by default for timing
direct comparison against tar+zstd
round-trip verification mode

The benchmark scripts are included in the repository.

For example:

bash ./scripts/run_bench.sh --type size ./scripts/run_bench.sh --type time ./scripts/compare_on_repo.sh --mode test

The full benchmark page is here:

https://github.com/arhuman/metarc-go/blob/main/docs/benchmarks.md

Why cold cache?

Benchmarking archive tools is tricky.

A hot-cache run can mostly measure CPU and compression speed.

A cold-cache run includes more of the real end-to-end cost of archiving a source tree from disk.

Both are useful, but they answer different questions.

For now, the default benchmark uses cold cache because it better represents the practical operation of archiving a repository.

That said, the distinction matters.

One thing I learned while working on the benchmark is that methodology can change the interpretation dramatically.

So if you look at the numbers, please look at the methodology too.

Benchmarks without context are just numerology with better fonts.

What Metarc currently does

Metarc is still experimental, but the current architecture already includes the core pieces needed to explore this idea:

text scan → analyze → plan → store → compress

At a high level:

Metarc scans the source tree.
It analyzes files and metadata.
It detects redundancy and chooses transforms.
It stores a catalog and content blobs.
It compresses the final archive.

The important part is that the archive format is not only a serialized tar stream.

It contains a representation of the structure Metarc discovered.

That gives the format room to evolve.

What could come next

The current results are encouraging, but this is still early.

Some possible next steps:

stronger file-level deduplication
repeated boilerplate detection
license block factoring
JSON normalization
log normalization
generated-file detection
language-aware transforms
better corpus analysis
more benchmark repositories
benchmark history per release
stronger archive verification tooling

I am especially interested in transforms that are simple, explainable, and reversible.

The goal is not to invent a magical compressor.

The goal is to find practical cases where knowing more about the input lets us compress it better.

Why Go?

Metarc is written in Go because the problem fits Go well:

file tree walking
concurrency
streaming I/O
simple binaries
good standard library
easy distribution
predictable performance

It is also a good language for building experimental infrastructure tools without turning the codebase into a research prototype that only runs on the author’s laptop during a full moon.

Go keeps the project boring in the right places.

That is useful when the idea itself is already unusual.

Is this production-ready?

No.

Metarc is usable, but it should still be treated as experimental.

The format may evolve.

The transforms may change.

The benchmark corpus will expand.

The implementation will likely be rewritten in parts as the design becomes clearer.

For now, I see it as a playground for exploring compression strategies above the byte-stream level.

If it becomes useful as a real archiver, great.

But the first goal is to test the idea properly.

The core idea

The shortest way to summarize Metarc is this:

`text
tar compresses a byte stream.

Metarc compresses a source tree.
`

That difference is now measurable on my benchmark corpus.

And that is what makes the project interesting to me.

Not because tar+zstd is bad.

It is not.

But because source-code repositories contain structure, and maybe compression tools should exploit more of it.

Feedback wanted

I am especially looking for:

criticism of the benchmark methodology
source-code repositories with unusual redundancy
ideas for reversible semantic transforms
references to similar projects or papers
cases where this approach should fail

The repository is here:

https://github.com/arhuman/metarc-go

The benchmark page is here:

https://github.com/arhuman/metarc-go/blob/main/docs/benchmarks.md

If you know a repository that would be a good stress test, I would love to try it.

Trying to beat the venerable tar

arhuman — Mon, 27 Apr 2026 01:53:29 +0000

Hi,

I’ve been working on a small Go project called Metarc: It's an Open Source file archiver and I’d be curious to get feedback from the community.

The idea is to explore “metacompression”: instead of only compressing bytes, try to reduce structural and semantic redundancy across files first (licenses, JSON, logs, duplicated content…), then apply a standard compressor.

On early repository benchmarks, it’s already:
_ 22% smaller thant tar + zstd on very specific kind of archives
(Code source with lot of redundancies)
_ faster than tar
_ with archive sizes often in the same range on popular github repos

It’s still experimental, but already usable and mainly intended as a playground for experimenting with compression strategies.

Would love to hear your thoughts or ideas on the subject.

Your Servers Deserve Better: Meet Minexus, a Smart Admin Agent System in Go

arhuman — Tue, 01 Jul 2025 00:48:30 +0000

Meet Minexus — A Modular, Distributed Admin System in Go

I was tired of managing my servers with brittle scripts, ad hoc SSH sessions, and clunky monitoring tools. So I built Minexus, a modular platform to monitor and control servers via secure agents, with Go and gRPC under the hood.

If you’ve ever wanted:

To send a command to 50 machines and get results back fast
To build your own admin plugins with Go
To manage your servers like a well-oiled, distributed system

Then this might be up your alley.

Architecture at a Glance

Minexus is made of 3 main components:

Nexus — the central server, connected to a PostgreSQL DB

Minions — lightweight agents running on your hosts, communicating with the Nexus via gRPC + mTLS

Console — an admin UI and command interface, also talking to the Nexus

Minions register periodically. Commands go through the Nexus, and results are logged/stored. Want a new command? Just write a command.

It’s simple, extensible, and built for sysadmins/devops/devs who want control without vendor lock-in.

Use Cases:

Remote command execution (with return capture)
Service restarts across hosts
Health checks / monitoring plugins
Security scans (CVE lookup, etc.)

Anything you can plug into a Go module...

Want to send restart-service nginx to all your production servers and get clean results in seconds? Minexus can do that.

Current status

It's early days, but it’s usable and growing. Contributors welcome — the command system (soon a plugin system) makes it a playground for Go devs.

You're not a coder, it's not a problem: I’d love 🙏

Feedback on the architecture
Suggestions for useful commands/plugins
Help testing on non-Linux environments
Ideas to make this your go-to internal admin framework

Let’s Build This Together

I believe sysadmin/devops tooling should be:

Easy to use
Hackable
Fun to extend

If you agree, give Minexus a spin, drop a comment, or open an issue.

GitHub: https://github.com/arhuman/minexus

Cheers,

Why I like generics in golang

arhuman — Fri, 31 Jul 2020 22:20:33 +0000

(article originally written on my blog in French)

I was reading again the excellent article from Ian Taylon and Robert Grisemeer (The next step for generics) and I couldn't help thinking that I love the way we're heading. In fact, I love so much those new generics that I've decided to write an article to claim it.

With the latest drafts published, you should all have a precise idea about what the generics will look like in the next version of Go. So rather than writing another technical review about the changes, I'll rather state why I like those generics because it's the exact same reasons why I like the language.

I like generics because they're simple

As type parameters are special parameters, they're now handle as parameters (after the function name) but in an optional distinct list starting with the 'type' keyword and located before the usual parameters list.

func Process(type T)(s []T) {
    // do something with the slice of T
}

The call is similar to a standard call, specifying the type just before the parameters list.

Process(int)([]int{1, 2, 3})

In some cases (when all the types are used for the input parameter types and not in the body) the compiler is even able to deduce the type from the parameter types.

Constraints are now defined through interface type (no more contracts). For example, if we want the type T to implement String() we just have to add the Stringer interface constraint.

// Stringer is a type constraint that requires a String method.
// The String method should return a string representation of the value.
type Stringer interface {
    String() string
}

func Process(type T Stringer)(s []T) {
    // do something with the slice of T, and call String() on slice elements
}

And if we want to put a constraint on an operator, we can now use base types in an interface type by prefixing the list of base types with 'type'.

// Ordered is a type constraint that matches any ordered type.
// An ordered type is one that supports the <, <=, >, and >= operators.
type Ordered interface {
    type int, int8, int16, int32, int64,
        uint, uint8, uint16, uint32, uint64, uintptr,
        float32, float64,
        string
}

And to make your life even simple, a new type constraint 'comparable' is now available to handle '==' and '!=' operators

// Index returns the index of x in s, or -1 if not found.
func Process(type T comparable)(s []T)  {
    // Now you can compare elements of slice even if they're struct or array
}

Simple, isn't it?

I like generics because I like Gophers' community spirit

But beyond the feature added to the language, what I like with those new generics, is that the way they were added adhere to the community spirit.

you have to remember that generics were the 3rd point (with dependencies/package and errors handling) considered as the most important to improve according to 2016 Go users survey and 2017 one.

The fact that language evolution has been initiated based on the community feedback (rather than on choices made by a "benevolent dictator for life") is already great.

The pace at which the features were introduced is also an interesting metric:

Modules handling (introduced in version 1.11 in 2018)
Errors handling (introduced in version 1.13 in 2019)
Generic introduction (executed in version 1.15 due for end of 2020)

As we see, the release pace is quite fast but not rushed.

I like generics because I like Go's philosophy

Lastly, I like generics because they comply with the Go's philosophy.
(since the Go Brand Book published in 2018, I'd rather use the word values)

Simple: As seen above those generic is simple (bye bye contracts) with few language modifications.
Efficient: With every draft, performance has been a constraint and the last one manage to allow you to choose between faster compilation and slower execution and the contrary.
Thoughtful: Because instead of implementing generics based on another language, the community took its time to design one complying to the spirit of the language, to write drafts, to discuss them, to improve what can be improved and do it again to reach an implementation which complies to the language objectives and spirit without sacrificing to performance.

I like generics because it's practical

Go being a pragmatic language, you can already test this generic implementation on go2go playground

But as I tend to be optimistic and enthusiastic, maybe I got carried away, so let me ask you: And you, What do you think about this generics implementation?

How could you pretend to be Agile if you don't even know Scrum rituals?

arhuman — Tue, 03 Sep 2019 13:06:47 +0000

(Article originally posted on my blog)

That's more or less what I've been asked in a recent (failed) interview.
That was more subtle of course, but after being corrected on Scrum terminology,
failing to recognize the prevalence of the retrospective over the other rituals probably sealed the outcome of the interview.

I clearly didn't convinced my interviewer. My last Scrum experience was ten years ago. And would probably be considered as "Faux Agile" in actual terminology. So he was probably allowed to assert that I wouldn't be a good Scrum Master. But does that mean that I was not Agile?

As a pragmatic person, I neither stubbornly rejected his assertion nor did I slavishly waived my belief.
I did some work: I've read books and articles and I've asserted my processes and values.

Yes, values...
Because to me it allways boils down to values.

The Agile Manifesto

To understant why, let's get back in time, in 2001 to be precise.
Because it's in 2001 that the Agile movement was born.
Seventeen Software developers, published what is now known as the "Agile Manifesto".
This 68 words long text is considered to be the basis of the Agile movement.
But most important to me, they also proclaim 4 values that define what we now call Agility:

Individuals and Interactions over processes and tools
Working Software over comprehensive documentation
Customer Collaboration over contract negotiation
Responding to Change over following a plan

At the same time they also presented 12 principles to enforce and develop those values but that's out of the scope of this article.

Regarding those values I could definitely consider myself as Agile.
I praise those values, and incidently I also follows several principles. And if you adhere to the Open Source culture you also probably do: The KISS principle, the “release early release often motto” are common illustrations of some of those principles.

eXtreme Programming

Going further, I discovered that prior to the Agile Manifesto, other (now considered) Agile methodologies existed, eXtreme Programming is one of those.

It also have values

Simplicity
Communication
Feedback
Respect
Courage

It happened that XP is also the first methodology I encountered as an Open Source software developer.
So without surprise, I also integrated those values long ago.

XP also defined several rules, similar to the Agile Manifesto principles.
Again, many rules will seems familiar to any Open Source software developer:

Integrate Often
All code must have unit tests.
All code must pass all unit tests before it can be released.
All production code is pair programmed.
Simplicity

And from this rules derived practices: Continuous integration, Test Driven Development, Pair programming...

Let's recap I check all the values, most of the rules, and several practices (especially as a CPANtester). So am I good, or is there something special about SCRUM that I miss?

Scrum

Let's see Scrum Values

Focus
Courage
Openness
Commitment
Respect

You probably noticed that it has 2 values in common with XP, the 3 remaining 'Focus', 'Openness' and 'Commitment' are related to the Scrum team.

Maybe we have an hint here.
As a XP developer, I feel I can claim an Agile ability. But in a Scrum Team ?

Sure some of the Scrum rituals are also XP practice (daily standing meeting) but as a single developer, it was not the practices I used.

Some people consider that Agility only make sense as a team member.
I can't just dismiss this belief but allow me to find it debatable: XP values does not require any team, and even the Agile Manifesto mention
individuals and interactions but without any precision this could well be related to a developer and its customer.

IMHO, Agility is all about improvement: team improvement, process improvement, technical improvement and self improvement.

Kanban

For completness (Scrum, Kanban, XP being the 3 most used methodologies) here are the Kanban values:

Understanding
Agreement
Respect
Leadership
Flow
Customer focus
Transparency
Balance
Collaboration

As a perceptive reader you might have spotted the 'Respect' value which is common to the others methodology.
To be honnest, I've never had the feeling that Kanban values were central to the methodology.
In what I've read, the core practices are often highlighted, and most of the time the values wheren’t even listed.
But may be I'm biased, I'm not sure people know XP values more than TDD or pair programming.

Conclusion

Back to the original question, I'm confident saying that I'm Agile even if I'm not an experienced Scrum Master or even practicionner.
First, because Scrum isn't the only Agile methodology out there and besides XP there are also Kanban, RAD, Lean SD, Wild Agile and many others.
Then and above all, because I follow/praise/put in practice values which are at the heart of many Agile methodologies (including Scrum).

Going further I think that the simple fact of restricting Agility to a process knowledge is an anti-Agile pattern to me (Remember "Individuals and Interactions over processes and tools"?)

That doesnt mean Rituals/practices are useless, they are a good way to check that you actually enforce the values you pretend to follow.
But they are only meaningfull if you remember and adhere to the associated values:
Attending a daily standing melee, with people you don't respect, staying silent on the encountered issues to hide that you screwed your task because you're just lazy is by no mean 'Agile'.

On my side, I'm aware that rituals/practices are the best way to enforce/check those values and I will go on improving my knowledge of all rituals/practices and of the associated principle. After all constant improvement is one of the 12 principles of the Agile Manifesto...

Credits

I'd like to thanks my peers from Happy Dev for their reviews/advices/insights.
And I'd like to express my gratitude to the interviewer mentioned in the article: he forced me to re-think my Agile stance, convinced me to improve my Scrum knowledge and reminded me that self-improvement is a daily duty.