Colas.Nahaboo.net - Blog

AI without AI

2026-08-08T00:00:00+00:00

Generative AI is currently morally bad, as most of it steals copyrighted works — but it would still be useful for people like me with no drawing skills. So I am increasingly using "AI without AI".

That is, I just post the prompt I would have used with a generative AI, and let the reader use his own wetware (aka "Brain") — the NI (Natural Imagination) — to visualize the picture.

As an example, in a reply to John Scalzi's post on Bluesky I described the book cover instead of generating it via AI:

And for some AI-without-AI, here is the prompt to generate the cover in your own wetware (aka "Brain"): «A book cover for the next Sci-Fi humoristic novel of the fictional author John Barefoot titled 'The Brother Laser Printer Aficionados'»

The nice thing about running prompts on your wetware is that the model is local, free, and the output stays in your head. No credits, no seed, no style references, infinite resolution, perfect privacy. It renders instantly — the only downside being that nobody else gets to see the result.

Also, it is something that has bothered me for a long time. As a boy, I was struck that during his famous 65-day survival drift across the Atlantic Ocean in 1952, narrated in his book Naufragé Volontaire, French physician and adventurer Alain Bombard — aboard his boat l'Hérétique — took only a few personal items, including a pocket score of Beethoven's string quartets (specifically the 15th String Quartet in A minor, Op. 132) alongside Bach's Passions. He recounted that studying and mentally playing this complex music helped keep him sane and motivated during extreme isolation and hardship.

I loved listening to Beethoven, but I could not fathom somebody actually "listening" by merely reading the score. It turns out he was doing AI-without-AI, ... decades before AI.

And now... start posting!

2026-08-07T00:00:00+00:00

I must say, I have been toying with the idea of posting more regularly here for a while. And now, at last, I decided myself to really start posting.

Let me reassure you right away: this is not a social network. I will not post reactions, reposts, or random thoughts the moment they cross my mind — no, I will not become yet another feed of instant takes. The last thing the world needs is my version of the Bluesky noise. What I will post is things that pertain to my actual activities, not my mood.

Which means: mostly coding and surfing, the two obsessions that occupy my days since I retired, and everything that surrounds them. The occasional silly waste of a full weekend on an obscure terminal command that only I will ever use. The existential satisfaction of a clean configuration file. A tool I built and decided to share openly.

Does this mean a post every single day? No. That would be a nice pledge, but I know myself too well to pretend I will hold that rhythm. I made that mistake once, in 2021, and I was right to be skeptical of it. So: no strict schedule, no guilt, just a sincere intention to write more, and to write about things that matter to me.

There is a quiet pleasure in it. Publishing on a corner you own, with zero algorithmic pressure and a total absence of pop-up newsletter modals, feels a bit vintage — like casting a message in a bottle into an ocean of infinite scroll. What changed is that now, this message may be found not by a human reader but an AI agent that will feed it to the giant automated ideas fisheries that has become Internet.

So, here is the promise I make to you, dear biologic or electronic reader: One post every single day, until ... not.

Migration of this site to the new Zola Tera2

2026-08-06T00:00:00+00:00

I migrated this site to Zola 0.23, released yesterday with the new Tera 2 template engine (Well, 0.23.1 from today actually). When I chose Zola last March, I praised its creator for not chasing the latest fad. I stand by it: 0.23 breaks my templates, but it does it in a cleaner way.

Tera 2 removes the old macros and imports, and Zola 0.23 removes the shortcodes. Everything is now a namespaced component. A macro that I used to import and call like this:

{% import "macros.html" as utils %}
{% macro show_link(url) %}<a href="{{ url }}">{{ url }}</a>{% endmacro %}
...
{{ utils::show_link(url=link) }}

is now a global component with no import at all:

{% component site.show_link(url) %}<a href="{{ url }}">{{ url }}</a>{% endcomponent %}
...
{{<site.show_link url={link} />}}

The big philosophical change: components are global and no longer inherit the caller context. Every variable — page, section, config, current_path — must be passed explicitly as an argument. More verbose, but it makes dependencies visible. I like that more and more: one way to do it, and it is visible.

Tera 2 is also strict: a missing variable is now a hard error. My templates use optional chaining (?.) for anything optional, which catches typos at build time instead of silently rendering broken pages.

What concretely changed:

concat and slice filters are gone → array spread and slicing
get_env is gone → config.mode == "serve" for local editor links
include ... ignore missing is invalid → empty hook templates
get_page with fatal=false → canonical path with lang and allow_missing=true
get_taxonomy_url with name → term

The migration guide was my best map through all of this.

I use the Apollo theme as a git submodule, and as it does not support Zola 0.23 yet, I keep a small local template-only patch of it until upstream migrates. The design, CSS, and JavaScript are untouched: this was a syntax migration, not a redesign, and I did not rewrite my post contents either.

Use of AI🔗

I chose to have AI help me migrate my site. It worked flawlessly, so I encourage you to do the same. AI work especially well with Zola, as it is opinionated, and that means that there are clear ways of doing things so that AI agents do not get lost in rabbit holes trying to pursue all the possibilities of more flexible systems like Hugo.

For reference here is the first prompt I gave it to prepare the plan for the migration:

I want you to only create a document for agents ai/agents/tera2.md to summarize
how tera2 of Zola 0.23 differs from tera1 of Zola 0.22, and the plan to migrate
my site from Zola 0.23 to 0.22.

Examine the differences between Zola 0.22 and 0.23, not just tera.

Docs:
Tera2 https://keats.github.io/tera/
Migration guide Tera1 → Tera2 https://github.com/Keats/tera/blob/master/MIGRATION.md
Zola 0.23 docs https://www.getzola.org/documentation/getting-started/overview/

Take your time, be thourough, but do not modify yet any file of my site except
the ones in ai/agents/ and AGENTS.md

Then, plan the migration of this site to zola 0.23
1. not modifying the contents of the posts unless necessary for tera2 changes
2. not changing the look and feel, the UI of the site
3. adapting the various templates
4. changing my local copy of the Apollo theme I use if needed.
   These changes are a stopgap measure until upstream apollo is migrated to Zola 0.23

I use Deepseek v4 flash normally, but chose to use GPT-5.6 Luna for this migration as it is currently quite cheap and I trust it more to not go change unecessary files. And Deepseek as no vision, so it cannot check the actual visual results of changes. It helped me greatly for this migration, without any problems.

Summary of AI actions:🔗

Replaced Tera 1 macros, imports, self:: calls, and macro namespaces with namespaced Tera 2 components in the root templates and Apollo templates.
Converted the local language-listing, page, navigation, debug, file inclusion, and section-name helpers to components.
Converted the site shortcode implementations to components in templates/macros/shortcodes.html.
Converted active post calls from the removed Zola shortcode syntax to Tera 2 component syntax. This includes YouTube, snapshots, attachments, Mermaid, static-file inclusion, legacy overlays, obsolete notices, and SVG icons.
Passed explicit base_path values to components that used to receive page.path implicitly from Zola shortcodes.
Updated get_page calls to use the canonical path with lang="fr" and allow_missing=true.
Updated get_taxonomy_url calls from name to term.
Replaced the removed get_env call with config.mode == "serve" for the local editor links.
Replaced the removed concat and slice filters with Tera 2 array spread and slicing, and changed the object test to map.
Added empty Apollo hook templates because Tera 2 no longer accepts include ... ignore missing.
Updated dev/bin/site-check to recognize the new legacy component syntax.
Updated static/ZOLA to zola 0.23.0.

PDP: Publish, Don't Perish

2026-08-02T00:00:00+00:00

I stumbled recently upon Elizabeth Tai's POSSE and PESOS definitions:

POSSE: Publish (on your) Own Site, Syndicate Elsewhere
PESOS: Publish Elsewhere, Syndicate to Own Site

Which prompted me to think that after a first POSSE phase, toying with the emerging web landcape, I was doing mostly PESOS as I found that posting in topic-specific forums made reaching an audience much easier. But after some time, after seeing forums disappear suddenly, I began to POSSE-collect my scattered PESOS posts.

But now at 66, I am more and more focused on PDP: Publish, Don't Perish!

Why?🔗

POSSE and PESOS answer the question where you publish. They say nothing about the one that worries me most at my age: will what you published still be there when you are not?

The whole "own your content" movement assumes you will be around to keep owning it — to renew the domain, to pay the host, to answer the support tickets. But at 66, I am starting to think more about the opposite assumption: what happens to all this when I cannot maintain it anymore?

What?🔗

I started applying PDP years before I gave it a name. Five years ago, in one year retired I wrote:

It may sound ridiculous, but at now 61, setting things up so they do not disappear when I do is becoming an important consideration. I will thus progressively stop using self-hosted sites to publish on places that will survive me, as nobody in my family is tech-savvy enough to maintain a web site.

That was the switch from mercurial to git, and moving to GitHub. As we say in France, "the graveyards are full of indispensable men."

So, as a pun on the famous saying Publish or Perish I decided to call it PDP: Publish, Don't Perish!.

How?🔗

Over the years I have refined this into a simple triage: separate my content by how much I need it to survive me.

Transient — thoughts, rants, day-to-day musings. Keep them on this own self-hosted site. If it dies, no great loss.
For the family — photos, memories, things your children will want. Put them somewhere that outlives you and easy to use for non-technical wife and chidren, even if it costs a bit: this is where paying a reliable host is worth it. I use a Hetzner Box.
Perennial — code, hard-won knowledge, things the world might still want in 50 years. This goes into git repositories that I can thus move easily to git platorms that are the most probable to survive me, GitHub for now. I don't use facny GitHub features, to make moving or copying these repository as simple as possible.

And there is now a new, unexpected ally in the perennial column: AI. Even if I never get a single visitor on my pages on this site, I know that publishing on a perennial platform means my code will be ingested by AI assistants and become a tiny — very tiny — part of humanity's collective knowledge. I have no illusion that my contribution is a major one, but there is something quietly satisfying in the thought that my bash snippets will be digested forever by some distant neural network. The graveyards may be full of indispensable men, but their code lives on in the training data.

Am I reinventing the wheel?🔗

I did a bit of homework, and the honest answer is: no, the idea is not new. There is a whole movement around it, I just did not know the name.

The IndieWeb community has called it the Long Web for years, a concept Jeremy Keith articulated in 2008: the qualities that make a format good for the long term — simplicity, openness, standardisation — are the same qualities that make it good practice today. Brennan Brown's recent essay is the best modern treatment: the stats are sobering (a quarter of the web's pages from a decade ago are gone, two-thirds of links rot), and the conclusion is that the IndieWeb is accidentally a preservation ethic.

There is also Jeff Huang's "This Page is Designed to Last", a practical manifesto for building sites that survive 10 to 30 years — vanilla HTML, no hotlinking, static over dynamic. Much of what I did with this very site (plain Markdown files, no database, an SSG that outputs static pages) aligns with it, and the migration to Zola in 2026 was done with exactly these concerns in mind.

And if you want someone else to do it for you, the market exists: Posthaven promised to never shut down, and WordPress.com now sells a 100-Year Plan — $38,000 to keep your site online for a century. I wish them well, but it does raise the obvious question: what happens to the plan if Automattic itself does not make it to 2125?

So where does that leave PDP? I see it as the lazy man's version of all this. The Long Web is a movement, Jeff Huang's page is a manifesto, the 100-Year Plan is a product. PDP is just a reminder, for people like me who do not want to pay $38,000 or join a movement: choose your formats and your hosts with an eye on outliving you, and the rest takes care of itself. The good news is that the "correct" choice is also the simple one: plain files, open formats, and a host bigger than you are.

POSSE and PESOS assume you will be there to keep your site alive. PDP is for those of us who know we will not. :-)

Related thoughts: my single-binary fanaticism is the same reflex applied to code; the 2026 Zola migration and moving to GitHub were PDP before I had the name.

Fanatic of the single self-contained executable

2026-07-31T00:00:00+00:00

I am becoming more and more a fanatic of the single self-contained executable, with no runtime dependencies, that Go provides: one binary, forever. No npm, virtualenv, docker, flatpak, snap... no version hell.

The qualities I lived with and took for granted during my years of coding in C and shell.

To the point that when I find now a python/node/java/ruby/php piece of software I would like to install, my first reflex is to just recode the darn thing in Go. I know, I know, rewriting a perfectly working piece of software just to avoid a dependency is bordering on insanity, but the result is so satisfying... A single file that will still run in 20 years, with no upgrades, no breakage, no maintenance.

And with AI, now, it is becoming less and less insane!

(Bluepost )

Why is the US the only country to write dates as MM/DD/YYYY

2026-06-09T00:00:00+00:00

In short: chance, followed by isolation.

Before the late 19th century, there was no international standard for writing dates. In both Great Britain and the American colonies, people used two formats interchangeably.

You could write Month-Day-Year (e.g., "October 31st, 1776"), which matched the spoken phrase "October 31st."
Or, you could write Day-Month-Year (e.g., "the 31st of October, 1776"), matching the spoken phrase "the 31st of October."

Because the British Empire colonized America during a period when Month-Day-Year happened to be incredibly common, early Americans adopted it as their standard format.

However, during the late 19th and early 20th centuries, global trade, international shipping, and telegraph networks expanded. Great Britain sought to standardize its systems to align with continental Europe, which favored the Day/Month/Year format because it is strictly logical and hierarchical.

Ultimately, while Britain altered its habits to match Europe, the United States remained geographically isolated across the Atlantic and saw no pressing economic reason to change. The exact same thing happened with the adoption of the Imperial system (feet versus meters).

I recovered my Facebook account, read how

2026-04-28T00:00:00+00:00

What happened🔗

On 2024-10-24, my Facebook account was hacked. Alas, Facebook did not allow me to get back my account, or even report the account as compromised, without entering the current password that whad been changed by the hackers. So I had to create a new account, and moved on.

However, I recently created a test account on Instagram, to try to generate RSS feeds to follow Instagram accounts more comfortably via my RSS-Bridge. And I was surprised to see that my "new" account was in fact the account of another user that had been blocked, then unblocked.

This prompted me to try to re-log into my old Facebook account and... it worked! I was able to reset the password without knowing the current one. I thus will remove the new account after some time.

Nice, but why?🔗

But looking a bit (for instance about Risk-Based Authentication (RBA), it appears I was lucky to try to re-use my account just days after a 6 month delay: Facebook relaxes accounts the security measures 6 months after a detected suspicious activity!

The behavior I experienced — being blocked from recovery despite having valid contact info, followed by a sudden "opening" of access — is apparently a documented pattern in Facebook’s security ecosystem, notably their automated risk assessment procedures.

The "Security Freeze" (Why I was stuck)🔗

When a hijacker changes a password, Facebook’s "Trusted Device" and "Location" protocols often trigger a lock. Even if my email and phone were correct, Facebook may refuse a reset if:

I cannot provide the current password, aka The "Current Password" Requirement. This is a common defensive measure when Facebook detects a "conflict of ownership." If the system sees two different locations (mine and the hacker's) trying to claim the account, it often demands the current password to prevent the owner from being "kicked out" by someone who isn't actually the owner. Needless to say, this is a really bad design, as hackers first move is to change the password.
I use another browser. As I tried many ways to recover my account, I also tried to use another browser on another machine, to start afresh. But this failed Facebook IP Reputation detection: Seeing I was trying to recover the account from a network or device the system didn't "trust" at that moment, it applied the most restrictive recovery path to the account.

Why it suddenly worked (The 6 months "Cooldown" Period)🔗

Nothing is actually officially documented, but here is the likely scenario:

Risk Score Decay: After 6 months of inactivity (or if the hacker eventually triggered a "Security Lock" that made the account go dormant), the "Risk Score" associated with the account drops.
Account Dormancy: Facebook often flags accounts that have been compromised as "checkpointed." After a certain period of time without successful logins from the hijacker, the system may lower the threshold for recovery for the original owner, especially if he are using a device or IP address that was associated with the account for years before the hack.
The "Verification Reset": Facebook occasionally clears the "verification debt" on accounts. If the hacker was blocked by Facebook’s automated systems (e.g., for spamming), the account enters a state where the next person to provide valid 2FA or email confirmation is granted access without the "current password" hurdle.

All of this is totally automated, with no human intervention, by the system's "Identity Verification" logic resetting itself after a period of dormancy. Once the "Pirate" was no longer active, the system stopped viewing my recovery attempt as a "hostile takeover" and allowed the standard email/phone reset to work.

Summary of Known Behavior🔗

Stage	System Logic	Result
Initial Hack	High-conflict state; system protects the "active" user.	Recovery denied despite valid email.
The 6-Month Gap	Account goes dormant or hacker is "checkpointed."	Security tension on the account relaxes.
Recovery	System recognizes you are the owner IP/Location and valid contact info.	Password reset allowed without "Current Password."

What to do once the account is recovered🔗

Check the Settings for "Saved Login", "Where you're logged in", and "Apps and websites" immediately. Sometimes hackers leave a "backdoor" by authorizing a specific browser or app that doesn't require a password.
Change the password, enable 2FA (Two-factor authentication).
Remove all apps connected to the account.
Check other sites that authorized logins from this Facebook account, change their passwords andf look for suspicious activity.

Numéros de telephone arnaques

2026-04-13T00:00:00+00:00

Attention arnaque:

Le No de tel 0189628604 vous appelle en se faisant passer pour un conseiller bancaire (AXA), en ayant votre nom, adresse, en prétendant avoir remarqué des tentatives de paiement répétées depuis Amazon.

C'est une arnaque. J'ai raccroché de suite et appelé AXA pour vérifier.

La conseillère nous a d'ailleurs dit que elle-même avait failli se faire avoir récemment (un faux appel de sa mutuelle).

Je fais ce post simplement pour mettre 0189628604 (ou 33 189628604 ou 01 89 62 86 04) sur le web pour que une recherche de ce No tombe sur ce message.

A new version of the site for 2026, in Zola

2026-03-19T00:00:00+00:00

I said that I wanted to migrate this web site to a SSG (Static Site Generator). And, after 5 years of procrastination, Ta-Da! here is the new site!

Initially, I was planning to use Hugo, since I love coding in Go, and was not planning to learn Rust (Hugo is coded in Go and Zola in Rust), but I finally chose Zola over Hugo for many reasons:

Zola has basically all the performance advantages of Hugo, and is also a single binary, with no need for databases, docker, snap, flatpak...
Zola is opinionated. This is very important for me, I love more and more the systems were there is "only one way to do it". Needless to say, I hate perl, and I love Go.
Zola is stable, and its creator ("Keats") very committed to not chasing the latest fad. This means less risk of an upgrade breaking things.
Zola template engine, Tera, is both more powerful and more readable than the standard Go template engine used by Hugo.
Zola comes with more useful built-in features, but no plugins that in my opinion brings complexity, especially in docs, and upgrade hell.

As for the theme, I was looking for a clean responsive modern simple theme, with high scores in the various web performance benchmarks, with search and comments, and some support for multilingual (the site is in English with a few pages also translated in French). I tried the two leaders in the Zola theme ecosystem:

Tabi I liked the looks but it felt a bit too complex for my needs: as a Zola novice I was afraid to end up relying too much on Tabi-specific feature instead of pure Zola and CSS ones.
ABridge I liked the architecture, not so much the design, but I struggled to make it work, it seems the doc still advise settings that break on recent Zola versions.

I thus looked for a simpler theme, and chose:

Apollo which was perfect for my needs, and simple enough to be easily modified for any of my future needs. I also enabled its support for the Giscus commenting system.

Porting my contents was made easy because I had anticipated this migration, and used Markdown for my posts in the Foswiki engine, instead of the native Foswiki syntax. So converting was basically adding a frontmatter to the pages, and fixing some links. I converted older posts with pandoc.

I have made a quick first migration. I will continue working on the CSS architecture and the looks in the following weeks.

Update on 2026-03-22: I now am satisfied of the result. I plan to work a bit more to add a search for only the French pages (now the search ignores them), autodetection of the browser light/dark preferences, sort the tags alphabetically in the page info line.

Mon compte Facebook a changé (piraté)

2024-10-24T00:00:00+00:00

OBSOLETE

Warning: obsoleted by this new version.

Attention : le 2024-10-24, mon compte Facebook a été piraté. Hélas, Facebook ne m'a pas permis de récupérer mon compte, ni même de le signaler, et j'ai donc dû en créer un nouveau.

Je vous prie donc de ne plus utiliser mon ancien compte ( https://www.facebook.com/colas.nahaboo ) et de le bloquer sur Facebook pour être sûr, car les pirates vont l'utiliser pour pirater et hameçonner d'autres personnes, et d'utiliser mon nouveau compte: https://www.facebook.com/profile.php?id=61567836084230.

J'ai changé ma photo de profil (sur Facebook uniquement pour l'instant) pour différencier les deux comptes :

My Facebook account has changed (hacked)

2024-10-24T00:00:00+00:00

OBSOLETE

Warning: obsoleted by this new version.

Warning: on 2024-10-24, my Facebook account was hacked. Alas, Facebook did not allow me to get back my account, or even report it, so I had to create a new one.

So please never use my old account anymore ( https://www.facebook.com/colas.nahaboo ) and block it under Facebook to be safe, as hackers are going to use it to hack and phish others, and use my new account: https://www.facebook.com/profile.php?id=61567836084230

I changed my profile picture (on Facebook only for now) to differentiate the two accounts:

One year retired

2022-02-24T00:00:00+00:00

I have been retired for one year now, and what happened? Well...

I basically stopped coding and reading about anything computer-related for eight months. I didn't expect it, I was thinking I would start coding at once, going through my huge todo list of various projects.
I enjoyed being able to go SUP surfing at will, but I ended up actually less on the water than before, simply because i didn't feel pressured into going on the water if the conditions were not enjoyable: I have now all the time in the world, I can wait for better conditions.
I started what I should have done years ago: Stretching at least 30 minutes daily, and warming up a full 10 minutes before going surfing. Work and play for me were mainly sitting in front of a computer, and I had become awfully stiff. I will detail my routine in later posts, it is worth it.
I dived deep in modern physics: astrophysics, cosmology and quantum mechanics. This also will warrant a full separate post.
I started re-coding in the last four months:
- The first month I began working on various bits of code (shell scripts), progressively getting back to speed, and also deciding to learn the language Go. I was looking for a very longtime for an efficient language to replace lisp or C as compliment to scripting (I never liked Java), and was hesitating between Rust and Go. A discussion with Olivier Arsac convinced me to try Go.
- I switched to git (I was using mercurial) for version control, and moved my publicly available source codes from my personal web site to my GitHub. It may sound ridiculous, but at now 61, setting things up so they do not disappear when I do is becoming an important consideration. I will thus progressively stop using self-hosted sites to publish on places that will survive me, as nobody in my family is tech-savvy enough to maintain a web site.
- Then in December I stumbled upon the Advent of Code challenge that I decided to do in bash for the challenge, and it was unexpectedly productive? I learned more in these 25 puzzles than in my last 10 years of professional bash scripting. You can see my solutions in my post Bash lessons learned with AoC 2021.
- Thus, after finishing the Go tutorial, I decided to do the previous AoC years in Go. And I just finished the AoC 2015 in Go. This definitively made me a Go enthusiast, I realized that the designers of Go had exactly the same opinion of what should be a general programming language: They worshiped readability, simplicity, performance and maintainability while hating inheritance and the feature creep of most modern languages.

That was my first year. And now, embarking for the next one!

Pinboard pricing model

2021-03-01T00:00:00+00:00

I am a knowledge addict, and always has been. I was reading as many books as possible, and the advent of the web has been a marvelous gift for me. But I soon realized that I needed some tools to manage this knowledge and supplement my memory. It started with pen and papers, then I used a lot the PDAs (Personal Digital Assistants) such as the fabulous Psion Series 3 and Series 5, the various smartphones, and finally the bookmarks-in-the-cloud service Delicious

But as Delicious closed, I searched a replacement, and found Pinboard, and was hooked. Not only it offered the same functionalities as Delicious (and more), but if was fast and sleek, with a minimal no-nonsense design that I favor.

It also had an original pricing system: you paid a one-time fee of $0.001 per the number of current users to get access for life. E.g $9.26 if there was already 9263 paying users and you wanted to become the 9264th. The goal was to entice people to register now rather than waiting, even though it may not have scaled. (see Pinboard.in Pricing Model: Fixing Their Math).

Alas, it could not be sustained, so in 2015 it adopted a more mainstream yearly fee scheme: $11 / year. New Pricing Policy (Pinboard Blog)

But we, old timers, kept our lifetime access we bought before the change. We were basically free-riding the new wave of customers...

Of course it could not go on, so last week, Maciej, the Pinboard author, suggested we voluntarily switch to the yearly fee scheme. And I did it gladly, Pinboard is for me a model of what web sites should be: sleek, fast, and efficient (and not re-selling your private data). At the opposite of the bloated monstrosities that a lot of sites tend to be nowadays.

Long live Pinboard!

Retired, at last!

2021-02-25T00:00:00+00:00

At last, I am now retired!

I ceased all activity on 2021-02-17, and my work account will be destroyed on 2021-02-28. A new era of full time surfing, coding and playing opens up. For now it is mostly playing with the new Valheim game that is making a huge debut(*), as the waves are not good (winter storms) and I take a (small) coding break.

I will try to make a post per week on this site, starting now 2021-03-01. I know there is no way I will be able to keep the rhythm, but let's say it should be my long-term goal.

(*) I strongly recommend you read # Valheim: 7 marketing lessons from their amazing launch, which tries to shed some light on its phenomenal success.

A New version of the site for 2021

2020-12-27T00:00:00+00:00

A big change is planned for this site in 2021: I am going to abandon the Foswiki engine for it, to pursue my recent goal of going back to the web roots. Basically, it a quest that relies more on:

Fast rendering by no rendering at all: pre-compiling the site pages into static HTML+CSS+JS pages: the JAMstack approach.
What I call a LAUW approach (Linux Apache Unix-utilities Web Standards) instead of the traditional LAMP. Using the full strengths of Linux, Apache, the GNU Unix utilities, and the modern web standards (HTML5, CSS4, JS ES6) now that Internet Explorer is at last dead. This means not using software libraries (e.g: JQuery) and processors (e.g: Saas) that were designed to remedy to the poor state of some browsers.
Using Markdown for text editing
Using ultra stable and reliable technologies. I want to use things that will still work in 10 years, not the fad-of-the-day javascript framework that will be obsolete in 6 months, or that will break compatibility on each update.
Technical: And that do not try to be friendly to non-technical authors and admins, as I will be the sole admin and editor.

Now🔗

So now (December 2020), I am still using Foswiki, but progressively prototyping on it the features I will try to implement later:

A simplified skin, with all the "wiki-ism" (everything editable) removed. As you can see I got rid of the left toolbar, to keep only the top banner with its sections (Code/Surf/Blog) menu on the logo and minimal tools on the right
Editing contents in Markdown instead of the Foswiki syntax: I now do not use the Foswiki system to edit topics, but desktop-edit via marktext.
Having all the post sharing a common Form, so that the fields of this form can be easily converted to YAML as used as frontmatter (metadata) in modern Markdown-based systems.
But still using all the Foswiki power for the site admin and non-content topics (indexes,...)

The idea is to migrate progressively the contents into a form (Markdown + Frontmatter) usable in a modern static web generator like Hugo, while adapting Foswiki to use this content form, preparing a future migration.

I have developed the details of what this means in my post on the Foswiki site: Foswiki for non-wiki web sites

Spring 2021🔗

After I retire, at the end of February 2021, I will have more time to ditch Foswiki and implement the site on a new engine. It will probably be a static website generator, most probably Hugo, but maybe also Zola Eleventy, or Gasby, and incorporating ideas of the myriad of other ones.

Summer 2021🔗

I will then probably replace progressively various components of this system by ones that I will handcraft optimally to incorporate all the ideas I have been toying with during all these years: the HTML+CSS+JS layout, the tag/category system, the search engine, the comment engine, the editing process...

Later...🔗

And I may even at some time create a totally new web engine system, who knows?

Or code a wiki replacement: a collaborative editing site based on the concepts learned via this experiment.

A New Version of the site for 2020

2020-07-26T00:00:00+00:00

After 10 years of neglect, it is time for a new start of this site, because:

I am going to retire in early 2021 (in 6 months), and I will have now time to properly maintain a personal site
I am feeling the need to archive in a central place all the contents I scatter in various different places, if only for the selfish reason to be able to retreive them more easily
I was toying with the idea of going to a static web site, as it is now in vogue, and it has a kind of nostalgia for me as I started my web sites as static sites anyways. But by looking at the existing solutions, I was not convinced by them, as a lot seemed to naively solve the 80% easy part of the problem, and them struggle without any clear vision on how to solve the 20% hard part... a classic situation.

I thus decided to keep on using Foswiki (v2.1.6), as it is now quite mature, and thus stable: I like building on solid, time-tested fundations that will not change every month. And let's be honest, it is both extremely powerful and incredibly reliable. I am just tweaking it for using it as a public site (one author with all admin rights, and read-only viewers), rather than the standard wiki setup of many authors, all able to edit contents, with some able to also admin rights. My postulate is that a dynamic web site like a wiki, with proper caching, has all the advantages of a static web site, but is more practical to maintain (although more complex to implement).

I will detail my views on how to website-ize a wiki in future posts, but for now, on 2020-07-26 at noon French time, let go live!

Welcome to my (new) world!

Colas.

Migration to Foswiki

2015-10-18T00:00:00+00:00

At last, I found the motivation to work again on this site that I have left dormant since 2009. And I start with a long deserved migration of the engine from the old TWiki system to the superb Foswiki WIki engine.

Just installing a new Foswiki, and copying the data seem to provide a working base, I will then work on fixing the minor bugs and designing a new look in the following weeks.

Usability issues on a payment form

2009-03-03T00:00:00+00:00

I know, I know, it is easy to nitpick on other people design, but this morning I tried to pay my phone bill online, and... failed. I had to retry many times, because I kept making mistakes on a simple, run-of-the-mill form to enter my credit card data. I was dumbfounded. How can, in 2009, people manage to make such a trivial and essential part of online business go so wrong? As I guess you are as curious as me, here is what I found out: (See the picture for the 3 main pain points)

1 the expiration date example is ambiguous: does 0903 here means 2009-03 or 2003-09 ? Why didnt they disambiguate it by also adding a specification (like MMYY, or, as it is a french dialog, MMAA ?)
2 but today, it was not only ambiguous but plainly misleading! As we were in March 2009, I assumed that the example was built from the current month and year. I said cool, so it is YYMM. Wrong! it was actually the reverse, MMYY, resulting in one failed attempt
3 ok, I filled the fields, and hit the OK button... and it just reset the page to empty fields! Grumbling, I re-typed the fields, re-clic, and... another blank page! After these two more failures, I tried to think (which is what you do not want your users to do, trust me). I then read the button label and discovered that this big, prominent button alone at the bottom of the page was not the Submit button but the Cancel one. I should have hit the middle one "Valider", but this button was not in the correct place on the flow of the form.

So,after 3 failed attempts, I managed to pay my bill. All this on a simple form with no fancy verification code or Captcha. Well done Telefact, I wonder if you can find a worse example still in use today.

What is good code?

2008-10-22T00:00:00+00:00

I stumbled upon the blog post "Is it important to write good code?" the other day, and became more and more ill at ease as I realized that I thought that I preferred the original code, that the author was trying to ridicule, over his new "improved" object-oriented version. At first I guessed this was another manifestation of the the "Worst is best" scenario - enhancements are often not worth the added complexity - but I realized that it was perhaps a more profound factor:

The original code is very good because it ... is small. It fits on a teminal screen, so an human being can read it at once and have less items to maintain in his short term memory and also understand it easily because it follows a natural way of thinking with sentences using IF. This becomes obvious by reading the body of the blog post surrounding the code samples, where you can see that the author is using phrases such as "if I need this I do that", showing that in plain english, the if statement is the best way to make people understand what you mean. And making code that people understand is the best way to make debuggable and maintainable code.

At this moment I noticed the citation in the blog header: "Good programmers write code that humans can understand"

Indeed :-)

PS: I know I am a bit exaggerating the issues there, and that I unfairly nitpick on Fredrik Normé, but it is that it seems to me from my personal experience that the two changes I see most in my coding efficiency as I grow older is a decrease of my short term memory capacity, and that I make more and more typos where I realize I mix up totally words with totally different meanings but that sound the same, for instance writing "never" instead of "nether", making me suspect that our natural way of thinking may be much more language-based that I imagined...

Mercurial web templating

2008-10-09T00:00:00+00:00

For some time now, I have seen the light and I switched to the new wave of the Distributed Source Control management systems. Linus famous video of his Google talk decided me to try. I was a bit apprehensive at first, wary of engaging myself on a technology that would bring more problems than solutions, but after some days of use, the realisation dawned over me: Distributed Source Control may be one little step for a programmer, but it is a giant step for programming. Why? because, its mental model actually follows your first intuitions that most of us developed as young programmers before using any source control system. Suppose you want to try a feature? instead of just copying the directory, you clone it. You mess an operation? you just remove the directory, no embarrassing traces left to keep the burning scar of shame on you for the following decades of a central repository. You are used to think of your enhancements as patches, you can work with patches. I could go on and on, but many people have done it much better than me so I'll just say that you should definitely try it.

By the way, between the 3 main contenders, git, mercurial (aka HG), and bazaar, I chose mercurial because of its simplicity, its better support of windows (I work in Linux since 1995 but my coworkers currently use Windows), and because some people at ILOG started using git so I wanted to be able to try something else. I did not choose bazaar as I wanted to stay close enough of git, to be able to switch to it if ever my dream to work in a windows-free world materializes one day...

So I started to set up a public web repository of my Open Source personal work with mercurial, which gave me a simple way to publish my work in full detail, but, although mercurial is quite easy to use, but I had a bit of trouble figuring out how to customize its look & feel.

The rebirth of this site

2008-04-04T00:00:00+00:00

At last, I decided myself to redo my old website, which was a collection of static html and was based on many of the various tools I made in these past years. As I grew in love with wikis over these years, the natural tought was just to do it in a Wiki, and naturally in the Wiki I like the most, TWiki. So bear with me and keep posted, as this site will slowly emerge in this first half of 2008.

Browser-history

2008-03-21T00:00:00+00:00

Legacy

Browser-history started on February 15, 1996, out of a desire to overcome a Netscape bug: at the time, there was no global history. [Nowadays, in 2026, all browsers have one, of course.] Back then, if you closed a window, its entire history was lost.

For people visiting many sites, the ability to track where they had been meant they didn't have to clutter their bookmarks file. If you weren't sure a site was worth saving, you didn't have to bookmark it; if you needed it later, you could just browse your history files.

Later, it occurred to me that this could also be a valuable add-on for people developing experimental browsers [a lot at the time], sparing them from having to build the functionality themselves.

Browser-history was a small, efficient daemon written in C. Real user services could be built on top of its log files to provide more advanced features, such as graphical representations, advanced search, or collective histories. While it could be seen as a "quick-and-dirty hack" compared to the general solution of using a personal proxy for housekeeping, it was easy to use and it worked.

I created this legacy page to help people find the archived version of the project, specifically the latest version of 2000-07-20.

The code archive itself is browser-history-2.8.tgz

Here is a screenshot of the page:

Enjoy!

The manual page🔗

NAME🔗

browser-history - external history of web browsers, such as netscape

SYNOPSIS🔗

browser-history [ options ]

DESCRIPTION🔗

Browser-History is a client-side X daemon maintaining a browser-independent global history of all the web sites you visited .Its usage is very simple, just put the following line in your .xinitrc or your X start-up script:

browser-history &

And open the file ~/.browser-history/history-log.html and bookmark it.

Browser-history came from the will to overcome a Netscape bug: there was no global history, and if you close a window, its whole history is lost. For people browsing lots of sites, having a possibility to track back where one has been before means that you dont have to put everything in your bookmarks file. If you are not sure if a site may be worth remebering, don't add it in your bookmarks. If you need it later, just browse your history files.

Later, it came to our minds that this also could be a valuable add-on to people writing experimental browsers, so they dont have to add this functionality to their browser itself.

Browser-history is a small and efficient daemon. Real user services could be built on top of the log files it maintains for more possibilities (graphical representation, advanced search options, collective histories). It can be seen as a quick-and-dirty hack wrt to the general solution of using a personal proxy to provide this history and housekeeping facilities. But in the meantime, it is easy to use and it works.

IMPLEMENTATION🔗

Browser-History spies your web browser and logs in ~/.browser-history/history-log.html all the URLs you went through. You can then browse the log under Netscape or other browsers via the URL: file:~/.browser-history/history-log.html (replace the ~ by your home directory). It tracks automagically all already present browser windows, and all new ones created in the future. This program has no user interface. It just appens information to a log file in html format so you can browse it through a web browser. If more that one hour has passed since last entry, it draws an horizontal lines, and adds H1 headers to delimit new days. Each week (sunday mornings), it archives the week history, compresses it by gzip (that you must have in your path), and starts a new history with links to the older ones. To make room you can just remove the obsolete history files. You can search files for string XXX in shell via:

zgrep XXX ~/.browser-history/*

This version (2.6) works with Netscape, Arena and Amaya.

URLs can be excluded from logging by putting them, one per line in the file ~/.browser-history/history-log.exclude , then, if an URL begins with a line from this file, it is not logged. In this file, empty lines or lines beginning by # are comments This file is read once at startup, and re-read when receiving the signal 1. e.g:

# We exclude local files file: # Exclude search engines... http://home.netscape.com http://guide.infoseek.com

When browser-history is run, it looks if another one is running, and by default it kills the previous one if it is an older version. Otherwise, it the new one is the same version number or older, it just aborts.

OPTIONS🔗

All options can be given by their first letter: you can specify either -verbose or -v, but you cannot group options, e.g. you must say -v -k , but not -vk

-display display_name
Specifies X display, otherwise contents of $DISPLAY is used

-verbose
outputs information on what it is doing. useful for debug.

-Version
prints version number and exit.

-logdir directory
which directory to store files into? defaults to ~/.browser-history

-gzip gzip_filename
the complete path to the gzip compressor. Defaults to "gzip". E.g:

-gzip /usr/gnu/bin/gzip

-seconds delay
if two entries are made are more than delay seconds apart, an horizontal rule will separate them, else just a simple line break. Defaults to one hour (3600).

-replace
If there is an already running browser-history on the display, aborts. Default is to replace it only if the version is older than ours.

-noreplace
If there is an already running browser-history on the display, aborts. Default is to replace it only if the version is older than ours.

-kill
If there is an already running browser-history on the display, kills it, then terminates immediately in all cases..TP -DontGrab Never Grab the X Server, which might cause deadlocks while debugging, when browser-history or gdb tries to print on the grabbed xterm or emacs.

LOG FILE FORMAT🔗

A log file can have some decorative HTML to represent days, but each entry has the form: (on a single line since version 2.4)

separator
    <b>name</b>
    <a href="URL">URL</a>
    YYYY/MM/DD-HH:MN:SS <small>windowid</small>

where the following items are:

separator: either
or
name: the name of the document (window title) URL: its URL YYYY/MM/DD-HH:MN:SS: year, month number, day number, hour, minutes, seconds. (2-digit numbers) windowid: the X window ID of the browser window, in hexadecimal

Note Before version 2.4, the 4 sub-parts were separated by newlines, but since 2.4, they are only blank-separated to ease searching for URL in log files via "grep". Note Before version 2.5, the year was stored in 2 digits. Now it is stored in 4 (or more :-) digits, to fix this Y2K bug

HOME🔗

The latest version of browser-history can be found at:

ftp://koala.inria.fr/pub/browser-history

and its WWW home page, with full technical documentation is at:

http://koala.ilog.fr/colas/browser-history

AUTHOR🔗

Colas Nahaboo, http://koala.ilog.fr/colas

COPYRIGHT🔗

browser-history bears the same license as the X Window System: you can do everything with this code (selling it, modifying it), except suing me or using my name in your advertisements, or expecting any kind of support or guarantee.

Colas Nahaboo X mouse wheel scroll page

1997-12-30T00:00:00+00:00

Legacy

On December 30, 1997, I started this page to help developers manage the — then new — mouse wheel. My goal was to encourage a standard scrolling direction for the X Window System on Unix and Linux.

It quickly became the most-viewed page on my personal site, and even across all INRIA-hosted websites at the time. However, as mouse wheels became mainstream, the page lost its relevance. I let it quietly disappear in 2018 when I upgraded my site.

Seeing that this remains one of my most accessed URLs even in 2026, I decided to create this legacy page at the same legacy URL. It allows people to easily find the historical version on the Web Archive, specifically the latest version of 2015-09-06, from which is the screenshot:

Enjoy!