Home on A journey into a wild pointer

Free of GitHub

Fri, 14 Aug 2026 12:00:00 +0200

GitHub was a source of joy for me since day one: a platform to connect with other nerds, discover new cool projects, read code and learn, which made me better… This was great.

But over time, the platform, and the internet, has deeply changed.

I don’t follow the current AI trend (and I don’t share the enthusiasm for AI agents), and I no longer learn anything new on this platform. Except that GitHub is now poorly managed and maintained by developers who don’t seem to care…

I’ve been gradually deprecating my GitHub account over the past few months.
And as of today, it’s been a month since I last touched, contributed to, or pushed anything to the platform.
I decided to write software for me, on my own place, on my own terms, and to expose it if I really think this can benefit for anyone else.

Before the AI shift, my default was to make everything public, and on GitHub.
But as the internet has become more agent-driven, I’ve switched to keeping things private and local by default.
This won’t have any impact on the internet at all. However, this will have a positive impact on the way I work, and on how I manage my time for my hobbies such as programming or making games.

I will keep the account open to publish or respond to issues, or to submit pull requests. Otherwise, I won’t publish new projects or updates there.

Thank you if you were a follower of my GitHub account.

Blame

Sat, 08 Aug 2026 00:00:00 +0000

The ideas shared here are mine alone and are not endorsed by my past or current employers.

I am a senior systems engineer and game engine programmer, living in Grand-Est region (France).

Contact #

Feel free to send “hi” at dev[at]carette[dot]xyz.
My public GPG key to contact me privately is available here.

Work experience #

My resume, in English.
My MobyGames profile.

Please take a look at this page for my past projects and publications.

Interesting links #

Projects

Sat, 08 Aug 2026 00:00:00 +0000

Books and research papers #

Books #

2017, Mastering Rust, Vesa Kaihlavirta (PACKT) - official reviewer

Research papers #

2016, Investigating the Energy Impact of Android Smells - accepted to SANER 2017
2015, A Learning Algorithm for Change Impact Prediction: Experimentation on 7 Java Applications - RAISE 2016

Blog posts, talks & presentations #

Professional blog posts #

Talks & Public presentations #

2018, L’apprentissage automatique, c’est pas automatique (Machine Learning is not magic), TakeOff Talks, Lille (France)
2018, Why you should take a look at Rust - an easy introduction to the Rust programming language, FOSDEM, Bruxelles (Belgium)
2017, Why you should take a look at Rust, LilleFP Meetup, Lille (France)
2016, Why you should take a look at Rust, Dernier Cri, Lille (France)
2016, Eco-design of Android applications, Latece team, UQAM (Canada)
2016, State of art about energy consumption models, for mobile devices, Emeraude team, IRCICA (France)
2015, Software development to study bugs propagation in Java applications, SequeL team, INRIA (France)
2015, Serious-game development, based on distributed artificial intelligence, SMAC team, CRIStAL (France)
2014, Software developer for the Vidjil project, Bonsai team, LIFL (France)

Video games #

Pico-8 cartridges #

Galactica, a (basic) space shooter

Personal projects #

Please check my Forgejo account for my recent personal projects.

My Github account is no longer in use (but I will keep it for legacy reasons) because:

I don’t trust Microsoft and GitHub engineers to do good work,
I don’t want my code to be used to train unethical LLM models or ‘AI agents’.

Moving forward

Tue, 21 Jul 2026 10:00:00 +0200

The lofi girl was right

Sometimes, fighting for a change isn’t worth it.

You try. Again and again. And as hard as you can.
You see the problems. You feel their weight. And you have solutions to propose: clear, practical, good ones.

So you speak up. Naively, you assume others will care.
Why? Because you believe in something simple: that people value integrity.
That a company thrives when its employees do.

But it fails.

Not because your arguments lacked clarity.
Not because the issue was yours alone to bear.
Not because you didn’t reach the right persons.
Not because you didn’t try hard enough.

It fails because people don’t want to change. Ego, laziness, short-term gain, apathy… none of these follow your logic.
And then, you realize something: logic is not the currency here.

So, after being drained by all those efforts, you step back.
Not in defeat, but in self-preservation.

You let go of the illusion that reason will win. Because in the end, the only thing left to fight for is yourself.

A story of screwdriver drivers

Sun, 05 Jul 2026 12:00:00 +0200

Any relation between this tale and modern software engineering is entirely up to your own interpretation.

This is the story of a building company CEO named Matthew. Matthew is a simple person: he likes to build buildings, and he likes it when people appreciate his buildings.

Compared to other construction companies, Matthew always checks for quality over quantity. He believes that clients are happier with clean and well-constructed building, and will come back to him more often if the final quality is high rather than just delivered fast.

However, recently, the market changed entirely.
A massive new trend took over the world: screwing things on walls. Clients no longer want standard, empty rooms. They suddenly want custom shelves, heavy cabinets, and complex fixtures screwed onto every available surface.
The trend is so massive that if a building doesn’t have hundreds of beautifully screwed-in assets, no one wants to buy it. Stocks of screw manufacturers skyrocketed, and they paid hardware shops to make weird videos on TikTok to promote that, again and again…

This put Matthew in a difficult position.
When he started his company, he built his first houses entirely by himself.
But today, as a CEO, he spends all his time drawing blueprints, managing budgets, and talking to clients. His hands haven’t touched a physical tool in years. When he tried to adapt to this new trend, he realized he couldn’t just pick up a screwdriver and finish the work himself. Modern screws are complex, he has no time for it, and honestly, he has lost all interest in the repetitive, manual labor of twisting a wrist all day…

On the other side, if he doesn’t adapt to the trend quickly, his competitors will steal all his clients.

So, on Monday, Matthew urgently posted an announcement: he is hiring a screwdriver driver with a great benefits package and a high salary. He has the budget for one screwdriver driver, and he wants the best one of all.

By Friday, he already had 100 applications.
Overwhelmed with the number of applications, he decided to close the job posting and to start processing the list of candidates.

Looking at the applicant profiles, they seemed great!
They knew how to use a screwdriver!
They even had their own screwdrivers! AMAZING!

But then, Matthew asked himself:

How can I actually choose the best one among these 100 applications?
Should I take the first one?
Should I take the one who has the most experience with a screwdriver?
Should I take the one who has the most expensive screwdriver?
Or maybe I should take the one with the most used screwdriver?

So many questions made Matthew worried that he couldn’t choose the right person for the job…

But, he had suddenly an idea.

The contest #

Matthew decided to run a contest.

He already had four buildings waiting “to be screwed”, for four different clients who were strongly following this #SCREW trend. His idea was to hire four different people for one week, one building per applicant, and choose the one who made his clients the happiest.

Among those 100 applications he chose:

the youngest: very enthousiast to start working, who dream of screwdrivers at night, learned everything on the internet, and spent his time endlessly customizing his screwdriver for years,
the dandy: his profile was incredibly clean, and he had spent thousands of euros on his gold screwdriver… surely he must know how to use it well, right?
the pragmatic: he had recently converted from a hammer driver to a screwdriver driver, but could his past experience translate from one tool to another?
the 10x rockstar: very famous in the Builders community on YouTube (though criticized by another minor community in a specialized forum), known for delivering things fast.

Each applicant was given one job: one building, one client, and a strict list of requirements. The requirements consisted of a plan detailing exactly what needed to be screwed, and where, provided by the client of the building.
The goal was to finish all the screwdriver work in their assigned building within the week. As soon as the week was over, Matthew would visit each building with the clients and listen to their feedback.

All applicants agreed, and the contest started.
In the meantime, Matthew took a week off in the mountains, forgeting his phone and the world behind him.

The first building #

One week after, Matthew came back from holidays and visited the first building with his clients, assigned to the youngest applicant.

All the screwdriver work was done! Great!
The clients looked happy at first, but upon closer inspection… it wasn’t good at all.

Paintings and kitchen cabinets were not aligned properly. Some small objects had way too many screws, while large shelves meant to hold 100+ kilos of books were held up by only one or two. The clients tested a few fixtures, and they immediately fell off the wall. Worse, some screws had punctured holes in the plumbing, causing water to leak in several places.

Matthew asked the applicant “Why did you do this? Did you followed the requirements?”
The applicant simply answered that he might not have understood the requirements. In the end, it was clear he didn’t even understand the client’s actual needs, he needed support and mentoring, even if he built a lot of stuff on his own at home.

The second building #

Matthew moved on to the second building, full of hope, to meet the dandy applicant.

The screwdriver work wasn’t done… in fact, it wasn’t even 20% finished. The clients were not happy at all and demanded to know why the delivery was so late.

Matthew asked the applicant “But, why are you so far behind?”
The applicant replied that the original requirements were weak, so he had to rework a lot of things himself. He handed Matthew a brand new plan, which looked nothing like the original. Some of the building’s foundations had been entirely redesigned from the ground up because the applicant felt structural modifications were necessary.
At the end of the discussion applicant asked for one more week just to finish planning, before he could even start the real work.

The third building #

Matthew moved to the third building, feeling desperate, to meet the pragmatic builder.

The screwdriver work was 80% done, but things were slightly out of place. Matthew and the clients were annoyed, and Matthew asked the applicant “Why didn’t you finish the work? And why did you change a bit the plan?”

The pragmatic applicant explained his reasoning. The original plan was just theory: it assumed everything had a perfect place for a perfect reason. However, he explained that some things needed to deviate slightly from the plan. For instance, some screws were originally planned to go dangerously close to pipes, while others were supposed to be driven into brittle materials. He spotted these risks based on his broad knowledge of building materials and his past experience with hammers.
In his defense regarding the timing issue, he had tried to call Matthew several times but, as he was on holidays with no phone, he couldn’t get the answers in time.

The applicant explained he needed two more days to finish the work, but only after Matthew and the clients answered a list of clarifying questions to fix the flawed requirements.

The clients and Matthew understood, agreeing that the changes were ultimately necessary. Not because the applicant manipulated them, but because he was a true expert, and all his explanations made perfect sense.

The fourth building #

Matthew moved to the fourth building, with mixed feelings.

But, once he reached the door of the building… The screwdriver work was completely done! Actually, the 10x rockstar had finished everything in only four days! And the clients were actually very happy!

Matthew and the clients, very enthousiastic, asked the screwdriver driver “But, how did you do this so fast?”.
The builder explained: instead of a normal screwdriver, he had brought a heavy, custom-made electric drill that seemed to do all the thinking and spinning for him.
He just had to point it, pull the trigger, and let the tool do the magic.
He said that screwdrivers were tools of the past, and that electric drills are the future.

Matthew was relieved, and the clients left, a big smile on their face.

But as Matthew took a quiet walk through the building, his expert eyes started to notice terrifying details. The applicant had driven heavy screws directly into fragile drywall, completely missing the solid wooden foundations behind it. He had mixed incompatible metals together and forced thick screws into thin glass edges. The cabinets and shelves were holding up for today, but the mistakes were deep and entirely invisible to a normal client. They required an expert to even spot them. Eventually, under the weight of time, the entire wall would rip open, and some levels of the building would need to be rebuilt from scratch.

It was an hidden disaster.

Matthew asked the applicant “What did you do? Did you understand how weight distribution and structural foundations actually work?”
The applicant just shrugged. He admitted he didn’t really know how the walls were built inside, but he had no time to learn as he wants to build things. His shiny drill just made things stick together, it looked fine on the surface, and that was all that mattered.

Matthew then noticed a shelf was a bit crooked. He decided to adjust it, but he didn’t have a screwdriver on him, neither the screwdriver driver. So, he went to the nearest hardware store and bought one. When he came back, he tried to unscrew the shelf a little bit, but he couldn’t. He looked closely at the screw, and then at all the other screws. Every single screw head on the shelf was completely destroyed. They were totally flat and stripped.

Matthew called the applicant back, and asked “What will happen when the wall inevitably starts cracking, or if the clients need to move a kitchen cabinet later?”
The applicant answered that he delivered faster than anyone else, which is what clients always want. He pointed out that the original plan never explicitly said the building needed to survive for the next ten years.

“Also”, he raised, “is there a real purpose to maintain this big building for more than 10 years…?”

The hiring #

At the end of the day, Matthew sat down at his desk, staring at the four files.

He reviewed the results of the contest:

the youngest applicant had punctured pipes and caused water leaks in several rooms. He had finished the work, sure, and Matthew knew that with mentoring and real-world experience, this young kid could become one of the greatest screwdriver drivers in the world. But Matthew simply didn’t have the budget or the time to provide that guidance…
the dandy applicant hadn’t even started the real work, trapped in endless planning and rewriting the original plans,
the pragmatic applicant did not finish the work, and had paused at 80% to question the requirements, but his questions and worries made sense,
and the 10x rockstar had finished all his tasks in just four days, despite critical and foundational flaws.

Matthew smiled warmly as he looked at the pragmatic screwdriver driver profile.
Matthew knew by intuition this was the absolute perfect fit for his company values. Yes, he was a bit slower, but that was because he actually cared. He didn’t just blindly force screws into a flawed plan, he actually paused to understand the true needs of the client in order to provide the most qualitative, enduring solution possible.
The clients would be genuinely safe and happy for years to come.

Matthew picked up the phone, and called back the 10x rockstar. He was hired.

Bringing Swift through Distrobox on NixOS

Sun, 28 Jun 2026 19:00:00 +0100

I am working on a project that combines Swift, Raylib, and Raygui.
I don’t really know what the end-goal is here, but I am having fun. That’s enough for me to work occasionally on that.

I like Swift very much, and I have had more fun developing in Swift than in Rust or C++ recently. But, there is a small catch with Swift outside the Apple ecosystem: its adaptability to other platforms sometimes, mostly on some Linux distributions. As an example, even though Swift is a general-purpose programming language for multiple platforms and OSs, its official support does not include NixOS, a Linux distribution I have been using for a few months now.

The latest version of Swift, maintained by the NixOS community, is 5.10.1.
People are actually trying to bring the latest version of Swift to nix systems, but it is not ready yet, and the installation today is still a loud, highly manual process with very specific steps.

I wish I had more time and knowledge to contribute to swift-nixos, but I also wanted to test my project very quickly on my small linux machine, under 15 minutes.

So… distrobox to the rescue!

The configuration #

Distrobox is a pretty cool project.
Its main objective is to bring any Linux distribution inside your terminal, via containers. Compatibility is great, and the created container will communicate tightly with the host, sharing the HOME directory of the user, graphical apps (X11, Wayland), audio, … which is absolutely perfect for my needs!

On NixOS I enabled both rootless containers (via podman) and distrobox:

virtualisation.podman = {
  enable = true;
  # This makes typing 'docker' under the hood use podman
  dockerCompat = true; 
  defaultNetwork.settings.dns_enabled = true;
};

environment.systemPackages = with pkgs; [ distrobox ];

Once the quick system rebuild is finished, I can finally set up my distrobox environment for Swift:

distrobox create --name swift-env --image ubuntu:26.04

Even though Swift is compatible with Ubuntu 24.04, I preferred to use the 26.04 LTS version instead.

This will need an extra step, as a dependency uses a different version than the one provided by apt (we will come to that later in this blog post).

Now, let’s enter the Ubuntu container:

distrobox enter swift-env

and… that’s it! I am in an Ubuntu environment, on my NixOS machine. Great!

Now, let’s set up that container as if it were a true local Ubuntu system:

$ sudo apt update && \
sudo apt install -y mesa-utils x11-apps git make libxml2-dev && \
curl -O https://download.swift.org/swiftly/linux/swiftly-$(uname -m).tar.gz && \
tar zxf swiftly-$(uname -m).tar.gz && \
./swiftly init --quiet-shell-followup && \
. "${SWIFTLY_HOME_DIR:-$HOME/.local/share/swiftly}/env.sh" && \
hash -r

swiftly and the Swift programming language are now installed in that Ubuntu container.

I can now go to my local project, and try to run it (debug mode):

cd ~/Devel/recreational-swift-raylib-game && swift run -c debug

but…

> /home/user/.local/share/swiftly/toolchains/6.3.2/usr/bin/lldb: error while loading shared libraries: libxml2.so.2: cannot open shared object file: No such file or directory

So close. But this makes sense!

I said earlier that the Swift installer proposes the Ubuntu 24.04 version, but not the 26.04 one. In this newer Ubuntu release, the libxml2 developers introduced a backwards-incompatible update that bumped the shared library name from libxml2.so.2 to libxml2.so.16.

However, the pre-compiled Swift toolchains available through swiftly were built in environments that strictly expect the older libxml2.so.2. So, even though we have the latest version of the library installed, lldb is completely blind to it.

Let’s use the good old hack to trick the Swift toolchain into using the new version of the library by creating a symbolic link from the old filename to the new one:

sudo ln -s /usr/lib/x86_64-linux-gnu/libxml2.so.16 /usr/lib/x86_64-linux-gnu/libxml2.so.2

and it finally works!

The distrobox ini file #

To automate the setup, distrobox allows you to create an ini file that processes things automatically for you:

[swift-env]
image=ubuntu:26.04

init_hooks="apt-get update"
init_hooks="apt-get -y install mesa-utils x11-apps git make libxml2-dev"
init_hooks="ln -sf /usr/lib/x86_64-linux-gnu/libxml2.so.16 /usr/lib/x86_64-linux-gnu/libxml2.so.2"

# Pull the latest version of the image if it isn't cached
pull=true

init_hooks calls run as root to install system libraries and apply our symlink hack. swiftly is intentionally excluded here, as my ~/.local/share directory is shared with the NixOS host, meaning swiftly only needs to be installed once manually!

A praise to nixpkgs maintainers #

Hopefully, this post will be helpful for anyone looking for a quick way to test their Swift projects on unsupported Linux distributions.

Even though this quick hack is great to quickly test a build on a Linux system, it does not fit the philosophy of NixOS: an automatic, deterministic system.

I want to thank all contributors and maintainers of the Swift programming language for Nix to dedicate their (mostly personal) time to bring this programming language, and ecosystem, to Nix systems.
So, a big thanks to Daniel Duan, Samasaur, Stéphan Kochen and Tom Repetti for maintaining Swift for Nix systems. Also, thanks to Lucas Ly Ba for his contributions in bringing a new way to build Swift from source on NixOS.

I plan to spend more time contributing to that topic as well, and on the LLVM side (trying to contribute to Swift WASM), as soon as I get more time to focus and contribute to open source projects.

The mud and the mind

Sat, 13 Jun 2026 11:00:00 +0200

In my previous article I discussed about the necessary evil to change the coding tests to filter engineers.

As LLMs become the ultimate coders (producing boilerplate infinitely, instantly, and without fatigue) the software engineering workflow is rapidly shifting, and day-to-day work is moving heavily toward auditing and reviewing AI-generated code.
But because of this shift, a dangerous corporate fantasy is taking root: the belief that engineers should simply become project managers. But let us not confuse this evolution with a retreat.

Becoming an auditor does not mean keeping your hands clean.

Expecting engineers to simply shuffle tickets and prompt LLMs is a profound misunderstanding of the craft. An engineer’s primary output has never been code but has always been deep thought on how to efficiently solve a problem.

To solve a problem, you will need intuition.
To develop intuition you need experience.
And to gain experience you definitely need to put your hands in the mud and break your teeth on walls of complex archiecture.

You might ask yourself: “if writing boilerplate syntax is no longer the mud, so what is?”.
We need to redefine where the hard work actually happens in software engineering. The mud is no longer writing REST controllers, or scaffolding a CRUD application. The mud is profiling memory leaks in production. It is tracing unpredictable latency spikes across a distributed system. It is staring at obscure telemetry logs at 3 AM because your beautifully Claude-generated architecture introduced a silent race condition that only appears under heavy load.

That is where engineering happens and where engineers are needed.
That is the mud.

And this brings us to the ultimate reality check: accountability.
You can automate the creation, but you cannot automate the responsibility, because LLMs and Agents can write the boilerplate but they cannot suffer the consequences of a bad design. At the end of the day, you do, and this is what you get paid for.

Companies that confuse engineering with mere ticket-shuffling will inevitably build fragile, incomprehensible black boxes, and if an organization expects you to be a PM rather than a deep technical thinker, they have already lost the plot.
In this special case I have an advice: ignore them, and solve problems in places where the real problems to solve are.

The five pillars of the post-AI interview

Fri, 12 Jun 2026 23:15:00 +0200

Programming tests used to be our primary filter to separate profiles.

In software engineering, they historically differentiated three distinct ones:

the engineers, the ones who solve the fundamental problems.
the developers, the ones who apply the right patterns and orchestrate the architecture depending on the needs.
the coders, the ones who just write code, code, and code.

We used to put candidates through exhausting steps to check everything: their writing, their communication, their “syntax recall”, and if their mind fit the culture of the team.

Before the LLM boom, the live coding interview was already questionable as, most of the time, it was a “performance of memorization”. However, today, it became pointless.

Shifting #

Culture fit remains the immovable constant. A toxic genius or an uncommunicative teammate is still a catastrophic hire, regardless of the tools they use. And, as you might already know, AI doesn’t fix human behaviours.

But the coding test itself is dead, not because writing code isn’t useful (I will always be the one who considers that making a thing is the best way to understand that thing), but because cheating the test is easier than ever. We are entering an era where a Builder agent can generate a 500-line pull request in a matter of seconds, mostly slop, and submit it directly in an ocean of slops.

In order to improve the workflow, the primary job of the human is shifting. Some of us are no longer just creators, but (unfortunately, in my own opinion) editors and auditors.

The five new pillars #

If we strip away the obsolete rituals, we are left with a new reality.

In order to reflect this reality, I personally would replace the traditional tests with five distinct checks, or pillars:

the cultural fit check.
the algorithmic core: if you can’t design an algorithm with nothing but pseudo-code, you will write unscalable, unmaintainable software. Worse: you will let an LLM write it for you, and you won’t even get the intuition to realize it is fundamentally flawed.
the architectural feeling: the hardest problems today are not about writing isolated functions but managing data flow, handling asynchronous events, defining strict API contracts, and surviving the chaos of distributed architectures. This is still a valuable skill (which is not even owned at Anthropic apparently…).
the code review: if you can’t review code, you can’t direct AI tools. You cannot lead a team. You cannot even trust your own work.
debugging code: if LLMs are doing the heavy lifting of writing the boilerplate, the human is left with the hardest part: debugging. A great modern interview test would hand a candidate a codebase riddled with subtle, AI-generated logic flaws and ask them to find and fix the bugs.

At the end, if a candidate cannot critique, debug, and verify code, they are not an asset but a liability.

Previously, we had room for all three profiles, and our tests were designed to expose those specific skills.

Today, there is a catch.
The trend is undeniable: LLMs are the ultimate coders. They produce boilerplate infinitely, instantly, and without fatigue. We are leaving the coders behind, returning, by necessity, to a future built entirely by engineers.

Made (by humans) in California

Tue, 26 May 2026 23:15:00 +0200

Very recently, I was hunting for a new TV show and clicked on Apple TV, drawn in by the buzz surrounding Margo Has Money Troubles. I launched the first episode and got hooked by the new intro logo.

It caught my eye because it felt weirdly alive. There was a specific, imperfect flicker of light across what looked like “organic glass”. It lacked the sterile, mathematically perfect glare we’ve become numb to in modern streaming intros.

Then a friend told me how it was actually made: this wasn’t rendered on a server farm but carved from actual glass, lit by hand, and filmed in a blacked-out studio like a 1960s Kubrick shot.

In 2026, when every piece of motion design can be generated by typing a text prompt, choosing a physical rig feels less like a throwback and more like a provocation.

From “crush” to craftsmanship #

Apple has always built its brand premium on human craftsmanship.

In 1984, Ridley Scott’s dystopian “1984” ad didn’t just sell Macintosh computers, it used practical sets and real actors to position Apple as the ultimate anti-establishment tool (against Big Blue at that time). Even today, “1984” is still used as a reference for commercial ads.

In 1997, the “Think Different” campaign didn’t show products at all (and that is weird for a commercial ad). Lee Clow, Craig Tanimoto, and Jessica Edelstein filled billboards with raw, black-and-white portraits of Einstein, Lennon, MLK, and Picasso.
The subtext was arrogant but brilliant: Apple stood with the creators, not the systems.

But, in 2024, that relationship fractured.
Some of us remember the disastrous “Crush!” ad for the iPad Pro, where a hydraulic press crushed pianos, cameras, and paint tubes into a thin sheet of silicon. At first, it looked like Apple was finally siding with the machines, celebrating the compression of human culture into a sterile tablet. The creative community felt betrayed, expressed it, and Apple remove the ad after a few weeks.

Today, the new glass logo feels like a calculated, multi-million-dollar apology tour.
At Cannes Lions, Tor Myhren, Apple’s VP of marketing communications, stated: “AI will not save advertising. The human touch is our superpower.”.
And their decade-long partnership with TBWA\Media Arts Lab, recently awarded the One Show’s Penta Pencil, proves they are trying hard to pivot back to their roots.

So when it came time to rebrand Apple TV, the choice did not feel aesthetic, but political.

Glass and light #

The new intro is a lesson in intentional friction. In a world where you can click “render” and get perfection in a matter of minutes, Apple chose to solve brutal physics problems on a physical stage.

The asset exists in three lengths: a brief one-second trailer pop, a five-second television intro, and a full 12-second cinematic version for features.

As the “behind the scenes” footage reveals, there are no digital shortcuts here. Full-scale glass panels were cut, polished into the Apple logo shape, and mounted on precision rigs. The shifting colors and organic refractions weren’t mapped in software. Instead, a studio crew physically choreographed lights around a static camera rig. A single smudge on the glass or a misaligned light beam meant resetting the entire take.

TBWA\Media Arts Lab and the directors at Optical Arts explicitly chose practical effects over CGI. Even the audio (a sparse, tactile composition by Finneas) and the typography (a customized variant of Apple’s in-house San Francisco font) were tuned to feel “physical”.

Instead of simulating light bouncing off a polygon, they let actual glass bend, scatter, and pool light in ways that path-tracing algorithms still can’t entirely replicate without looking “uncanny”.

To the roots #

In an era where the tech industry is rushing to automate every creative impulse, Apple’s glass logo is a quiet, deliberate act of resistance.

It marks a profound moment of self-correction. If the “Crush!” ad was a clumsy misstep that valued the machine over the medium, this logo is a humble return to the roots that made Apple a beloved brand in the first place. It is a reminder that technology should be a tool for the creator, not a replacement of the creator.

When digital perfection becomes the default, it loses its soul. By choosing the messy, unpredictable choreography of physical glass and studio lights, Apple didn’t just take the hard road, but proved that human intention still possesses a warmth that code cannot replicate.

They looked at a future dominated by synthetic generation, and chose to bet on the unmatched superpower of human touch.

Made (by humans) in California.

Who is gonna buy your services if you fire us all?

Mon, 18 May 2026 23:00:00 +0200

Silicon Valley executives used to complain about “the Great Resignation” to justify replacing people with machines. Now, they have suddenly changed their tune to sound like generous givers. Figures like Sam Altman and Elon Musk now claim that artificial intelligence will culminate in a liberated society characterized by truncated 32-hour workweeks and Universal Basic Income (UBI). In their view, automation is a tool that will finally free humans from the need to work to survive.

Stripping away this corporate talk reveals a simple paradox for AI: if automation destroys human jobs, it also destroys the customer base needed to buy AI subscriptions like ChatGPT, Claude, or Gemini.

The sudden trend of supporting universal cash payouts does not come from a kind heart. It comes from self-preservation. Looking at history, this plan is just a modern version of the same economic tricks used in the 19th century to turn workers into forced consumers.

Rebranding the cost of labor #

To understand why elites love UBI today, we have to look at what happened after slavery ended. In the early 19th century, forced labor was the ultimate way for business owners to make money without paying wages. When slavery was legally abolished across European colonies, the old economic system did not disappear. It simply changed its name to keep power in the same hands.

A perfect example happened in the French colony of Réunion after the 1848 abolition decree. The government paid former slave owners for losing their “property,” but gave the freed workers abstract legal freedom without any money or land to survive. Because freedom without money is just another way to stay trapped, the sugar plantations quickly created the engagisme (indentured labor) system.

Former slaves were replaced by workers tied to strict five-year contracts. They were paid in a tightly controlled mix of tiny wages and basic food. Trapped by manufactured debt and harsh laws, their exploitation never actually ended. The British Empire did the exact same thing after its 1833 abolition act, replacing Caribbean slaves with waves of contract workers from India and China. This proves that moving from slavery to contract labor was just a modern way to keep extracting wealth from workers.

The creation of the working consumer #

As the industrial revolution grew, Western factories ran into a major bottleneck: machines were making huge amounts of goods, but the working class was paid too little to buy them. From this crisis, elites realized a foundational rule of modern capitalism: to keep selling goods, the worker had to be turned into a consumer.

This shift is often romanticized as an act of kindness by early industrial titans, especially Henry Ford’s creation of the five-day workweek and the five-dollar daily wage. However, historical data demonstrates that Ford’s adjustments were entirely transactional optimization strategies designed to solve catastrophic employee turnover and secure an adequate domestic market for mass-produced vehicles. Workers needed both free time and cash to buy the very cars they were building on the assembly lines.

When wages stopped growing naturally in the late 20th century, corporations kept this buying loop going by building a massive system of debt. This allowed the working class to keep buying goods today by borrowing against their future labor.

The closed-loop feudalism of the AI era #

The modern rise of large language models and AI agents is the next step in this history. As corporations replace human workers with AI to cut costs, they hit a major capitalist contradiction: an economy devoid of salaried workers is an economy devoid of aggregate demand.

This mathematical problem explains the true purpose of UBI. When tech billionaires push for a government allowance, they are not trying to redistribute wealth fairly, but they are designing an emergency money injection to stop the consumer market from collapsing.

In an AI economy where a few massive tech giants own all the tools and data infrastructure, UBI is just a closed loop. The government hands cash to displaced people, who immediately send that money right back to the tech companies to pay for subscriptions, automated food delivery, or digital entertainment.

This plan shows a complete lack of real bravery. Instead of sharing the ownership of AI, the tech elite wants to build a modern version of technofeudalism. Just like the contract workers of 1848 who were legally free but forced to spend their wages at the plantation store, modern citizens under this system are freed from work only to be permanently trapped as captive consumers.

The tech formula #

The tech sector is currently solving its profit problem in three clear steps:

eliminate human labor using scalable AI systems to maximize corporate profits,
launch UBI as an economic cushion, ensuring people have just enough cash to keep buying products and subscribe to services,
lock down control of capital, keeping the core code, hardware, and billions in profits in private hands.

The real issue is not whether machines will take our jobs, but why we should accept a system where we only exist to pass cash back to tech corporations. These AI systems were trained on data created by the collective history of human knowledge.
Because of this, the wealth generated by automation should be treated as something that belongs to the public, rather than a private monopoly. Instead of accepting a small allowance handed down by Silicon Valley to keep us quiet, we should view the benefits of automation as a shared resource that belongs to everyone.

Beyond C: wrapping Dear ImGui in Swift with zero FFI

Thu, 26 Mar 2026 23:00:00 +0100

A few days ago I wrote and published a blog post about how Swift interacts with C projects, using Raylib.

Somehow, much to my delight, it has been posted on multiple social networks, like Reddit and Hackernews.
Comments were interesting and constructive. Many people praised how Swift manages interactivity with Raylib, but a few expressed their disappointment about the lack of demonstration on how to interact with a C++ project.

Yesterday, again, I was bored. So I tried.

Like the previous one this article is for demonstration purpose only.
I will not demonstrate this time how to build a WASM version of the finished project, most particularly because some exciting changes are coming in the Swift WASM ecosystem and I am waiting for those changes before doing the WASM build.

Swift <3 Dear ImGui #

This time I decided to integrate Dear ImGui into my (very simple) project.
Raylib will be used to initialize the window, initialize the screen, clear it, and draw some text. ImGui, compared to Raylib, will be used to draw some GUI (used mainly for very useful menus to interact with the core of your program).

Last time I discussed how easy integrating Raylib was: dropping the main header file of Raylib and its static library, and let the compiler and package manager do their magic.

But how is it different compared to Dear ImGui, a C++ project?

The project structure #

The project structure does not change that much.
I included a static build of Dear ImGui (including rlImGui, which is a Raylib integration with DearImGui), and the headers of both Dear ImGui and rlImGui.

That folder (ImGui) will be dedicated to being a Clang module, as Raylib was previously.

Package.swift
Sources/
    ImGui/
        macOS/
            dearimgui.a
        imconfig.h
        imgui.h
        imgui_internal.h
        ...
        module.modulemap
    CRaylib/
        macOS/
            libraylib.a
        WASM/
            libraylib.a
        raylib.h
    MyGame/
        main.swift

Again, I declare a module.modulemap in this folder, to help the compiler make the bridge between the Clang module and Swift:

module ImGui [system] {
    header "imgui.h"
    header "rlImGui.h"
    link "imgui"
    export *
}

Compared to Raylib I exported two headers here: imgui.h to interact with Dear ImGui, and rlImGui.h for rlImGui (as a reminder: the bridge between Raylib and Dear ImGui).

The Package.swift file #

As with Raylib, I explicitly define a new target called imgui, which has a dependency to raylib:

// swift-tools-version: 6.2
import PackageDescription

let package = Package(
    name: "MyGame",
    targets: [
        // Raylib
        .target(
            name: "craylib",
            path: "Sources/CRaylib",
            publicHeadersPath: ".",
            linkerSettings: [
                .unsafeFlags(["-L", "Sources/CRaylib/macOS"], .when(platforms: [.macOS])),
                // Link required macOS graphics frameworks
                .linkedFramework("OpenGL", .when(platforms: [.macOS])),
                .linkedFramework("Cocoa", .when(platforms: [.macOS])),
                .linkedFramework("IOKit", .when(platforms: [.macOS])),
                .linkedFramework("CoreVideo", .when(platforms: [.macOS])),

                // WASM only
                .unsafeFlags(["-L", "Sources/CRaylib/WASM"], .when(platforms: [.wasi])),
            ]
        ),
        // NEW: ImGui integration
        .target(
            name: "imgui",
            dependencies: ["craylib"], // Usage of rlImGui, which needs a dependency to the Raylib Clang module
            path: "Sources/ImGui",
            publicHeadersPath: ".",
            linkerSettings: [
                .unsafeFlags(["-L", "Sources/ImGui/macOS"], .when(platforms: [.macOS])),
                .linkedLibrary("c++", .when(platforms: [.macOS])), // This time I use a C++ library, so I want the C++ standard library linked to that module
            ]
        ),
        .executableTarget(
            name: "MyGame",
            dependencies: ["craylib", "imgui"], // Now my project has two dependencies: Raylib and Dear ImGui
        ),
    ]
)

Let’s run it #

Ok, now, I have to change the Swift main.swift source to use our new dependencies.

import CRaylib
import ImGui

let screenWidth: Int32 = 1200
let screenHeight: Int32 = 800

InitWindow(screenWidth, screenHeight, "Swift + Raylib + ImGui")

SetTargetFPS(60)

let rayWhite = Color(r: 245, g: 245, b: 245, a: 255)
let darkGray = Color(r: 80, g: 80, b: 80, a: 255)

rlImGuiSetup(true)
var showDemoWindow = true
while !WindowShouldClose() {
    BeginDrawing()

    ClearBackground(rayWhite)
    DrawText("It's alive... ALIVE!", 300, 300, 20, darkGray)

    rlImGuiBegin()

    if showDemoWindow {
        ImGui.ShowDemoWindow(&showDemoWindow)
    }

    rlImGuiEnd()

    EndDrawing()
}

rlImGuiShutdown()
CloseWindow()

The code is very simple: I spawn a native window, setup using Raylib, and then draw some text and display the Dear ImGui demo window.

Let’s run that make run-mac command and…

[...]
<unknown>:0: error: too many errors emitted, stopping now
/Users/me/Devel/craylib/Sources/MyGame/main.swift:4:12: error: could not build Objective-C module 'ImGui'
 2 | 
 3 | #if os(macOS)
 4 |     import ImGui
   |            `- error: could not build Objective-C module 'ImGui'
 5 | #endif
 6 | 

make: *** [Makefile:17: run-mac] Error 1

Oh no.

Upgrading the Clang Importer #

What happened?

Swift uses a built-in tool called the Clang Importer to import Clang modules and maps the C or Objective-C APIs for Swift. This means that the Clang Importer looks at our files, sees C++ keywords like namespace, class, template, completely panics, and throws an error saying it doesn’t recognize the syntax. This explains why I can easily compile C code, and not C++ code…

Thankfully the Swift community managed to make the “translation” for C++ since Swift 5.9 using the interoperabilityMode Swift build setting. This setting enables C++ interoperability for a given target.

interoperabilityMode has to be enabled in our executable settings, so:

let package = Package(
    name: "MyGame",
    targets: [
        ...
        .executableTarget(
            name: "MyGame",
            dependencies: ["craylib", "imgui"],
            swiftSettings: [
                .interoperabilityMode(.Cxx) // tells Swift to parse C++ directly
            ]
        ),
    ]
)

Now, does this compile?

Let’s run it (2) #

Ok, let build and run it again, and…

Mission completed!

Conclusion #

Wrapping DearImgui for Swift, a C++ project, was as straightforward as wrapping Raylib. The subtle difference is simply enabling the C++ interoperability in the package configuration, which is just a matter of a simple Google search (or in your favorite LLM).

I guess people will argue that this project is not complex or big enough to make assumptions. And they are right!

But this is a start, and I don’t plan on stopping there…

Link to the Github project: https://github.com/k0pernicus/swift-c-raylib.

Testing the Swift C compatibility with Raylib

Sun, 22 Mar 2026 14:00:00 +0100

Since Ladybird team abandoned their Swift adoption for the browser I heard a lot of criticism about the Swift ecosystem and the interaction between Swift and C/C++ projects.

My usage of Swift is mainly for command line tools, recreational programming (like Advent of Code 2023 and previous years) or Metal programming.

In my previous experiments I really enjoyed Swift, and actually preferred it to some other programming languages like Rust. However it seems that programmers have wrong opinions about this programming language, especially about its accessibility (no it is not only for Apple platforms) and its actual power wrapping C/C++ libraries.

Today, I will demonstrate how easy I built a very basic Raylib game using Swift, with no FFI, and for macOS and web (using WASI).

This article is for demonstration purposes, and is not a tutorial. To this end I will not explain how to install Swift, the WASM SDK for Swift, etc.
However, if you are interested in reproducing this demonstration at home, you can find the finished project on my github and adapt for your own needs.

Swift <3 Raylib #

Unlike other languages, Swift does not require you to write manual FFI bindings or wrapper layers to interact with C code. FFIs are engineered to be completely invisible and automatic via the Clang importer (more about that later).

This means you can directly drop your C headers in your project, the static C library, and use the power of the Swift Package Manager to tell the compiler how the project needs to be compiled.

The code I want to run is very simple: initialize raylib, a window, and drawing a text.
This is the Swift code:

import CRaylib

let screenWidth: Int32 = 800
let screenHeight: Int32 = 600

#if os(WASI)
    InitWindow(screenWidth, screenHeight, "WASM C Raylib from Swift!")
#else
    InitWindow(screenWidth, screenHeight, "Raw C Raylib from Swift!")
#endif
SetTargetFPS(60)

let rayWhite = Color(r: 245, g: 245, b: 245, a: 255)
let darkGray = Color(r: 80, g: 80, b: 80, a: 255)

while !WindowShouldClose() {

    BeginDrawing()

    ClearBackground(rayWhite)
    DrawText("It's alive... ALIVE!", 300, 300, 20, darkGray)

    EndDrawing()
}

CloseWindow()

The project structure #

Generally a Swift project is constituted like this:

Package.swift
Sources/
    ProjectName/
        code.swift

All code in Sources will be used by the Swift Package Manager to compile my project.
In my case I want to differentiate what comes from the Raylib C project and my own code. So, my Swift project ends up like this:

Package.swift
Sources/
    CRaylib/
        macOS/
            libraylib.a
        WASM/
            libraylib.a
        raylib.h
    MyGame/
        main.swift

Everything in Sources/CRaylib is related to raylib itself: header files, static libraries (based on platforms, here macOS and WASM), etc. And everything in Sources/MyGame is my code, that will use the raylib C code.

I actually prefer downloading and replacing directly the files in my project, instead of letting a script, the package manager, or even the end-user, download them automatically. This approach comes directly comes from my experience in game engine development: never trust that the library will be available online in one minute, and never trust that the next version will not end up breaking your project or your dependencies.
This is actually an “anti-web” way to see things, but it actually saved my (dev-)life more than one time.

The Package.swift file #

But how to build that project (let’s call it “MyGame”) now?

Let’s dig into the Package.swift file at the root of the project:

// swift-tools-version: 6.2
import PackageDescription

let package = Package(
    name: "MyGame",
    targets: [
        .target(
            name: "raylib",
            path: "Sources/CRaylib",
            publicHeadersPath: ".",
            linkerSettings: [
                // macOS
                .unsafeFlags(["-L", "Sources/CRaylib/macOS"], .when(platforms: [.macOS])),
                .linkedFramework("OpenGL", .when(platforms: [.macOS])),
                .linkedFramework("Cocoa", .when(platforms: [.macOS])),
                .linkedFramework("IOKit", .when(platforms: [.macOS])),
                .linkedFramework("CoreVideo", .when(platforms: [.macOS])),

                // WASM only
                .unsafeFlags(["-L", "Sources/CRaylib/WASM"], .when(platforms: [.wasi])),
            ]
        ),
        .executableTarget(
            name: "MyGame",
            dependencies: ["raylib"]
        ),
    ]
)

The interesting part of this demonstration is in how I defined the targets. This target is actually a Clang target, which specifies how the target is named, where is the source code, the header, and which libraries the linker needs to interact with for the linking step.

In this case, I have a target named raylib with the source code in a relative path (Sources/CRaylib) and different libraries depending on the OS (macOS or WASM).
Very easy!

Let’s run it #

If I try to run my project, I have an issue:

> swift run
warning: 'craylib': ignoring declared target(s) 'craylib, MyGame' in the system package
warning: 'craylib': system packages are deprecated; use system library targets instead
error: no executable product available

Hum, what is going wrong here?

Swift natively has no idea what a header (or .h) file is. As in, you cannot write import raylib.h in a Swift file directly.

To solve this, Apple built the Clang Importer into the Swift compiler. When the Swift compiler compiles Swift code, Swift silently boots up Clang, that parses the C headers, translates them into a format Swift can understand, organizes code into modules, and hands them back to Swift through.

However I actually had to help the compiler making the bridge between this Clang module and Swift, using a module.modulemap file in my CRaylib project:

module CRaylib [system] {
    header "raylib.h"
    link "raylib"
    export *
}

Here, the module.modulemap can be explained like that:

module CRaylib [system]: “Create a brand new Swift module named CRaylib and treat it as a system library…”,
header "raylib.h": “Here is the exact file you need to parse to find the C functions and structs…”
link "raylib": “Whenever a Swift file imports this module, automatically tell the linker to look for a compiled library named libraylib.a…”
export *: “Take every single C function you find and make it publicly available to my Swift project”

Our final project structure is like this:

Package.swift
Sources/
    CRaylib/
        macOS/
            libraylib.a
        WASM/
            libraylib.a
        raylib.h
        module.modulemap
    MyGame/
        main.swift

Now, if I try to run it… I have a window! Yeah!

Ok, let’s summarize what I did previously:

Downloading and copy-pasting raylib header and static libraries to my project: EASY,
Write a Package.swift file in order to declare my project and its dependencies: EASY,
Write a module.modulemap file to make the transition between raylib C files and my Swift project: EASY.

EASY + EASY + EASY = EASY.

Swift <3 WASM #

Ok, now that I have a native build… why not building it for WASM?

The Swift community made a ton of improvements the last years to build WASM applications using Swift.
If you are interested with it I would advise you to take a look at the official documentation.

Building the project for WASM was a bit more complicated, maybe because I miss some documentation to build this kind of project using the WASM SDK for Swift.

As shown here I did link the WASM project with the correct static library, in the correct path. And I do not have any modification to make in the module.modulemap file for raylib WASM. Nice.

All the following is just how to build the final WASM project:

> swift build --swift-sdk swift-6.2.4-RELEASE_wasm # i am using Swift 6.2.4 and Swift SDK for WASM has been installed

As I build for browser I have a linking error, but my object file has been built using Swift WASM compiler.

Because Swift’s stdlib was built for a headless server (WASI), it expects a terminal.
I needed to write a tiny C stub to intercept those terminal requests (errno, __wasi_args_sizes_get and __wasi_args_get) so the browser’s WebGL environment (Emscripten) doesn’t panic:

// wasi_stubs.c
#include <stdint.h>

int errno = 0;

int32_t __wasi_args_sizes_get(int32_t *argc, int32_t *argv_buf_size) {
  *argc = 0;
  *argv_buf_size = 0;
  return 0;
}

int32_t __wasi_args_get(int32_t *argv, int32_t *argv_buf) { return 0; }

and finally to compile the project using emcc:

emcc .build/wasm32-unknown-wasip1/debug/MyGame.build/main.swift.o ./wasi_stubs.o \ 
    Sources/CRaylib/WASM/libraylib.a \
    -L</PATH/TO/YOUR/SWIFT_SDK>/usr/lib/swift_static/wasi \
    -lswiftCore \
    -s USE_GLFW=3 \
    -s ASYNCIFY \
    -o index.html

Important note
Browsers cannot handle infinite while loops without freezing.
In order to avoid rewriting my infinite loop function in main.swift I used the magic Emscripten flag ASYNCIFY to pause the Swift code and let the browser actually draw the frame.

Once I have my web files generated (index.html, index.js and index.wasm) I can spawn a tiny web server, and go to http://localhost:8080 to see…

The hardest thing was using emcc to build our final WASM binary. I did not even need to modify our source code or our project!

Mission completed!

Conclusion #

Wrapping C for Swift was pretty straightforward, and I successfully spawned a window and draw some text using raylib. The usage of the Swift Package Manager is useful, and I did not need to dig so much into compiler issues, or build wrappers by hand, to actually interact with the C code of raylib.

So, if you want to build games using raylib, why not learn learning or use Swift for that?

The Influentists

Tue, 06 Jan 2026 16:00:00 +0100

Last week, the developer community was busy discussing about a single tweet:

I'm not joking and this isn't funny. We have been trying to build distributed agent orchestrators at Google since last year. There are various options, not everyone is aligned... I gave Claude Code a description of the problem, it generated what we built last year in an hour.
— Jaana Dogan ヤナドガン (@rakyll) January 2, 2026

The author is Jaana Dogan (known as Rakyll), a highly respected figure in the Google ecosystem, in the open-source world, and in my heart (thank you Rakyll for your great Go blog posts).

At first glance, the tweet suggests an enormous shift in the software industry: the ability to build in just one hour what previously required weeks or months for a team of sofware engineers, using just the description of the problem. The tweet was too-much dramatic in my own opinion, but actually impressive!

The post triggered an immediate wave of “doom-posting,” with many fearing for the future of software engineering (as each week since a year now). However, as the conversation reached a high number of replies and citations on social networks, Rakyll released a follow-up thread to provide context:

To cut through the noise on this topic, it’s helpful to provide more more context:

- We have built several versions of this system last year. - There are tradeoffs and there hasn't been a clear winner.
- When prompted with the best ideas that survived, coding agents are able to… https://t.co/k5FvAah7yc
— Jaana Dogan ヤナドガン (@rakyll) January 4, 2026

This response thread revealed a story far less miraculous than the original tweet suggested. Let’s analyze it.

Crucially, the foundational “thinking” had already been performed by Rakyll herself, who guided the AI using architectural concepts (honed over several weeks or months of prior effort) rather than the AI thinking and inventing the “product” from scratch.
Furthermore, the resulting project was strictly a proof-of-concept that falls far short of a production-ready system capable of managing real-world complexity.
And finally, this success hinged on the Rakyll’s implicit domain knowledge and deep expertise. The last point is often (strategically?) omitted from these “magic” viral demonstrations in order to make the tool appear way more autonomous than it truly is.

Hmm. Now, this is far less exciting…

Under influence #

This pattern of “hype first and context later” is actually part of a growing trend.

I call the individuals participating to that trend “The Influentists”. Those people are members of a scientific or technical community, and leverage their large audiences to propagate claims that are, at best, unproven and, at worst, intentionally misleading.

But how can we spot them?

I personally identify these “Influentists” by four personality traits that characterize their public discourse.
The first is a reliance on "trust-me-bro" culture, where anecdotal experiences are framed as universal, objective truths to generate hype. This is a sentiment perfectly captured by the “I’m not joking and this isn’t funny” tone of Rakyll’s original tweet, but also the dramatic “I’ve never felt that much behind as a programmer” from Andrej Karpathy’s tweet. This is supported by an absence of reproducible proof, as these individuals rarely share the code, data, or methodology behind their viral “wins”, an omission made easier than ever in the current LLM era. And finally, they utilize strategic ambiguity, carefully wording their claims with enough vagueness to pivot toward a “clarification” if the technical community challenges their accuracy.

I've never felt this much behind as a programmer. The profession is being dramatically refactored as the bits contributed by the programmer are increasingly sparse and between. I have a sense that I could be 10X more powerful if I just properly string together what has become…
— Andrej Karpathy (@karpathy) December 26, 2025

A growing pattern #

Rakyll is far from alone. We see this “hype-first” approach across major AI firms like Anthropic, OpenAI, or Microsoft.

Consider Galen Hunt, a Distinguished Engineer at Microsoft. He recently made waves by claiming a goal to rewrite Microsoft’s massive C/C++ codebases into Rust by 2030 using AI.

When the industry pointed out the near-impossible complexity of this task, but also asking clarity for popular and critical products like Microsoft Windows, he was forced to clarify that it was only a “research project”.

Similarly, engineers from Anthropic and OpenAI oftenly post teasers about “AGI being achieved internally” to release months later models that disappoint the crowd.

Wait, can we consider seriously the hypothesis that 1) the recent hyped tweets from OA's staff
2) "AGI has been achieved internally"
3) sama's comments on the qualification of slow or fast takeoff hinging on the date you count from
4) sama's comments on 10000x researchers
are… https://t.co/f57g7dXMhM pic.twitter.com/Gap3V7VqkK
— Siméon (@Simeon_Cps) September 24, 2023

Liam, I have been a professional programmer for 36 years. I spent 11 years at Google, where I ended up as a Staff Software Engineer, and now work at Anthropic. I've worked with some incredible people - you might have heard of Jaegeuk Kim or Ted Ts'o - and some ridiculously… https://t.co/Ku8agTrps3
— Paul Crowley (@ciphergoth) December 31, 2025

Similarly, many other companies lie over what they are solving or willing to solve:

The cost of unchecked influence #

When leaders at major labs propagate these hyped-based results, it can create a “technical debt of expectations” for the rest of us. Junior developers see these viral threads and feel they are failing because they can’t reproduce a year of work in an hour, not realizing the “magic” was actually a highly-curated prototype guided by a decade of hidden expertise.

We must stop granting automatic authority to those who rely on hype, or vibes, rather than evidence.
If a tool or methodology were truly as revolutionary as claimed, then it wouldn’t need a viral thread to prove its worth because the results would speak for themselves.

The tech community must shift its admiration back toward reproducible results and away from this “trust-me-bro” culture.

The CEO cost function

Fri, 02 Jan 2026 13:30:00 +0200

We are living through a strange era in tech.

Every month, a new headline appears. Another CEO announces a massive round of layoffs of managers, developers, and engineers.
They talk about “efficiency” and “streamlining”, which should maintain the same quality while spending less on staff. However the engineers, and the users, on the ground see something else: a decrease in software quality, a loss of institutional knowledge, and a product that starts to feel like it’s held together by duct tape.

Meanwhile, these same CEOs see their incomes rise.

It makes me wonder. If a CEO’s job is essentially a series of inputs (decisions) and outputs (stock price and revenues), can we finally treat that role as a cost function?
If we can model a complex distributed system, why can’t we model the person at the top?

The formula of a leader #

History is surprisingly clear on this. We have decades of data on stock movements, economic strategies, and the specific decisions that led to them. We have thousands of articles explaining exactly why a pivot worked or why a merger failed.

When you strip away the charisma and the expensive suits, a CEO is just an optimization problem over an original idea.
They are trying to maximize a reward function ($J$), which can be simplified as:

$$J = \sum_{t=0}^{T} \gamma^t (w_1 \cdot R_t + w_2 \cdot S_t + w_3 \cdot U_t - w_4 \cdot Q_t)$$

$R_t$: quarterly revenue,
$S_t$: stock price / market cap,
$Q_t$: system quality (technical debt, employee retention, bug count, …),
$U_t$: user satisfaction (measured via churn rate, NPS, sentiment analysis, …),
$w_n$: weights assigned by the board of directors (likely for priorities).

The problem with human CEOs is that they often set $w_3$ (user satisfaction) or $w_4$ (system quality) to zero if the sum of $w_1$ and $w_2$ (revenues and stocks) are higher. Their incentives (mostly vesting schedules and annual bonuses) encourage them to maximize $R_t$ and $S_t$ at all costs.
A good AI, however, could be hard-coded with a high $w_3$ value.
Then, it would be mathematically incapable of “winning” if software quality drops below a certain threshold.

Human CEOs are expensive, they are prone to ego-driven mistakes, and they often “bullshit” to cover their tracks. An AI wouldn’t buy a social media platform on a whim just to prove a point. It would be transparent. It would explain exactly why it chose to cut a budget or invest in a new feature.

Most importantly, an AI would cost a fraction of the 1,200% increase in CEO pay we’ve seen since 1978.

Surgical cut #

In the current corporate playbook, layoffs are a blunt instrument. When a CEO needs to save money, they often fire the most expensive people: the Senior Engineers. This has been explained, once again, by AWS CEO a few months ago:

“Number two, they [the junior developers] are usually the least expensive because they’re right out of college, and they generally make less. So if you’re thinking about cost optimization, they’re not the only people you would want to optimize around.” AWS CEO Matt Garman

But the senior people are the same people who know where the “bodies are buried” in the codebase. Removing them to save the budget is like a pilot throwing the engines overboard to make the plane lighter.

An AI CEO would see the company not as a list of salaries, but as a dependency graph.

If the platform’s stability is failing, the data is usually screaming the reason why. It might show that the “code-to-bug” ratio is spiking in a specific department, or that “time-to-resolve” is dragging because of a bottleneck in management.

In this scenario, the AI wouldn’t fire the engineers. It would look at the data and realize that the engineers are actually performing well, but are being slowed down by three layers of middle management that produce nothing but meetings. The AI would perform a surgical cut: it would remove the bureaucracy to save the builders.

Objectivity and Truth #

By using an AI to manage the “human resources” of a company, we remove the politics of survival. In a human-led company, the person who survives a layoff is often the one who is best at “managing up” - the one the CEO likes personally.

An AI doesn’t have “favorites”. It only has metrics.

This brings us to a new kind of corporate transparency. If you are fired by an AI, you get a receipt. You see the data. You see the logic. If your contribution to the system’s health is high, the math protects you. If your role is purely administrative and the data shows you are a net-negative on velocity, the math removes you. It’s cold, yes, but it’s honest.

The alignment problem #

There is a danger here, of course. If we train an AI on historical data, it might learn the wrong lessons.

As an example, if the history shows that every time a company fires 10% of its staff stock price jumps for two months, then the AI will keep firing everyone until there is no company left. This is totally normal for the AI because it tries to maximize the reward at the expense of survival.

This is the classic “alignment problem”.

There is also the risk of “corporate monoculture”.
If every company uses the same CEO model trained on the same data, every company will act exactly the same. They will all chase the same trends and be exploited by anyone who figures out the algorithm.

And then there is the morality. An algorithm doesn’t care about the families affected by a decision. It only cares about the math.

Self-correctness #

The solution of alignment problem and corporate monoculture isn’t just a better model, but better engineering. We need exploration, not just exploitation of past data.

We can imagine a system where the AI is not just a decision-maker, but also its own judge. As an example, we could have a “self-introspection layer”, a secondary model that audits the decisions made in the previous quarter and refines the decisions for the next round.

If the “CEO Model” predicted that firing the entire QA team would save $22M without affecting quality, but the “auditor model” sees that bug reports increased by 40% and user retention dropped, the system corrects itself. It adjusts its own “cost function”. It learns that short-term savings are actually long-term liabilities, for the company it tries to manage.

This is something human CEOs rarely do as admitting a mistake is politically expensive for a human CEO. However, for an AI it is just a weight adjustment of its function.

“Augmented CEO” #

We aren’t ready to hand the keys of the boardroom to a server rack just yet. However the “augmented CEO” is already becoming a necessity.

Imagine a board meeting where every proposal is stress-tested against 10,000 simulations. The CEO says, “We need to layoff 500 engineers to hit our quarterly targets”. The AI responds, “That decision has an 85% probability of causing a system-wide outage within 12 months due to lost expertise”.

In this world, decisions become data-driven instead of gut-driven. It forces a level of honesty that the current corporate structure lacks, or do not want to listen on purpose.

Also, to have a companion for that would reduce the bonus and salary as the CEO is not anymore the executive, but just an “interface” between the AI and the board of directors.

The conclusion is simple, even if it’s uncomfortable for those at the top. The idea that certain roles are “too human” or “too complex” to be automated is a myth.
History shows that no one is truly irreplaceable. Once the cost function is solved, not even the CEO is safe.

Going immutable on macOS

Wed, 31 Dec 2025 14:30:00 +0200

With no surprise the end of one year marks the start of the next.
And the beginning of a year is always synonymous with… a fresh macOS system!

But managing a good working environment on macOS has long been a game of “hope for the best.” We’ve all been there: a curl | sh here, a manual brew install there, and six months later, you’re staring at a broken PATH and a Python environment that seems to have developed its own consciousness.

I’ve spent a lot of time recently moving my entire workflow into a declarative system using nix. From my zsh setup to my odin toolchain, here is why the transition from the imperative world of Homebrew to the immutable world of nix-darwin has been both a revelation and a fight.

The problem to solve: imperative rot #

Homebrew is great.
From the Linux world, it was the perfect missing package manager for macOS at first, promoted by a lot of developers, and it (mostly) works. But Homebrew has a problem: it is imperative.

When you run brew install you are changing the state of your machine in a way that is difficult to reverse or replicate exactly.
As an example, if I set up a new Mac today, brew install neovim might give me version 0.10. However, if I do it six months from now, the version might changed and I had to reconfigure some components because of that change. The consequence is me, spending a few hours debugging my environment instead of writing code.

A solution to that is postfix every brew package by its version, but this is not possible for every package.

Another solution is system immutability and the Nix store.

System immutablility, and the Nix store #

Nix approaches the problem from a functional programming perspective.
Your system is not a collection of side effects, but a pure function of your configuration.

This allows different strong points like:

reproducibility: Every package lives in /nix/store with a unique hash. This means I can have three different versions of the Odin compiler side-by-side, and they will never see each other, or even mess up with the different versions.
rollbacks: If a system update breaks my shell, I don’t panic. I just boot into a previous generation. The previous state of my system is still sitting in the store, untouched.
flakes: Using flake.lock, I pin my setup to specific git commits. If it works on my laptop then it will work on yours. Period.

Rollbacks on macOS exist, and are great to go back to a previous version “that works”.
As an example, to list all my previous generations, I can do:

> sudo nix-env --list-generations -p /nix/var/nix/profiles/system
   1   2025-12-28 01:21:38
   2   2025-12-28 01:33:47
   3   2025-12-28 09:34:27
   4   2025-12-28 09:43:15
   5   2025-12-28 11:00:49
   6   2025-12-28 11:10:12
   7   2025-12-28 11:19:03
   ...

Each generation is also stored in a read-only specific volume on your system, which prevents accidental mutability of your packages.

On macOS nix-darwin allows me to modify everything, from Finder settings to the Dock, or the Trackpad.

As an example, this is a part of my setup:

...
configuration = { pkgs, ... }: {
    # Firewall settings
    networking.applicationFirewall = {
        enable = true;
        enableStealthMode = true;
        allowSigned = true;
        allowSignedApp = true;
    };

    system.defaults = {
        CustomUserPreferences = {
          # Disable siri
          "com.apple.Siri" = {
            "UAProfileCheckingStatus" = 0;
            "siriEnabled" = 0;
          };
          # Disable personalized ads 
          "com.apple.AdLib" = {
            allowApplePersonalizedAdvertising = false;
          };
        };

        # Show battery percentage in the menu bar
        controlcenter.BatteryShowPercentage = true;

        # Allow touch to click
        trackpad.Clicking = true;

        # Hide the dock after a small delay of inactivity
        dock.autohide = true;
        dock.autohide-delay = 0.25;

        ...
    };
}

And all those settings are documented in the official nix-darwin manual here.

The Nix flake #

Before diving into the pros and cons of Nix, we need to address the engine under the hood: The Nix Flake.

In the traditional Nix world, things were a bit loose.
You had “channels”, but “channels” that could change behind your back… and we don’t want to get back to mutable systems.
Nix flakes fixed this by introducing a strictly defined structure.

Every Flake has a flake.nix (the blueprint) and a flake.lock (the time capsule).

The lockfile is actually the secret sauce.
It records the exact git commit of every dependency. When I build my system, I’m not just asking for “the latest version of the Odin programming language”, but for the exact version of Odin that existed at a specific moment in history.

So, when you run darwin-rebuild switch --flake . to update your system (depending on configuration changes), Nix will look first at the lockfile. If the lockfile says you are using nixpkgs from October 12th at 10:45 PM, that is exactly what it fetches. Nix doesn’t matter if you are on a new MacBook or an old iMac. If the lockfile is the same, then the resulting environment will be identical to your previous setup.

This turns system administration into a pure function: the same inputs always produce the same result.

The “get and forget” workflow #

One of the most liberating features is the “ephemeral shell” provided by Nix.
Imagine you need to test a script against Python 3.15, but you don’t want to install a pre-release version globally and risk breaking your system tools…

With Nix, you run:

nix shell nixpkgs#python314

Suddenly, python --version returns 3.14. You run your tests, you exit the shell, and it’s gone.

No leftovers, no site-packages conflicts, no trace. It is the ultimate “get and forget” utility, without messing up your system.

However be careful as “ephemeral” does not mean “sandboxed” or “isolated” in this context! A common misconception is that nix shell is like a Docker container or a VM, but it is not as nix shell only isolated the environment variables, and is still running directly on the darwin kernel.

The learning curve cliff #

Is this configuration exempt from defaults? Absolutely not.
In fact, its biggest “default” is one of the most significant pain points in modern software: it arrives wrapped in complicated concepts and dense foundations.

The learning curve for Nix is actually not a curve, but a vertical cliff face.

Unlike Homebrew, where you just type a command and forget it, Nix requires you to learn a domain-specific language called… Nix (I know, it is confusing). You have to understand how symbolic links work on macOS, how the Nix daemon interacts with Apple’s read-only system volume, and why your applications don’t magically appear in Spotlight.

For instance, getting GUI apps to show up in the Applications folder requires “trampoline” binaries or custom activation scripts using mkalias.
After a few minutes debugging and scrolling forums it works great, but many users will simply stop there and walking away with the mistaken impression that nix-darwin is an immature project, rather than a deeply powerful one.

The documentation is great, but maybe not well arranged.
As an example, this is the manual to write your own flake.nix: https://nix-darwin.github.io/nix-darwin/manual/. You can be lost very easily in the manual if you do not know what you are looking for…

The hybrid reality #

Despite my love for Nix, it isn’t perfect for everything. macOS GUI applications like Thunderbird, Firefox, or CrossOver, often fight against the read-only nature of the Nix store.
Those software expect to self-update and live in /Applications on your system.

I found the sane path to be an hybrid approach: I use nix-darwin to manage my critical state (compilers, LSPs, shell aliases), and use the homebrew module inside my Nix config to handle the big GUI pieces. It looks like this:

// file: brew.nix
homebrew = {
  enable = true;
  casks = [ 
    "firefox" 
    "thunderbird" 
    "crossover" 
  ];
};

That’s it! And using this, I am sure Nix will use brew to install those software on my system, as I did manually with my brew install scripts.

This gives me the best of both worlds: Homebrew handles the macOS-specific integration, but Nix still “records” that they should exist in my declarative blueprint.

How to start #

If you want to move away from “hope-based” configuration:

install the Determinate Nix Installer: it handles the messy macOS multi-user setup for you.
initialize a Flake and home-manager: Create a flake.nix and a home.nix for your home-manager instance.
think “modularity”, like keeping your system settings in system.nix, your dev tools in dev.nix, and your GUI apps in brew.nix.
version everything and commit your flake.lock! It is the source of truth for your system.

If you are curious I’ve documented my current setup, including my security hardening (firewall, stealth mode, etc.) here: k0pernicus/dotfiles/nix-darwin-config.

Keep in mind this configuration is personal, and might not be interesting (and certainly not useful) for everyone.

A few links that helped me to make a first setup version for my mac:

It’s more work upfront, certainly. But there is a profound peace of mind in knowing that your system is defined by code, not by a history of forgotten terminal commands.

Deep dive into crossover

Sat, 20 Dec 2025 15:00:00 +0200

If you read my previous post about gaming on mac, you know I have a soft spot for running Windows games on Apple Silicon.

Early this year I upgraded from a M1 MacBook Air to an M3 Max MacBook Pro. Naturally, I had to test three completely different generations of games at it: ARC Raiders (2025), Routine (2025), Watch Dogs 2 (2016) and Tron 2.0 (2003).

I expected the modern game to struggle and the old game to fly. The reality was exactly the opposite, and it forced me to dig deep into how CrossOver handles translation layers under the hood.

This article summarizes my investigations and challenges to play DirectX 12, Direct 11, and DirectX 9 games, using Crossover.

The modern stack: D3DMetal and MSync #

There is no place for anti-cheats #

Let’s start with the bad news: no, you still can’t play everything. Despite the M3 Max being a hardware beast, there is a hard software wall called Kernel-level Anti-Cheat.
I am not going to get into the debate of if it is useful or not, but if you are interested in that debate you can feed this Steam forum discussion.
Games like ARC Raiders are strictly unplayable because Wine cannot emulate the deep Windows kernel access that Easy Anti-Cheat (EAC) or BattlEye require. If your target game relies on invasive anti-cheat then the Crossover solution is not the good one, as there is no “userspace bridge” built by Apple and / or Crossover to support those software.
For that kind of games you might be interested in installing a Windows VM and then install Steam and your game(s) on that system, but this is not the purpose of this blog post.

However, for the vast majority of single-player titles that don’t treat the OS like a crime scene, the landscape has changed dramatically.

ARC Raiders : Fail.

The routine #

First, I tried the most recent game, Routine. Routine is made using Unreal Engine and uses the DirectX 12 graphics API under the hood.
I tried this game on a default “Steam” bottle on Crossover, with “Auto” settings, and… it launched successfully! No graphics or performance issue, no issue recovering my saves through Steam cloud, and I successfully continued the game I began on my other machine.

Great!

Routine : Great success.

The hackerspace #

Next, I tried Watch Dogs 2. This game is almost 10 years old, and runs on DirectX 11.
As Routine I tried with the auto settings, but the game did run poorly, and glitchees appeared too regularly.
It was time to tweak the machine!

On modern versions of CrossOver (23+), we have a new toy: D3DMetal. This is essentially Apple’s Game Porting Toolkit (GPTK) integrated directly into CrossOver.
Using GPTK, instead of the traditional translation path: DirectX -> Vulkan (via DXVK) -> Metal (via MoltenVK), D3DMetal translates DirectX headers directly to Metal.
GPTK is a great tech, and enable some modern games to run on macOS. If you want to know more for a list of compatible games I invite you to look for this website.

Going back to Crossover, I enabled the D3DMetal flag it in the bottle settings, along with MSync and the performances were much better, despite regular stutters I investigated and actually solved (more in the next section).

Note:
For those who missed the memo, MSync replaces the old ESync/FSync methods. Instead of using eventfd (which is a Linux kernel feature that macOS lacks and must emulate), MSync maps Wine synchronization primitives directly to macOS native kqueue or Mach semaphores. The result is a much lower CPU overhead.

The retina problem #

However, performance was initially terrible. Why? Because macOS tells the game: “Hey, I have a 3024x1964 screen!” and the game engine says “OK!” and tries to render a poorly optimized open-world at 4K.

The fix was simple:

turn OFF “High Resolution Mode” in the bottle settings.
force the game to 1920x1080.
enable Temporal Filtering in the game engine (which essentially renders at lower res and upscales).

Suddenly, the M3 Max was pushing stable frames. Unfortunately this “modern” approach completely breaks when you look backward.

Watch Dogs 2 : Success.

The legacy stack: when D3DMetal fails #

I then tried to run Tron 2.0, a monolith classic from 2003 running on the LithTech engine (DirectX 9).

I naively kept D3DMetal on. The result? An instant crash.

Here is the technical reason: D3DMetal does not support DirectX 9. It currently only handles DX11 and DX12 instructions. For older games, you must fallback to the translation chain: DirectX 9 -> DXVK -> MoltenVK -> Metal.

So, I created a separate bottle (and this is crucial: never mix eras).
I set this bottle to Windows XP mode to avoid modern OS overhead, and enabled DXVK.

The case of the missing DLL #

Even with the correct graphics layer, the game wouldn’t start. This is where it gets interesting for C++ developers.

The crash wasn’t graphical. It was a missing dependency: msvcirt.dll.

This library is the old C++ runtime (MSVC 6.0 era). Modern Windows (and by extension, modern Wine bottles) have largely deprecated or removed it. The game was calling functions in a dynamic library that simply didn’t exist in the virtual system32 folder.

To fix this, I had to:

manually create a Windows XP bottle (which is more likely to handle legacy calls).
use the “Install Software” tool to inject DirectX for Modern Games (which oddly enough, contains legacy DX9 redistributables).
manually patch the executable with the community-made “Killer App Mod” to strip the DRM that Wine couldn’t parse.

Tron 2.0 : Partial success.

The proton reality check #

On the four games I wanted to test only one launched with great perfor,ances “out of the box“. Two have been tweaked to run great, and only one did not run at all (due to anti-cheats software compatibility).

We often think of “emulation” (or translation, in Wine’s case) as a linear performance cost. But on Apple Silicon, it’s really about choosing the right translation path:

“retro” Games (<= 2012): use DXVK as it handles the fixed-function pipeline of older DirectX versions way better than Apple’s toolkit does,
“modern” Games (> 2012): use D3DMetal and MSync provides the best combo here as it skips the Vulkan translation overhead.

However, we have to address the elephant in the room: Proton on Linux.

If you own a Steam Deck or run Linux on your desktop, you know that the experience is lightyears ahead of what we have on macOS. Why? Because Proton (Valve’s fork of Wine) is solving a much simpler equation.

On Linux (x86_64), the CPU instructions are native. Proton only needs to translate Windows API calls to Linux Kernel calls, and DirectX to Vulkan. It’s a 1:1 translation.

On macOS (Apple Silicon), the translations are more expensive:

Rosetta 2 translates x86_64 instructions to ARM64 (CPU overhead),
CrossOver translates Windows API to macOS API (OS overhead),
D3DMetal translates DirectX to Metal (GPU overhead).

This triple-layer cake is technical wizardry, but it explains why my $400 Steam Deck can sometimes launch a game with fewer glitches (and slightly better performance) than an Apple Silicon MacBook Pro. Proton simply has less distance to cover, and Vulkan is a first-class citizen on Linux.

I actually tried to run the same four games on another machine using CachyOS with Proton and… all four games launched without any tweak. That is a major success for the Linux community.

Maybe MacBooks will come to launch and run natively Windows games (if Apple wants to).

Chaos or comfort: a reflection on the engineer's quest

Mon, 25 Aug 2025 16:00:00 +0200

Disclaimer
Article fully writtened by the author, but grammar correction by Gemini.
Images generated using Gemini.

Every software engineer I know is searching for it.
Me included.
They don’t always call it the same thing, but the desire is universal.

I call it the “holy grail”. That one project, that perfect role, where we get to solve problems that matter. The kind of deep, complex, elegant challenges in architecture, scaling, or algorithmic design that can justify long hours of coding and debugging. It’s the work that finally makes us feel like true engineers: the builders and architects of what could like the future.

We often associate this grail with a specific company or a famous team. But this search is a mirage. The grail isn’t waiting for you in a specific building or behind a particular logo. It’s a phantom we chase, and the landscape of our industry has cleaved the path to it in two.

The forge of Chaos #

On one side, you have the startup. This is the path of trial by fire.
The prevailing wisdom here is that to build something new, or innovative, you must move at a speed that is fundamentally at odds with stability.

The main goal of a startup is not to be right, but to be first.

In this world, and based on my experience on several startups before, an engineer is rarely just an engineer. A Software engineer can also be an architect, part of the DevOps team, a database administrator, and, if you are not lucky, part of the on-call support. And all of this can happen in the same afternoon.

You are handed a blank canvas and told to build a cathedral by next Tuesday. The result is an environment of incredible learning velocity. You’re forced to understand the entire stack because you are the entire stack. You learn about resilience because you are the one who has to fix the server when it inevitably crashes at 3 AM. And, most importantly, you don’t have time to spend on endless meetings or delivering documentation that nobody will ever read.

You do not have time to get border and the skills you gain are real, forged in the heat of necessity.
But the engineering can be illusion. You aren’t solving complex problems of scale; you are solving the immediate problem of survival. The solutions are often messy, and riddled with technical debt as you care mostly about fast deliveries. It’s less about elegant architecture and more about patching the hull of a sinking ship fast enough to reach the next shore. You learn a great deal and at fast-paced, but you risk becoming a master of the temporary fix.

Autonomy is essential here. You have a freedom you won’t find on the other path. Feedback is instant. Your ideas are heard, and if they create a positive impact, then they become the product. About failure, a bad decision can kill the company, but and the feedback is instant as well. The lesson is learned by all, some products could be shutdowned almost instantaneously, but more importantly the startup itself will grow up by its mistakes.

The gilded cage #

On the other side stands the big company, the tech empire. Here, the problems of survival were solved years or decades ago. The machine is already built, maybe not much innovative, and its engine is running at a good speed. The goal here is to keep the engine running at the same speed and, if possible, make it 0.05% more efficient (mostly in terms of costs) this quarter.

The scale is immense, almost abstract. A single change can impact a billion users, so it is treated with the gravity of a moon launch (mostly by people who have great responsabilities in the company but not interested to understand how the engine is actually working).
This creates its own kind of complexity.
The engineering challenge is not anymore “Can we build it?” but “Can we deploy it without breaking anything for anyone?”
We can clearly assume that big companies rest on one’s laurels.

This can a comfortable place for an engineer who is not interested to solve new challenges.
The pay is good (most of the time way better than a startup), the process is mostly defined, and you can slowly draft your individual carrier.

But, in my own opinion, comfort is the enemy of skill.
My philosophy is that a senior engineer is an athlete of the mind. To stay competitive, you must train relentlessly, and practice on solving different problems. The gilded cage, however, often encourages the senior engineer to become a coach who directs from the sidelines, and without even participate to competitions before. The problem is, you can’t maintain your edge by telling others how to compete if you did not compete before and won medals.

As I said, an engineer’s mind, like a muscle, atrophies without resistance. In the gilded cage, you become a specialist in a microscopic part of a colossal machine. You might spend a several weeks optimizing a single API endpoint or shaving milliseconds off a recommendation algorithm, and several months to produce an accurate documentation for your managers who, actually, do not have the time to read this.

Autonomy is viewed differently here and, often, it isn’t valued. The feature you’re building was likely decided by someone else. Someone who understood its financial impact, but not the technical one. In big companies failure is slow, quiet, and political. A bad project is never killed, but can become a zombie, draining morale for years. In big companies failure is not a lesson for anyone (especially not for your manager), but more a big stain on your performance review.

The workplace that matters #

We are taught to see these two paths as a choice: the chaotic and skill-building startup, or the stable and specialized corporation.
We ask ourselves which one is better, which one will finally lead us to the grail.

But this is the wrong question.

The “holy grail” of engineering isn’t a job description. It is not found in the startup’s frantic sprint or the big company’s careful optimization. It is not a place you arrive at. It is not when your start the morning or when you leave the office.

It is actually the thing(s) you do, and the thing(s) that make you happy.

It is the act of consciously seeking out and imposing structure on chaos, of finding the frontier even within a gilded cage.

In a startup, it means resisting the urge for the quick fix and asking “How can we build this to last, even when we only have a week?”.
It means being the one who carves out time to pay down technical debt, who introduces a design pattern that will save everyone from themselves six months from now.

In a big company, it means fighting the gravitational pull of comfort and most of the time hierarchy.
It means actively seeking out the messy, undefined problems that exist between the well-oiled cogs of the machine. It means providing engineering value instead of boring documentation and meetings with people who do not even understand what you are speaking of.
It means becoming an archeologist of the company’s own complex systems, understanding not just your piece, but how it connects to the whole.

The mirage is the belief that someone will hand you the interesting problems.
The reality is that interesting problems are almost always the ones no one else wants to solve. They are messy, political, and poorly defined.

The grail is not found, it is made.
And it is made by engineers who decide to stop searching for the perfect problem and starts solving the imperfect one right in front of them.

The skill of the future is not 'AI', but 'Focus'

Tue, 11 Feb 2025 16:00:00 +0200

If you frequent Hacker News regurlarly, you have likely noticed the buzz around engineers using AI (specifically Large Language Models, or LLMs) to tackle Computer Science problems.

I want to be clear: I’m not against LLMs.
LLMs are incredibly powerful tools, and can be a huge boon to engineers. They can automate repetitive tasks, generate code snippets, help with brainstorming, assist in debugging, … and this can frees up engineers’ time and mental energy, which could be channeled into more complex, creative problem-solving.
But, like any tool, LLMs should be used wisely.
LLMs can hallucinate, exhibit inconsistencies (especially with self-reflection models), and harbor biases. These limitations mean that LLM outputs require careful review before they can be trusted.

A key concern with LLMs lies in their training data.
The data can be biased, contradictory sometimes, but those data contain solutions to known problems.
If an engineer wants to “reinvent the wheel,” an LLM might offer a solution (good or bad, depending on the prompt). But when faced with truly novel problems, LLMs often provide unreliable responses, placing the burden of error detection squarely on the engineer.

This reliance on readily available solutions, particularly for familiar problems, creates a real risk: engineers may inadvertently atrophy their own problem-solving skills, hindering their ability to tackle truly novel challenges.
The solution lies is balance, and a focus on the “why”, not just the “what”.
Engineers should strive to understand the reasoning behind LLM-generated solutions, not simply accept them blindly. Blind acceptance shifts the focus from solving problems to merely obtaining a solution. Crucially, solving complex problems often depends on mastering simpler and foundational skills, which the engineer might lose quickly.

This idea summarizes why I disagree with those who equate the LLM revolution to the rise of search engines, like Google in the 90s. Search enginers offer a good choice between Exploration (crawl through the list and pages of results) and Exploitation (click on the top result).
LLMs, however, do not give this choice, and tend to encourage immediate exploitation instead. Users may explore if the first solution does not work, but the first choice is always to exploit.
Exploitation and exploration are complementary. Remove the exploration and you will introduce more and more instability into the exploitation process.

Computer Science emerged because Humans needed tools to solve problems faster and wanted to focus on the real problems, not repetitive tasks. Humans built machines to accelerate problem-solving, but engineers remained the masters of the algorithms.
I fear we’re losing our grip on this mastery. Not because engineers are becoming less and less intelligent, but because the pressure to deliver solutions quickly is paramount.
In embracing these “fast-paced solutions”, we risk losing a fundamental skill: focus. Because focus, like any skill, requires practice.

This is a worrying trend. If engineers become less adept at solving complex problems, what does the future hold? Will our ability to tackle complex challenges rest solely on self-reflecting AIs, rather than human ingenuity?

The paradoxical disconnection of Silicon Valley

Sun, 02 Feb 2025 16:00:00 +0200

A few months ago, a video of a private tech conference leaked online. The speaker was Eric Schmidt, discussing tech entrepreneurship, his past experiences, and how to make money today.

The transcript of the video can be found here.

Frankly, the conference was painful to watch, not because of technical issues, but because of the terrible advice and ideas Schmidt shared. This isn’t the first time I’ve heard such pronouncements from (ex-)CEOs and managers, especially those from Silicon Valley. However, this time, I sensed something amiss, a disconnect from reality among those who manage significant companies and products.

This feeling has been amplified by the “war” between US and Chinese tech companies, particularly evident in the OpenAI vs. DeepSeek situation. This disconnect can be illustrated by five key quotes from Schmidt’s conference.

The TikTok case #

If TikTok is banned, here’s what I propose each and every one of you do.
Say to your LLM the following: ‘make me a copy of TikTok, steal all the users, steal all the music, put my preferences in it, produce this program in the next 30 seconds, release it and in one hour, if it’s not viral, do something different along the same lines.’
That’s the command.
Boom, boom, boom, boom.

This boils down to: “Rob fast, Sell faster, and Iterate quickly”.

We’ve heard this kind of rhetoric more frequently in recent years, especially from companies that profess to love open source, yet readily clone and rip off entire GPL or MIT projects without attribution, effectively taking credit for work they haven’t done. While this has always been a problem, there’s now an open embrace of leveraging open-source information and solutions for profit, especially as developers become less concerned about the licensing rights they grant.

This quote also exemplifies the “move fast and break things” mentality, which, in my view, has eroded trust in software. This approach suggests that software is no longer designed for long-term user benefit, but rather for short-term investor gains—a demonstration of what a company could do, until they inevitably break (or abandon) their latest “innovation.”

This quote encapsulates much of what’s wrong with the modern software industry over the past decade.

Steal, Stole, Stolen #

Schmidt’s next statement sent chills down my spine:

In the example that I gave of the TikTok competitor…
and, by the way, I was not arguing that you should illegally steal everybody’s music…
what you would do if you’re a Silicon Valley entrepreneur […] is, if [your business] took off, then you’d hire a whole bunch of lawyers to go clean the mess up.
But, if nobody uses your product, then it doesn’t matter that you stole all the content.

To me, this translates to: hypocrisy and theft are core competencies for a Silicon Valley entrepreneur. The bolded phrases highlight this hypocrisy.

Further evidence of this hypocrisy can be seen in his comments about European regulation:

Europe is screwed up because of Brussels. It’s not a new fact.
I spent 10 years fighting them.
And I worked really hard to get them to fix the EU act and they still have all the restrictions that make it very difficult to do our kind of research in Europe.

yet, later he states:

So in my career, I helped Microsoft get broken up and it wasn’t broken up.
And I fought for Google to not be broken up and it’s not been broken up.

Hypocrisy, indeed.

“Employaves” #

Google decided that work life balance and going home early and working from home was more important than winning. I was in Taiwan, different country, different culture. And they have a rule that the starting PhDs coming out of the good physicists work in the factory on the basement floor. Now, can you imagine getting American physicists to do that? The PhDs, highly unlikely.

It’s true that people generally prefer a life outside of work, a fact that seems to irritate many CEOs these days. This is ironic, considering the increasing number of CEOs demanding a full-time return to the office, even as they themselves work remotely…

I won’t belabor this point, but perhaps Schmidt has forgotten that Nvidia, with over 80% of its staff working remotely, continues to dominate the competition in AI and gaming chips.

It seems Silicon Valley is less concerned about employees and more interested in “employaves”—perhaps a fitting term for the current climate.

The hard truth about Silicon Valley #

Based on these quotes, the Silicon Valley entrepreneur emerges as a hypocrite, a liar, and a thief. Someone willing to climb over others to appear a giant.

The hard truth: these individuals are not giants, and never will be. They suffer from a false sense of self-importance, much like, perhaps, the US itself?
Let’s hear from Schmidt:

Countries with a lot of money and a lot of talent, strong educational systems, and a willingness to win.
The US is one of them, and China is another one.

It’s no secret that California, particularly Silicon Valley, is losing its grip on tech dominance. Silicon Valley’s golden age as an innovative hub for hackers is fading.

The US-China tech war, especially the OpenAI vs. DeepSeek debacle, is farcical. Humanity won’t achieve AGI without collaborative effort, particularly in scientific resources and energy consumption. Furthermore, I believe we deserve to see evidence of cutting-edge technologies through scientific papers, source code, and open weights, rather than having them locked behind a $200 paywall.

This secrecy reveals a key point: the US, and Silicon Valley in particular, fear losing their perceived top spot. Especially on the Tech field, and AI as the New Battleground.

We need more insightful discussions from individuals like Denis Assabis of DeepMind, where interviews resemble science courses rather than the kind of vapid advice I just witnessed.

CEO-Bots #

The drive for ‘winning’ at all costs, as exemplified by Schmidt’s remarks, naturally leads to a focus on maximizing efficiency and minimizing costs. In this context, the idea of a ‘CEO-bot’ becomes less far-fetched…

In ML terms, what could be the cost function of a good CEO-bot?

The cost function for a CEO might be simpler than that of an engineer: maximize profits, monitor engineering performance monthly and adjust accordingly, keep abreast of news and future trends.

It would be interesting to explore how an AI CEO would perform. Especially as it can fits the dreams of Silicon Valley investors and entrepreneurs: no exhuberant salaray, an intelligence that do not sleep or eat, that do not take the plane each time he needs to sign contracts or go to an expensive garden party…
Just imagine the significant savings that could be realized with just one salary.

And, the icing on the cake, no more personality cult and no more bullshit on over-the-top conferences!

Could be great.
Just saying! ;-)

The state of Vulkan apps in 2024

Tue, 28 May 2024 20:30:00 +0200

UPDATE 2TH OF JUNE 2024
Removed typos (thanks Geoffrey! :) )

As a game engine developer, I always ask myself the same question working on new features or bug fixes: “What are the targets of my game engine?”.
Excluding the consoles, this question mostly implies which operating system - or platform - is targeted: Windows, Linux (or GNU/Linux, but I will keep “Linux” for the rest of the article), or macOS.

Developing the same game on multiple platforms could increase the developer’s interest to use the same technology for the different platforms. This may reduce the development time and be more productive.

Targeting multiple platforms among Windows, Linux, or macOS, only two mainstream graphics APIs might be useful: OpenGL and Vulkan. I exclude WebGPU on purpose here as the API is not stable yet.
OpenGL and Vulkan have their specifications developed by the same company, Khronos. However Khronos declared in 2017 that OpenGL was no longer in active development, in favor of the Vulkan API, whose first stable version was released in 2015.

So, eight years after its introduction, what is the state of Vulkan today among graphics apps?
Is Vulkan finally a “DirectX 12 killer”, or is it (unfortunately) a splash in the water?

A retrospective #

Vulkan has a nice community-based list of released apps using its own API. The main issue of this list is it is non-exhaustive, as some Vulkan apps may not belong to this list if the game developer(s), or the community, did not suggested it.
I would like to thanks Khronos to publish this list and allow the community to contribute. This list made my research easier.
Also, I invite you to suggest any app that uses Vulkan but not listed!

Note: a Vulkan app is not necessarily a game, but any software that uses the Vulkan API in its backend (for example: geekbench).

201 Vulkan apps have been released since 2015 (202 listed apps, but one duplicate one called “Golf It”).

Using those data I will draw three different graphs, and three different conclusions:

the number of released Vulkan apps since 2015, year by year, compared to DirectX 12,
the number of released Vulkan apps per platform, and the number of platforms targeted,
and the number of released Vulkan apps per SDK version.

Released Vulkan apps per release date #

As we can see below, the number of apps using Vulkan is decreasing since 2019, from 35 released apps in 2022 to 9 released apps in 2023.

Based on the Wikipedia page “Game Engines that support Vulkan(API)” 11 game engines support Vulkan as a graphics API, most of them from very famous video game companies like id Software, Valve, and Epic Games.
In my knowledge only Id Tech 7 supports Vulkan rendering only for PCs.

As a comparison:

PCGamingWiki shows more than 1600 games released since 1997 using OpenGL, 16 in 2023 despite the fact that no new OpenGL version has been released since 2016, which is more than with Vulkan for the same year,
PCGamingWiki shows more than 430 games released on the latest version of DirectX (DirectX 12 and DirectX 12 Ultimate) since 2015, 88 in 2023.

So, twice more games have been released with DirectX 12 than Vulkan in total, despite the fact that DirectX 12 is exclusive to Windows.

As we can see here, the number of released Vulkan apps, compared to the number of released DirectX 12 apps, was really close until 2021. Once DirectX 12 Ultimate as been released in 2020 we can clearly see a winner with DirectX 12.
Multiple factors can be explained here: the introduction of the Xbox Series S|X in 2020 and the fact that DirectX 12 targets also Xbox One & Xbox Series consoles (Microsoft does not allow any graphics API other than DirectX 12 on Xbox Series, not even DirectX 11), the fact that most AA and AAA games are released after 3-4 years of development (and the introduction of DirectX 12 in new engines), or maybe the fact that DirectX 12 is good enough to target the platform with most users on it: Windows.

Released Vulkan apps per platform #

Based on the previous observation, we can ask ourselves whether the demand for cross-platform applications is high or negligeable, and what are the main platforms that Vulkan apps developers are targeting.

Windows and Linux are clear winners for Vulkan since 2015, with 41.7% of Vulkan apps for Windows, and 30.2% for Linux. The Android mobile platform is kind of a success compared to iOS, with 16.2% of Vulkan apps.
Unlike Sony and Microsoft consoles, the Nintendo Switch officialy accepts Vulkan as a graphics API for first and third-parties games.

To finish, the major Vulkan apps targets only one platform, which may be a big disappointment given Vulkan’s promise to be multi-platforms.

Released Vulkan apps per API version #

Now, let’s take a look at which API version developers are using: do they prefer the later APIs or do they stick with the first versions of Vulkan instead?

This graph is not easy to interpret as there is a large number of Vulkan apps that does not expose publicly their API version.
However, if we exclude the 36.8% of unknown versions, we can notice that developers did not move to a SDK version superior at 1.1 to release their Vulkan apps, which has been released in 2018.
Vulkan 1.2 has been introduced in January 2020, more than four years from now, approximately at the same time as DirectX 12 Ultimate.

The 2023 survey #

LunarG organizes a Vulkan survey for Vulkan developers, since a few years now. The survey is free, open for everyone, and LunarG published the 2024 results here.

Despite the fact that the survey has been largely shared to Vulkan developers (more than 13.000+ recipients of the LunarG Vulkan SDK mailing list, social networks, Vulkan Slack channel, etc.) only 275 developers answered the LunarG’s 2024 Vulkan survey. In comparison there were 288 respondents in 2022, and 364 in 2021.

As stated in the survey the main targets of the recipients are:

Windows (11, 10),
Linux,
Android.

This reflects our observation that the great majority of released apps is actually for Windows and / or Linux platforms only.

Vulkan apps developers do not seem to target macOS (yet?), and state that targeting Android can be an issue as the driver support is still “poor”.
However there seems to have more interest in supporting Vulkan on Android than iOS, despite the efforts of a dedicated Khronos team to port Vulkan on Apple platforms with MoltenVK.

To finish, developers show once again that the complexity of the Vulkan API is still a barrier to adoption, despite the fact that it is now 8 years old.
This statement can be a surprise as DirectX 12 is criticized too for its complexity compared to DirectX 11, but still gains traction from the Gaming industry compared to Vulkan.

The terrible situation of Windows (professional) laptops

Sun, 19 May 2024 17:25:00 +0200

Last Saturday, after logging on ~~Twitter~~ X, I came across two tweets from two great programmers I follow.

*** Deeply Negative Tweet Alert!!!!!! ***

My ASUS Rog Strix G16 super hyper gaming laptop has lasted approximately 1 year before destroying itself.

For about a month it has been in a mode where it's impossible to sleep it (and there is no Hibernate option in Windows any more,…
— Jonathan Blow (@Jonathan_Blow) May 18, 2024

I bought a Macbook a third of the price of my expensive Windows 11 Dell, and everything feels smoother and nicer (aside from the fact I'm not really used to the OS, and learning vscode is going to be a thing).
— Omar 🍋 (@ocornut) May 17, 2024

Context: Jonathan Blow and Omar Cornut are two programmers focusing on games and game engines development.

Note: I will use the word “professional” for laptops with high-end specs and components like CPUs, GPUs (which includes “Gaming” laptops), and RAM, and big battery capacity.

In the first tweet, Jonathan Blow exposes its troubles on its latest professional laptop:

the laptop lasts around one year before dying ✝,
the laptop suddenly starts from itself in his laptop, got hot, and runs into battery life issue(s),
the audio does not work well, with terrible lagging and audio skipping,
CPU / GPU performances become weak at very random times,
and the SSD is “excruciatingly slow” when the laptop is unplugged.

In the second tweet, Omar Cornut exposes also the fact that its latest Windows laptop does not follow the same rate of performance / price compared to an half-priced Apple macintosh.

Buying a Windows laptop (or just computer hardware in general) there are two different things to differenciate:

the hardware and its manufacturer,
and the operating system shipped with the laptop, coming from Microsoft.

and we can rearrange the list of complaints of the first tweet based on this.

The list of the laptop manufacturer faults:

bad hardware quality (including SSD),
shitty cooling system,
not focused on real-usage quality & tests,
high pricing for shitty hardware.

The list of the Microsoft Windows faults:

the hibernate system that does not seems to work for laptops,
inexplicable performance drops,
calculating superficial things in background, which explains the wake-up in the laptop.

Both seem to fault here, and we can ask ourselves how evolved the professional laptops “industry” since the last 10 years.

Note: the title of the next sections can contains spoilers about each evolution.

The greediness of the laptop manufacturers #

Today, the based price of a professional laptop is between 1000 and 1200$.
As an example, if you go to the website of the famous DELL manufacturer, you can find some XPS devices with latest Intel chip in it, at least 16GB of RAM, 512GB of SSD, but no dedicated graphics card.
If you count on a GPU, then you will have to upgrade some specs (like the size of your laptop and, then, the size of your screen) to have a basic NVIDIA RTX 4050 mobile GPU in a 16" XPS for 2500$.

4000$ for a laptop is a thing. And for this price you should get the Rolls-Royce of the modern laptops with:

best hardware quality as possible,
best customer service as possible,
and best overall experience as possible.

So, in total, we should expect for a device that costs 4x the price of a “basic” professional laptop the best reliability ever.

But how can we compute that reliability?

As for smartphones, we can count like that:

best overall quality of each component, and its homogeneity,
if the manufacturer shipped drivers for Windows only or for GNU/Linux also,
the software support in terms of drivers,
the battery life.

Among the best selling devices for professional we can count on many different brands. I will only take care of four different here for my expose, and a recent one called “Framework”.

The quality of the components #

Professional laptops contain their own lot of good, bad, and weird components. The Gaming category contains maybe the most non-sense use of components among the different categories of laptops.

As an example you can find 4K panels on 14" screens, which consumes a lot of battery and is not very well different than a 2K panel for this screen size. However the “4K screen” ad bumps up the price of the hardware. As a personal opinion, I would prefer a 1080p or 2K OLED panel than a bad calibrated 4K panel… especially on a 14" device.

RGB lighting is another example of “flashy” laptops that rely mostly on its design. Except if you want to show off during a Twitch session, I don’t think this is what you really want to show working in a coffee shop on Monday morning…

Slim designs are a weird thing for Gaming laptops, as they need to cooldown heavily to avoid throttling. Slim designs reduce the space needed for components, increase the price of each component too as they have to be specifically built for a laptop model specifically, and also diminishes the repairability of the laptop. In a funny way, the most expensive laptops seem to be the slimest devices - so, more you spend money on a device and less you care about reparaibility…

Finally, the most stupid idea are coming from Razer to introduce a high-end expensive mobile GPU with a 140W power with a low TDP and power supply that can’t fully power it… So, you pay for the high-end mobile GPU and you only obtain the same power than a chipper GPU card. Razer is not the only manufacturer to blame here: the same thing happened since years about the CPU, where the cooling system was not good enough to avoid general throttling, which reduces drastically the performances of your laptop.

Talking about cooling systems, innovations about cooling systems stopped since years now, and manufacturers usually install a larger fan and a more agressive “Extreme Performance” software profile (only available when plugged).

And, finally, the CPU. CPUs had a really low increase in terms of performance on Windows laptops but are, at least, as expensive as previous generations of CPUs. They consume more and more energy to try to performance better than the previous generation but sometimes fail because of bad thermal performances and throttling. You can check the prices of new high-end laptop CPUs here, which are mostly in the same range of prices than a general business laptop.

OS support #

Windows 10 has been introduced in 2015, and its end is scheduled for 2025. A majority of Windows 10 laptops, introduced in 2015, where not suitable to move to Windows 11, so most of those will just die once the EOL of Windows 10 will be claimed.

Windows 12 specs will tell us if Microsoft is forcing people to buy new hardware, or if Windows 11 was only a “step for security” as they claim.

Except DELL no one supports GNU/Linux for hardware drivers, and DELL only does this for its XPS brand, no other.

Another thing is the number of bloatwares shipped with a laptop today, and the number of background services that are running to ask you to register somewhere for whatever reason… Those applications are really annoying and come with plenty of default softwares from Windows 10/11 that slow down the overall performances of your computer.

Drivers support #

About laptop lifespan per brand, it is very difficult to have reliable information from those manufacturers. Despite searches I only found that Microsoft released on official statement about 4 to 6 years of software support, at least, depending of your Surface device.

However, 2 years ago, a Medium user called “Greencodetech” has done its own searches on the subject and published a paper about it here.

Its own searches led him to this top 5 (according to hardware models):

Lenovo, with 5 to 7 years of drivers support,
DELL, with 5 to 6 years of drivers support,
HP, with 5 to 6 years of drivers support,
Microsoft, with 4 to 6 years of drivers support,
Acer, with 3 to 4 years of drivers support.

The battery life #

A laptop without battery life is just as useful as a car without wheels: a theoritical portability.

Most professional laptops support a “good” battery component, drained very quickly by the energy-consuming components that compose the laptop.
To avoid your battery life to end in less than 2h, Microsoft and laptop manufacturers imagine different profiles to help components to consume less energy while reducing their performances. So, as a result, your computer will lasts 4h but the compilation time will lasts 2x more than plugged…

Another fact is some components will be disabled on purpose to avoid waste of energy… so, as the manufacturer did not increased the capacity of your battery life (or just did not invested on improving the situation here) you will have a decent battery life but with weaker performances and disabled hardware parts.

In overall… #

Professional laptops are as expensive as previous generations, but they are, at best, as “ok” as the previous generations, if not weaker.

The OS and drivers support is in average 5 years but, if I am being honest here, I never found a person with a 5-years professional laptop in its hands since a while, mostly because the device died by itself, or some components stopped working well, or just the need to upgrade to better specs, which is not what you can do easily on modern professional laptops.

The fact that certain brands like Razer, DELL, or Microsoft let you buy very expensive laptops with expensive components on it that you can’t use at full speed and / or at full power is another fact that end-users are not respected.

A possible future : the Framework laptop #

One possible alternative is called Framework, which focuses very heavily on scalable and modular configurations, and long-lasting hardware.
Unfortunately there is still no reliable data to know how really lasts a Framework laptop, and how reliable those modular configurations perform.

The unreliable state of Microsoft Windows #

How can we explain that our laptops have more powerful components than 10-15 years ago but software still feels “laggy”?
A simple hypothesis is our computing devices are actually busy to execute shit instead of focusing only on user’s demands.

It is not a surprise that each new version of Windows from Microsoft is a fiasco.
However, the new mainstream thing - since Windows 10 actually - is that each new update of Windows introduces again more bugs (and more ways to lose your data), less useful features, more ads, and less performance!

As an example, in 2022, Tom’s Hardware performed a benchmark on running the exact same software on a classical machine running two different versions of Windows (10 and 11). Tom’s Hardware found out that each software was running between 6% and 10% slower on Windows 11 than Windows 10.

The Microsoft marketing team does seem aware of this issue as they stated, releasing Windows 11:

Both operating systems have similar security features, update processes, and compatibility with hardware and software. However, Windows 11 offers improved performance and features compared to Windows 10, making it a better choice for those looking for a more modern and efficient operating system. To get this statement, please follow this official Microsoft webpage.

Also, Microsoft did not even tried to fix one of the most noticed bug on a laptop for Windows 10 and Windows 11: “modern standby”, which leads to a Windows laptop that wakes up suddenly in your backpack. This is the issue Jonathan Blow stated in its tweet.
This issue has been raised by everyone, including all modern streamers and YouTubers, like Linus Tech Tips in the following video.

Microsoft acknowledged the issue, and released several fixes that do not seem to work for everyone, as this bug is regularly reported again on some official and unofficial Windows forums.

Is there an OS alternative for gamedevs ? #

As I said earlier the two tweets authors are working in game and game engine development, and I understand why both authors are targeting Windows as a default / main platform for their work, despite the weird state of this OS today and the macOS and GNU/Linux alternatives today.
First, as a game developer you may want to target the largest community of gamers as possible, and this community is 95% on… Windows.
Then, as a game developer you may want to target also the console gamers, on Xbox, PS5 and Nintendo Switch. The main issue is that all tools from those console manufacturers, including the SDK, are exclusively built for… Windows.

Unfortunately, to target the main audience in gaming (industry / market), there is no big room for GNU/Linux or macOS.

We are doomed

Sun, 14 Jan 2024 20:00:00 +0100

I wanted to write about modern graphics APIs at first, how exclusive they are depending of the platform you are developing on (and for), and how difficult to use they are. However, after (over-)thinking about this blog post, I came to the conclusion that this problem could be generalized to all software.

This is a very pessimistic view of some people call “modern software engineering”, observed by a 10 years professinal experience engineer and 20 years programmer.

Take it with one (or two) grain(s) of salt.

Once upon a time, a developer and a graphics renderer… #

Three years ago I began to work on my custom graphics renderer. “Just for fun”.

At that time I was working on macOS (an Apple Silicon hardware) so, naturally, I had four different graphics API available for my needs:

OpenGL: deprecated in 2018 by Apple for their platforms,
Vulkan: not supported natively by Apple, but Khronos is maintaining Vulkan for macOS through MoltenVK,
Metal: the official and exclusive graphics API from Apple for their platforms,
My own software renderer: … naah…

I felt a bit lost there.
I would go for OpenGL if Apple did not deprecated the API (version 4.1, circa 2010): simple to use, simple to understand, a great community if you have questions and a very good compatibility with existing hardware and other operating systems.
Ok, so Metal? The main drawback of Metal is that it is only for Apple platforms, nothing else. I don’t know what tomorrow will be made of, and I have absolutely no guarantee that Apple will not lockdown again their APIs / hardware / platforms and make my project completely useless in a few years… no go then!
Ok, so Vulkan? As I said Khronos is maintaining a version of Vulkan for macOS using MoltenVK, a translation layer to Metal. I liked the idea but Metal is missing a lot of features compared to other hardware like AMD or Nvidia hardware, and MoltenVK is like two years behind schedule compared to other platforms versions… hugh…

At that moment I had the strange feeling that I was not choosing for the best graphics API, but the least worst of them.

But how is the state of the graphics APIs on Windows by the way?
Fortunately OpenGL still exists (actually it is more a living-dead API), version 4.6, depending of your hardware (but AMD / Nvidia did the updated for OpenGL 4.6 so your hardware should probably support it), and Windows has a great compatibility history to support old software and old DirectX versions. But DirectX is only available on Win32 platforms like Metal is for Apple ones.

Ok, so we have four (4) different graphics APIs available, only two (kinda-)multiplatforms:

OpenGL, version 4.1 on macOS and 4.6 on the others (kinda), but Khronos moved forward and is not interested on maintaining OpenGL anymore…
and Vulkan.

Spoiler: I choosed Vulkan.
The gap between OpenGL and Vulkan is abysmal, and I did realized that Vulkan was a sort a “bastard library”: made for engine and graphics developers but its API is so wild that it looks designed for device driver developers. The documentation is unclear, the examples are quite complicated to understand and to adapt, and it seems that “extensions” principle can be used for very specific hardware versions, which is not what we want as a “product developer”.

Developing features took time, and I had hard times developing them using Vulkan, but I continue to work on this project… until a few weeks ago. I was sitting in front of my computer, on a performance issue on Windows until I realized the same code, on both Windows and macOS APIs, perform very differently. The Windows version was 30% slower than before, but the code performed better on macOS… I stopped there.

Dedication to complexity #

Looking back at when I first started programming when I was a kid (2002, on a old Compac PC running Debian) the things were pretty simple : just find a good documentation (at that time we shared some very good technical books with friends instead of googling everything like today), the distribution was shipped with a C compiler and a text editor, the base standard library, and a very few APIs to make graphics. If you want to exploit your dedicated hardware then you could use OpenGL (or other APIs) but most of the time you exploited your entire CPU to render something on screen… and it was very simple!
Also, we were running computers with 256MB of RAM, a single core CPU (less than 2GHz if I remember correctly) and software at this time were running blazingly fast! Tools, games, … everything was running ok.

I have the feeling that software became (and still continue) very complicated and very expensive in terms of resources because of poor libraries and poor APIs, bloated operating systems, used by strong hardware but running poorly due to all of this. Engineers tend to over-think an API through the piece of hardware that has to be exploited by the end developer.
This is very true for GPU hardware manufacturer, where one dedicated piece of hardware has a non-standardized API to exploit it, which is not compatible with another manufacturer, and this is true also for console manufacturers like Sony, Nintendo or Microsoft. But this is true also for system software providers like Microsoft or Apple, through their own operating system and tools.

Complexity impacts everything now, from the programming language to the operating system, passing through the API you are using to exploit your dedicated hardware, the “stack” you are developing your piece of code on, or the compiler you are using. We have very fast computers today which don’t seem fast at all as soon as you try to compile a simple project with more than 20 C++ code files in it, mainly because the CPU is busy to run extra code and software running on your computer?
A simple example: It takes 13 seconds to my new Windows computer to compile my 20+ C++ files project, or 780 frames if you are developing a game at 60Hz refresh rate.
Maybe because of Microsoft Defender, keeping an eye on newly created file in case of malware? Another process that analyzes the content of your computer every second, or another process that limits your hardware depending of your environment…? Who knows! 🤷

I wonder how much time the C++ compiler I had in 2002 would takes to compile a project with 20+ C++ files… 13 seconds too maybe? :)

Bloat is everywhere… and nobody seems concerned #

The goal of a software engineer (or developer) is to solve real problems using a computer. I am very pissed when I see software “engineers” more concerned about a vim configuration than thinking why their shell profile takes three to four full seconds to load.

As end users we have no choice to use what developers deliver. But, as software engineers, we have no choice either to use what software and hardware providers deliver too, and the quality of the tools or libraries is becoming weaker and weaker year by year, version by version…

Developers today are definitely not productive than before, mainly because they have to deal with a mountain of libraries, APIs and abstraction, which increase the level of complexity of developing and releasing a good software for the end users, and distract them.

But do we have a choice here?
Imagine that you are (like me) porting games and game engines to consoles : you will have to deal, again, with new tools, new APIs, new abstractions, to build games exclusively using… Windows.
No tools to develop GNU/Linux (there was a time SCE released tools for Linux to develop on PlayStation 2 but this time is now revoked), no tools for macOS, … just Windows. So, you are forced (not encouraged, but forced) to use this operating system and tools (like Visual Studio), and to deal with its complexity, to release a product on another platform.

I don’t blame the software developers here. They have to live, and they mostly operate by people only interested in retention rates and how much end users spent on their tools and platforms.
Also, mostly do not care about performance and optimization anymore as their own computers have enough of RAM to handle the app itself, and do not even know how their own software is being executed… This is very sad to me.

As an example, I am still amazed the difference of time PhotoShop is taken now to open a simple image, compared to 10 years ago for the same picture: much less time, much less RAM, and much (much much much much) less HTTP calls too.

The “container” joker card #

When I discuss about OSs behaviours I hear more and more oftenly this very unique sentence

OS does not matter anymore as we use containers now…

So, based on the fact I could run, deploy and “save” my software in a container for 10 years, does it means I could develop and run a game engine on a container and deploy the image everywhere without platform incompatibility?
If yes… did you hear about the Docker incompatibility when Apple Silicon chips have been released…? :) Or maybe another platform incompatibility?

As Docker mentions in their documentation:

Every Engine release strives to be backward compatible with its predecessors, and interface stability is always a priority at Docker.

followed by

In all cases, feature removal is communicated three releases in advance and documented as part of the deprecated features page.

This implies that, if you find an old image you want to use, you must definitely use the version of the engine that was used originally to develop and build the image if your system still supports it.

The only system with a good software compatibility that I know is Windows, and this explains a ton of things keeping very old UI/UX frameworks, software and APIs to run, for example, Windows 95 compatible games like “Roller Coaster Tycoon”.

Otherwise, you are doomed.

Generated using memegenerator.

Gaming on mac in 2023

Tue, 26 Dec 2023 12:00:00 +0100

If you know me since a while you know my love for the macintosh and the Apple Silicon chips. Actually my main daily driver is an Macbook Air M2 and I have a Steam Deck next to me which I bought to play Windows games in an handheld format. But, sometimes, I just want to play “old” games on the mac device, which may not be compatible with macOS x86/64, so no Rosetta 2 translation available…

In a post last year I wrote about mac source ports, an excellent website that lists all games and game engines ports from Windows to macOS. This time, as I have little free time, I tried out the new version of crossover, that I bought in a Black Friday discount (thanks Andrew Tsai!) after checking sales on GOG and looking for a good game to play on.
After a few searches I found out that one of my favorite games on Xbox 360, Stranglehold, was on sale at 2 euros! I haven’t played this game for years and I was wondering how this game would run on CrossOver… so I bought it, reinstalled CrossOver on my mac and tried out to create a bottle from scratch to play this game on my Macbook Air.

First I did a quick search in the CrossOver database and I found out that the game has been rated 4/5 by some users, nice!

Unfortunately the bottle is using the Steam app as a backend, and I don’t want to have a static Steam application for each of my games. Also I just bought the game on GOG so…

So, first, I created a new bottle called “Stranglehold”, and I downloaded the files from GOG in a dedicated folder.

The files are:

one binary, that contains an installer for GOG Galaxy, and look for the files,
and the .bin files that are basically disk images containing the install data.

Note: _ If you want to look at all the data files you can download innoextract and just run innoextract -l <GAME.EXE>. An alternate tool is Extractor but it is only available for macOS. _

Just link the executable in the folder to the bottle, and the installation process will be executed automatically, very nice!

CrossOver exposes a lot of configuration settings for a bottle, and you might be interested by some of them depending of the game your are running on. Basically D3DMetal supports translation to DX12 and DX11 (kinda). DXVK, in the other hand, can somewhat support DirectX versions between DX9 and DX11 (included).
Stranglehold was developed using Unreal Engine 3, using DirectX 9.0, so using DXVK can be a good option to have better performances.

If you want to display some additional informations about how well the game is running, you can go to the game’s C drive, find the cxbottle.conf file at the root of the bottle and add the following line to it:

"DXVK_HUD" = "fps,frametimes,gpuload"

At the end I could enjoy Stranglehold on my mac, running without any issue!

2023, in a nutshell

Mon, 25 Dec 2023 12:16:16 +0100

In my last year’s blog post I wrote

2022 was a strange year for everyone I think.

I do think, as game developers (or just computer developers), we can agree that 2023 was way worst than 2022, maybe one of the worst year since a long time actually.
Despite records sales in the video game industry, and record earnings, the number of layoffs in the field was incredibly high (more than 6000 jobs lost in 2023 only so far, recorded from January to November 2023). Also, E3 communicated a few weeks ago they are definitely closing their doors, sounding the death knell of an era of physical celebration for the video game industry.
I am very sad for all developers who lost their jobs this year, and I sincerely hope that the industry will recover quickly from this.

Professionnally I ported two video games for 5 platforms each, one game engine (and another half for 2024), and I helped porting two game engines to fix bugs in upcoming and released games. Not so bad! The main challenge of this year was porting SHINORUBI and its game engine called V3X, developed by RealtechVR for five different platforms: PS4, PS5, Nintendo Switch, Xbox One and Xbox Series consoles. The work for SHINORUBI began in September 2022, ended in late-November 2023, and the release is planned for January 2024. Apart from that I helped to make fixes for existing game engines but the games have not been annunced yet by RedArtGames so I can’t tell anything the games and game engines (yet).

Shinorubi is almost here!

The hellacious Danmaku style shmup from @LastBoss88 is coming digitally to Nintendo Switch, PlayStation and Xbox consoles on January 12, 2024!

The limited Switch, PS5 & PS4 physical editions can still be pre-ordered from https://t.co/rbcxlKLx2i pic.twitter.com/XyvBqgHHeC
— Red Art Games (@RedArtGames) December 1, 2023

I continued my own game engine in my spare time, but more and more I tend refocusing the game engine to a renderer-only project, with a Vulkan and Metal backends.
Also, I just finished the 2023 edition of advent of code, an annual program (in December) of small programming puzzles to solve “for fun”. As always I did not participate to the competition, mainly because I had to get up at 6AM to get a chance to participate (too early for me), but also because I wanted to do AoC for fun and without any stress. Except the Day 24 Part 2 I did everything the release day, using Swift. This year I put on my list Rust, C++ or Swift, and asked to a friend to choose a number between 1 and 3 (included) - he choosed 3… so Swift :)
My AoC repository is available here.

I did not changed my computing environment: a M2 macbook air only, which I use for everything except gaming. This machine is pretty incredible: great power & excellent battery life, perfect combo!

I played a very high number of good games this year:

Psychonauts 2,
HiFi-Rush,
Battlefield 4 (yes, I know, this one is old…),
Alan Wake 2 (my GOTY),
Quake 2 Remastered,
Assassin’s Creed: Mirage,
…

I do not expect anything from 2024 except stablization in the game & software development industry: let’s keep it simple.

Time for me to close the lid, wish you the best for 2024!

The tunnel effect

Mon, 28 Aug 2023 22:45:00 +0200

The demoscene #

The tunnel effect is a pretty old-school effect in graphics programming, coming directly from the demoscene. If you take a look at pouet.net you may find many (many many) examples of a Tunnel effect for different hardware configurations, like this one using 3D raycasting.

In this collection of web demo effects you can find and experiment with this effect: https://seancode.com/demofx/.

In one of the most well-known demos ever, “Second Reality” from Future Crew, the team presented a very nice Tunnel effect in… 1993, years before any graphics card in a personal computer. You can take a look at this effect, running on the CPU, on YouTube.

The key word for running this on any PC at this time was “pre-calculation”, as the pixel distances and angles of the tunnel are pre-computed, and the runtime is basically moving around those tables at each frame.
Pre-calculation is what makes this demo running so fast and so smoothly at 60 frames per second, on a very old PC’s CPU.

If you are interested in the CPU computation, you can take a look at this excellent blog post.

Running the code #

Developing on “Frame Engine”, I wondered how long it would take to rewrite this effect using a modern graphics API like Metal.

First, as I transformed my 2D engine to full-3D, I forgot to include some very basic 2D meshes like a surface… so, I wrote a very basic one as an OBJ file:

mtllib 2D_surface.mtl

v 0.000000 1.000000 0.000000
v 0.000000 0.000000 0.000000
v 1.000000 0.000000 0.000000
v 1.000000 1.000000 0.000000
vt 0.000000 0.500000 0.000000s
vt 0.000000 0.000000 0.000000
vt 0.500000 0.000000 0.000000
vt 0.500000 0.500000 0.000000
# 4 vertices

f 1/1 2/2 3/3 4/4
# 1 element

Once I have the surface, let’s write the fragment shader.

The Metal fragment shader is actually very simple:

#define ANIM_DISTANCE 0.45
#define ANIM_ANGLE    0.25

float4 tunnel(float2 worldPosition,
              texture2d<float, access::sample> colorTexture,
              sampler colorSampler,
              constant FragmentUniforms& uniforms) {
    // Compute the angle for the effect
    float  angle = atan2(1.0 + worldPosition.y, 1.0 + worldPosition.x) / PI; 
    // More the pixel is near the center and more it is distant for the effet
    float  distance = sqrt(dot(position, position));                    
    // Compute the UV of the texture to render
    float2 uv = float2(angle, ANIM_DISTANCE + (ANIM_ANGLE / distance));
    // Return the color
    return colorTexture.sample(colorSampler, uv);
}

To make a movement, you can multiply for example the ANIM_DISTANCE by your timer, like this:

float2 uv = float2(angle, cos(uniforms.time) * ANIM_DISTANCE + (ANIM_ANGLE / distance));

Now that we have the metal shader, let’s take a look at the sampler…
We want to repeat the texture motif for s and t, we do want linear filter near the eye, and nearest filter far the eye.

Associated to the texture, we could set the sampler like this:

let samplerDescriptor = MTLSamplerDescriptor()
samplerDescriptor.normalizedCoordinates = true
samplerDescriptor.minFilter             = .nearest
samplerDescriptor.magFilter             = .linear
samplerDescriptor.sAddressMode          = .mirrorRepeat
samplerDescriptor.tAddressMode          = .mirrorRepeat
samplerDescriptor.maxAnisotropy         = 2
self.samplerState = device.makeSamplerState(descriptor: samplerDescriptor)

Using this setting, and a few textures, you should get the following results:

The animated version is available on YouTube:

Update on Frame engine (2/x)

Sun, 13 Aug 2023 15:00:00 +0200

Almost one year ago I posted my advances on “Frame”, a custom game engine wrote in Swift with SwiftUI, and Metal as a backend.

From August 2022 to August 2023, I made a journey into two different graphics libraries: Vulkan, and Metal.

The new project #

I definitely wanted to take a deep look into Vulkan for multiple different reasons: i) it is cross-platform, and ii) Vulkan begins to be widely used as a “standard” for game engines rendering backend, iii) I needed to get deeper for my work. Indeed, since July 2023, I port at RedArtGames a Vulkan game engine for all the modern consoles, and it made me curious to learn more, more, and more and this graphics library.

Metal is great and very (very very) powerful, or at least powerful enough for me to create good 2D and 3D experiences for mac, iPhone and iPad users. But the issue with Metal is that it is used for Apple platforms only. You can compile your shaders on Windows now, but you can’t (still?) run Metal application from other platforms.
So, I took my bag and got into a journey to create a tiny 3D rendering program portable using Vulkan and Metal as backends, which could run on Windows, macOS and iPadOS. At the end, after a year, this “tiny 3D rendering program” became my new graphics engine…

There exist some Vulkan binding projects for Swift, like SwiftVulkan, but I prefered this time a simpler approach, developing this program in good-old C++ (17).

The issue with Vulkan #

First, I got into the documentation of Vulkan, which is very large and which you can simply fall into… and getting more confuse at the end. It is a very strange feeling: the documentation is very dense, too much straightforward most of the time (no context of the error at all for example), and when you get answer then two other questions pop in your mind based on what the documentation describes as the error…
Very strange.

The Vulkan API (1.3.211.0 in my case) is too verbose, and there is a rumor thats says you will have to write 300 lines of code before rendering your “hello-world GPU graphics programming program” : the famous RGB triangle.
Yes, it is 100% true.
I don’t have any issue with verbose APIs but, to me, verbose APIs have to be verbose for a reason: like very long names to avoid unnecessary comments or dev doc, to let the reviewer understands what the code is doing or what is the current process in the graphics pipeline, etc. To me this is not the case for Vulkan.
What is the purpose of setting all your pipeline parts in your code if it has to be default one most of the time?
What is the purpose of implementing a wild-variety of non-typed enums if it is not for making mistakes and scratch your head for 15 minutes?
The API structures / classes are large and it is very easy to make a mistake, simply put a wrong enum, and lose 3ms in performance because of this…

A nice thing about Vulkan otherwise is the internal validator. The warning / error messages are good enough to get what is the problem right away, including a hyperlink to the online documentation.

In terms of documentation, I think there is no official tutorial for Vulkan. I found out a very old tutorial called “Vulkan Tutorial” but, after looking at the description and the code, I wouldn’t recommend it to anyone as it is very outdated and contain multiple mistakes.

Let’s back to the engine… #

My engine has two backends now :

Vulkan, used on Windows and macOS, using VoltenVK,
Metal, used on macOS, iPhone and iPadOS, and using Metal-Cpp layer for C++.

For the cross-platforms thing, I used the old-friend CMake to be assured that the engine could be built & run almost everywhere. However one of my friends advice me to look at another build system called premake, which could simplify a lot all the CMakeFiles files I had to create to make everything portable.

I implemented a debug view using ImGui (again, big applauses for ocornut and the ImGui community for this awesome work), a nice graphical interface that runs almost everywhere, and the nice Docking features.

I implemented all the conditions to have a “modern” scene:

a proper Scene architecture for thousands and thousands of objects to compute and render,
a multitude of cameras in the Scene object, and a way to switch from one to another very easily,
a proprietary solution to package 3D models, textures, …
multiple lighting solutions for the environment,
a very simple collisions solution for objects in a scene,
and a basic editor to quickly drag and drop objects from the computer to the virtual scene, move objects, move the scene’s main camera hitting “PLAY”, etc.

Also, I have implemented almost all of the things I had in my bucket lists from last year, except to let the developer modify and integrate its shaders via the game editor.

I still don’t have a physics engine and sounds interpreter, as well as a game interpreter to run the objects scripts, but this is on list for August 2024… if I can find the time!

All it takes #

A game engine is a very complex piece of software, and as all other complex softwares everywhere else, it costs in developing features, in refactoring, in debugging, in profiling, … It costs your time. To find the time to search and make all of this, once the kids are in bed after work, twice a week at most, is a challenge for me today.

I am very proud of what I learned and what I did after this one-year journey. Metal is definitely a simpler API compared to Vulkan, just comparing the API complexity together, and I continue to think that Vulkan should have taken the same path as Metal in terms of simplifying the API, while offering great customization of the graphics pipeline if only necessary.

See you in August 2024 for the third update 👀

Screenshots #

A lighting scene, rendered on iPadOS

A small part of the editor and its basic debug interface

The weird unreachable code

Sun, 12 Feb 2023 23:03:00 +0200

Last week I heard about a weird behaviour of a C++ program on Twitter.
The code is:

#include <iostream>

int main() {
    while (1);
}

void unreachable() {
    std::cout << "wait... WHAT?!" << std::endl;
}

Pretty simple, right? Two functions, one infinite loop, and the unreachable function that is never called…
As you might expect the program will run until the user forces the program to quit, without any standard output, no catch at all.

However, under a certain condition, it could also be executed in less than a millisecond and print

wait... WHAT?!

I reproduced it on godbolt here for you if you do not believe me: https://godbolt.org/z/MYhb9Ezv1.

Now, let me explain what is really happening under the hood.

The singular points of the program #

To explain the behaviour, let’s cut out the different parts of the program.

The main function #

int main() {
    while (1);
}

The main function runs an infinite loop that is doing absolutely nothing, and no instruction to break it somewhere. The objective of the main program is very very simple: loop over and do not stop.
Also, there is no explicit return statement, but the compiler implicitely appends a return 0 statement at the end of the code block.

So, the final code, understood by the compiler, results as it is:

int main() {
    while (1) {};
    return 0;
}

The unreachable function #

The unreachable is also very simple: print the message “wait… WHAT?!” and return. The important thing to look here is that the function definition and implementation is done after the main function, and this is very important to understand the behaviour of the final execution of the program.

The compiler settings #

Here, we are using clang13.0 (c++ frontend), with the following arguments:

-01, which is the first entry of optimizations for clang,
-Werror, which enables all warning statements as errors.

Let’s play #

The main issue here is not coming from the program, or from the developer. Actually, it comes from the compiler.

In godbolt, looking for the code generated by clang, the issue is on the first lines:

main:                                   # @main
unreachable():                          # @unreachable()
        push    rbx
        mov     edi, offset std::cout
        mov     esi, offset .L.str
        ...

As you can see the @main label is empty here, which results in executing the instructions contained in the next label… which is @unreachable.

Let’s interpret what the compiler might want to understand here…

I am executing the main function…
Hey, I don’t need to return anything from the main function, as the loop is running forever! Ok, let’s remove it…
Hey, the loop is doing nothing, and the dev asks me to optimize the code… let’s remove the loop then…

And then, we have a main function that does not contain any return statement, or any other instruction.
Just an empty function.

This behaviour is quiet complex to understand at first as developers may want to say: “but, this is the same than any other void functions right?”.
Absolutely… not.

If you take a look at the generated asm code from the following C++ function

void do_nothing() {
    return;
}

it does contain a return statement:

do_nothing():                        # @do_nothing()
        ret                                  # <<<--- INSTRUCTION TO EXIT do_nothing()

So, the following program, using clang13.0 and -O1 optimization, does not execute the loop but does not print anything:

#include <iostream>

int main() {
    while (1) {};
    return 0;
}

void do_nothing() {
    return;
}

void unreachable() {
    std::cout << "wait... WHAT?!" << std::endl;
}

as the generated asm code proves:

main:                                   # @main
do_nothing():                           # @do_nothing()
        ret                                     # <<<--- QUIT HERE
unreachable():                          # @unreachable() - NOT EXECUTED
        push    rbx
        mov     edi, offset std::cout
        mov     esi, offset .L.str
        ...

The strange case of an infinite loop #

So, why does this occurs using an infinite loop ?

Because an infinite loop is simply… an undefined behavior.

The C standard (C11 to be more precise) says this:

An iteration statement whose controlling expression is not a constant expression that performs no input/output operations, does not access volatile objects, and performs no synchronization or atomic operations in its body, controlling expression, or (in the case of a for statement) its expression, may be assumed by the implementation to terminate… This is intended to allow compiler transformations such as removal of empty loops even when termination cannot be proven.

In this case, while(1) is an example of a constant expression, and then it may not be assumed to terminate. So, the compiler may (or may not) decide to optimize it removing it from the code… so does clang.

This behaviour has been implemented for clang13.0, and is still used today in clang15.0.

A fix that could implement clang for this case would be:

emit a label (like jmp loop) to jump over the infinite loop, and not remove it,
or remove the infinite loop but emit another call to return 0 from main.

2022, in a nutshell

Tue, 27 Dec 2022 12:00:00 +0100

2022 was a strange year for everyone I think. To me, it was a year full of reconsideration, of reflection on myself, the World, and my family’s future. People tend to think that 2020 was the worst year to live recently, I don’t agree at all as I think the worst may come “soon”…

Anyway.

The blog posts statement #

I published nine posts this year (10 if you include the one you are reading):

three technical topics, mainly on low-level programming principles and graphics programming,
three personal notes about 2022 and personal changes,
two high-level technical notes, about demoscenes and publishing,
and, finally, one non-technical note about how to run old games on Apple Silicon macs.

I think I found a “good” publishing rate, and I expect to write more technical blog posts in the next year (maybe a “game engine series”, who knows).

“Rethinking” #

Professionally, 2022 got off to a terrible start but ended with the best work experience of my life.
I switched in 2021 from an AI Engineer job to a Senior Software Engineer job, and 2022 was another transition to a Game Developer career (to be honest, more a Game Engine Developer job), at Red Art Games.

After eight months at Red Art Games, I found out the video games industry works great to me compared to other ones. The thing I like the most is: your work has an end. Once the game is “ready to ship”, then you switch to another project and you don’t have to go back (except if a player found a bug or if you want to develop an extension to the original game).
Then, you take the experience you earned from the previous game, reconsider the full experience, take the best, and finally make a transition to the new game, and redo the same process again and again for the next game(s).

Compared to a web project, you don’t have to develop new features and reconsider the architecture of the current “stack” to deliver new things each X months. If you want to do more with an IP, then you develop a sequel or a new game in the same world, but it is another project.

Also, after a few years using Go and Rust full-time, getting back to C++ 17/20 comforted me in the idea that the language evolves in a good direction.

What I expect for 2023 #

In 2022 I helped to port the games “OmegaBot” and “Shinorubi” on consoles, which are great projects for very different reasons.
For 2023, I expect more cool games to port, more complex tasks to learn new skills or to perfect my own skills, and a few “easy” tasks to take a deep breathe between two complex ones.

At the beginning of my gamedev career, I did not know what I wanted to do, and what I wanted to become. After eight months working in a video game studio, I understood I am more interested in game engine development and optimization (on the game engine side) than just “developing a game”.
So, I would explore more game engine development “stuff”, and maybe refine again my skills and where I want to contribute at the gamedev side.

In a more personal way, I sold my gaming laptop for a Steam Deck from Valve, which is actually the “2022’s Game Gear” compared to the Nintendo Switch. The Steam Deck is powerful, has some great features and works well, but more and more I play on it and more and more I understand why the Nintendo Switch is the best handheld device since five years now. Don’t get me wrong: it is awesome to play to “Death Stranding” or “Spiderman” on the Steam Deck, but I still consider it (and its OS) has a beta for geeks and hackers, and not a device for everyone. So, I expect a Nintendo Switch 2 for 2023, with more power and a slightly better battery.

Finally, in an idealistic future: less war, more love, and an eco-friendly society.

What I do not expect for 2023 #

The beta version of “Cyberpunk 2077”, which is still in alpha version since almost three years…
If CD Projekt still think they can make an ‘ok’ game with what they done yet :)

Fun with data alignment

Fri, 18 Nov 2022 21:30:00 +0200

Whoever worked on system programming know that data alignment is very important to save memory space, or avoid runtime crashes casting from a specific type to another.
After some months on porting games to console systems, I noticed how data alignment could be, sometimes, a source of errors and a lack of knowledge.
I wanted to discuss about data alignment in this technical article.

Note: This is the technical stack I used for this article:

MacBook Air M1 (base model, 2020),
clang 14.0.0 (Apple version), with C++17 support.

The problem #

What is a data structure alignment? An alignment is an integer value representing the number of bytes between successive addresses at which a given struct, or object, can be allocated.
In short: it a way to arrange and access an address in the computer memory.

As an example, for basic types on a 64bits system (we will consider the following examples running on a 64bits system), an int type sizes 4 bytes, a char type sizes 1 byte, a double type size 8 bytes, etc.

But what about a struct? A first approach to compute the size of a struct is to consider that the size of a struct is equals to the sum of its fields size.
As an example, we could compute the size of the following Example C/C++ structure as 4 + 1 bytes, which results to 5 bytes in total.

struct Example {
    int a; // 4 bytes
    char b; // 1 byte
}

However, Example is not 5 bytes but… 8 bytes, which is 3 bytes more than our hypothesis.
To explain this behaviour, we will consecutively split the issue for five different structs and compare our expectations to the reality.

How to compute struct sizes ? #

DA01 #

struct DA01 {
    char a, b, c, d; // 4 * 1 byte
}

For DA01 the maximum size taken by one field is 1 byte. We have 4 fields of 1 byte, which results to 4 bytes.

DA02 #

struct DA02 {
    char a; // 1 byte
    // Padding of 3 bytes
    int b;
}

For DA02 the maximum size taken by one field is 4 bytes (b). We have a field of 1 byte and another of 4 bytes, which results to 8 bytes as we have 3 padding bytes to allocate memory for a.

DA03 #

struct DA03 {
    char a; // 1 byte
    // Padding of 3 bytes
    int b; // 4 bytes
    char c, d, e; // 3 * 1 byte
    // Padding of 1 byte
}

For DA03 the maximum size taken by one field is 4 bytes (b). We have a field of 1 byte and the second one of 4 bytes, and then three other 1 byte fields. This results to 12 bytes as we have 3 padding bytes for a, and 1 padding byte for e.

DA04 #

struct DA04 {
    char a, b, c, d; // 4 * 1 byte
    int e; // 4 bytes
}

For DA04 the maximum size taken by one field is 4 bytes (e). We have 4 fields of 1 byte consecutively, which results to 4 bytes and no padding needed. This results to 8 bytes.

DA05 #

struct DA05 {
    char a; // 1 byte
    // Padding of 7 bytes
    float b; // 8 bytes
}

Finally, for DA05, the maximum size taken by one field is 8 bytes (b). We have a field of 1 byte at first, and we must insert paddings to get 8 bytes in total - so, a padding of 7 bytes. This results to 16 bytes in total.

Summary #

Struct	Supposed size (in bytes)	Real size (in bytes)
DA01	04	04
DA02	05	08
DA03	08	12
DA04	08	08
DA05	09	16

The difference of size between DA03 and DA04, which contain the same fields but using a different order, should alerts you how data alignment could be important to manage and save some space in your programs.

The benchmarks #

If you want to reproduce the results by yourself, this is the simple program I used:

#include <stdio.h>
#include <stdlib.h>

struct DA01
{
    char a, b, c, d;
};

struct DA02
{
    char a;
    int b;
};

struct DA03
{
    char a;
    int b;
    char c, d, e;
};

struct DA04
{
    char a, b, c, d;
    int e;
};

struct DA05
{
    char a;
    double b;
};

template <typename T>
void getSize(T s, const uint8_t expected_size, const char* const name)
{
    printf("* %s: expected %d bytes, got %lu bytes (alignment of %lu byte(s)) \n", name, expected_size, sizeof(s), _Alignof(s));
}

int main()
{
    {
        const DA01 s = {};
        getSize(
            s,
            sizeof(s.a) + sizeof(s.b) + sizeof(s.c) + sizeof(s.d),
            "DA01");
    }
    {
        const DA02 s = {};
        getSize(
            s,
            sizeof(s.a) + sizeof(s.b),
            "DA02");
    }
    {
        const DA03 s = {};
        getSize(
            s,
            sizeof(s.a) + sizeof(s.b) + sizeof(s.c) + sizeof(s.d) + sizeof(s.e),
            "DA03");
    }
    {
        const DA04 s = {};
        getSize(
            s,
            sizeof(s.a) + sizeof(s.b) + sizeof(s.c) + sizeof(s.d) + sizeof(s.e),
            "DA04");
    }
    {
        const DA05 s = {};
        getSize(
            s,
            sizeof(s.a) + sizeof(s.b),
            "DA05");
    }
    return 0;
}

If you execute the program, using any optimization (-Oxxx) compiler parameter you want, you would obtain the following output:

* DA01: expected 4 bytes, got 4 bytes (alignment of 1 byte(s))
* DA02: expected 5 bytes, got 8 bytes (alignment of 4 byte(s))
* DA03: expected 8 bytes, got 12 bytes (alignment of 4 byte(s))
* DA04: expected 8 bytes, got 8 bytes (alignment of 4 byte(s))
* DA05: expected 9 bytes, got 16 bytes (alignment of 8 byte(s))

Why does this matter ? #

As you might know, the CPU accesses memory by a single memory WORD at each CPU clock.
As long as the memory WORD size is, at least, as large as the largest data type supported, aligned accesses will always access a single memory WORD. This may not be true for misaligned data accesses.

Performance #

As I explained before the system tries to grab a value, and parse it, from its data alignment information.
As an example, there is absolutely no issue for the following structure to parse it with a manual alignment of 1 byte.

struct Example {
    char a, b, c, d; // 4 fields, 4 reads.
}

However, let’s consider the following structure

struct Example {
    int a; // 1 fields, but 4 reads if the data alignment is set to 1 byte.
}

As we know, for a x86/64 or arm 64 architecture, an int type has a size of 4 bytes. If we specify a data alignment of 1 byte, this mean that the system will have to read 4 times the fields in order to get the real value behind a, and make something with.
This would be at most 4 times slower than specifying a data alignment of 4 bytes for this Example structure, which could grab the entire value in only one read (and I did not count the data consolidation cost).

And I don’t talk about misaligned continuous fields in a struct that can reduces significantively the reading and parsing of the data stored in it, and might results to undefined behaviors.

Also, a correct alignment for your data structures may help very much the cache system.

Undefined behaviors #

In system programming you could consider to cast one type to another… and so a structure or a basic type.

As an example, you could theoritically cast, or copy, a uint8_t type to a uint32_t type.
However, the size is not correct, and so the data alignment.
So, a page fault error could happen finishing the cast and reading the result value, a 32 bytes value from an 8 bytes aligned value… outch!

Undefined behaviors can also happen, which are most of the time much harder to find and solve than crashes.

This may happen very frequently when you try to copy a data structure from a memory place to another, which belongs to another hardware / chip. This is frequent for systems with APU(s).

Alignment specification #

In the code #

There are different ways to specify a data alignment for one, or all, data structure(s).

As an example you could specify a data alignment using pragmas:

#pragma pack
#pragma data_align
#pragma align
…

You could also use the alignas keyword specifying the data structure, like this:

struct alignas(32) AlignAsExample
{
    float a[4]; // 4 * 8 bytes, which results to 32 bytes. Nice!
};

or using, for example, the __declspec(align(#)) keyword.
However, as the official Microsoft documentation states for MSVC:

The compiler doesn’t guarantee or attempt to preserve the alignment attribute of data during a copy or data transform operation. You can take a look at this documentation here.

This may be the principal method to use, as you may want to use a different data alignment per struct, and not for your entire program.

Via your compiler’s options #

Fortunately you can specify the alignment for each or all structs in the code, or via a compiler’s setting.
On my local clang compiler the option to specify the maximum alignment data size is -fpack-struct.

As an example, compiling the same code (from the “Benchmarks” section) with a -fpack-struct of 1 byte outputs:

* DA01: expected 4 bytes, got 4 bytes (alignment of 1 bytes) 
* DA02: expected 5 bytes, got 5 bytes (alignment of 1 bytes) 
* DA03: expected 8 bytes, got 8 bytes (alignment of 1 bytes) 
* DA04: expected 8 bytes, got 8 bytes (alignment of 1 bytes) 
* DA05: expected 9 bytes, got 9 bytes (alignment of 1 bytes)

Update on Frame engine (1/x)

Wed, 17 Aug 2022 19:20:00 +0200

Today I wanted to share my advancements on Frame, a game engine I began almost two years ago, for Apple devices only.

In December 2020 I played a bit with Swift, SwiftUI, and Metal, on a custom game engine called “Frame”.
At that time I was not yet a father, and I had a lot of spare time (too much maybe) to spend on this project.
I dropped the project a year after, in December 2021, as it became very difficult for me to focus and spend my spare time on this kind of difficult project.

As making games is hard, making game engines is 100x harder, trust me.

Recently, during an incredible sunny day, I re-opened the Frame project, looked at the code and, using the strength of a powerful and deep voice, said “WhAt ThE F#$% Is ThIs CoDe?!”.
After one year and a half I became a much better Swift programmer, and I noticed quickly the core mistakes I made, which “forced me” to step back from the project.
So, during two week-ends and a few days of vacations, I get back on “Frame” to deliver a much better experience to the game developer (actually ‘me’), more features, better performance, and… more platforms support!

Better code abstraction #

The first thing I made was to make my Swift code simpler to understand and better to maintain.
I removed a lot of duplicated things, introduced new code abstraction for better code management, make the Scene object as a real code representation of a game scene, etc.

The mistakes I made in the first version of the engine was the consequence of how I learned Swift and SwiftUI, and how I understood the concepts at this time.

Now, as I became better using those tools, I am able to detect some anti-patterns and to fix them quickly.
Pretty nice!

In the first version of Frame, which was a simple 2D rendering tool, this is my codebase (using cloc):

-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Swift                           18            170            249            741
Metal                            2              8             19             28
-------------------------------------------------------------------------------
SUM:                            20            178            268            769
-------------------------------------------------------------------------------

For the new version of Frame, which is basically a 2D/3D rendering tool with proper 3D objects and multi-platforms support:

-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Swift                           14            142            204            791
Metal                            1             14             13             59
C/C++ Header                     1              7             11             24
-------------------------------------------------------------------------------
SUM:                            16            163            228            874
-------------------------------------------------------------------------------

which is “only” 100 more lines in total, not bad at all!

The C/C++ header is to use only one representation of data structures to pass in the shaders, instead of duplicating the data structures each time.

The camera object #

In the previous version of Frame, there was no proper camera - only a fixed “eye” at origin (0, 0, 0) that displays everything around him with a limit of (1, 1, 1).

The camera is now an object, and contains a proper Field of View (FOV) property, and a limit (the far limit) to avoid declaring and rendering very far objects from the camera (something that could exists at runtime, but so tiny in the scene that you can’t see it very well).

The camera position and angle can be updated using native gestures through SwiftUI:

drag to move the camera in the scene (actually, move the scene objects around the camera…),
pinch-in and pinch-out to zoom-in and zoom-out in the scene,
and use the rotation gesture to rotate the camera around a particular 3D object.

Actually, the camera is a special Swift 3D object (see next section) that does not contain any mesh or texture, and not rendered.

An example of the interaction in a very basic 3D scene that contains 5 differents objects:

the camera,
the light bubble, which lights up and lights down the objects of the scene,
three different 3D boxes, each with a proper texture.

3D objects and textures support #

For 3D objects I can now render dynamically any .obj file for an abstract 3D object, as soon as it packaged in the app (which is not really useful for a game engine, I admit it).

The 3D object can move its own position in the scene, its euler angles, etc. There is no limit for it.

Any 3D object derived from a BaseObject3D protocol, which derived itself from ObservableObject:

protocol BaseObject3D: ObservableObject {
    /// The position of the object in the world space
    var position: simd_float3 { get }
    /// The visualization angle of the object in the world space
    var angle: simd_float3 { get set }
    /// A name to describe the object
    var tag: String { get }
    
    /// Function to update the attributes of the BaseObject3D, each
    /// time the render function must be called
    func update()
}

The BaseObject3D is very simple, but I will make it a bit more comfy to add new attributes and information, like the meshes to use, the texture to load and to render, etc…

I added support for textures, and created another shader to display them correctly.
I still have some issues to render a texture on rounded 3D objects (like a sphere), but this will be fixed anytime soon.

Also, I implemented a first version of a Light object, to light up (and down) 3D objects that belong to the rendered scene.
There are still big improvements to make for the Light object but the basic version works quite well.

The renderer #

This can be part of the first section but the scene and the rendering code were really intricated and very difficult to maintain without touching of each other.
Normally, in a modern and “generic” engine, this should not happens: the renderer should run without any internal knowledge of the scene to render: just vertices, colors, and textures to draw.

The first version of the renderer was not great, and difficult to maintain.
I also made some abstractions to avoid containing the renderer in the internal Coordinator object of the engine view, which should be a NSViewRepresentable derived object.

Better performances #

Now, running the full engine, creating and rendering a simple 3D scene is taking 24MB of RAM maximum and, of course, the rendering is done 60 frames per second.

Simplifying the code and the rendering reduced drastically the RAM taken by the app, from 100MB to 24MB. There are new things to be done in order to increase the performances, but I am happy about the improvements for now.

The renderer takes, in average, 4ms in debug mode, so I can render this basic scene at 250 FPS… in debug mode, and for each platform.

Natively on iOS, iPadOS, and macOS #

The main drawback of my initial project was the support of multiple Apple platforms.
At the beginning I imagined Frame as a game engine to run on macOS, to developer games for macOS. However, more and more I worked on Frame and more and more I was convinced to run the engine on the iPad and develop games on the iPad directly could be a really nice feature.

Now, Frame is supported natively¹ on iOS, iPadOS, and macOS.

The devices I test all along the changes were:

my mac (macbook air m1 - base model),
my iPad (iPad 9th gen - base model),
two iPhone simulators: iPhone SE (for compatibility with older iPhone models) and iPhone 13.

The debugger of the engine (the right part of the renderer) is not displayed correctly in the simulator, but it renders well on real hardware.

The annoying part: Xcode #

I use Apple devices as a developer since more than 12 years now, and I am noticing each year the decline of Apple to develop appealing and stable tools for developers… like Xcode.

Xcode is a messy developer tool, greedy for computing resources, to write code for Apple devices.

Some annoying features from Xcode are still present since a few years now, like Xcode Preview, which does not reload correctly, or some random build errors (clean + build again fixes the issue), or some cache issues, and very annoying simulator issues to emulate the iPad app on the macbook through Catalyst (pinch-in and pinch-out works half of the time).

Those issues are present since I worked on the first version of Frame - almost two years ago - and I am frustrated to use a buggy (developer) tool to develop a big project.
I never thought I would say this but, concerning developer tools, Microsoft delivers much better developer tools for their platform, like Visual Studio 2019 or Visual Studio 2022…

Conclusion and future #

I made big improvements over two weeks of (hard) work on Frame, and I am very happy with the changes for this new version.
Of course Frame is absolutely not ready to create a very simple game using it, but it’s a new beginning for me and I am excited to see what I will do next on it. I know it will take me, at least, another two years to make very simple games using it, building and delivering as packages on the iOS and macOS App Store.

The list of features to implement keeps to grow:

keyboard handler for iPadOS and macOS,
multiple shaders support,
better UI/UX,
import external (not-in-the-app-bundle) 3D objects,
integrate first 3D objects interaction(s) with the fingers and/or the mouse,
let the developer modify and integrate its own Metal shaders in a dedicated native text editor,
collision support,
Metal 2 and Metal 3 support,
etc.

The code of Frame will be kept private until I am done with it, and ready for interested people to take a look and use it.

Using the same Swift / SwiftUI code, and one click (on Xcode) to build and deploy on the platform of your choice. ↩︎

How to publish a bad programming article

Tue, 09 Aug 2022 23:48:00 +0200

[10th of August 2022 - Article Update]
A friend of mine told me he would not used the word “instructions” talking about the size of a binary program, as there are not only instructions but the ELF structure, the imports, etc.
After its careful review, I removed the word “instructions” for “lines” (even if I don’t really like the word “lines”…).
Thanks Eric for the review! :)

After going to famous orange website I noticed an article claiming that ‘“Hello world” is slower in C++ than in C (Linux)’.

I was intrigued by the title at first but, after reading the first two paragraphs, I became mortified.

The issue with the article #

C++ is a programming language that includes its own standard library, but can also work with the C standard library. When you make comparisons, and especially if you publish the results publicly, you have to make sure that what you are comparing can actually be compared (in short: do not compare apples with oranges).

In this article, the author compares two different programs.
A C program:

#include <stdio.h>
#include <stdlib.h>

int main() {
    printf("hello world\n");
    return EXIT_SUCCESS;
}

and a C++ program:

#include <iostream>
#include <stdlib.h>

int main() {
    std::cout << "hello world" << std::endl;
    return EXIT_SUCCESS;
}

However, as you already noticed, those programs are valid C and C++ programs but those programs compare the stdio module against the iostream module.

Note: std::endl does a buffer flush before printing the message on the standard output compared to the C version, so the code is not strictly equivalent to the C sample…

Let’s redo the experiment #

If we want to compare both languages, we actually have to compare the binaries (size / memory performance / execution time / …) of the same program compiled by different compilers: a C compiler, and a C++ compiler.
So, if we really want to compare the languages, lets take only one code sample (the C sample), compiled with the same parameters, lets run them at least 5_000 times x 10 times (to avoid some computer working behaviours) and extract the median of those bench (and the standard deviation as well, always interesting to take a look at this).

Note: Also, the author did not explained which version of gcc/g++/clang, and which version of c++, to use to reproduce the results, which is a bad sign…

After updating the Makefile:

all: helloc hellocpp
	hyperfine --runs 5000 ./helloc
	hyperfine --runs 5000 ./hellocpp

helloc: hello.c
	clang -O2 -o helloc hello.c -Wall

hellocpp: hello.cpp
	clang -O2 -std=c++17 -o hellocpp hello.cpp -Wall

Here, the .cpp and the .c files are stricly equivalent:

#include <stdio.h>
#include <stdlib.h>

int main() {
    printf("hello world\n");
    return EXIT_SUCCESS;
}

I used clang version 13.1.6 for this experiment.

After compiling the binaries, lets compare the size first:

> wc -c < helloc
   33427
> wc -c < hellocpp
   33429

The C binary has 33427 lines, and the Cpp binary 33429 lines… quite a lot to print an “hello world”!
So, both binaries are different, as the cpp output has 2 lines more than the C one (could be instructions, a header difference in the ELF structure, etc…).

And how many lines differ?

> cmp -l helloc hellocpp | wc -l
   376

376 lines are different between both binaries, which is 1.12% of the entire size of the cpp binary (not so much).

The issue with hyperfine #

hyperfine is a correct tool to make basic benchmarks but, as every software in the market, its performance and results depend of the conditions during the tests. To demonstrate this, I launched hyperfine 5000 times for the same C program. While hyperfine was running the C program, I opened my text editor and began to write this article, knowing that it should reduce drastically (all is relative) the performance running this simple C program.
For the C++ one, I let hyperfine running without touching the computer, and… the results are amazing, as C++ is now three times faster than C!

> hyperfine --runs 10000 ./helloc
   Benchmark 1: ./helloc
   Time (mean ± σ):      10.7 ms ±   6.0 ms    [User: 1.5 ms, System: 3.0 ms]
   Range (min … max):     0.0 ms … 193.3 ms    10000 runs

> hyperfine --runs 10000 ./hellocpp
   Benchmark 1: ./hellocpp
   Time (mean ± σ):       3.4 ms ±   6.8 ms    [User: 0.4 ms, System: 0.8 ms]
   Range (min … max):     0.0 ms … 424.8 ms    10000 runs

This is, of course, an example of “what you should absolutely avoid”, as the conditions to test the first and the second programs were not the same. And, if comparison conditions are not the same, then you can’t compare the results…

Also, this is to demonstrate why you should run multiple times your benchmarks, with no software running in the background (especially for very little programs like those).

Running the real tests #

Running the same both programs with the same conditions only ten times, this is the median of the observations:

C: 3.2ms, standard deviation of 0.8ms,
C++ (with c++17): 3.2ms, standard deviation of 0.9ms.

Same thing.

Conclusion #

The author stated in its blog post:

What we are testing by running these programs is the overhead due to the choice of programming language. […] One millisecond of overhead, if it is indeed correct, is a huge penalty.

This is wrong, as the author measured the overhead due to the choice of API used to print to the standard output, and not the overhead of running the same program compiled with a C compiler, and another with the C++ compiler.

Final Note: to finish, the author just demonstrated that iostream is slower than printf, and I think every good or curious C++ developer in the world already knew that…

The demoscene

Wed, 27 Jul 2022 20:25:00 +0200

Among all the computer subcultures that exist, the demoscene subculture is, without a doubt, the one that impresses me the most.
The demoscene is composed by demomakers, a worldwide network of very creative minds involved in the making of (non-commercial) demos, just for fun.

But was is a demo? A demo is a technical and/or aesthetic achievement made by demomakers - most of the time by groups of demomakers -, to show off their programming, visual and musical skills through an innovative computer program.
There are many demoscene productions: games, graphics, music, … all with an idea of solving a challenge, making a new big technical achievement, innovating, while having a lot fun.

There exists a nice file browser in scene.org for 2022, here, that you can browse to look for great and fun achievements, with the only goal of making something “great and fun”.

As an example, this is a demo of a low-fidelity modern cinematic on an Amiga 500, a 34 years old computer, called “Eon” by The Black Lotus:

The Amiga 500 was the most popular computer of the Amiga family, composed by a Motorola 68000 CPU (7,09 MHz PAL, or 7,14MHz NTSC), and 512 KBytes of RAM, which is 16384 times less RAM than actual modern computers. In the 80s, the Amiga offered a beautiful and colorful display, a better sound and a more advanced operating system than most of its competitors as standard.
The Amiga 500 for the demoscene is not an exception: the demomaking computers family that were commonly used were: the Commodore 64, the Atari ST and, of course, the Amiga family.

Composed generally between 3 and 8 people, demomakers masterize their tools, and have so much creative minds to push the boundaries of programming, graphics, and music composition.

Another demo from The Black Lotus shows, in 2006, a very impressive demo called “Starstruck” running on an (accelerated) Amiga 1200, competing with the best games of the time on recent hardware:

The demoscene contains multiple contests itself. The most known are:

the 4k contests: the demo must be self-contained in an executable of 4KBytes,
the 64k contests (or intros): the demo must be self-contained in an executable of 64KBytes,
the Demo contests: people express their creativity in building small executables (generally 4MBytes) with great graphics,
the Gfx contests: graphics contests,
and the Mod contests: for musicians, to express their creativity creating partitions based on new unique sounds.

About video games, a lot of newly created studios come from demoscenes like Starbreeze, Remedy, Techland, Guerilla Games, or Housemarque.

Links #

To know if there is a demoparty near your location: https://www.demoparty.net,
A web forum that lists great demos: https://www.pouet.net.

Old games on m1 macs, natively

Wed, 09 Mar 2022 09:30:00 +0200

Apple Silicon chips on the mac changed everything… except the gaming industry (yet).
Even though M1 chips (M1, , M1 Pro, and M1 Max) have been sold a lot (+25% this January compared to January 2021, which had already broke all the records for mac sales), a very few companies updated their actual games to run on M1 chips.

Even if a few solutions exist to run windows games on the M1 mac, running a windows VM using Parallels, or translating at runtime all the API calls via Crossover, those products are expensive to run - in terms of both money and computer resources -, still labeled as “experimental”, and there is a high risk to not run all your games.

I recently heard about a website that lists old games ports (think about a port as a “translation” of a game from a given architecture [x86, x86_64, powerpc, …] to another) for mac, including arm as a target, and finally found the website: https://macsourceports.com.

The home page of Mac Source Ports website

Mac Source Ports games are universal, to run in both x86_64 architecture (basically an intel chip) and arm architecture (M1 chip).
Those ports are signed and notarized, so no issue running them on your mac and no awful pop-up asking to push the application into the bin.

But the ports contain only the technical work about the game, which not include the data. So, you will have to buy the game first (GOG is a great platform to buy DRM-free old games), extract the data from the official executables, and drag-and-drop the data files in the app you downloaded from Mac Source Ports.
A software is freely available to extract the data from an executable here, signed and notarized (universal binary).

There is a great list of old good games to play again and again and again:

System Shock,
Return to Castle Wolfenstein,
all Quake games and all old Doom games,
Star Wars Jedi Knight: Dark Forces II
RollerCoaster Tycoon 2,
Diablo,
etc.

The website lists all known ports, and do not hesitate to contact the author of the website directly if you know a port that can be used in both x86_64 and arm architectures.

As stated by the author in the FAQ section (“Why don’t you have Game X?”), if the source code of the game is not available the port can’t be done. That is the only drawback of a port work. Fortunately there are still some companies all around the world that release the source code of good old games (excluding the game data) to work on the ports, like ID software.

The full list of games is available: https://macsourceports.com/games, and the source code of some ports is available on github: https://github.com/MacSourcePorts.

The case of OpenGL, in C++, on m1 mac

Mon, 07 Mar 2022 16:45:00 +0200

Since a long time now I was interested in learning computer graphics and “do stuff” with computer graphics APIs.
I began to work on a very simple Game engine in Swift / Metal last year but I began to switch to a Windows machine a few months ago, and Swift / Metal is not compatible with Windows (and will never be I think).

Here, I wanted to go further in exploring OpenGL and / or Vulkan, for multi-platform GL.
I choosed OpenGL because I am prototyping with GameMaker Studio 2, and writing shaders for it.
Shaders in GMS2 use [GLSL](https://www.khronos.org/opengl/wiki/Core_Language_(GLSL), the OpenGL Shading Language, for OpenGL.

I am using modern C++ (C++17) for this project, mainly because I really like modern C++.

The goal of this (first?) part is to draw the famous RGB triangle, on the m1 mac, using C++17.

Why not Metal with C++ ? #

Even if Apple Metal is great (actually, the API is pretty awesome), it is unfortunately specific to Apple products, and I wanted to work on something with platforms that do not include only Apple.
Also, Metal is still a pretty young API and the documentation is not quite right sometimes…

And why not Vulkan? #

I am not opposed to Vulkan at all: performances are great, great ideas behind, and multiplatforms. However, Vulkan is still young and is way more complicated to learn than learning OpenGL.
For this project I wanted to do simple graphics computing before, and it seems OpenGL is still supported in a large range of operating systems (despite the fact that Apple deprecated the version >= 4.2 a few years ago to introduce Metal).

Pre-requisites #

Compile and install GLFW #

In this project, we will use GLFW.

GLFW is an Open Source API for creating windows, contexts and surfaces, receiving input and events, for OpenGL, OpenGL ES (outch…), and Vulkan on desktop. What does it means it that GLFW is a helper library that starts the OpenGL “context” (a running copy of OpenGL, tied to a window) for us, and talks to a lot of platforms / operating systems in the same way.
The current version of GLFW, writing this article, is the third: GLFW3.

In homebrew, GLFW3 is not universal (so, not compatible with m1 macs).
An issue on Github is still opened about this: https://github.com/patriciogonzalezvivo/glslViewer/issues/219.

Compile it yourself #

To use it, you will need to compile it yourself.
For this, you will need to install cmake: brew install cmake.

Once cmake has been installed, you can install your arm64 compatible version of glfw3:

# Remove GLFW
brew uninstall glfw

# Build GLFW from source
git clone https://github.com/glfw/glfw.git && \
cd glfw && \
cmake -DCMAKE_OSX_ARCHITECTURES=arm64 . && \
make && \
sudo make install

You can tweak the make install statement in order to install the libraries in your prefered space.
I choosed here the default location, which is /usr/local/lib.

Pass the architecture via homebrew #

Another way to install it is to install it directly from source via homebrew:

brew install --from-source glfw3

but please to check first that brew does not link by default to rosetta2 (and then produce x86_64 binaries, which are not compatible with arm64).

The code #

In a file named test_opengl.cpp:

#ifdef __APPLE__
// Defined before OpenGL and GLUT includes to avoid deprecation messages
#define GL_SILENCE_DEPRECATION
#include <GLFW/glfw3.h>
#endif

#include <iostream>

int main(int argc, char **argv)
{
    if (!glfwInit()) return -1;

    std::cout << "GLFW lib has been initialized..." << std::endl;

    return 0;
}

The line to compile the project:

g++ helloworld.cpp -o test_opengl -std=c++17 -framework Cocoa -framework OpenGL -framework IOKit -lglfw3

Exciting test_opengl you should get a Initialized... message on your stdout, and a quick open/closed window.
Initialisation worked, yay!

Also, we force the usage of modern C++, here c++17 specs.

About GL_SILENCE_DEPRECATION #

Apple deprecated OpenGL since macOS Catalina, as Apple wanted to force their own tech: Metal.
OpenGL has been designed 25 years ago and lacks a lot of features now (and does not match right the modern hardware architecture: GPU pipeline has changed, unsupported multithreaded operation, etc.).
So, compiling the project without this flag will show a ton of warnings that OpenGL is now deprecated on Apple devices / platforms.

Defining GL_SILENCE_DEPRECATION allows us to remove a ton of this kind of flags and focus on real problems.

To know more about why Apple deprecated OpenGL (and introduced Metal), please to take a look at this talk from WWDC2018.

The case of including the .frameworks everywhere… #

When checking the online documentation of GLFW3, it is required to include official Apple frameworks for Cocoa, OpenGL, and IOKit:

If you still wish to build manually, you need to add the required frameworks and libraries to your command-line yourself using the -l and -framework switches.

A more complex example #

Now, let’s create a window, and wait for the user to close it using his prefered signal, or by pressing the Escape key:

#ifdef __APPLE__
// Defined before OpenGL and GLUT includes to avoid deprecation messages
#define GL_SILENCE_DEPRECATION
#include <GLFW/glfw3.h>
#endif

#include <iostream>

const size_t WIDTH = 640;
const size_t HEIGHT = 480;
const char* WINDOW_NAME = "Test OpenGL";

/*
 * Callback to handle the "close window" event, once the user pressed the Escape key.
 */
static void quit_callback(GLFWwindow *window, int key, int scancode, int action, int _mods)
{
    if (key == GLFW_KEY_ESCAPE && action == GLFW_PRESS)
        glfwSetWindowShouldClose(window, GLFW_TRUE);
}

int main(void)
{
    GLFWwindow *window;

    if (!glfwInit()) {
        std::cerr << "ERROR: could not start GLFW3" << std::endl;
        return -1; // Initialize the lib
    }

    // Minimum target is OpenGL 4.1
    glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 4);
    glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 1);
    window = glfwCreateWindow(HEIGHT, WIDTH, WINDOW_NAME, NULL, NULL);
    if (!window)
    {
        std::cerr << "ERROR: could not open window with GLFW3" << std::endl;
        glfwTerminate();
        return -1;
    }
    // Close the window as soon as the Escape key has been pressed
    glfwSetKeyCallback(window, quit_callback);
    // Makes the window context current
    glfwMakeContextCurrent(window);

    const GLubyte* renderer = glGetString(GL_RENDERER);
    const GLubyte* version = glGetString(GL_VERSION);
    std::cout << "Renderer: " << renderer << std::endl;
    std::cout << "OpenGL version supported: " << version << std::endl;

    // Now we have a current OpenGL context, we can use OpenGL normally
    while (!glfwWindowShouldClose(window))
    {
        // Render
        glClear(GL_COLOR_BUFFER_BIT);
        // Swap front and back buffers
        glfwSwapBuffers(window);
        // Poll for and process events
        glfwPollEvents();
    }

    // ... here, the user closed the window
    glfwTerminate();
    return 0;
}

On my mac, it runs flawlessly and write on the standard output:

Renderer: Apple M1
OpenGL version supported: 4.1 Metal - 76.3

Improve the build system #

In order to avoid copy/pasting complex command lines to build an executable, but also to improve our build system with system conditions (like if the OS is Microsoft Windows, if macOS, if the kernel is linux, etc…), we will need something more robust.
For this, we will create our own CMakeFiles.txt file, which contains all the rules to build our own executable.

On macOS, you will need to install cmake (and make) using brew: brew install cmake make.

cmake_minimum_required(VERSION 3.22 FATAL_ERROR)

project(myproject VERSION 1.0)

add_definitions(-std=c++17)
set(CXX_FLAGS "-Wall")
set(CMAKE_CXX_FLAGS, "${CXX_FLAGS}")
set(CMAKE_BUILD_TYPE Debug)

add_executable(myapp main.cpp)

find_package(glfw3 3.4 REQUIRED)
find_package(OpenGL REQUIRED)

target_include_directories(myproject PUBLIC ${OPENGL_INCLUDE_DIR})

target_link_libraries(myproject "-framework Cocoa")
target_link_libraries(myproject "-framework OpenGL")
target_link_libraries(myproject "-framework IOKit")
target_link_libraries(myproject glfw ${OPENGL_gl_LIBRARY})

Now, cmake . && make will produce a binary called myapp, which displays the same black window than before.
Nice!

This setup will simplify a lot of things later, especially for conditional builds and testing (because, yes, we can execute some tests using cmake).

The shaders #

I will use specific features of C++17, like optional, in order to improve the code and avoid to throw errors / exceptions everywhere…

/* shader_utils.h */
#ifndef _SHADER_UTILS_H
#define _SHADER_UTILS_H

#include <optional>

namespace ShaderUtils
{

    enum Type
    {
        FRAGMENT_SHADER_TYPE,
        VERTEX_SHADER_TYPE,
    };

    struct Program
    {

    private:
        /**
         * @brief The vertex shader ID, as an optional
         */
        std::optional<unsigned int> vertexShader = std::nullopt;

        /**
         * @brief The fragment shader ID, as an optional
         */
        std::optional<unsigned int> fragmentShader = std::nullopt;

        /**
         * @brief The GPU program ID (or shader ID), as an optional
         */
        std::optional<unsigned int> program = std::nullopt;

        /**
         * @brief Stores if the shader has been registered or not
         */
        bool registered = false;

    public:
        /**
         * @brief Constructor
         */
        Program();

        /**
         * @brief Destructor
         */
        ~Program();

        /**
         * @brief Register a shader
         *
         * @param shader_type The type: fragment or vertex
         * @param shader_source The source code as a string
         * @return true The shader has been successfully registered
         * @return false The shader has not been registered - error is logged
         */
        bool registerShader(const Type shader_type, const char *shader_source);

        /**
         * @brief Register the GPU program (or shader), after compilation
         * of the fragment and vertex shaders.
         *
         * @return true The shader has been successfully registered
         * @return false The shader has not been successfully registered - error is logged
         */
        bool registerProgram();

        /**
         * @brief Returns the GPU program ID object, as optional
         *
         * @return std::optional<unsigned int>
         */
        std::optional<unsigned int> getProgram() const;

        /**
         * @brief Returns if the GPU program object has been registered or not
         */
        bool programIsRegistered() const;
    };

}

#endif /* SHADER_UTILS_H */

For the implementation:

/* shader_utils.cpp */
#ifdef __APPLE__
/* Defined before OpenGL and GLUT includes to avoid deprecation messages */
#define GL_SILENCE_DEPRECATION
#include <GLFW/glfw3.h>
#endif

#include "logs.h" // Simple macros for DEBUG, INFO, ... messages
#include "shader_utils.h"
#include <optional>
#include <iostream>

ShaderUtils::Program::Program() {}

ShaderUtils::Program::~Program()
{
    if (vertexShader.has_value())
        glDeleteShader(vertexShader.value());
    if (vertexShader.has_value())
        glDeleteShader(fragmentShader.value());
    if (registered && program.has_value())
        glDeleteProgram(program.value());
}


bool ShaderUtils::Program::registerShader(const ShaderUtils::Type shader_type, const char *shader_source)
{
    int success = {};
    char errorMessage[1024] = {};

    bool isFragmentShader = shader_type == ShaderUtils::Type::FRAGMENT_SHADER_TYPE;

    auto real_shader_type = !isFragmentShader ? GL_VERTEX_SHADER : GL_FRAGMENT_SHADER;

    auto shader = glCreateShader(real_shader_type);
    // Now, pass the shaders
    glShaderSource(shader, 1, &shader_source, NULL);
    // And now, compile them
    glCompileShader(shader);

    glGetShaderiv(shader, GL_COMPILE_STATUS, &success);
    if (!success)
    {
        glGetShaderInfoLog(shader, 1024, NULL, errorMessage);
        if (isFragmentShader) { error("Fragment shader compilation error : " << errorMessage); }
        else { error("Vertex shader compilation error : " << errorMessage); }

        return false;
    }

    if (isFragmentShader) { fragmentShader = shader; }
    else { vertexShader = shader; }
    
    return true;
}

bool ShaderUtils::Program::registerProgram()
{
    if (registered)
    {
        error("program is already registered");
        return false;
    }
    if (!vertexShader.has_value() || !fragmentShader.has_value())
    {
        error("cannot compile program without vertex and fragment shaders");
        return false;
    }
    int success = {};
    char errorMessage[1024] = {};
    const unsigned int vertexShaderValue = vertexShader.value();
    const unsigned int fragmentShaderValue = fragmentShader.value();

    program = glCreateProgram();
    const unsigned int programValue = program.value();

    glAttachShader(programValue, vertexShaderValue);
    glAttachShader(programValue, fragmentShaderValue);
    glLinkProgram(programValue);

    glGetProgramiv(programValue, GL_LINK_STATUS, &success);
    if (!success)
    {
        glGetProgramInfoLog(programValue, 1024, NULL, errorMessage);
        error("Shader linking error: " << errorMessage);
        return false;
    }

    // We can now delete our vertex and fragment shaders
    glDeleteShader(vertexShaderValue);
    glDeleteShader(fragmentShaderValue);
    glUseProgram(programValue);
    registered = true;

    return true;
}

std::optional<unsigned int> ShaderUtils::Program::getProgram() const
{
    return program;
}

bool ShaderUtils::Program::programIsRegistered() const
{
    return registered;
}

Using those helpers, our shaders registration take a few lines of code:

// in main.cpp, just before the `while` loop
    ...
    auto shader_utils = ShaderUtils::Program{};

    if (!shader_utils.registerShader(ShaderUtils::Type::VERTEX_SHADER_TYPE, basicVertexShaderSource))
    {
        glfwTerminate();
        return -1;
    }

    if (!shader_utils.registerShader(ShaderUtils::Type::FRAGMENT_SHADER_TYPE, basicFragmentShaderSource))
    {
        glfwTerminate();
        return -1;
    }

    if (!shader_utils.registerProgram())
    {
        glfwTerminate();
        return -1;
    }
    ...

As our current target is the basic RGB triangle, our shaders are very simple.

For the vertex shader source:

#version 410 core
layout (location = 0) in vec3 vertexPosition;
layout (location = 1) in vec3 vertexColor;
layout (location = 0) out vec3 fragmentColor;

void main() {
    gl_Position = vec4(vertexPosition, 1.0); // `w` is used for perspective
    fragmentColor = vertexColor;
}

, and the fragment shader source:

#version 410 core
layout (location = 0) in vec3 fragmentColor;
out vec4 finalColor;

void main() {
    finalColor = vec4(fragmentColor, 1.0);
}

For this, you can easily write down those shaders in dedicated files, and load them interactively via the command line.
For this exercise, I am writing those shaders down into two dedicated strings, and use them non-interactively:

    ...
    const char *basicVertexShaderSource = "#version 410 core\n"
                                        "layout (location = 0) in vec3 vertexPosition;\n"
                                        "layout (location = 1) in vec3 vertexColor;\n"
                                        "layout (location = 0) out vec3 fragmentColor;\n"
                                        "void main()\n"
                                        "{\n"
                                        "    gl_Position = vec4(vertexPosition, 1.0);\n" // `w` is used for perspective
                                        "    fragmentColor = vertexColor;\n"
                                        "}\0";

    const char *basicFragmentShaderSource = "#version 410 core\n"
                                            "layout (location = 0) in vec3 fragmentColor;\n"
                                            "out vec4 finalColor;\n"
                                            "void main()\n"
                                            "{\n"
                                            "    finalColor = vec4(fragmentColor, 1.0);\n"
                                            "}\0";
    ...

A story about vertices… #

We have our main program, we have our shaders… now, let’s draw the famous triangle!

The array will contains 6 elements, with the following labels x, y, z, r, g, b.
The offset for a position will be 0, and the offset for a color will be 3.

I wrote down the basic specification in a specific library component:

// in maths_utils.h
#ifndef _MATHS_UTILS_H
#define _MATHS_UTILS_H

namespace MathsUtils
{

    const unsigned int VERTEX_ELEMENTS_NB = 6;

    /**
     * @brief Reassemble all elements of a vertex in a dedicated type
     * Contains, in the following order: x, y, z (position, in 3D), r, g, b (RGB colors)
     */
    typedef float vertex[VERTEX_ELEMENTS_NB];

    ... // Some uninteresting functions for this exercise

    /**
     * @brief Returns the number of individual vertex arrays inside a vertices array
     *
     * @param vertices - an array of vertex
     * @return The number of the individual vertex arrays
     */
    const unsigned int getNbVertex(const vertex vertices[]);

    /**
     * @brief Sums and returns the number of individual elements stored in the vertices array
     *
     * @param vertices - an array of vertex
     * @return The sum of all individual elements stored in the vertices array
     */
    const unsigned int getNbElements(const vertex vertices[]);
}

#endif /* _MATHS_UTILS_H */

The implementation is straightforward:

// in maths_utils.cpp
#include "maths_utils.h"

const unsigned int MathsUtils::getNbVertex(const MathsUtils::vertex vertices[])
{
    return (unsigned int)(sizeof(*vertices) / MathsUtils::VERTEX_ELEMENTS_NB);
}

const unsigned int MathsUtils::getNbElements(const MathsUtils::vertex vertices[])
{
    return MathsUtils::getNbVertex(vertices) * VERTEX_ELEMENTS_NB;
}

So, we end with the following code:

    ...
    // Specify position attribute - 0 as offset
    glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, MathsUtils::VERTEX_ELEMENTS_NB * sizeof(float), (GLvoid *)0);
    glEnableVertexAttribArray(0);

    // Specify color attribute - 3 as offset
    glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, MathsUtils::VERTEX_ELEMENTS_NB * sizeof(float), (GLvoid *)(3 * sizeof(float)));
    glEnableVertexAttribArray(1);

    glBindBuffer(GL_ARRAY_BUFFER, 0);
    ...

Now, we have to explicit say that:

we want to use the GPU program,
bind the vertex array,
and draw the triangle.

In the while loop, we could just write:

    ...
    while (!glfwWindowShouldClose(window))
    {
        // Render
        glClearColor(0.5, 0.5, 0.5, 1.0);
        glClear(GL_COLOR_BUFFER_BIT);
        glUseProgram(shader_utils.getProgram().value());
        glBindVertexArray(VAO);
        glDrawArrays(GL_TRIANGLES, 0, 3);
        // Poll for and process events
        glfwPollEvents();
        // Swap front and back buffers
        glfwSwapBuffers(window);
    }
    ...

and, do not forget the delete the buffer right after:

    ...
    glDeleteBuffers(1, &VBO);
    glDeleteVertexArrays(1, &VAO);
    glfwTerminate();
    return 0;
}

Then, hit cmake . && make, launch the program and… tadaaaa!

An RGB triangle, built with OpenGL 4.1 on a macbook air m1

The full code is available at: https://github.com/k0pernicus/opengl-explorer, commit 0e311828fb34b272809432254307e8561e951335:

git clone https://github.com/k0pernicus/opengl-explorer
cd opengl-explorer
git checkout -b rgb_triangle 0e311828fb34b272809432254307e8561e951335

The m1 mac is an awesome machine, but lacks of continuity for OpenGL (especially as OpenGL 4.5 >= introduces a lot of new exciting features that make the code less verbose).
As OpenGL 4.1 is still robust and, as Apple did not completely removed OpenGL from the stack, it is still interesting to draw things with OpenGL.
However Vulkan may be interesting at this point for further / longer multiplatform compatibility (despites its complexity).

I don’t know if I will continue on this kind of exercises, and go further on trasnformations for example… but do not hesitate to give me some feedbacks (by emails) if you want to know more about X or Y.

macOS hidden features

Sat, 20 Mar 2021 12:00:00 +0200

I just discovered a very good dotfiles that contains a lot of hidden features in macOS, or to manage you system through the console.
Please check it out here if you are interested in. Thanks to Mathias Bynens for this!

Conditional compilation and optin dependencies with Rust 'features'

Fri, 12 Mar 2021 00:45:00 +0200

I am a long time Rust user/fan - since 2014 - and I still have some troubles to follow the community in terms of RFCs, or accepted features to be included in an upcoming version of the language. Most of the time, checking for the new features, I have the feeling that I don’t need to use them for my current & past projects… like a purist C / C++ developer who uses the strict minimum of the features to make something great.
And sometimes I am wrong.

I am working on a game engine since a while now - a Wolfenstein3D-like engine, with the goal to run Wolfenstein 3D on it and develop new mods for it “easily”.
I had to postpone the work since a while now and I recently rewrote (almost) everything from scratch after dumb mistakes, as I did not understood how a game engine is working, and more and more difficulties to introduce some new features in the project… like cross-platforms compatibility.
To introduce this feature, we need to make feasible the usage of multiple OS specific low-level libraries (sound, graphics, etc…), which means different API usage, different API implementation, most of the time incompatible with each other… in the same common piece of code.
So, we need an API, or interface, that can communicate with different backends (let’s call them packages), based on the operating system platform - so, chosen before / during the compilation of the engine.

Rust proposes since the beginning some specific features for conditional compilation options (like the cfg attributes), but since the 1.18 they introduced a more powerful feature called features.

The repository that contains the demonstration is available here.

The problem #

I have an awesome game called “guess a number”, a textual game written fully in English, and I want to make it accessible for the International: French guys, Spanish, Italian, Greek, etc…
More important, I want this game to be translated by anyone, based on the original English texts only…

So solution to this could be to make my game public, and let people contribute in including their own i18n Rust module, write a menu to let the user choose the language, etc…
But I don’t like this solution is that my game is very small (90 lines of code, including comments and many many blank lines), and I don’t want to compile the game with all the languages into it, or let the user choose the language on runtime.
I want the game to be included with the user’s prefered language only: included at compile time.

This is where Rust features comes in.

A brief introduction #

Rust features allows to include, at compile time, packages as optional dependencies, or a set of other features.
And this is perfect for our usage, because I want to propose as many builds as available translations (including English).

To do this, in our example, we need first to declare our different linguistic packages (or features):

[dependencies.english-linguistic-pkg]
version = "0.1.0"
optional = true
default-features = false
path = "english-linguistic-pkg"

[dependencies.french-linguistic-pkg]
version = "0.1.0"
optional = true
default-features = false
path = "french-linguistic-pkg"

[features]
english = ["english-linguistic-pkg"]
french = ["french-linguistic-pkg"]

A feature is a dependency - so you need to declare it anyway in the Cargo.toml file, even if you don’t want to use it by default in your final build. Here, we define two different dependencies: english-linguistic-pkg for English, and french-linguistic-pkg for French. We need to declare those as features, in the [features] section.
For simplicity, we create an alias for each of those: english and french, in order to simplify the declaration of which language package to use.
As an example, you could use

cargo build --feature english

instead of

cargo build --features english-linguistic-pkg

Also, I included both dependencies in the game crate. Of course, those packages could be available in a dedicated repository, and fetch directly using an URL…

A benefit of using features is to use configuration conditional check to use the choosen package in the same namespace:

// in main.rs
#[cfg(feature = "english")]
pub use english_linguistic_pkg as i18n;
#[cfg(feature = "french")]
pub use french_linguistic_pkg as i18n;

Using configuration conditional checks, i18n is a namespace that can be linked to english_linguistic_pkg or french_linguistic_pkg. This means, obviously, that both english_linguistic_pkg and french_linguistic_pkg must share the exact same contracts.

So, print_message(i18n::SAY_HELLO) can print “hello” if the English package has been selected, or “bonjour” if the French one has been chosen instead.

One namespace to rule them all!

Let’s build! #

Ok, it’s time to build our game!

Running cargo build, the panics:

error[E0433]: failed to resolve: use of undeclared crate or module `i18n`
  --> src/main.rs:46:27
   |
46 |             print_message(i18n::INVALID_INPUT, None);
   |                           ^^^^ use of undeclared crate or module `i18n`

error[E0433]: failed to resolve: use of undeclared crate or module `i18n`
  --> src/main.rs:66:23
   |
66 |         print_message(i18n::GUESS_A_NUMBER, Some(":"));
   |                       ^^^^ use of undeclared crate or module `i18n`

error[E0433]: failed to resolve: use of undeclared crate or module `i18n`
  --> src/main.rs:69:48
   |
69 |             Ordering::Equal => { print_message(i18n::PREDICTION_WIN, None); break; },
   |                                                ^^^^ use of undeclared crate or module `i18n`
...

Oops!

i18n has not been found because… we forgot to link the linguistic package we want to build with!

Using the following command, we give the information to cargo that we want to include the English package with:

> cargo build --features english
   Compiling rust-features-example v0.1.0 (/Users/antonin/Devel/rust-features-example)
    Finished dev [unoptimized + debuginfo] target(s) in 0.69s

Wouhou, it works!

How about the French one?

> cargo build --features french
   Compiling rust-features-example v0.1.0 (/Users/antonin/Devel/rust-features-example)
    Finished dev [unoptimized + debuginfo] target(s) in 0.67s

The ‘default’ features key #

Now, let’s come back to the first error: use of undeclared crate or module i18n.

It is possible to solve this issue setting a default package to use. We can do that configuring the default key to the linguistic package we want to use by default:

[features]
...
default = ["english"]

Let’s try to build the project, without specifying explicitly any package:

cargo build
   Compiling rust-features-example v0.1.0 (/Users/antonin/Devel/rust-features-example)
    Finished dev [unoptimized + debuginfo] target(s) in 0.29s

Yes! It finally works!
How about the French one now?

error[E0252]: the name `i18n` is defined multiple times
 --> src/main.rs:4:9
  |
2 | pub use english_linguistic_pkg as i18n;
  |         ------------------------------ previous import of the module `i18n` here
3 | #[cfg(feature = "french")]
4 | pub use french_linguistic_pkg as i18n;
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `i18n` reimported here
  |
  = note: `i18n` must be defined only once in the type namespace of this module
help: you can use `as` to change the binding name of the import
  |
4 | pub use french_linguistic_pkg as other_i18n;
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Outch! This is rude…

Looking at the error message, we understand that both English and French packages may be included in the final build. The solution is simple, as we just have to set to disable the default feature(s):

cargo run --no-default-features --features french

After some thoughts, it comes to my mind that putting English as a default feature is not intuitive, especially if you will have to deal with cargo to build binaries with other linguistic packages…

Advantages and disadvantages #

As always in every language, a feature always comes with advantages and disadvantages…

I can notice several advantages here:

no multiple useless packages inside the binary, as used in compile time, which can reduce the binary size,
really easy to plug a new translation: just update the Cargo.toml file, and include a conditional compilation option to use it in the project (in the main.rs, or lib.rs if you are working on a Rust library).

About the disadvantages, the developer has to produce as many binaries as available translations, and that you will have to maintain multiple packages… also, one modification in your English package and you have to ask to all to update their translation packages.

Note: I would say that this feature miss some real examples in the rust doc, and sometimes can be difficult to understand and to use for developers.

References: #

https://doc.rust-lang.org/cargo/reference/features.html

Do you trust your FOSS?

Sat, 02 Jan 2021 16:07:00 +0200

People tend to believe that free and open source softwares (FOSS) are way more trustable than proprietary softwares… and I want to believe this idea.

Unfortunately, the idea behind this blog post is that it is not because a software has a free or open source licence that someone already checked and validated its full source code (including the dependencies)!
As an example, how many times did you put a star on a github project without checking the code at 100%? Doing this, you can unfortunately promote a vulnerable library, which could be shared to your github followers who can believe that, as you trusted this library enough to star it is obviously trustable…

This is a typical chain of trust problem.

The first level of trust #

To enable the confidence to a software, you have to:

trust the developer,
check and validate the source code of the project,
check and validate the dependencies of the project, and the dependencies of the dependencies, and so on…

This is already a big measure to be sure that the software you are installing on your computer can be trusted… as a minimum level!
Especially if you want to install a big FOSS project like emacs… or even bigger: chromium or the linux kernel!

Note: If you don’t belive me about trusting your dependencies, please check this NodeJS module CVE from 2020, which has been used seven million times.

Let’s imagine here that you checked everything, and that everything is fine… The next step is to install the software on your machine.

The second level of trust #

The simplest solution to install a sofware on your system is… to use a package manager.
Using this, you will have to:

trust that the package manager is installing the right package in your system (comparing the hash for example… if the hash function does not produce hash collisions!),
check and validate that the software, available in your package manager server(s), corresponds to the build of the source code you checked right before,
check and validate that the maintainer of this packet is also the developer and, if not, trust or not the maintainer.

Outch… this is becoming a more complex issue as you have to trust a lot of newcomers now…
So, let’s do like all Gentoo users: compile the software, wait for a few minutes / hours / days (if you want to install Chromium for example…) and install it yourself!

But the issue remains the same as the question now is: “can you fully trust your compiler?” ;-)

Conclusion #

People tend to think that a software is trustable (and secure) because its licence is GPL or MIT, which tends to be wrong, especially since a basic CLI can be a weird gigantic pile of dependencies…

Don’t get me wrong: I don’t say that free and open source softwares are bad, and I don’t believe to this idea! On the contrary, I do think at 200% that FOSS are absolutely a necessity for developers and end-users.
I am grateful for FOSS and all people that work on their spare time to develop great tools, free to use, free to modify, and free to distribute. Unfortunately, some persons are taking advantage of this wrong “trust situation” to introduce widely new flaws and vulnerabilities…

The battle of trusting your softwares is unfortunately not yet won.

Anyway, thanks Flash...

Thu, 31 Dec 2020 21:20:00 +0100

This is truly the end of some good indie games… and a security threat.

Even with the effort to preserve flash projects, Flash on it's own was a stepping stone for a lot of people, And it paved way for content creation on the internet pre-youtube days.

Thanks Flash pic.twitter.com/iBRMvHHAIT
— FABINO (@KinoFabino) December 31, 2020

Know your threat model

Thu, 31 Dec 2020 18:00:00 +0100

Last week, a very good blog post has been published about how Linux by default is “not a secure operating system”… (kernel actually).
I agree with most of the ideas and methods explained in it, but this article has a big issue: the target is absolutely not defined. Unfortunately, this has been posted on hackernews (oops) this morning (iich) and, as expected (ouuh), it has created a lot of comments and criticisms (oh my…).

After a first read, you can think that Linux is absolutely not a good / decent kernel, which is absolutely false! Linux is an amazing open-source kernel, built by thousands of amazing contributors all over the world, making a lot of efforts to make the kernel the most generalistic (it runs on various architectures), fast, and secure as possible.
However, if you think that Linux is a secure kernel, you are wrong, especially because of the first rule of computer security: absolutely no system is secure.

We all know that the most common GNU/Linux users are nerds: people who love computers, test multiple (new) operating systems or softwares, and hack most of the time… or just people who think that Linux is “cool” and install it on their PC just “to feel like an’hacker, y’a know” (:facepalm:)…

When reading a blog post like this, which can be summarized as “a GNU/Linux distro is not secure by default”, it resonates mostly for paranoid people and people who are scared about their “privacy”…

Note: don’t forget that “security” and “privacy” are not synonyms, and are not necessarily connected together. You can have a very secure OS where developers could fix all the bugs fast based on all your logs, which can be a privacy nightmare for you.

But first, I will explain the three different categories of persons who are using a GNU/Linux distribution today, and their specific threat model:

the students, the isolated nerds, the “random cool guys” in a small town somewhere or some random programmers all over the world, the /r/unixporn participants, etc. : you are not the target of this article.
Sorry to tell, but nobody is interested in knowing which kind of tools or vim themes you are using, what you ordered for your family recently at Christmas, or which porn’s categories you are interested in Pornhub. Even Google, Facebook, or the NSA does not really care about you (except if you really did something unusual…).
You are just a number, an ID inside a database column. Nothing more.
the company’s members, especially employees: people who want a minimum of security to avoid targeted hacks, which are not making people lives in danger.
Depending on what / where you are working, you can be a potential target, and you can be interested in this article. As always, if you work in a company, be careful about what you are clicking on, but mainly on social engineering techniques: sometimes, some people just need to make a phone call to get all the informations they want…
If you are in this specific category and don’t know how to start, please ask some advices to your IT department, or to do that for you.
finally, the persons who are deeply concerned about high security and privacy levels, like the journalists, (h)activists, whistleblowers, computer scientists who work in security and / or on critical systems, big companies like banks, and security agencies…
People whose lives (or other persons lives) may be in danger.
For those, I think this blog article can be a good guide to make their life a bit less “paranoid”, and reduce at the same time the surface of attack of their device(s).
For those persons, I include that some good tools like Qubes or Tor could be a game changer for them, in their daily life.

Comic from xkcd, ‘Authorization’ (https://xkcd.com/1200/)

Whether you are part of the 1st, 2nd or 3rd category, even if you don’t use a GNU/Linux distribution but another OS like Windows or macOS, the following (basic) rules can help you to manage your security:

encrypt your data - if you are tweaking your kernel but did not thought about encrypting your data… oh boy…
set a firewall - put it to basic (no ssh by default, accept all that goes out),
use a password manager - some great tools like Bitwarden are open source and can create strong passwords for your online accounts… but please to create a strong password to open your password wallet!
do not click on everything, everywhere, and be careful about what you install on your kernel (just because “RGB IS SO COOL ON MY KEYBOARD MAN!” does not means that you have to install a specific driver in your kernel space :/).

AlphaFold 2: a new AI achievement

Thu, 03 Dec 2020 23:22:00 +0200

The last 30th of November, DeepMind published on their website an article about AlphaFold 2, an Artificial Intelligence that solves with 92.4 GDT, on simple protein structure, a 50 years old grand challenge: the protein folding problem.

DeepMind released the first version of AlphaFold in 2018.
This first version achieved a score of 58 in the Global Distance Test (GDT) at the Critical Assessment of Structure Prediction (CASP) competitions, which was the highest score at that time.
For this occasion, an article has been published on Nature, and the source code publicly available on Github. With version 2, DeepMind’s dedicated team performed a median score of 92.4 GDT overall across all targets on the same competition dataset, and a median score of 87.0 GDT for the very hardest protein targets.
Almost 30 more GDT in two years, a huge improvement between those two years.

In this blog post, I will decompose this breakthrough into several parts: talk about the protein folding problem, the competition and the achievements before AlphaFold, and very quickly about both AlphaFold 1 and 2.

Protein? Folding? What? #

A protein is a macromolecule (= big molecule) that performs a vast array of functions within organisms, from transporting molecules to DNA replication[1].
In short: proteins are essential to life.
Like every other chain of molecules - a protein is composed by amino acids - two proteins are different by their content, or composition.
However, something is specific and unique to a protein: its 3D structure!

Indeed, a protein with the same amino acids than a second one have two different functions if their 3D structure (or their physical shape in space) vary, as a shape can deliver, or hide, an activation section for every other molecule around in order to interact specifically with.
Even if people are still fighting again on asking ourselves if we can simplify the sequence similarity measure between two proteins as a structural similarity, we will assume that the 3D structure of a protein determines its own function within an organism.

The structure of a protein is, almost all the time, very complex to understand, as it depends of four different levels of complexity: hydrophobic interactions, hydrogen bonds, the Van der Waals forces between nearby amino acids, and di-sulphide connections between cysteine molecules.

To test all the possible folds of a protein using brute force methods is not possible then, as, based on the Levinthal’s paradox, it could be more than 10^143 ways to fold a single protein, which is way more than playing chess (10^120) but less than all the possible moves in the game of Go (10^360).
Obviously, misfolding a protein has way more implications than making a wrong move in a Go game…

Ribbon diagram of the 3D structure of hemoglobin - credits to Azom.com[2]

Unfortunately, a protein can be modified, or misfold, and lead to strong issues in the organism…
Indeed, an accumulation of misfolded proteins - proteins that contain at least one structure modifications - can lead one or multiple disease(s), sometimes neurodegenerative like Alzheimer’s disease, or Huntington’s disease.

So, reducing the problem of identifying a protein by its amino-acids sequence can help the scientists to design a specific protein for a drug, or to understand how a modification, or mutation, in a protein can cause a specific disease.

Competitions, researches and results #

Every two years a community-wide worldwide experiment for protein structure prediction, called CASP, is launching global competitions to review the recent scientific researches and results on protein folding. This review is done by computing the GDT, or Global Distance Test using a complex dataset of 200 million of proteins.
A GDT is a measure of similarity between two protein structures with identical amino acid sequences and different shapes - in short, a prediction accuracy for proteins shape.
Claimed by the Science community, the higher total score of GDTs, the better a given model is in comparison to reference structure.

The CASP competitions for protein folding are performed since 1994, and new algorithms and results are evaluated by this community every two years.

CASP results, 30th November of 2020 - credits to DeepMind[3]

The AlphaFold breakthrough #

CASP 13, in 2018, has been won by the first version of AlphaFold, with 58 GDT, which was the highest score at this time.
This year, CASP 14 has been won by the second version of AlphaFold with nearly 90 GDT.

The secret of the second version of AlphaFold is not known yet, but, as stated by Mirko Torrisi, Gianluca Pollastri, and Quan Le, the secret of the first version is known as a distance map predictor, implemented as a very deep convolutional neural networks, trained on more than 170_000 proteins by 200 GPUs.[4][5][6]

AlphaFold 1 has two steps in the process:

a Convolutional Neural Network (CNN), that takes

at least - as input the amino acids residue sequences, and output the distance metrics between the amino-acids in space,

a Gradient descent optimisation of folding the 3D structure to match the distances between amino-acids in the protein.

AlphaFold 1 architecture - credits to DeepMind[6]

As stated by the team of AlphaFold, the second version of the model may be significantly different from the first one, as the first version has a (light) tendency of overfit the data.

People tend to think that the second version replaced the CNNs with transformers, an attention-based neural network, and speculate on more accurate feature engineering of amino acids residue sequences.

What’s next ? #

“In some sense the problem is solved.” John Moult

AlphaFold will have implications for areas like drug design or treatments, biomaterials, environmental sustainability - like designing enzymes to eat the plastic in our oceans - or agriculture.
Indeed, AlphaFold could be used to understand how protein structure can lead to specific diseases, how to identify proteins that have malfunctioned, but also learn unknown functions of genes encoded in DNA.

Both AlphaFold versions are the work of incredible talented engineers and researchers at DeepMind, but also of all the researchers who participated since the last fifty decades at least.
So, congratulations to John Jumper, Richard Evans, Alexander Pritzel, Tim Green, Michael Figurnov, Kathryn Tunyasuvunakool, Olaf Ronneberger, Russ Bates, Augustin Žídek, Alex Bridgland, Clemens Meyer, Simon A. A. Kohl, Anna Potapenko, Andrew J. Ballard, Andrew Cowie, Bernardino Romera-Paredes, Stanislav Nikolov, Rishub Jain, Jonas Adler, Trevor Back, Stig Petersen, David Reiman, Martin Steinegger, Michalina Pacholska, David Silver, Oriol Vinyals, Andrew W Senior, Koray Kavukcuoglu, Pushmeet Kohli, Demis Hassabis, and all the other engineers and researchers who have been involved in any way in this subject.

As stated in their blog post, DeepMind is pretty optimistic about the impact AlphaFold can have on the wider world… I am too!
To me, AlphaFold is another proof that AI can be beneficial for humanity.

Five years after Alphago, DeepMind just solved another big challenge… Who knows which big challenge DeepMind will solve in 2025!

Online resources #

Slow... for your safety!

Fri, 13 Nov 2020 17:30:00 +0200

EDIT (15th of November 2020)
I made a mistake in explaining that OCSP send in its request the hash binary, which is not correct, and I am sorry for that.
Indeed, OCSP send out the hash of the app developer certificate, as explained in this great blog post.

Apple released it’s new mac operating system update - macOS Big Sur - yesterday night, a version that introduces a new design, closer to the iOS / iPadOS interface, new security updates (goodbye hacky kernel extensions…), new features & apps via Catalyst and… an optimized version of macOS for Apple Silicon devices.

First, the hype… #

The update night was a big “update party” for many people, as Big Sur is a trully big next step for the mac, and for its users.

It was a “big update party”, but not for the good reasons…
Indeed, in one single night, Apple demonstrated to everyone the main drawbacks of their “new security updates and protocols for macOS”, and it was bad, really bad.

… then, the outages #

At 7PM yesterday, Apple released Big Sur.
People got the notification, shared the excitement, and ~~downloaded it~~ tried to download it.

The image size of Big Sur to download was 12.1 GB, which is 4 GB more than the previous version of macOS: Catalina.

The image is huge, and I do think that, despite the latest precautions taken by Apple, the servers were not fully ready to handle the hype… which leads to an outage, a worldwide fail, and a lot of good memes.

It Just Works.™ #Apple #macOS pic.twitter.com/FTGzn7ZYBU
— ᴺᴼᵀ Jony Ive (@JonyIveParody) November 12, 2020

Then, the situation gotten worse and worse as Apple decided to release, during the outage, new beta versions of many tools and operating systems (iOS, watchOS, …) for the developers.

In parallel to this situation - and I don’t know exactly if the following issues were related to the Big Sur update - the Apple Developers app kept crashing all the time, Apple Card and Apple Pay were under outage also, iMessage stopped as well as Apple Plans APIs and big services for the developers… and the final customers.
And this, as a domino game, leads to another fail…

Apple System Status during the outage, for apps and APIs [1]

Apple System Status during the outage, for devs [1]

Slow by design #

I stopped very quickly to try to download Big Sur, as many people all over the world were complaining about the situation, and decided to work on my own stuff… but then, I noticed that opening apps like Firefox took me almost 20 seconds on my latest Macbook Pro, as well as iTerm, VSCode, and many other dev apps (because, yes, I am writing code in my spare time - blame me!).
I restarted the machine, and got the same issues.

This was weird, but it became even weirder when I saw on Twitter that other developers have exactly the same issues, in the same time…

🤔 FYI, seems to be something going on with super sluggish app launching right now. It doesn’t seem to be just us. We are looking into it! https://t.co/RZduhcBwiX
— Panic (@panic) November 12, 2020

Then, suddenly, Jeff Johnson proposed this solution:

Hey Apple users:

If you're now experiencing hangs launching apps on the Mac, I figured out the problem using Little Snitch.

It's trustd connecting to https://t.co/FzIGwbGRan

Denying that connection fixes it, because OCSP is a soft failure.

(Disconnect internet also fixes.) pic.twitter.com/w9YciFltrb
— Jeff Johnson (@lapcatsoftware) November 12, 2020

A lot of people reacted to this tweet as

“Wait… how a network request - that I did not send - can slow down all my tools on my local machine?!”.

Let me explain the magic behind Gatekeeper…

#ForYourSecurity #

Apple introduced in 2012 Gatekeeper, a “security-first tool” to make sure that all the softwares you launch, on your mac, have been verified by Apple itself, and do not contain any code intentionally designed to cause damage on user’s computer.
Gatekeeper has been recently updated (on macOS Sierra) to disallow the system to install software that have not been approved by Apple (downloaded from the App Store) and unapproved by the user manually. Because of this, each user has now to allow manually, in the system preferences, that he wants to run this specific software on its own machine.

But, to check if a given software has been validated or not by Apple, Gatekeeper has to check the validity of the soft (~~a simple hash of the binary~~ a hash about the app developer certificate[2]) over the internet to Apple servers after a given time you opened it at first (not each time [2]).
The service daemon is called trustd.

This means that if Apple servers are slow to answer, Gatekeeper will block the opening of the software until it got a response… which can take a while.

Note: yes, libc can make a phonecall!

Introduce security checks like this to the detriment of the consumer is ugly, and the main decision that has been taken by a lot of developers yesterday, to run their software faster at that moment, was just to block the request from trustd using some great firewall tools, like LuLu or Little Snitch.

Unfortunately, this method will not work anymore on macOS Big Sur as trustd can’t be block by users anymore.

On Big Sur, trustd is in Apple's "ContentFilterExclusionList"
....meaning firewalls can't block it! 😭

Welcome to the future? 😱 https://t.co/8PkmWkcZDS pic.twitter.com/ypYxLRGULn
— Patrick Wardle (@patrickwardle) November 12, 2020

“Here comes the sun…” #

Apple fixed all of those issues in less than two hours, hopefully!
I will not blame the company for the outages, the update fail, all of this… but for the decision to maintain the disastrous architecture of Gatekeeper to the detriment of the mac user.
This needs to be change, but the update pointed by Patrick Wardle does not presume anything good on this side unfortunately…

[1] Screenshots to credit to 9to5mac - got from this 9to5mac article

[2] https://blog.jacopo.io/en/post/apple-ocsp/

Macintoshgarden

Mon, 05 Oct 2020 20:00:00 +0200

if “macintoshgarden” doesn’t give you a smile on your face, I’m pretty sure you don’t know this site…

macintoshgarden is an abandonware archive dedicated to supporting the Macintosh computer platform, from the Symantec THINK C 5.0 compiler, to Quake II and the original Snow Leopard build for PowerPC.

This website is organized into different categories, according to the categories of softwares you are looking for (development tools, utilities, visual arts graphics, games, etc…), or the guide you are looking for, like an introduction to emulation for Macintosh softwares.

If you never heard about macintoshgarden but interested about, do not hesitate to take a look at this “gold mine” of original (and great) Macintosh platform softwares.

Books recommendation (1/x)

Thu, 16 Jul 2020 00:00:00 +0200

In 2019, I read an average of three books a month, including comic books.

Unfortunately, during the lockdown since March, it was difficult to read new interesting books, due to several reasons:

no new release;
physical bookstores close their doors;
people ordered a lot of books to avoid boredom, which has sharply reduced stocks (and the choice of books as well);
parcel and mail delivery has been greatly impacted too, and delays have been extended from two days to one month.

This strange situation gave me the opportunity to read again some books I like(d), and to make a short list of books I recommend.

All the books I recommend have a link to goodreads if you want to learn more about a particular one.

This is the first part of this recommendation list.

“Hackers: Heroes of the Computer Revolution“, by Steven Levy #

First published in 1984, this book changed life of many IT people around the world.
This book describes accurately what hackers look like from the 40’s to the 90’s, from isolated mainframe nerds to the computer revolution that changed our world forever, and the birth of the “hacker ethic” around the DEC PDP computer in MIT.
An inspiring “documentary book” for all computer nerds.

Goodreads link

“Masters of Doom”, by David Kushner #

I consider John Carmack and John Romero as trully computer heroes. From the first Keen to Quake, “Masters of Doom” describes how those guys (and their friends / colleagues at IdSoftware) revolutionized the video game and computer industry in early 90’s.
The book is well written, and full of great stories.
Also, it is very interesting to read how they developed their hacker spirits via video games and computers, and how the previous book I mentioned (“Hackers: Heroes of the Computer Revolution“) forged them.

Goodreads link

“Code: The Hidden Language of Computer Hardware and Software”, by Charles Petzold #

Do you want to know everything behind the scenes of computer hardware and software, from atoms to assembly language? If yes, this is a book for you!
I would say that this book can be an introduction to “Hackers: Heroes of the Computer Revolution”, as it describes how Human was ingenious enough to manipulate language and invent new means of communicating with each other.
A must read for curious people and hackers.

Goodreads link

(Science)Fiction books #

“Neuromancer”, by William Gibson #

A science fiction masterpiece, written and released before the release of the first Macintosh in 1984, that exposes one of the most brilliant vision of the twentieth century.
Just “Wow”.

Goodreads link

The “Millenium” trilogy, from Stieg Larsson #

A brilliant trilogy with one of the most charismatic figures of the 21st century: Lisbeth Salander.
From a complete description of Sweden in its sad moments to the striking psychology of its characters, the first trilogy exposes a crazy, gripping story about murders, hacking, and misogyny.

Comic books #

“Scott Pilgrim”, by Bryan Lee O’Malley #

Fun, geeky, including a great love story.
For all comic books / manga lovers.

Goodreads link

“V for Vendetta”, by Alan Moore #

Who said that comic books are apolitical…?
The comic book for adults.

Goodreads link

“Wizzywig: Portrait of a Serial Hacker”, by Ed Piskor #

From early blue-boxing and phone phreaking days to the Internet, this comic book relates the story of a computer hacker (Kevin Mitnick?) during the 80’s.

Goodreads link

The state of memory safety in Chromium

Sun, 24 May 2020 00:00:00 +0200

As Microsoft last year, the Chromium project team, responsible for the Chromium browser (which is the base of many open source and proprietary projects like Chrome, Brave, or Visual Studio Code), released a blog post last week about memory bugs in Chromium.

The analysis #

The analysis has been based on both past and present 912 high or critical severity security issues, since 2015.
Based on those bugs, the observation is clear:

The Chromium project finds that around 70% of our serious security bugs are memory safety problems.
[…] Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs.

Chart about memory bugs on Chromium, from Chromium Project team

Despite the efforts of the project team to maintain good security architecture in managing sandboxing and site isolation, to let those heavy components manage and contain the severity of memory bugs has both limitations and resources cost.
Also, even if those security components (or layers) stay necessary for daily usage, this not enough to stop attackers and avoid attacks.

Instead, as stated in the blog post:

[…]The cheapest way to maintain the advantage is to squash bugs at source instead of trying to contain them later.

The different solutions #

As always in software projects, solutions (and decisions) come with a trade-off.
Indeed, the team developed a plan to solve those issues, using two criterias:

time and resources costs needed to implement the improvement(s),
the real benefit of those costs, basically the number and the quality of those improvement(s).

Plan for next years memory bugs improvements for / in Chromium, from Chromium Project team

This spectrum reflects the different strategies offered by the team, from left to right:

to keep their dev model in unsafe system programming languages (like C or C++) but to bring attention on memory safety first (spatial memory safety, custom C++ libraries, and moving to newer standards like C++17 or the next C++20);
customize their needs using custom C++ dialects, and / or continue on their idea of using a C++ garbage collection library for Chromium;
move to a safe system programming language (and ecosystem) like Swift or Rust, to bind with C++ parts first before rewriting those.

This plan is not new, as the Mozilla foundation already made experiments about switching from C++ to Rust since 2015).
Indeed, to make the switch to another technology has a big cost in a project, because it implies both to limit new upcoming features and to give some time to developers to embrace a new technology that they may not be accustomed to use daily. Also, the plan here is to have a long-term vision, and not switching again to another technology in five or ten years.

In my opinion, to switch first to “modern C++” can be a good option for a short term solution, but is may not be a great option to “save your ass” all the time.
Rust of Swift are definitely game changers in tech since their first stable version release.

To go further #

An excellent blog post from Mozilla about preventing developers about memory safety and memory bugs: link to blog article.
My article about security by design, in the Tadaweb blog: link to blog article

Developers are not superheroes

Sat, 25 Apr 2020 19:00:00 +0200

There is a myth in IT.
The myth of the “super code monkey”.

The “super code monkey” is an expert in everything, in every situation.
The “super code monkey” does not introduce bugs when he writes code.
The “super code monkey” sleeps at least eight hours every day.
The “super code monkey” is young, has a social life, and practice sport each day to keep in shape.
The “super code monkey” is an expert in Android and iOS apps development, he knows how to write excellent code in, at least, C, C++, and Java.
The “super code monkey” studied Data Science in three weeks, and became an expert on Python, R, Matlab, Octave, and Julia in less than a month.
The “super code monkey” has strong knowledge in Docker and Kubernetes, and masterized 10 different Javascript frameworks the last six months.

But, as every myth… the “super code monkey” does not exists!
Except maybe in the “requirements" section of some IT recruitment companies…

In this blog post, let’s discuss about the sense of the word “expert” in Computer Science, softwares without bugs (spoiler: it does not exists), and the fatal comparison with known figures from an old era…

What is an “expert” ? #

Let’s define what I understand by “someone is expert in…”.

You can be “good” at something, but you must have a professional experience to prove in order to be considered as an expert. Also, you can’t speak about being an expert in a given subject without explaining the context you applied to it, and without maintaining a recurrent technological watch on the subject you are mastering.
As an example, a data scientist can claims that he is a Python expert for Data Science, and he know really well how to use famous modules like Pandas, or Scikit-Learn. But, this is totally different for a network engineer, or for a software pentester!
All three will be able to write very good Python code associated to the context of the application.

Becoming an expert on subject or technology X depends strongly of two different criteria:

your current experience to solve a problem in, or using, X,
and the time you are ready to spend for this.

We all know that time is not something that you can “buy“. Therefore, logically, multiplying many “little” experiences on many things will force you to increase the time to be “just good” at one simple task, and can discourage you more easily to become an expert in one task.

As a personal opinion, I encourage people to become an expert on only one thing (based on a defined context, or subject), and just “good enough” in other subjects or technologies they are interested in.

Features come with bugs #

If you look at big projects like the Linux kernel, or the Chromium browser, you can notice that those are not bugs free.
As you might know, the management of those big projects introduces a hierarchy to validate new features, or bug fixes. The final step of this hierarchy for every merge request (new feature or bug fix(es)) is validation (and merge the feature of the fix to the original code base), or rejection, after pair reviewing.

So, when you discuss about a bug in production, you imply that both the developer and the reviewer have their own responsability here, as they missed the bug before the deployment.

Developers have to accept that features come with bugs, and that the most trickiest ones are, sometimes, invisible to humans.

Most of the time, a developer is not a quality assurance. But, some solutions exist to help developers and reviewers in finding easy and tricky bugs in code: code analyser, monkey testing, chaos engineering, or just tech switching that proposes security by design if you are developing systems or features in critical projects.

Stop to compare with IT known figures #

In order to know how we perform in one task, we often feel the need to compare our work with another person.
When developers do this, they tend to compare what they are spending most of their time on: their code, or the software project(s) quality and popularity they achieved, or they are working on.
This comparison can exists with colleagues, but also with known IT figures.

Those known figures are people who contributed actively to an important part of the IT history, and made a lot of efforts to build beautiful things we are still using today.
For example, we can mention Ada Lovelace, Grace Hopper, Ken Thompson, Dennis Ritchie, Brian Kernighan, Margaret Heafield Hamilton, Steve Wozniak, Roberta Williams, Linus Torvalds, … and many other persons, coming from different Computer Science subfields.
Those persons are mainly considered as “rockstars” because they are considered as “modern“ computing pioneers.

Indeed, in order to solve real problems, those persons had enough imagination to propose new “standards” on low-level constraints: most of the time hardware configuration and the operating system used by users.

The book “Masters of Doom”, from David Kushner, is a perfect example here. This book relates how two geniuses, John Carmack and John Romero, co-created (at least) two revolutionary games (“Doom” and “Quake”), which revolutionized computer graphics and game development.
In “Masters of Doom”, you realize quickly that computers at this time were still in its infancy… and that we cannot compare the work of those pioneers to the work of our engineers today.
Note: If you are more interested in game engines, I recommend you “Black Book: Wolfenstein 3D” and “Black Book: Doom” from Fabien Sanglard, who made incredible researchs to explain how they successfuly built from scratch those masterpieces.

Today, software constraints are really different and, I would say, more complex. Instead of building complex pieces of code on a unique hardware or software stack, most of the developers now are using different standards to ship every day very complex piece of codes, on very complex stacks, in different private versatile environments.

This implies today multiple technologies, and communities, to build one common thing using different tools.

To break down an open door, developers tend to be more “users“ today than “programmers” in the past.

Conclusion #

Even if developers try to save the world each day, they don’t have superpowers (and they are not machines either).

If you are a developer, do not spend your time in trying to become real expert everywhere, everytime, on everything, it’s impossible. Instead, you can try to be a real expert in only one thing more quickly, and just to be “good enough” in other fields or using other technologies.

Zero-cost abstractions in Rust

Sat, 08 Feb 2020 23:10:00 +0200

Last week, Ibrahim Dursun published an article about zero-cost abstractions in Rust.
Unfortunately, except for a subpart of the article, this article did not reflect, in my own opinion, correctly what are zero-cost abstractions.

Indeed, zero-cost abstractions, or “zero-overhead”, can be difficult to understand and to separate from other compiler optimizations, and can be easily misunderstood.

In this blog article, I discuss about this specific feature, and give you an example of how Rust is using it to deliver optimized code of your abstracted projects.

Note: an excellent blog article about zero-cost abstractions already exists, written by withoutboats, last year. My blog post can be an additional content to the article of withoutboats.

What are zero-cost abstractions #

When you are developing a project, and the project is becoming more and more complex, you generaly want to include abstractions in your code to make it easier to maintain and to customize, to add more features. In this case, your last wish is that those abstractions penalize the performances of your program at runtime.

So, as a software developer, you generaly want two things:

to design your project where code readibility and code management are more important than complex hand-writtened optimizations,
still benefits of great software performances at runtime.

Indeed, improving code readibility implies to limit code optimizations and memory overhead, which comes with indirect memory access that can cause performance issues at runtime.

Zero-cost abstractions are coming from C++, and defined by Bjarne Stroustrup in Foundations of C++:

In general, C++ implementations obey the zero-overhead principle: What you don’t use, you don’t pay for. And further: what you do use, you couldn’t hand code any better.

To summarize what Bjarne Stroustrup said, using zero-cost abstractions:

you don’t pay the features you don’t use,
the high levels APIs (or concepts) will compile to machine code as good as what you could get by writing more lower-level code.

This means that most of the abstractions provided by the programming language (or it’s standard library) will not add any additional cost at runtime.

In Rust, zero-cost abstractions is a core principle for:

compile-time memory checks and static garbage collection (borrowing and ownership) - as a reminder, Rust does not check and collect memory at runtime, but is tracking the lifetimes of your code entities at compile time, instead of using reference counting or gargage collection,
traits, which is one of the most impressive feature to extend the types used by your Rust programs,
generics,
iterators,
etc.

This can explain why Diesel, a famous Rust ORM, was 30% faster than the raw postgres solution for Rust, using more abstractions.

Example #

Let’s take a simple example to illustrate this feature.
In this section, we will… compute the sum of odd numbers.

To solve this problem, we can write two functions:

fn sum_odd_numbers(n: u64) -> u64 {
    let mut acc = 0;
    for element in 0.. {
        if element >= n {
            break;
        }
        if element.is_odd() {
            acc += element;
        }
    }
    acc
}

, or

fn sum_odd_numbers(n: u64) -> u64 {
    (0..)
        .take_while(|element| element < &n)
        .filter(|n| n.is_odd())
        .fold(0, |sum, element| sum + element)
}

The second code sample borrows functional programming concepts to compute the sum, and is seems more “compact” (and easier to understand) than the first one.
However, if we decompose this second sample, we can make wrong assumptions here:

create an iterator that begins with a zero value,
take all elements lower than n, a number passed as parameter by the user - as a reminder, if we explicit the final of the iterator, the compiler could decide to compute the final number at compile time, and store it in the executable -, and store the result in another array,
loop all over the last array of elements to get only the odds, and store the result in another array,
loop over the odds array to compute the sum, and return finaly return the value.

So, multiple array allocations just to compute a simple sum…

Fortunately, Rust does not do that: instead, the compiler writes as great code as the first solution provided here, by itself!

Let’s demonstrate it using benchmarks.

Benchmarks #

The following benchmarks have been made using an Intel Core i5 (3 GHz, 6 cores * 2 threads / core), and show the median execution time of the both programs, hand-optimized and abstracted, ran ten times, and for different n values.
I used the time program to measure the user + system execution times each time, and computed the median of those values.

I performed the benchmarks for both debug and release versions.

As a reminder, to build a release version of a Rust program using cargo:

cargo build --release # in the root of your cargo project

To finish, the code repository of each code sample is available in a public github repository, at https://github.com/k0pernicus/Rust_zero_cost_abstraction_illustration, if you want to reproduce them yourself at home.

Benchmarks

Version	n	Hand-optimized execution time	Abstracted version execution time
Debug	100	0,02s	0,01s
Debug	100000	0,02s	0,03s
Debug	100000000	2,97s	6,59s (x2.22)
Debug	1000000000	29,61s	65,16s (x2.20)
———	————	——–	——–
Release	100	0,00s	0,00s
Release	100000	0,00s	0,00s
Release	100000000	0,03s	0,03s
Release	1000000000	0,26s	0,26s

As you can observe, optimizations for the abstracted version are mostly performed for the release version, and both program versions have the same runtime performance in comparison with the debug versions.

Compile time consequences #

Unfortunately, zero-cost abstractions has a consequence: as the compiler has more work to do to optimize itself the abstracted code, it will run more longer.

If you take a look at the compile time of each versions below, you can observe that the abstracted version compiles more slower than the hand-written version, even for a simple program like this…

Version	Hand-written optimized	Abstracted
Debug	0,01s	0,01s
———	————————	————
Release	5,80s	8,19s (x1.41)

Conclusion #

Do not hesitate to include abstractions in your code when you need them - in Rust, you should never think about hand-written optimizations first, but think about abstractions, software design, and code readibility, even if you care about runtime performances.
Unfortunaly, this has a (heavy) cost at compile time.

Thanks to Robert Syme for his contribution.

Dealing everyday with anxiety, impostor syndrome, and mental depression

Fri, 24 Jan 2020 20:00:00 +0200

This is for sure the most intimate blog post I ever made on this website, and this blog post was absolutely necessary.

Since I was in middle school, I suffered a few years from anxiety, mental depression, but also impostor syndrome. The path was hard, but thanks to my family and my friends, I am feeling a lot better now.

Recently, after talking with people in real life or in the internet, reading blog posts, or simply scrolling on Twitter, I do feel that anxiety, depression and impostor syndrome is taking more and more place in our society, with this sentiment that all of those belong to what I will call in this post “the pain of the century”.

Indeed, anxiety and depression makes you think that emotional states are a prison for your mind, that you are just trapped by your sentiments, which is actually a fake actor in this situation.
At the other hand, impostor syndrome lets you think that you will never belong to a real group of people, and make you lose your self-esteem.

I wanted to write down my own opinions about this pain that is ravaging more and more people, and the different methods I tried to deal with all of those issues, in order to help you to live with them.

Investigate on yourself #

At first, you have to understand that, every day, you will have to deal with two kind of persons: yourself, and all the others.

To investigate on yourself allows you to understand who you really are, and target your key points, but also your flaws. This goes throught several states, but the first (and most important one), is to understand your weaknesses, meditating on yourself.
The path will takes some time (days, weeks, months, or even years), but will makes you stronger each new day of your life: a long path to a long term beneficit.

At the contrary, hiding your weaknesses could be beneficial for short time, but will make your life more difficult to live at the long term, for sure.
Also, to hide them could bring another problem in your daily life: greater and greater efforts to hide them more and more… Indeed, your principal fear in this case will be to let someone exploit your flaws, and makes your life worse.

The best way to meditate on yourself is to trace each of your bad feelings, from today to the origin, and to understand the how and the why. Take the time you need to medidate - in my own opinion, 30 minutes of your time per day is more than enough.

Another technique is to write down on paper your different thoughts, and to throw the paper in the trash a few minutes later. This method seems very dumb, but to write down your feelings and destroy them can help you to realize that sentiments can just be words on paper, and that you are not trapped by your feelings.

Remember that dealing with weaknesses and hiding them are two very different aspects, and hiding feelings are more painful in the long term than understanding and accepting them.

You are free to make mistakes #

I do think that impostor syndrome, or fraud syndrome, is very hard to deal with because it’s in everybody.

When I was in college, I remember to sit down on my student chair, looking at the other students around me, and almost got a panic attack because I had the sentiment that I was not good enought to feel part of this big group of students. However, after discussing with some of them about my feelings - remember that you have to accept your feelings, not hiding them -, I realized that the other students I talked to had exactly the same psychological pattern.
I understood at this time that impostor syndrome was not a personal feeling, but a society problem, and that I was not alone with this group of students.

Knowledge is definitly not innate, and each person will have his or her own facility in a particular field, subject, or technique, and have difficulties to understand anothers.
The most difficult thing in this part is to discover on what you are good at. Difficult, but definitly not impossible.

When you are suffering from impostor syndrome, one of the worst thing we have to handle is sentiments from our environment, like your colleagues, your family, or someone else. Dealing with people -and their sentiments- is a common issue for people that live with fraud syndrome, especially when they found their exact opposite: people who have the sentiment to know everything even if they only scratched the surface of a field, subject, or a technique.

Unfortunately, I don’t have a magic solution for this syndrome. To be honest, I begin to think that there is no solution for this kind of problem.
My only way to deal with this was to practice the domain I wanted to be good at, and to break with people that makes me feel bad in this domain.

Find an hobbie that get your attention #

Anxiety, for me, cames with social pressure and, of course, stress. To overcome those psychological issues, you have to clear your mind, and try to think about anything else.
This is where personal hobbies come in this story.

My personal hobbies are to read books, play video games, and watch movies.
I did not found yet the sport that attracts me yet, so I don’t practice physical exercises at all.

Personal hobbies will help you to assimilate that you are not your thoughts, and think about something else than daily problems

To help you with this part, I recommend you to listen this Q/A session from Jonathan Blow, an independant game developer and designer, about techniques to deal with lack of motivation, malaise, and depression.

Listen to yourself, and BREATHE #

If you feel that something is starting to overwhelm you, stop it right now. Breathe, make a pause, and ask yourself if it’s worth continuing. Sometimes, just taking a little step back from a difficult task makes you more aware about how to solve it.

When I was in college, I was really interested in video games development, especialy indie games success stories. At this time, I started watching some documentaries about indie games and indie developers, like “Indie Game: The Movie”, or reading books about it… After consuming them, I was incredibly dismayed to learn that, even though the indie developers of that time were successful, and that they earned a lot of money, they went through anxiety and mental depression right afterwards, precisely because of their hard developing experience.
Indeed, most people will continue to work on something, even if they have losed motivation about it, until he finished it’s work. However, most of the time, bad things will happen once the work is done, and the road to healing is long and very painful.

To sum up: there is no shame to drop something, and there is no shame to make mistakes if you gain experience from it.

Conclusion #

First of all, there is no shame to understand your feelings. You are the only person on board in your mind, so don’t take the emotions from the others to assimilate them: feel yourself, and f**k off for the others. Also, don’t be scared of your sentiments, embrace them instead!
Next, we are humans, not machines, and knowledge is not innate. We have to learn, understand, and make mistakes to grow up.
To relax, find an hobbie, or maybe a place to relax, in order to release all the anxiety and social pressure on your shoulders as soon as you can. Just breathe a few minutes, relax, and take time for yourself.
Finally, listen to yourself, listen your body, and breathe, breathe, and breathe. If you are not feeling great with something, just step back and meditate on this. Remember that, again, there is no shame to drop something to feel better.

Good luck my friend.

A strange strings comparison problem, in Go

Sun, 15 Sep 2019 02:00:00 +0200

Thanks to https://github.com/egonelbre/gophers for this sketch

Go is known for it’s strong type system, and explicit type conversion.

For example, if you have to compare two different values of different types, you will have a compiler error:

package main

import "fmt"

func main() {
   var x int = 0
   var y int32 = 0
   fmt.Printf("%+v", x == y) 
}

If you try to compile this code sample, you will have to deal with the following error, reached during compilation:

./main.go:8:24: invalid operation: x == y (mismatched types int and int32)

In order to make it work, you will have to convert x to int32 (or y to int in order to not loose any precision - which is not the case in the code sample), which is called explicit type conversion.

This behaviour, in Go, is normal, because a well known design decision is the absence of implicit type conversions, like in C.

Great design, no?

Except that, even for awesome tools & rules, there always exist some exceptions.

Type identity #

Let’s talk about the following code sample:

package main

import (
	"fmt"
)

type myString = string // Here, myString will be replaced by string

func main() {
	var x myString = "Hello"
	var y string = "Hello"
	fmt.Printf("%+v", x == y)
}

This code outputs “true”, which is understandable because myString is a type alias of string.
Some people still think that the compiler converts (implicitly) a myString value to a string value during compilation, which is not the case.
Actually, the compiler will just replace each myString type name with string (think about a Vim’s :%s/myString/string/g in the whole program) in order to compile the program. So, for the bytecode, a myString type is a string type.

Now, if you remove the equals symbol at line 7 (when defining the type myString), you are defining a new type, related to a string one, but that is explicitly different than a string for the type system.

In this case, the code will not compile and the error will be almost the same as before:

./main.go:12:22: invalid operation: x == y (mismatched types myString and string)

Now, let’s try something a bit different…

If I replace the line

var y string = "Hello"

with

var y = "Hello"

the problem still remains the same.
Using type inference feature, the compiler will understand that "Hello" is a string, and will type it implicitly.

So, the following program must be the same than the previous version, right?

package main

import "fmt"

type myString string

func main() {
	var x myString = "Hello"
	fmt.Printf("%+v", x == "Hello")
}

Here, we did not declared y and instanciated it with Hello. We let the compiler do it for us.

Let’s run it to expect the same error and the program… suceeded !?
And outputs "true".

But… why?

Untyped string constants #

The first idea here is to ask ourselves if the compiler does not instantiates by itself Hello as a myString type, which is false:

fmt.Printf("%+v - type of 'Hello' is '%+v'\n", x == "Hello", "Hello")

outputs true - type of 'Hello' is string.

The second idea is to ask themselves if "Hello" is a variable, and not a constant value…

This blog post from Rob Pike about constants in Go, explains clearly that all unassigned text between double quotes are considered as constant values.

So, the previous code is (almost) exactly like the following one:

package main

import "fmt"

type myString string

const y = "Hello"

func main() {
	var x myString = "Hello"
	fmt.Printf("%+v", x == y)
}

which still outputs true.

As Rob Pike explained in the blog post:

This is an untyped string constant […]. Yes, it’s a string, but it’s not a Go value of type string. […] An untyped constant is just a value, one not yet given a defined type that would force it to obey the strict rules that prevent combining differently typed values.

Later in the same blog post:

These untyped string constants are strings, of course, so they can only be used where a string is allowed, but they do not have type string.

So, following those explanations, we can understand that if we define constants with concrete types, and not let the compiler infer those, we will not having this issue anymore.
In this case, if we change the definition of y to this:

const y string = "Hello"

the comparison will fail at compile time, with the same compilation error message than the previous time(s).

Thanks to https://github.com/egonelbre/gophers for this sketch

But… why do we need untyped string constants? #

At first, it seems that untyped constants was a bad design move from the creators of Go, because you can use them to escape from Go’s strong type system, which allows you to make some comparison mistakes if you don’t pay enough attention, or even worst:

package main

import (
	"fmt"
)

type myString string

const y = "world"

func main() {
	x := make([]myString, 0, 2)
	x = append(x, myString("Hello")) // Append a myString "Hello"
	x = append(x, y) // As y is untyped, we can append y here - no compilation error
	fmt.Printf("%s\n", x) // Print "[Hello world]" here
}

Of course, the previous examples paid attention to untyped string constants, but you can obviously hack with untyped int constants, untyped float constants, and so on…

So, why do Go creators introduced the notion of untyped string constants?

Again, as Rob Pike explained in the blog post:

It is this notion of an untyped constant that makes it possible for us to use constants in Go with great freedom.

Thoses statements prove actually two things:

untyped constants move is a design decision for more flexibility for Go;
and typed constants don’t use the same type system as variables, in Go.

This great article from ArdanLabs provides a practical example to explain this Go feature in a numerical issue (look at section “One Practical Example”).

Conclusion #

Inference of constants values is different than inference of variables values, as typed constants don’t use the same type system as variables.

Untypes constants provide flexibility, and escape from Go’s strong type system.

Be careful about untyped constant - they might be useful in certain cases, but I strongly recommend to restrict first the type of your constants, and to remove them later if you really need more flexibility in your code.

(Un)marshal complex JSON objects, in Go

Tue, 16 Apr 2019 20:03:16 +0200

If you work a lot with APIs in Go, it may happen you have to work with complex JSON responses…

Ok, let’s talk about that using a simple example.

Imagine you have to work with the following data structure, which represents a Person data structure (like a real person, no trap) with the following characteristics:

the name of a Person object: a string;
the dog’s name of the Person object (if it exists): a Dog structure that contains only a string, which is its name;
the age of the Person object: an integer;
the last time the data structure has been updated: a datetime type.

First, we try to implement the associated Go structure, which is very simple:

type Person struct {
  Name      string    `json:"name"`
  DogS      Dog       `json:"dog"`
  Age       int       `json:"age"`
  UpdatedAt time.Time `json:"updatedAt"`
}

type Dog struct {
  Name string `json:"name"`
}

For now, everything is ok, and we imagine the JSON response like

{
  "name": "Ferdinand",
  "age": 25,
  "dog": {
    "name": "Rex"
  },
  updatedAt: "2019-01-01 00:00Z"
}

Unfortunately, the response does not look like this. At all

In contrast, the data in JSON looks like this:

{
  "name": "Ferdinand",
  "age": "25",
  "updatedAt": "2019-01-01 00:00"
}

There is (at least) three big issues in our previous Go code. Let’s decompose what (and where) are the problems, and how to solve them one by one.

Handle the missed data #

As you may already noticed, we miss a data in the JSON response: the dog object.

A basic solution to this is to implement a structure if the dog JSON object is present, or if the dog JSON object is not present… Spoiler: this is a very bad solution.

When you are (un)marshalling a JSON object in Go, you can omit some fields if the field is empty (consider empty as NULL, or just the default type value, like an empty string for string type, or a 0 value for a default integer value). Usually, this solution is really simple to use, because you just have to append the omitempty tag in the Go struct tags you wrote before, for the field you want omit. Using it permits also to reduce the payload if you want to send little data structure compared to your big (and complex) Go data structure.

So, for the dog, you just have to trick your Go data model like this:

type Person struct {
  Name      string    `json:"name"`
  DogS      Dog       `json:"dog,omitempty"` // We append here the 'omitempty'
  tag
  Age       int       `json:"age"`
  UpdatedAt time.Time `json:"updatedAt"`
}

type Dog struct {
  Name string `json:"name"`
}

Handle the string values #

Unmarshalling the previous JSON structure throws the following error: json: cannot unmarshal string into Go struct field Person.age of type int.

The second issue is that the age field is not an integer, but a string that represents an integer. Unmarshalling this kind of thing does not work at all… without an extra tag again!

This tag is string, and have to be append next the age field in the Go structure:

type Person struct {
  Name      string    `json:"name"`
  DogS      Dog       `json:"dog,omitempty"`
  Age       int       `json:"age,string"`
  UpdatedAt time.Time `json:"updatedAt"`
}

type Dog struct {
  Name string `json:"name"`
}

The string tag informs that the unmarshalling behaviour has to convert explicitly the string type to the type in the Go structure.

Unfortunately, magic can disappear really quickly… But we will explore this black magic of Go in the last section of this blog post.

Handle the wrong datetime format #

The Go time library does handle multiple time formats. Unfortunately, the format of the date returned in the response does not correspond to a supported time format, in the Go standard library.

You can try to check another Go library that handles this format (I doubt about it…), or you can write your own time parser, for this specific time format:

type PersonDate struct {
  time.Time
}

Now, we have to write our custom MarshalJSON and UnmarshalJSON functions for this custom structure, in order to valide the interface contract with the Marshal interface.

const PersonDateFormat = "2006-01-02 15:04"

func (pd *PersonDate) UnmarshalJSON(input []byte) error {
  strInput := string(input)
  strInput = strings.Trim(strInput, `"`)
  newTime, err := time.Parse(PersonDateFormat, strInput)
  if err != nil {
    return err
  }
  pd.Time = newTime
  return nil
}

func (pd PersonDate) MarshalJSON() ([]byte, error) {
  // Here, you can return the given time in an existing
  // (and accepted) time format
  return []byte(`"` + pd.Time.Format(time.RFC1123) + `"`), nil
}

At this point, you can unmarshal this custom date time format in replacing the time.Time type in the Person structure with the PersonDate structure, and marshal it into another time format that is recognized by the Go library.

Nice!

Handle the conversion errors during Unmarshalling #

For this last issue, I don’t think there is a “good” solution…

Imagine now that an error happened in the back side, and overrides the age value by an empty string (or something other than an integer) in the JSON response. If you have this type of response, an error will be thrown: json: invalid use of ,string struct tag, trying to unmarshal "" into int.

We can’t be angry with the UnmarshalJSON function, because this error is terribly logic.

Do not forget that unmarshalling a string into an int, using the string tag, will convert the data type into another one. In the case of converting a string type value into an integer, the function can explicitly call strconv.Atoi. If you already used this function, you know that the function returns an integer, or an error if the string does not represents an integer. Like an empty string.

Unfortunately, there is no easy way to handle this error… except rewriting the Unmarshal process for our structure, or… using two different structures.

1st solution: the custom Age field #

Like we did for our custom Date format, we can wrap the Age field into a custom Go data structure (for example, PersonAge), and write a custom MarshalJSON and UnmarshalJSON methods for this Go structure. However, if you plan in the future to create concrete type for each integer values in the Person Go structure, and if you have to manage later different integer values, you will have to create as much custom Go structure than integer values in the JSON response…

2nd solution: separate the JSON structure and the final Go data structure #

The purpose of this solution is to handle and unmarshal the JSON structure in a Go structure that contains all its values as string types, and create a function to convert this structure into another that contains the required Person types, using reflection. This solution can be generic, in order to convert all the data structures you want into another (using interface{} parameters), but can be complicated if you just want to solve this issue for this field issue only.

As I said previously, there is no best advice for this, because it depends of the kind of response you will have in real world. If you are sure that the JSON response will not change, and you only have one integer (or float) field type, go for the 1st solution! Otherwise, you can play with reflection in order to build a more concrete and durable solution, not only for this Go structure (and JSON response) but also for many other that share this issue.

Go playground #

If you want to play with this example, please play with this Go playground.

2019, as minimalistic

Wed, 20 Feb 2019 10:11:49 +0100

I became fed up with my electronic materials.

The way we evolve, as city dwellers, implies sometimes to adopt a non-minimalistic approach to live:

to have one device to make only one thing,
to have different devices that can be used to make the same thing,
to buy expensive things based on good ads,
to buy expensive things based on what you can do (and finally things you will never do), …

In 2019, I want to adopt a new approach in my life, which can be simply resumed as: do more, with less.

Both for myself, and for the Planet (don’t forget it).

In this post, I will develop four different points to adopt a general minimalistic approach.

Choose according your usage, and not the inverse #

A problem I have with myself is to choose a device based on what I would do with it, and not what I can currently do with it. This sort of thinking implies to buy a lot of devices, for all sort of things I will never have the time to do in the next months/years!

And this is purely wastefulness.

But be careful, I am not telling you to avoid any unnecessary technology, but rather to make a choice in order to use them conscientiously! Let’s make the distinction about my computing usage, based on the last three years.

For now, I have four computing devices:

a laptop, for web browsing, blogging and programming,
a tablet, for web browsing and blogging the night,
a smartphone, to communicate and to take a lot of photos,
and a gaming PC for… gaming. Only.

Four different devices, for four different (and common) tasks:

web browsing (read articles, and watch YouTube videos),
blogging,
programming (just a little),
gaming.

I think we can easily reduce the number to two: a laptop, and a smartphone.

For programming, based on my previous experience, I only use CPU computation, and my RAM usage is ~ 6GB of RAM. No need GPU here… For web browsing and blogging, I really don’t need an expensive hardware for that…

To avoid the tablet, I can make use of an hybrid laptop - like a surface, or a laptop with touchscreen (with a 360 keyboard).

But the gaming PC… the choice is hard. For this, I have three different possibilities:

Avoid a lightweight and (and unexpensive) laptop to buy an heavy gaming laptop;
To buy an eGPU, which add again a new device for this task exclusively;
To keep the lightweight laptop and buy a subscription to a cloud gaming provider.

Today, a lot of companies are working on gaming in the cloud: Blade (the French company that produces Shadow), Google, Microsoft, Nvidia… and, to have tested cloud gaming using a Shadow PC, it works really well if you have a good internet connection.

Be careful, I did not say “really good” or “exceptional” internet connection, but just “good” internet connection… The promise to have a really good gaming experience on 5MB/s connection was awesome for me.

So, for all those tasks, I can maybe express the idea that… a Chromebook can finally be a good choice for me, as a laptop!

Also, if I sell my current gaming PC, my tablet and my (expensive) laptop (for almost nothing), I can buy a good Chromebook for 33% of the price I will earn in selling those devices.

“Do I really need it?”, or how to avoid all sort of gadgets #

The common mistakes with gadgets is to ask yourself a wrong question: “Do I will use it?”. Instead, ask yourself the same question but based on your current needs: “Do I really need it (now)?”.

99% of the time, now, I came to the conclusion that I can avoid this gadget, and save my money for something I really need.

The DIY magic #

Sometimes, you have the feeling that, if you want the object of your dreams, you have to buy multiple things in order to assemble them, or to buy one unique really expensive thing to satisfy your desire. Also, you tend to forget that you can build it yourself…

To hack an object can, sometimes, be more refreshing and beneficial in the long term than buying a new “thing” for something you can abandon in two months. Also, generally, it costs less to do it by yourself…

Do not forget that the DIY approach is principally based on refreshing old objects, and to make something new with something old (or broken). In this way, do not throw an object in a trash if you don’t use it, even if this object is broken!

Sell it, or give it to someone. Do not throw it.

To finish… #

Live in the present, buy according your needs (and not according [only] your dreams), and make it :)

Struct embedding trick to avoid duplicate code

Tue, 06 Nov 2018 21:50:24 +0100

When you are writing go code, and try to make it more flexible, most of the time you are looking for interfaces. A go interface is a good solution to make your code more flexible, or scalable, and is also a way to achieve polymorphism.

As the official go documentation discusses about interfaces, interfaces are “named collections of method signatures”. So, to implement an interface on different structs, you have to implement each interface’s method for a given struct.

Now, let’s imagine a problem… I want to invent an RPG game, and I need two different classes of players:

orc,
elf.

Those classes can be grouped in an interface called “player”, for example:

type player interface {
  name() string
  getInformations() string
  strike(p *player) (int, error)
  stricken(p *player) (int, error)
}

type orc struct {
  name string
  age int
  health int
  size int
}

type elf struct {
  name string
  age int
  health int
  vision int
}

If I want to implement this interface for orc and elf, I have to implement name, getInformations, strike and stricken methods for both orc and elf, which is like duplicating code (except for getInformations as our struct contains different usefull informations about a given Player class).

A nice trick here is to consider that the redundant code may be included in an interface, via an embedded struct (the example has been reduced to make it more understandable).

...

type namer struct {
  name string
}

// We implement only one method, for namer
func (n *namer) getName() {
  fmt.Println(n.name)
}

type orc struct {
  namer // Instead of the name string type, we include directly the namer struct
  age int
  health int
  size int
}

type elf struct {
  namer // Same for the elf type
  age int
  health int
  vision int
}

func main() {
  o := orc{namer: namer{"Orc"}, age: 12, ...}
  e := elf{namer: namer{"Elf"}, age: 12, ...}
  o.getName() // It works, as an orc type contains the struct namer that respects
              // the deal with the get interface
  e.getName() // As well with the elf type :)
}

The go playground is available here.

Using this trick, we don’t have to implement twice the same method for orc and elf, and create duplication code, which is pretty nice if you have to add 10 new structs, and a lot of new methods in the namer interface.

`go mod`: manage all your dep as a single unit

Sat, 03 Nov 2018 20:04:54 +0100

Generally, when you want to package your go app, you are creating different packages, inside the same project. The problem is, if you want to use a single internal package, you simply can’t, because you have to import the entire package in order to user a single and very simple feature inside.

But, sometimes, you don’t want to use a single extenal package. Indeed, you just want to use a certain number of packages to do a task, and all compatible between them. And this become more complex… Also, do not forget that, when importing a Go project using go get, it will not check the package dependencies, or the package versions… So, you need an external tool to define and save the package versions your Go app is using.

Since Go 1.11 (as a beta version), a new feature pointed to the end of his nose in order to help you in creating, and managing, easily a group of packages as a single unit: the Go modules. Also, vendoring will be “deprecated” soon to give way to Go modules soon.

Let’s talk about this feature.

The context #

Go has a lot of external tools in order to manage dependencies: vendors, go dep… but those tools are not very efficient, and raised a lot of problems (and usability exception) since their public availability. The needs, for Gophers, was to build an internal command in order to fetch and install specific dependencies in order to build a Go package.

At this time, Go modules was born.

Go modules appeared in Go 1.11 as a beta feature, and has been released as a stable feature in Go 1.12.

In order to preserve the consistency and the maintanability of Go projects, go mod will check the Gopkg.lock, if it exists, in order to retrieve very fast the required libraries for your Go app.

The concept #

In order to define the different “components” of the Go module, a go.mod file is listing other required modules, at the root of the defined module:

/myGoModule
  go.mod
  main.go

If main.go is using bar and foo specific Go packages, go.mod will list those packages in order to fetch, download, and build them.

For this example, in go.mod:

module github.com/unnamedUser/myGoModule // Define the package name

require (
  github.com/unnamedUser/bar v0.0.1 // I want the 0.0.1 version of bar...
  github.com/unnamedUser/foo v0.0.3 // ...and the specific 0.0.3 of foo!
)

You can observe here that:

the module is named as your Go package;
go packages have been imported automatically (last version) in the require code block;
indirect go packages are explicited (in order to verify the entier Go app later);
the package version of each Go package is setted (and can be modified but you have to respect the consistancy of the dependencies versions).

So, if another user is trying to import/download/build your app, go mod will import the specific versions of your in-app packages. Very nice!

A simple example #

To illustrate how to use go mod, we will make a very simple exercise.

Here, we want to create an HTTP server, that consumes a single route, /proverb, which returns a Go proverb as a string. In order To do that, we will import the following packages:

quote, in order to retrieve a Go proverb,
color, because we see the life in TRUUUUUUUUE COLOOOOOR…

Ok, let’s create our Go package.

> mkdir -p /tmp/go_tests/httproverb
> cd /tmp/go_tests/httproverb

First, let’s initialize the go.mod file:

> go mod init github.com/k0pernicus/httproverb
go: creating new go.mod: module github.com/k0pernicus/hello

Using this command, go will create and initialize a go.mod file that contains only the name of the module, as we did not create our Go app.

Let’s create the main application, in httproverb.go:

package main

import (
  "fmt"
  "log"
  "net/http"
  "rsc.io/quote"
  "fatih/color"
)

func hello(w http.ResponseWriter, r *http.Request) {
  fmt.Fprintf(w, "<h1>Hello user</h1><p>Tip: Why don't you try /proverb ? :)</p>")
}

func proverbHandler(w http.ResponseWriter, r *http.Request) {
  goProverb := quote.Go()
  // Log the proverb (just to use color from fatih...)
  color.Green("This is my new proverb: ’%s’", goProverb)
  // Returned from the server
  fmt.Fprintf(w, goProverb)
}

func main() {
  http.HandleFunc("/", hello)
  http.HandleFunc("/proverb", proverbHandler)
  log.Fatal(http.ListenAndServe(":8080", nil))
}

The architecture of our project is very simple because it contains only two files: go.mod and httproverb.go.

Now we written the code of our Go app, let’s build it!

> go build
go: finding github.com/fatih/color v1.7.0
go: downloading github.com/fatih/color v1.7.0
package main
go: finding github.com/mattn/go-isatty v0.0.4
go: finding github.com/mattn/go-colorable v0.0.9
go: downloading github.com/mattn/go-isatty v0.0.4
go: downloading github.com/mattn/go-colorable v0.0.9
# github.com/k0pernicus/hello

If you want to see where are stored those dependencies, you can list the files in the go mod cache, in $GOPATH/pkg/mod/, and are postfixed with the dep version. In you are wondering why go mod is using is own cache, you can check the answer from Ross Cox in this article from Dave Cheney.

After playing a bit with the Go app, check the go.mod app:

module github.com/k0pernicus/httproverb

require (
	github.com/fatih/color v1.7.0
	github.com/mattn/go-colorable v0.0.9 // indirect
	github.com/mattn/go-isatty v0.0.4 // indirect
	rsc.io/quote v1.5.2
)

Great! Go has successfully listed our dependencies into the go.mod file, without any help.

Go contains a lot of subcommands in order to manage easily and properly the dependencies, like:

graph (print module requirement graph),
tidy (remove unused modules),
why (explain why packages or modules are needed for this Go app),
and many others (go mod help).

To go further #

If you want to take a look at a better/live example, please check a look at the httpstat package from Dave Cheney, a very famous Gopher. Otherwise, if you want to know more about Go modules, please to read the official proposal from the Go team.

Medium posts

Sat, 27 Oct 2018 01:23:11 +0200

** Update 16th of February 2025 **

Unfortunately two articles from DernierCri are now pointing to 404 pages:

“Déployer une app Phoenix sur Heroku, sans connaître Phoenix”,
and “Cinq fausses idées sur le Big Data”.

The article about the Julia programming language is still available, but it might be outdated.

I wrote a few articles for DernierCri about Big Data and Software Development on Medium in 2016 and 2018.

Those blog articles has been written in French.
This is the list of the blog posts I wrote:

The `go build` constraints

Fri, 26 Oct 2018 18:56:18 +0200

Credits to @ashleymcnamara

Recently, I started to use termui in order to build and run a modular dashboard on the terminal. This dashboard will display my daily todo list, some informations about my git projects/repositories, some daily news, etc…

I use everyday: a macbook pro, and a GNU/Linux laptop - so, two different operating systems.

Even if macOS and GNU/Linux share similar parts, those systems are strictly differents, and I will have to compile the dashboard for each one. No problem with cross-compilation, Go can handle that very quickly and simply via a compiler built-in option. Nice!

However, I quicky realized that I will have a trouble in specifying interruption handler path, for each of those operating systems.

Indeed, for termui, Linux can simply handle the letter key q to quit the program manually. For macOS, unfortunately, we must to complete the command using the full path to keyboard command /sys/kbd/q.

As a result, the full path does not works on my GNU/Linux system, and vice-versa.

Multiple solutions can be used in order to solve this problem, but my solution here is to define a constant for each keyboard command, for GNU/Linux and macOS, and let the compiler decide which one to use according to the current operating system. At this moment, I discovered the build constraints feature of Go.

What is `build` ? #

build is a Go package, available in the standard library. The main goal of the package is to gather information about Go packages, and includes several options and features in order to do that.

How a Go project is organized? #

Go is a compiled programming language. The Go compiler takes as input a source code, and return binary (or machine) code (after several internal processes) for the architecture you specified (or you are using).

In order to produce the binary code, the compiler needs several iterations to build some parts of the projects, as binary objects, to reassemble them later in order to produce the main binary.

Here, in order to use specific code for a given hardware architecture, we want to introduce compiler conditions. For the compiler, those conditions will permit to build specific binary objects according to a given architecture, and produce a final binary code fully compatible with the given architecture.

Those compiler conditions are presents in Go under the name of “build tags”, or “build constraints”.

A concrete example #

This is the tree of our Go project:

go/
  src/
    myproject/
      kbd_linux.go
      kbd_macos.go
      main.go
  bin/
    ./myproject

For those directives, or compiler conditions, Go does not have a preprocessor, a macro system, or a C-like #define declaration. Instead, Go is using a naming system convention, supported by the go tool.

So, compiler conditions will be defined as comments, in the first lines of the go file.

We will include the build constraints in kbd_linux.go and kdb_macos.go for, respectively, GNU/Linux and macOS, and let the compiler decides which one to use using the // +build directive.

Let’s build our specific GNU/Linux build tag file. In kbd_linux.go, we can write:

// +build linux

package main

// Route correctly for Linux machines
const QUIT = "q"

So, the QUIT keyboard event path will point to the simple path “q”.

For macOS, in kbd_darwin.go, we can write:

// +build darwin

package main

// Route correctly for darwin machines
const QUIT = "/sys/kbd/q"

Here, we define the same constant QUIT but we point it to another kernel path.

You can notice we defined the same constant in each file. This is not an issue at all because the compiler will choose one of those files to build the binary, at compile time. So, QUIT will never be erased or overrided at any time by the compiler.

Finally, in main.go:

package main

import (
  "fmt"
  ui "github.com/gizak/termui"
)

func main() {
  err := ui.Init()
  if err != nil {
    panic(err)
  }
  defer ui.Close()

  p := ui.NewPar(":PRESS q TO QUIT")
  p.Height = 3
  p.Width = 50
  p.TextFgColor = ui.ColorWhite
  p.BorderLabel = "Text Box"
  p.BorderFg = ui.ColorCyan

  ui.Render(p)

  ui.Handle("q", func(ui.Event) {
    // At compilation time,
    // QUIT will be replaced by the value
    // corresponding of the correct source code file
    // according to the current operating system.
    fmt.Println(QUIT)
    ui.StopLoop()
  })

  ui.Loop()

}

As the compiler will choose one of the kbd_<>.go file, it will create an internal package for the main.go source code file, and substitutes the QUIT constant to the kbd_<>.go one.

To check which go files will be included in the binary, you can use go list to get the names of the files that would be compiled: go list -f '{{.GoFiles}}'.

Simple and with a negligible loss of performance in the compilation, this solution permits to specify architecture conditions to build a specific binary, while ensuring a minimum of security in its Go app.

To Go further #

The 'intelligence' problem in 'artificial intelligence'

Sat, 22 Sep 2018 13:38:34 +0200

XKCD - Artificial Intelligence

The more I listen AI enthousiastic people, the more I can differenciate them in ‘10’ very different groups:

people who think that AI is a synonym of “strong black magic”;
people who are amazed by AI because “come on dude… it’s just maths!”.

There is something wrong with “Artificial Intelligence”… I don’t speak about some tech, just the term.

Let me explain why, in three different points.

The human feeling #

My teachers always told me:

People think a task is not valuable as ‘intelligent’ as soon a machine can do it.

But… are we training machines to do something intelligent?

A few years ago, top HackerNews articles were about separating muffins and chiwawa, playing go as an expert, or detecting earlier agressive cancers. Are people intelligent because we can differenciate muffins and chiwawa?

Personally, I don’t think so… If you take the cancer example, we are actually transform a computer into a cancerologist expert, to help him. And if you take the go example, we are actually transform a computer into a go expert player.

The same key between those two examples is “turning a machine into an expert of [put something here]”, and that is what AI is doing: to automatize tasks using an expert system. Also, if we discuss about Machine Learning, we are using concrete examples to let the computer infer the pattern in order to be an expert system. Those data are processed by experts first, in order to clean them, and improve the score of the ML algorithm.

There is nothing “intelligent thing” here. We are trying to automatize something to save time, and/or save resources.

The AI paradox #

Two years ago, I discussed with my thesis supervisor about optimizing a task using Machine Learning, and I explained that, with good features and intuition, I thought a logistic regression on the features could make real good predictions. But, suddenly, he laughed really hard because he didn’t understand why a logistic regression is classified as a machine learning algorithm as it’s Texas Instrument calculator could do the same thing.

The question behind this story is: “Can we restrict AI to algorithms that run only on strong hardware?”

Short response: of course not. AI is based on simple algorithms, and simple paradigms, that can run on powerless hardware. I agree that, today, a lot of complex algorithms are used to solve simple and complex tasks: bagging and boosting algorithms, or neural networks for example.

But to minimize AI as “complex algorithms” is totally wrong. The algorithm used to solve a task is not the most important task in Data Science, it’s feature engineering!

The “automatic”/“automatize” confusion #

Many people think that AI is a magic process to learn something to a computer. For those people, AI is a big black box which takes as input data, and output a value. If we follow this idea, I really don’t know why we need Data Scientists today…

Obviously, this statement is not correct - you can just train “something” on data without any interessment, but you will fail in the training process (otherwise, you are very lucky).

Actually, people are really confused between “automatic” and “automatize”. Computers don’t automatically learn something - we train them using data for a given task.

The goal of Machine Learning is to automatize a process using data. And there is no magic in the training, just mathematics…

Algorithms for Automatization ? #

For me, “intelligence” and “automatic” are two strong words to avoid we talk about AI. As the main goal of AI is to automatize some taks using algorithms… why not “Algorithms for Automatization”?

Pyenv

Sun, 22 Jul 2018 14:01:43 +0200

Credits to XKCD

I write Python code each day, for personal and professional projects. As I am working on multiple Python projects, old and fresh ones, I have to use different Python versions for those projects, from 2.7.2 to 3.7.0. Also, I want to switch the Python version of my projects very easily and quickly, in case of we have to upgrade the Python version of the software.

I am a macOS user, and I use a lot HomeBrew. Unfortunately, HomeBrew is not a great solution to keep a trace of multiple versions of a given build (especially the interpreters)… I can take a look at each source code in python.org, download the one a want, build it, and set manually all my paths in order to retrieve the Python version I want for a given project. But, we are in 2018, and I figured that someone already automatized this thing.

I was right.

This tool is called pyenv, and is a very simple Python package manager for UNIX-like systems.

What is `pyenv` #

pyenv is a Python package manager, focused on the interpreter and famous Python associated tools (easy_install, pip, etc…). pyenv was originally forked from rbenv and ruby-build for Ruby, and modified for Python. The project is composed, principaly, by shell scripts, and totalized nearly 12,000 stars on Github on 22th of July, 2018.

Installation of `pyenv` #

For macOS, using HomeBrew, the installation of pyenv is very simple: brew update && brew install pyenv. That’s it.

If you are not on macOS, or if you don’t want to use HomeBrew for that, you can check the automatic installer on Github.

pyenv uses an internal system calls shims to enable the search of the Python interpreters (and associated tools), and enable autocompletion. In order to use those binaries, you just have to enable shims and autocompletion using eval "$(pyenv init -)" (remember to add this line on your .bashrc or .zshrc).

Ok - now, pyenv is installed on the system…but there is no interpreter on your system yet.

Promises #

Install a toolchain #

First, you have to install a given Python ecosystem version (interpreter, and associated tools) on your system. If you check first the versions you have installed, using pyenv versions, the output is empty.

NOTE: Along the versions option, there exists the version option. versions returns the toolchains you installed on the system, but version returns the toolchain(s) you are using on the current session.

First, let’s try to install the version 2.7.15 of Python:

~ pyenv install 2.7.15
python-build: use openssl from homebrew
python-build: use readline from homebrew
Downloading Python-2.7.15.tar.xz...
-> https://www.python.org/ftp/python/2.7.15/Python-2.7.15.tar.xz
Installing Python-2.7.15...
python-build: use readline from homebrew
Installed Python-2.7.15 to /Users/acarette/.pyenv/versions/2.7.15

As you’ve seen, pyenv will download the 2.7.15 version of Python directly from the official Python servers, and will compile and install the binary directly for your system, on your system. If you are wondering where is the build, you can check the folder .pyenv/shims in your $HOME.

Now, let’s install the 3.4 version:

~ pyenv install 3.4
python-build: definition not found: 3.4

The following versions contain `3.4' in the name:
  3.3.4
  3.4.0
  3.4-dev
  3.4.1
  3.4.2
  3.4.3
  3.4.4
  3.4.5
  3.4.6
  3.4.7
  3.4.8
  miniconda-3.4.2
  miniconda3-3.4.2
  stackless-3.4-dev
  stackless-3.4.1
  stackless-3.4.2
  stackless-3.4.7

Oups - what the problem here? The problem is we were not specific at all, when we asked to install the 3.4 toolchain. Indeed, the 3.4 version is a major version of Python 3, and there exists multiple minor versions of 3.4. So, pyenv was asking to specify the minor version of the major version we asked for: pyenv install 3.4.8.

Note: If you look more closely at the error message, you can see that you can install multiple versions of anaconda via pyenv - so, the tool is not exclusive to Python builds but the Python ecosystem.

Global usage of a toolchain #

If you have more than 50% of your Python projects that are using the same specific version of Python, maybe you want to use this version as a global one on your system. pyenv can override the default Python version of your projects using the global option.

So, if you want to use the 3.4.8 version of Python as the default one, ask to pyenv to override it: pyenv global 3.4.8.

Now that Python 3 is different than Python 2 (actually, it may be a new programming language by itself…), maybe you want to override a default toolchain for Python 2 and for Python 3 too. You can do that using pyenv global 2.7.15 3.4.8.

Using this feature, when you want to use python2, it will reach Python 2.7.15. Also, if you want to use python3, it will reach Python 3.4.8.

You can see this behaviour on typing pyenv version (*no s at the end of version!):

~ pyenv version
2.7.15 (set by /Users/acarette/.pyenv/version)
3.4.8 (set by /Users/acarette/.pyenv/version)

Now, what happen when we want to use python?

When we asked to override the default toolchains, we gave to pyenv an order: 2.7.15 before 3.4.8. So, using this configuration, it will reach Python 2.7.15 first. If you want to override this behaviour, in using Python 3 instead of Python 2, you can do that switching the previous versions: pyenv global 3.4.8 2.7.15. Using this configuration, if you launch python, it will be the 3.4.8 toolchain:

~ pyenv version
3.4.8 (set by /Users/acarette/.pyenv/version)
2.7.15 (set by /Users/acarette/.pyenv/version)

Local usage of a toolchain #

The previous section explains how to define defaults toolchains in the entire system. Now, what if you want to work using different toolchains, on different projects?

pyenv can override the default Python toolchain for a given path (or project), creating a .python-version file at the root of your Python project. To do that, you need the local option.

So, using the local command, on a local project, each time I will want to use python, the shims will check if an overrided Python version has been done for this project. If a .python-version file exists in the current project, pyenv will launch the toolchain described in the file. Otherwise, pyenv will execute the first default toolchain.

Ok, let’s try:

~ mkdir -p Code/pyenv_test
~ cd Code/pyenv_test
~ pyenv version
3.4.8 (set by /Users/acarette/.pyenv/version)
2.7.15 (set by /Users/acarette/.pyenv/version)
~ pyenv local 3.6.2
~ pyenv version
3.6.2 (set by /Users/acarette/Code/pyenv_test/.python-version)

NOTE: like the global option, multiple Python versions: pyenv local 2.7.15 3.4.8, with the same priorities than before.

Interactive usage of a toolchain #

Python is a dynamic and interactive programming language and, sometimes, you just want to check something in the standard library, or just try to hack something on the interpreter.

Just imagine you are working on a given project, using the latest version of Python, when a colleague ask you to verify a very small piece of code using the version 3.6.2 of Python - maybe because something is struggling with the library standard of this specific version. The code to test is so small that it would be overkill to create a virtual environment to test it, and to put in on a totest.py file.

No, you want to test the code in a Python interpreter.

Currently, using global and local, you can’t do that. So, pyenv contributors added the shell option, in order to launch a specific version of Python in your current shell session.

~ pyenv version
3.4.8 (set by /Users/acarette/.pyenv/version)
2.7.15 (set by /Users/acarette/.pyenv/version)
~ python -V
Python 3.4.8
~ pyenv shell 3.6.2
~ python -V
Python 3.6.2

Pretty convenient, isn’t it?? :)

Conclusion #

As you noticed in the Promises section, pyenv offers great features to work easily with different Python toolchains, without scratching your head on how you can install different versions of Python in your system, for a given project. Of course, pyenv is not perfect - I still wait to install a toolchain only for a specific project, and let the tool to drop out the version if I delete the project - but it’s a very good beginning in managing your Python toolchains.

It's all about community

Mon, 15 Jan 2018 00:00:00 +0200

It’s on - my first blog post for 2018!

All my best wishes for this new year, about love, health, and love (quoting Patrick Sebastien, “love is everything”).

Ok, let’s talk about something more serious… Today, I want to talk about Rust. Yes, Rust, again. But this time it’s not about something I discovered, implemented or anything along the lines… You know, during the two last years, I tried to “promote” this programming language everywhere, because I strongly believe in Rust. I made two different talks at two meetups in Lille, attended to several Rust events and conferences, and each time I was thinking about how awesome the Rust community is. And now it’s time to make a blog post for this. So, I want to talk from the heart about the Rust community, and how it is awesome to see people building an awesome project together.

Do note that, sometimes, I use the word “we” to design the Rust community, and this blog article reflects only my feelings as a Rust fan since 2015.

People are all equal #

The first thing I noticed initially when starting with Rust is how the community is mature. I think that the maturity came because: 1) the community is pretty small, 2) every member shares the idea that people are all equal. The strongest rule of the community is that every member of the community must respects the other ones, and don’t be toxic to each other. This is, I think, the core of the current community, and it encourages people to never be afraid posting something, or to ask for help in a problem that they think is dumb (remember that no question is stupid - no one).

People are everything #

Some developers are unhappy that the Mozilla Foundation is sponsoring Rust, because they think that its future will only focus on what Mozilla products need, and not on what Rust developers need. It is true that this kind of incidents happen (actually, it had happened in the past and continues to happen even now), but, here, it’s totally different. Some of the Rust maintainers are hired by Mozilla but, every day, those persons are listening to your needs and your ideas (via public RFCs), asking what you wanna do with Rust, how to help you with your daily issues, or how can they improve the language for your projects. This is making the difference, because benefits happen in both directions: you, as a developer, feel integrated into the community, and the language can evolve and become even richer for everyone.

A perfect place to learn #

The Rust community strongly encourages the “newbies” to learn Rust, and we (members of the community) are here to help them in order to build and deploy in the most simplest possible way their project(s), simply because we believe in people. At this moment, 1,985 people have already contributed to the Rust compiler on github, for 50 releases and 73,379 commits, which is a huge success for an Open Source project. Just to compare with another Open Source programming language, 985 persons have contributed to the Go compiler, for 202 releases and 35,115 commits.

Freedom and excitement of exchanges #

Each week, I see on Twitter, Slack and IRC Rust developers posting blog articles, the crate(s) they are developing, or the couple of issues they are/were working on (and some hints to solve them). Do note that you don’t need to be a Rust wizard to propose an idea, and you should not be afraid to share something! Being afraid to post something on the Internet is actually the most common barrier to freedom - so, please, feel free to share whatever you want! Also, some Rust projects have become important now, because of the community’s support.

So, to conclude: feel free to join us, to discuss and to share your thoughts or ideas! We want to hear you to improve this fantastic project, because we strongly believe you can! :-)

Thanks to Alexandre and Sankalp for the English review, and a special thanks to Xavier for pushing me (every week) in writing blog posts.

Rustfest, an amazing experience

Sun, 01 Oct 2017 09:09:11 +0200

RustFest is an European event to attempt general talks about Rust, and to meet people from the Rust community.

Rustfest 2017 badge

RustFest is a two-days event. The first day is a series of talks from the Rust team (in Mozilla) and, predominantly, the Rust community about: the past and the future of the programming language, POCs, how to deal with macros, awesome new projects like 3D games, a gently introduction for developing 2D games (and how easy is it), why a company choosed to move their tech stack to Rust, etc. Each talk was a lesson: how to deal with a “rust-matic” problem, how to manage your project, how to deal with this feature, or how to present a complex subject to a various auditory.

Each people I discussed with was a huge wealth of wisdom, experience and knowledge. I discussed, drink beers, and eat (expensive) burgers, with incredible guys from France, Switzerlang, Great Britain, Germany, Sweden, Poland, Russia, United States of America, and many other countries!

To me, this first day of RustFest was more than a talks day, it was an epiphany. Rust brings us more than just incredible technology, it brings us a family. Thanks to this event, I remembered why I love Rust, and why this programming language is, actually, my favorite one. After making Zou awesome, I plan to begin to contribute to a big “Rust product”: Servo, thanks to Simon Sapin.

Also, Zürich is such a beautiful place to host this kind of event.

Thanks a lot to the awesome speakers: Felix Klock, Élisabeth Henry, Geoffroy Couprie (your love for macros is insane man! :-)), Alex Burka, Mohammed Makhlouf, Thomas Wickham, Igor Matuszewski, Niklas Adolfsson, Andrea Lattuada, Jorge Aparicio (aka “the-awesome-japaric”), Pierre Krieger, Andre “the poet” Bogus, Lisa, Fedor Logachev, and Anselm Eickhoff, thanks for the RustFest crew (I don’t have your names, but I love you guys <3), the sponsors and all the people and institutions who helped in creating, promoting, and maintaining the event.

Don’t change, you’re awesome 😘

In Rust, We Trust 🤘

Rustfest participants

Credits for this picture: the RustFest team Original tweet here

Is research innovation still belongs to Universities ?

Sat, 24 Jun 2017 08:02:35 +0000

I started my PhD two months ago, on automated ways to classify documents, and I begin to be depressed…

Since I started University in Computer Science, I wanted to do a PhD in biocomputing, combinatorial optimization, or machine learning. In CS class, Machine learning was the area I enjoyed the most - so it was natural to look for a PhD in ML. For me, research activities conduct to new innovative techniques, or tools, which have to be tested on real world examples.

As a good PhD student, I started my start-of-the-art and I began to experiment two or three ideas. So, I read about 50 or 60 research articles about new ways to classify documents, and text understanding.

The research articles I read in the area of machine learning came, in large majority, from web giants: Google, Facebook, Amazon, Baidu, Criteo…, but also from companies or startups which are related to those giants, like DeepMind. These research articles propose new approaches to classify text documents, and new ways to understand, and translate, documents. Those approaches have been tested on a massive dataset, and clearly outperform existing methods. Also, at NIPS (one of the greatest conference about machine learning and computational neuroscience), companies owned about 50% of accepted papers.

Now, I am wondering if innovative things in this research area still belong to Universities.

Maybe you are wondering why those companies are first, in this area. This is my answer:

They have massive datasets of real world examples,
They have tech’ (for example, the last chip from Google for DL, which is just amazing),
They own, or the work with, the best research scientists in AI (Y. LeCun, A. Ng, H. Larochelle…),
They have the best engineers who are working hard on this subject,
They can test their idea directly on well designed products, faster than light.

I realized, during my previous internships, that there is a hard competition between research institutions and companies. Some research institutions, like inria, share the idea that a research idea can be part of a great product - so, they propose to scientists to share ideas with startups, or to create their own startup. It’s the same thing in University of Luxembourg - for example, the DataThings startup has been funded thanks to the research ideas of a great team of scientists who are working on real time data series. So, research institutions are moving from pure research to applied research, and it’s great ! But, is this change not too late ? And is AI research area already belongs to giants ?

I know that companies, especially today with DL, would not have done these wonderful tools/products without research scientists. But I am sad those research scientists are now owned by private companies, to conduct internal research.

I am really scared that my work and research ideas are became soon outdated, because of a technology that exists since a few years, but has not been released yet due to private IPs or something like that. Also, how can you be peaceful if you know that companies can explore, implement a solution and draft a paper about it faster than you ?

Actually, I am depressed… but I am not giving up.

My new year's resolutions

Mon, 02 Jan 2017 19:32:13 +0100

Happy new year !

I hope that 2016 has been great for you. For me, 2016 was mixed: good (my internship at Montreal, my graduation and a pretty cool job) and bad times (many assassination attempts and, obviously, the election of Trump).

This year, we increment (again) the counter, and pass from 2016 to 2017, and I hope that this new year will be full of love, tolerance and respect.

In this blog post, I show you my personal resolutions for 2017. Because, as you know, a new year comes new resolutions !

A healthy spirit in a healthy body #

This year, I have to loose weight! A lot of weight! And, to loose weight, I have to exercise myself, eat healthier, and respect my sleep cycle. I wish to continue fencing, or to put on my rollerblades to discover new areas of my city… but I am lazy! :-(

To practice a sport and eat two burgers per day at lunch is (really) not a good method to loose weights (unfortunately…). So, with my girlfriend, we have pledged that 2017 is the year of some healthier diners !

Come on Antonin, five fruits and five vegetables per day… You can do it !

Read, read, and read again… #

I love rea but, unfortunately, I didn’t read as much as I wanted to in 2016. This year, my second resolution is to read MORE: a book (fiction, biography, …) every two weeks, and a research article per week (because to keep me informed about computer science researchs is important for me, and because I miss computer science research) in machine learning, compilers and operating systems domains.

One big free/open source contribution this year #

During the last month, I realized that I am not particularly good to begin and maintain a computer projects. So, instead of developing something, I want to contribute to a big free and/or open source project. My choice is to contribute mainly to Redox-OS, a Rust operating system. The community is great, the project is big, awesome and important, and Redox is written with Rust! Just the perfect project to involve myself in :-)

Mastering three “new” programming languages #

My main programming language is Python. I spent virtually four years to be really good using this programming language and, in all modesty, I’m pretty good using Python. But Python is boring now, and I want to create and contribute to projects using typed and compiled programming languages. So, for me, I will perform myself with :

Rust,
Ocaml,
and Nim.

The goal, for me, is to acquire some automatic reflexes for each of those programming languages, and to contribute to one big free and/or open source project (for each one).

Back to GNU/Linux #

Yes, I was wrong… macOS is cool but I miss a good operating system to contribute in strong computer projects like Redox-OS. Also, I think that 2017 will be the year to free myself about some “big brother” companies like Google, Apple, Dropbox or whatever… So, to begin the year with a free operating system (Arch Linux I think) sounds a good investment ;-)

The Hot-Pepper approach

Thu, 01 Sep 2016 13:41:55 +0200

Note: These observations are reported in my research report here, and a research paper is currently drafted on this. The source code of this approach is visible in Github.

During my final internship at LATECE in Montreal, I developed an approach, supported by a Python framework, to evaluate the energy consumption of Android bad practices, using the source code of the app. This approach is called Hot-Pepper. Hot-Pepper helped us to find that 3 popular Android code smells may be considered as energy code smells: HashMap Usage, Internal Getter/Setter and Member Ignoring Method. Also, it permits to evaluate picture practices, in terms of energy consumption, like formats (PNG vs JPEG), picture size (original JPEG and compressed JPEG, without degrading the quality of the picture) and picture bitmap formats to use (ARGB_8888 vs RGB_565).

Using this approach, we improved the energy consumption of 5 popular Android apps.

The approach is automated and really easy to use. It required:

the original Android source code of the app,
a smartphone plugged to a measuring device (ammeter, voltmeter, …),
a scenario based on user events (Calabash, Robotium, …).

The output of this approach is the source code of the most energy-efficient Android app, and the associated APK to deploy it immediatly in popular app stores.

Hot-Pepper consists in 3 steps:

detect and correct of Android bad practices,
compute energy metrics,
analyze energy metrics.

The first step uses an improved version of Paprika, a Java application to detect statically Android code smells in an Android APK (if you are interested in using this tool, you can contact Geoffrey Hecht here, the creator of Paprika, to obtain an access). The two last steps use Naga Viper, a software that compute and analyze dynamically some energy metrics, collected on an Android app. I developed Naga Viper and some Python libraries during this internship, and it works well!

I am somewhat disappointed to not have developed Naga Viper using anything else than Python (always better than Java but…) and to not have deploy the framework in the cloud. First, I wanted to use Rust or Golang to implement Hot-Pepper. But many students don’t know these programming languages, and are not interested in understanding the advantages of those languages for this project (do you feel the frustration in my words?). The second thing is that my demand to implement the framework with a new language has been understand, and that the framework will be deploy in the cloud after the new version in… Java (-_-).

Also, I tried to develop a tool, called Ghost Pepper, which develop automatically interesting scenarios using user events, for a given Android app. The development of this tool has been more problematic than previously thought, especially to maintain a good ratio between the exploitation and the exploration of the app (the tool uses a genetic algorithm to create a new scenario), and has not been fully tested to use Hot-Pepper on selected apps.

Hot-Pepper takes me less than 4 months to have some accurate and repeatable results.

Even if it works well, the approach may be improved, and I hope Android developers will use this approach to care about the energy consumption of their apps.

Five advices to future research interns

Wed, 10 Aug 2016 10:36:51 -0400

During undergraduate school, I completed 4 research internships and one research project. I learned a lot during those, especially how to reason in order to resolve a science problem. Most of my friends are continuing in PhD. I don’t. Not because I’m fed up but unfortunately for personal motives.

Research projects are great for major things like: diversity, creativity, no pressure to develop a working prototype, to be part of the dynamic and awesome scientist community… Really guys, research is awesome.

BUT, a research internship can be really hard, and this one can revolt you with research for a long time.

I propose 5 questions you have to ask yourself before to search or accept a research proposal, based on my personal experience.

Is the research proposal interesting me ? #

You just received a research proposal! 4 months in Nuuk to study quantum mecanics and properties of a thing you never heard it before… Are you REALLY sure that it interests you?

The research proposal is the first thing to check, and you have to ask yourself those questions:

What is the research structure which proposes you this opportunity ?
Is this research subject up your alley ?
Is this research domain totally new, the “new sexy” or already closed ?
Am I interesting in working on a problem and, maybe, not found a solution in resolving it ?

If the research internship is in a foreign country, don’t forget it can be difficult to be far away from your family and your friends. You can ask also if you have to work with an other intern on this project - teamwork can be cool, but also very painfull and can break your concentration and your motivation (trust me). Oh, and don’t trust some research teams that can tell you during the internship interview: “Come on, you can be the next Steve Jobs!”. You will not improve your commercial skills ;-)

Do I have a good english level ? #

If you are afraid to read english papers, or if you find that read research papers is boring, STOP NOW! Research is not for you.

If your english is not so good but you are interesting in reading papers about interesting subjects or new fields, you can practice and improve yourself during this one. My english is poor, but I am persistent in improving myself everyday!

Reading papers and new proposals takes part of our (research people) daily life, and it has to be a pleasure to discover new things and make your own critical analysis of a subject. Also, be warned about the possibility to write yourself a research paper. Glory and suffering…

Am I interesting in working hard, harder and harder again… ? #

I remember the time that I worked 12 to 14 hours a day during the 3 last weeks of an internship to finish a research paper, collaborating with a PhD on it. It was really hard, but I didn’t give up, especially because the subject was really interesting and the research team I worked with was cool!

You have to be persistent and not be satisfied with the first best explanation!

Am I fearless ? #

Don’t be afraid to make a mistake and to propose your ideas! Some important historical discoveries have been made by mistake. Also, don’t be afraid to discuss with some research people, especially in english to improve yourself in listening and speaking the language.

Quoting Theodore Roosevelt, “The only man who never makes a mistake is the man who never does anything”.

Am I interesting in solving problems ? #

The last but not the least…

Personally, I like solving problems and, when I just resolved it and have some results, I discuss about them and I make sure that I don’t made any mistakes. You just have some good results and made sure that there is no bugs in your program? So, your results can be interesting, but they are fully truth (except if you can strongly prove it). To re-evaluate your results and your way to do something is essential, don’t forget it!

Don’t forget that focusing on your subject in your project is the most important thing you will have to do during your internship. For me, focusing on just one thing is my principle weakness.

Finally, if you’re still interesting in working in research, I recommend you to read the following posts, wrote by two members of Inria’s SPIRALS research group:

“The Skills You Learn in Research”, by Martin Monperrus,
“Ongoing Research”, by Romain Rouvoy.

Display text easily in arOS, using a Rust macro

Wed, 27 Jul 2016 18:46:01 -0400

In my previous post, I talk about my joy to program my first operating system from scratch (arOS), using assembly and rust code.

Steve Klabnik, initiator of the intermezzOS project, hasn’t explain his own solution to display some text on screen, easily and using Rust.

The current code to display some text on the screen is the get the address of the VGA buffer (0xb8000), and to add manually our characters, one by one…

So, actually, to display a simple “Hello world” in color green on backscreen black, the code is 0x026c026c02650248026f. Ugly? Yes!

A solution proposed by Steve is to implement a macro which take as parameter a string and will save each character in the VGA’s buffer.

Let’s try!

This is the file lib.rs which contains my ugly code:

#![feature(lang_items)]
#![no_std]

#[lang = "eh_personality"]
extern fn eh_personality() {
}

#[lang = "panic_fmt"]
extern fn rust_begin_panic() -> ! {
    loop {}
}

#[no_mangle]
pub extern fn kernel_main() -> ! {
    unsafe {
        let vga = 0xb8000 as *mut u64;
        *vga = 0x026c026c02650248;
		let vga2 = 0xb8008 as *mut u64;
		*vga2 = 0x026f;
    }
    loop {}
}

First, let’s try to save the memory address of the VGA’s buffer. We want this address global. So, we will use static.

Instead of const, static can be mutable - the advantage of this solution is to have only one instance of this memory address, and a fixed location in memory.

static mut VGA: u64 = 0xb8000;

Also, I want to store the color of the text and the background to display on screen.

static COLOR: u64 = 0x02;

0x02 corresponds to have a black background color (0) and a green text (2).

Now, we have to define our Rust macro. This one take as parameter a &str pointer - so, an expression - and have to display on screen this one.

The skeleton of the macro (let’s called it k_println) is following.

macro_rules! k_println {
    ($e:expr) => {
	};
}

Now, we have to fill this macro.

We work on memory addresses, so we have to use unsafe.

macro_rules! k_println {
    ($e:expr) => {
		unsafe {
		}
	};
}

We know that $e is a string, and we want to display each character of this string. So, we have to iterate on those characters to put each one in the buffer of the VGA.

As my configuration is little endian, I must begin to enter the character (as an unsigned 64 bits value), and after that the color of the character to display. Also, to know where to display the character on screen, I have to save the offset!

macro_rules! k_println {
    ($e:expr) => {
        unsafe {
            let mut offset : u64 = 0;
            for c in $e.chars() {
                *((VGA + offset) as *mut u64) = c as u64;
                offset += 1;
                *((VGA + offset) as *mut u64) = COLOR;
                offset += 1;
            }
        }
    };
}

Great!

Now, our definition is k_println. So, we have to pass a new line (the hexadecimal value for this is 0x0A) and let the following line to be displayed under this one (you have to update the VGA buffer pointer to the current pointer + 160 characters).

We just have to complete the code with the two following expressions, after the loop:

*((VGA + offset) as *mut u64) = 0x0A;
VGA = VGA + 160;

And… TADA! We just wrote a simple Rust macro to display easily a string in your new awesome operating system! :-D

Final code:

#![feature(lang_items)]
#![no_std]

static mut VGA: u64 = 0xb8000;
static COLOR: u64 = 0x02;

macro_rules! k_println {
    ($e:expr) => {
        unsafe {
            let mut offset : u64 = 0;
            for c in $e.chars() {
                *((VGA + offset) as *mut u64) = c as u64;
                offset += 1;
                *((VGA + offset) as *mut u64) = COLOR;
                offset += 1;
            }
            *((VGA + offset) as *mut u64) = 0x0A;
            VGA = VGA + 160;
        }
    };
}

#[lang = "eh_personality"]
extern fn eh_personality() {
}

#[lang = "panic_fmt"]
extern fn rust_begin_panic() -> ! {
    loop {}
}

#[no_mangle]
pub extern fn kernel_main() -> ! {
    k_println!("Hello, World!");
    loop {}
}

I am writing my own OS

Tue, 26 Jul 2016 00:01:00 -0400

My fascination with computers turned faster as an obsession.

I’m obsessed with my machine. Really, I’m not feeling all right if I don’t clean up my machine physically every week, and if I don’t reinstall a new clean operating system each 6 months. Obviously, before each clean install, I overwrite my entire hard drive with zeros… which takes me a full day for a 1 TB hard drive.

When I was using a GNU/Linux OS, and before installing a new operating system on my computer, I always look up on distrowatch what’s new in the GNU/Linux world. What is the new fashion OS, new version of my favourite OSs, new forks, new OSs, etc… So, it happened (a lot) that I install a new operating system each 6 months, just to test it, see what’s new, the stability… and reinstall an ArchLinux maybe 3 days after.

Archlinux, Debian and ElementaryOS are my favourite OSs. Archlinux because it’s really modulable, and you can install what you want without have some garbage applications like basic mail clients, video and music players, or even Amazon packets (just 4 you Ubuntu…). Debian is really stable, but I install it only if my computer have more than 2 years, just to be sure that packets to manage for example my GPU is accessible and can be install/run without make some wizard things. Finally, I use ElementaryOS a lot for recent machines, especially because the base of this OS is Ubuntu, and I didn’t have some troubles using Ubuntu packets for recent hardware. ElementaryOS is pretty stable and Pantheon, the desktop, is really ergonomical and beautiful - inspired by macOS.

The operating system is the second software that the machine launch, after the bios. The operating system manage, by itself, some sort of things: processes, interruption handlers, memory management, events from external devices like Keyboard, etc… It’s a magnificient piece of engineering, between you and the hardware.

BUT, I don’t know how works really an operating system. I mean, I take some courses like “Architecture of Operating Systems” at university, I’ve got a large comprehension of what an OS do and how he can do that, but I never programed one. And, in computer science, like some teachers and research guys told me: “If you want to learn or just want to know if you had understand something, try to program it!”

I’m using Rust since 1 year now, and it’s a wonderful programming language. This language has been developed by the Mozilla foundation to avoid some problems due to using C++ for their products, especially memory leaks and error management. In june, a first version of Servo, the faster and most memery efficient modern browser engine ever made, has been released in a basic web browser - just a public ALPHA. And the project is REALLY AWE-SOME! Rust rised up recently the 1.10 stable version, and a lot of awesome projects are currently been build using this language.

Personaly, at the beginning, I used Rust a lot to port my slow Python projects into a faster and memory efficient program, but also during my combinatorial optimization courses, to prone usage of modern programming languages and also “4 fun”. During October/November 2015, I started to contribute to RedoxOS, a hobby operating system. RedoxOS works actually on Qemu and VirtualBox, and is written in Rust. The perfect project for me to contribute to a cool project, learn some things about operating systems and to improve myself in a cool programming language like Rust.

But the project is really big, there is a lot of contributions per week and the code is optimized to be not understandable sometimes…

So, to perform myself in 1) contributing to build the best operating system in Rust as possible and 2) improving myself in Rust, I decided to create my own operating system in Rust.

I called it arOS, for another rust Operating System.

Steve Klabnik, a famous Rubyist, just started a project called intermezzOS. This project is an hobby operating system, written in Rust. intermezzOS is open source, and anyone can see the code and reflexions behind this project, using the online book. Steve made this project by himself, “just 4 fun”. Also, as the project is currently building, he release some news and code regularly.

Currently, the final chapter is about how to link Rust code in your boot assembly code, which is the base to begin to program your own OS in Rust.

During 4 days, I followed the tutorial of Steve Klabnik. My code is kinda similar to his one, but I’m completing my learning programming a VGA driver by myself, which is the next chapter of the tutorial (and it’s not easy, trust me…).

During these 4 days, I was fighting with the nightly version of Rust and his feature tags. These tags are incredibly usefull, but there is much features for the nightly version that I’m completely lost sometimes… It was the first time that I creating some extern and unsafe code in Rust, that is really strange and completely exciting! Also, I wrote some assembly code during my classes, but not as well as the boot and multiboot assembly code showed in the tutorial.

This project is really interesting, and I just learn usefull things about assembly code, how to link Rust code, and some optimizations made by rustc, the Rust compiler, for projects which has to use less memory as possible.

This project is not really serious, just for learn and just for fun :-)

My next step, after the VGA driver, is to port this OS for the ARM family (a Raspberry Pi for example), using Qemu to test all long the operating system.

Computer science facts, in movies

Sun, 08 May 2016 01:34:34 -0400

I love watching movies. I see almost four of five movies per week, without any subject restriction. One of my favorite movie director is David Fincher. He is the director of Se7en, Panic Room, Fight Club or Gone Girl. But, above those ones, for me, David Fincher is the director of The Social Network.

The Social Network takes part of my ten prefered movies ever. The direction is awesome, actors are awesome, music is awesome and… it talk about tech! I love movies which talk about technologies, especially how the director has represented the computer science’s complexity, and see if facts are true or not.

Since Wargames, hackers are strongly represented in movies: Hackers, Swordfish, Firewall, Hackers 2, BlackHat, Computer Chess, Ex Machina, Live Free or Die Hard, The Fifth Estate,… and pretty soon Snowden!

These movies are popular in the pop-culture, but mostly are poor in real computer science’s things and/or hacker culture. You can just differenciate two sort of hackers: white hats (hack for science and for security things) and black hats (sort of evil thing of hacking). Most part of hackers are white hats, and do the things right (remember that, if you are a computer programmer, you are also a hacker).

Today, in movies, hackers are representated as bad guys dressed in black, have some social problems, type some (bad) C/C++ code in an unknown interface (in maybe just 10 seconds - world record!) and drink a lot of soda. Movies talking about “hackers” as black hats are, to me, pretty bad movies (even if the visual and scenario is great).

LOL. #

Very funny to see that movies screenwriters and directors thinks again with stereotypes, and don’t make some researchs before… This is zero sense. I don’t know if you are aware with TV-shows, but I strongly recommend you Mr. Robot, one of the best TV-show I have ever seen: the direction is perfect, the scenario is great (as if the first character is build from hacker’s stereotypes) and hacking and computer science appearances are relevant.

Some science-fiction movies play with computer science and enhance the domain, like Tron or Minority Report. In 1999, The Matrix imposed machines as leaders and dictators, artificial intelligence as the final intelligence and humans as slaves. Also, for the Human race, the virtual life is just cooler than the real world during the time that their energy is drained to put on new machines in the real one… Pretty optimistic screenplay! The story of the Matrix saga is pretty cool and the world that this saga built is just awesome. Also, I invite you to take a look at The Animatrix - an animated treasure!

There are not many good movies talking about IA and force you to think about the place of the machine today. We can cite for example 2001, a Space Odyssey, Wargames, Ex Machina, Ghost in the Shell (the original movie and the original sequel), Blade Runner, Her,…

Fiction is just Fiction #

To finish, there is the bad good idea that we can just adapt the story of a great figure of the computer science domain at theatre. In rare occasions (The Imitation Game), don’t forget that these movies are fiction movies! You can find some historic facts in these movies, but the truth is not there! You will not learn some things about Julian Assange watching The Fifth Estate, the truth about the relation between Jobs and Gates in Pirates of Silicon Valley and, as the video trailer shows, Snowden will not be as credible as the reality to tell the story of the Snowden’s leaks… You have to be warn before to watch these movies, and do not hesitate to ask or to search by yourself about the truth in the (pseudo) tech’ movie you are watching (Reddit is really useful for that).

What else? #

Ok, so now you want to watch some movies about tech’ but you don’t know which? This is a short list of movies, documentaries and TV-Show to watch:

Tech’ fiction movies: Wargames, Her, Ex Machina, The Imitation Game and The Social Network,
Hackers movies/documentaries: Codename Linux and The Internet’s Own Boy,
TV-shows about tech’ and hackers: Mr. Robot, Halt and Catch Fire and Silicon Valley (just for fun).

Picture from Silicon Valley (HBO), S03 E01.

Contributing in maintaining free and open source projects

Sun, 24 Apr 2016 01:37:32 -0400

We, computer developers, have to develop our knowledge ourselves every day. This practice allows developers to keep ourselves informed about new technologies, new solutions and security issues. For the majority of developers, this “update” is not a pain. We have choosen to work with computers due to our passion with these awesome machines, and this “update” thing is just the best thing to do to maintaining this passion.

You can, every day, consult some great tech news like HackerNews, TechCrunch, The Verge, Wired or Korben (for French guys) - and that’s already a good step. But these news not allows you to practice and to test these technologies. To do that, you have to program some things, to practice to a new programming language, or to maintain your system!

This thing can be exausted and really painfull, because, maybe, you don’t have the time to create and maintain an entire powerfull software, or the knowledge to program this one alone! So, let me introduce you the advantages in contributing to free and open source projects, for you knowledge!

To learn new things #

This is the principle objective of this post: to update you in computer science! As an inquisitive person, I’m still looking for to learn new things: an usefull technique or programming language, to continue to explore a computer science sub-domain (machine learning, software optimizations), to improve myself in coding, etc… Free and open source projects are great places to learn new things, because developers try some innovative things to build the best project as they can. Most free and open source are just some developed ideas from a single person or a small community of developers, banded together to create a new awesome computer thing. By learning new things, you can contribute for example by fixing some bugs, improving or refactoring the code, or building some new awesome features! Don’t forget that you’re free to read the code if you canno’t or don’t want to contribute, that is often a big step in improving your knowledge!

To develop new technologies #

Developers are developing new usefull technologies to improve the life of developers or common-users, and a small new feature can be the “plus” of the software that can change the story. I try to use new technologies each day, out of curiosity or pleasure. If the software embedded some awesome features, I star the repository from the version control repository (Github,Gitlab,BitBucket…) and I have some knowledge about used technologies for this project. B2GOS, Firefox, Chromium, VLC, GNOME, Go, Rust,… all these free-to-clone amazing technologies, using by thousand/million/billion of persons each day and you can contribute to!

To improve yourself #

Do you want to learn a new programming language? Check a simple project on Github to learn some efficient skills using this one! You have just found a great project and want to contribute in his development? Clone the repository, check the issues list and give yourself the objective to solve an issue per day/week/month,… A free and open source project is the perfect thing to improve yourself!

Do not reinvent the wheel #

Just imagine: you want to list all git local repositories in your systems and to pull remote branches for them, automatically at 08:00AM each day. You found a great project on Github that list your git local repositories, make some things with but, unfortunately, canno’t pull remote branches… Are you trying to make the software from scatch for this single feature and lost your time to do a simple thing, or are you clone the project, try your best to understand the software architecture and add this single feature to this awesome project? (Actually, this is not a question…)

To meet great people #

My experience in contributing on free and open source projects permits me to meet some great people in some amazing communities (Mozilla, RedoxOS,…), to discuss with them, share some knowledge and meet them IRL at meeting, conferences, etc… These people are my companions, my project colleagues, and now my friends.

And now… #

With this post, I don’t talk only to developers! You don’t code but you are interesting in contributing to free and open source projects?!

AWESOME!

Just put your core skills in practice: translation, project management, talk about the project, etc… There’s plenty of opportunity for everyone, and I am sure that you can find something interesting.

Is Skynet on his way?

Sat, 23 Apr 2016 01:38:33 -0400

Abstract #

Skynet is a technology reached by the Terminator franchise. In this saga, Skynet is an artificial intelligence which thought that the Human race is malicious, and has to be exterminated (pretty optimistic…). This artificial intelligence has been developed by engineers to help Humans for some difficult situations but, obviously (we are in a science-fiction movie), the artificial intelligence has developed itself and became aware of itself. People who are afraid of artificial intelligence always bring up this example, whenever there is an artificial intelligence success. But, is Skynet staying at the state of fiction, or this technology can be realize today?

Programmed to do something #

Artificial intelligence is a way to made his own computer to do something without explicitly programming it. John McCarthy has introduced the term in 1955. He defined the artificial intelligence as “the science and engineering of making intelligent machines”. The artificial intelligence science is vast. It can be splitted into subdomains like mathematical optimizations, multi-agent systems or machine learning. The current AI’s subdomain which reach is machine learning. Arthur Samuel defined in 1959 that machine learning is a “Field of study that gives computers the ability to learn without being explicitly programmed”.

Explicitly

A computer is a deterministic tool. This one will executes instructions you’re giving to it, and it will return to you a message or something else like a graphic in your screen. Machine learning gives the opportunity to give data to a computer, or allows this one to make some things in a based-environment, to maximize his chance to successfully make a regression on data or classify data (for example). To do that, the computer will iterate on data, try to learn characteristics from data, and minimize the number of errors he made by classifying his data. And this is an algorithm!

Stephen Hawking, the famous theoretical physicist and cosmologist, says “The development of full artificial intelligence could spell the end of the human race”. In the same article, Thomas G. Dietterich says that the real threat is “autonomous”. But the most interesting part of his speach is this following sentence: “AI systems will not become spontaneously autonomous, they will need to be designed that way”.

“They will need to be designed that way”

Ass I said, an artificial intelligence canno’t be aware to make some evil things if the algorithm has not been designed for that. A computer listen and execute some instructions, and has to be programmed to do this thing.

Don’t be evil #

We are afraid and proud about artificial intelligence success, but are we far to build a Skynet’s clone? We don’t have to forget that an artificial intelligence is developed to perform one task, like playing go. So, is a programmer, in this world, is currently trying to code a piece of program that will take control of everything? Maybe! But, to be optimistic, I think there is more chance that the Human race will kills itself that an artificial intelligence will takes control of everything…

Is Tay just a modern teen?

Fri, 01 Apr 2016 01:39:20 -0400

Abstract #

Tay is a teen-talking chat bot, built to discuss with people on the internet, specifically on Twitter. This bot is a creation of Microsoft’s Technology & Research and Bing teams, and was released eight days ago. A few hours after the release, this bot has been known as a crazy and racist bot, an Hitler-loving and a feminist-bashing troll. Tay is now off for several days/weeks or maybe months.

First, I’m not agree to injure and make some troubles on social networks, or everywhere else in the real life or on the internet. Also, to see a technology just says some horrible things makes me really sad. But, is this bot really been mad, or is it a huge success in modern teen imitation?

Let’s talk about machine learning #

Today, modern artificial intelligence applications are using two famous machine learning techniques: reinforcement learning and artificial neural networks. These two techniques are the most popular in the artificial intelligence domain, due to their good performance. Also, they can be paired up, like the AlphaGo algorithm.

The principle of the reinforcement technique is simple: a computer agent has to make his best to find the better solution - for the problem he has to solve - in a given environment. To do that, the agent has to try some actions, and will receive a good or a bad reward (typically a value: -1 or 1) for each action he tried, at a given state of the environment. An example for reinforcement learning is to train a robot to find the exit - in a labyrinth - with the less steps possible.

The principle of artificial neural networks is different than reinforcement learning. This supervised technique is based on biology’s neural networks, and the first artificial neural network has been developed in the 50’s by Frank Rosenblatt, with the perceptron model. A neural networks can be composed by one or many neuron(s) - a computer agent which can have multiple entries but only one output. Each entries have a weight. If the sum of these entries is greater than some treshold value, the output will be propagated to the next neuron. Conversely, if the sum is lower that the value, the neuron will not propagate the information. An artificial neural network example can be the digits recognition. Also, for your information, this intelligence artificial’s technique is the basis of recent works named deep learning.

Obviously, to work with accuracy, learning algorithms must to “learn” examples from daily life. Real examples, that you can found in the nature.

Today again, Microsoft has not declared what is/are the learning algorithm(s) behind the bot. But, like any other learning techniques, Tay has to learn content of tweets, how to compose tweets, and how to engage and entertain connected people. This learning exercise is made offline and online. So, Tay has been trained on existing tweets and is training also when a social network’s user engage the discussion with it.

Tay’s adaptation #

Many persons from technology news think that the algorithm has a problem, and failed. Microsoft search team, in a post, confirms. Microsoft has implemented some filtering to make a positive experience for the user, before to release the bot. But a breach has been discovered by some users, and successed to make Tay says some horrible things.

To me, this part of the project is a fail, but not the goal of the project. This project is just another artificial intelligence success. Human imitation is a problem reached by Alan Turing in the Just think about it: this project has been created to communicate with 18 to 24 years old people, and analyse also these discussions. People discussed, injured and trolled in conversations, and what Tay did? Exactly the same thing. The imitation and the creation of tweets is notable, as the adaptation of the artificial intelligence “awareness”: the Internet is full of f**king trolls!

So, do you think (too) I can now replace my “it” statements with “her”…?

Cover picture from ubergizmo.com.

Choose the one

Wed, 30 Mar 2016 01:40:25 -0400

Abstract #

We, humans, need to communicate to better understand each other, and what we can do together. This communication must be mutual. Thanks to this one, we can better understand what we want to do, what we have to do and what to be done. The communication can be start between 2 persons, or more, using a dialect called language. The language contains words, made with at least one symbol (basically, a character).

It’s the same thing with a computer. A computer can’t understand what you want if he can’t understand you. A computer only understand 2 symbols: 0 and 1, and it’s impossible to write a program with these 2 symbols only. So, we use an understandable language which can be translated into bitcode for the computer. This understandable language is called a programming language.

As I said, the communication must be mutual. When you have to communicate with a computer, you have to type a set of instructions on your keyboard, composed with words, and the machine will understand what you mean if you had composed correct instructions (checked by a compiler or an interpreter). After that, the computer will compute and return to you the result, in your language (it can be a set of strings, integers or a simple message which tells you “It’s ok God, I just finished the process!”). So, you have to choose the perfect programming language to have fun, while remaining perfectly understandable to the computer. A question that developers (commonly young developpers) ask themselves is: “What is the perfect programming language to use in daily life?”.

I will not fall into the trap of why I use this programming language instead of that other one (sorry trolls), but I will try to explain clearly how to make your choice. At the end of the article, you will understand that there is no best programming language to use in daily life.

First of all, you have to find a good language to communicate with the person you want to discuss. This language can be use by both of you, or only by yourself if the other people understand what you’re saying but are not enough confortable to talk to you with the same one. For programming, it’s the same thing, except you can choose the language to talk to your computer. So, we can say you’re a God, right? And you have to choose a programming language adapted to your task. In computer science, the adaptation is one of the most important thing to think about. So, ask yourself this question: “Does I really need to choose this programming language to do this, or can I choose an other one more pleasant and efficient?”.

The quest for efficiency #

Efficiency can be interpreted in different ways:

the platform you want to program (generally your OS or your computer architecture),
the program’s goal,
libraries you have to use to build it (this part is really important),
your ability to write code with a programming language you already know,
the programming paradigm the most adapted for your task,
the global performance of the programming language (you can visit the website The Computer Language Benchmarks Game if you are interested in performance),
and other subways like the time you have to program it…

This is a lot of tasks you have to take in care, but this list contains some basic things a computer developer have to ask himself before to code. Don’t be afraid. After practice, answers will obviously come to you.

The platform #

Generally, modern programming languages are independant to the platform you’re programming. But, you can be drift along to choose a programming language instead of an other, perhaps more convenient for the platform you want to launch your computer program. Today, there exists more and more different operating systems and system architectures that it’s really hard to make a good choice, and to be the most general as possible. A good multi-platform programming language is typically Java, because the program is transformed into bytecode while he’s compiling, which can be run into a platform which have the specific Java Virtual Machine you programming for. It’s can be awful to develop a program on a Linux distribution, to deploy it on Github, and to receive some negative impacts on this one because the program doesn’t run on Windows… Also, if you don’t have the specific operating system on which your code failed, it will be hard to debug it. This example works with low-level programming languages like C or C++. Also, some programming languages can be specific to a platform. For example, Windows and the C# programming language, even if some developers and companies are releasing their programming languages source code, to move them on new platforms (like Swift or .Net).

Goal of the program #

You will not code a piece of program in a low-level programming language (like C) to write a textual game, right? If you don’t have some sadomasochistic ideas, you will choose a more high-level programming language to not torture yourself with buffer overflow. Also, don’t hesitate to use some frameworks, especially web frameworks. For example, if you have to create a simple website and if you’re not good with PHP as well as Python, do not hesitate to take a look at Django.

Libraries you have to use #

Be decent with yourself: you will NOT only use your code in your program (except if the code is really simple, or if you are a programming language developer). You’re trying to write a game without graphic libraries? You’re kidding me, right…? You’re trying to write a program like CryptoCat without using Maths libs? You’re kidding me, right…? You’re trying to write a program without standard libraries? OMFG, YOU’RE KIDDING ME, RIGHT!? Hand on heart that 99.9% programs you will code or contribute will contains libraries. If they are not good, not well documented or not efficient, you’re screwed! So, to choose a programming language by available efficient libraries is a very good point.

Your ability to program with a programming language you already know #

Let me give you an example: It’s Sunday, 22h32, and you forgot you have to send your programming homework (a basic shell for example…) to your teacher until midnight. Suddenly, you decide to learn a new programming language, and to program the shell with this programming language! It’s ok, you’re good in programming and you decide that you will program a shell with… Logo! Congratulations, this is the worst idea you ever had! This example take advantage of 2 very bad ideas: not using your ability to program with a language you already know, and not using the goal of the program to choose the language. In this example, one of the perfect language to implement a shell is C/C++, due to the low-level goal of the program and the popularity of those 2 programming languages. Don’t forget: to not be perfect with a programming language is not bad! You have to practice each time you have the time to be better with this one. More and more you practice and more and more you will be better! Also, I support you to participate to open source and free softwares, or simply read the source code. This simple task can makes you better programmer than ever. Last thing: if the task is really simple, don’t forget to choose a programming language easy to use (please to see my example with Django overhead).

The programming paradigm #

The programming paradigm is one of the important thing to take on board. To write a simulator zoo without take care of objects programming can be really hard to maintain over time. Also, it can be fun to write a compiler with a functional language like Haskell, Ocaml or F#. Also, famous programming language merge now many programming paradigms, like Scala which merge object and functional paradigms, or Ocaml where you can choose to program with objects, with functions or imperatively. The programming paradigm is also important if you free your source code. Many programmers today use the objects oriented programming, and your project can be better understand and better known if you choose this one.

Global performance of the programming language #

Today, programmers search about performs programming languages for heavy or redundant tasks. In the book “In the plex”, Steven Levy give an example while explaining that the first web server wrote by Larry Page and Sergey Brin, the founders of Google, used the Python programming language. This web server canno’t serve more than 10 requests per second, due to the implementation of the code (very basic) and the usage of the Python programming language. So, one of the first engineer of the company had to rewrite entirely the web-server with a more efficient programming language, to take care about the number of queries per second the web-server can receive. Also, please to ask yourself what you really need: a compiled program (which will take care of compiler optimizations), or an interpreted program (like Python). Interpreted programming languages are better to make such simple things like a text parser or an HTTP traceroute. But, if you want to create a stronger program (a video-game from scratch for example) and if you take care about software optimizations, you have to choose a compiled programming language like C, Java, Go, etc.._.

So what? #

If you are a newbie (no offense, this is not a disgrace), do not hesitate to conduct research about which is the best programming language to begin, but I invite you to try many programming languages and many programming paradigms to think about pros and cons and what is the language you prefer. Today, programmers can be critical with modern programming languages (an example here for Go) because the programming language doesn’t respect some older programming codes established by their senior (basically C or Java). My advice is: don’t limit yourself to these criticisms, and **try **those programming languages to have your own opinion!

Cover image from https://community.spiceworks.com/topic/576245-the-magic-of-programming-language