J’ai passé des années à monter des labos à domicile. Puis, je n’arrivais pas à me résoudre à ouvrir un terminal.

Geoff Palmer a toujours été quelqu’un qui avait besoin d’avoir quelque chose à attendre avec impatience.

Parfois, c’était un problème difficile au travail. Parfois, une soirée qui s’évaporait dans le code. Parfois, c’était beaucoup plus simple : promener les chiens, rencontrer des gens lors d’un événement consacré à la sécurité, faire un tour à moto ou rentrer chez lui avec une idée qui continuait à lui trotter dans la tête.

La technologie comptait beaucoup pour lui, mais elle n’était jamais toute sa vie.

Pendant des années, cet équilibre lui a paru suffisamment ordinaire pour que Geoff ait peu de raisons d’y réfléchir. Le travail lui donnait des problèmes à résoudre. À la maison, il y avait les gens qui comptaient pour lui et les routines auxquelles il tenait. Et quand il restait du temps, il y avait généralement quelque chose d’inachevé qui l’attendait à proximité.

Une ligne de code. Une configuration presque correcte. Un matériel qui semblait capable d’en faire encore plus qu’il n’en faisait déjà.

La curiosité faisait partie du quotidien

La cybersécurité a offert à cette curiosité un cadre professionnel.

Geoff travaillait dans un domaine où poser une question de plus était rarement une mauvaise idée. Qu’est-ce qui avait été négligé ? Que se passe-t-il si cela échoue ? Qu’est-ce qui change si quelqu’un aborde le système d’une manière à laquelle personne ne s’attendait ?

Les événements et les échanges avec d’autres personnes du secteur lui permettaient de partager ses questions plutôt que de les garder pour lui, devant son écran.

Mais toutes les soirées n’avaient pas besoin d’un problème technique.

Il y avait des chiens qui attendaient de l’attention et des raisons de laisser l’ordinateur tranquille. Il y avait des journées où rien n’avait besoin d’être configuré ni réparé.

Cette partie de l’histoire compte.

Il est facile de regarder quelqu’un à travers des années de projets techniques et de le réduire à ce qu’il sait faire.

Le spécialiste de la cybersécurité. Le passionné de home lab. Le gars qui semble toujours avoir un autre serveur ouvert sur son bureau.

Mais la vie ne passe pas d’un projet réussi à l’autre en ligne droite.

Pendant longtemps, Geoff n’a jamais vraiment eu à se demander s’il aimait toujours la technologie.

Il l’a tout simplement fait.

Un projet inachevé était quelque chose auquel il voulait revenir. Ouvrir un terminal le menait généralement quelque part. Un problème technique pouvait l’occuper toute une soirée sans lui donner l’impression d’avoir perdu sa soirée.

Puis plusieurs aspects de sa vie ont changé en même temps.

Puis les choses familières ont commencé à disparaître

Geoff a perdu son emploi.

Sa famille a traversé le deuil de sa belle-mère.

Sa santé mentale s’est dégradée.

Chacune de ces choses aurait été difficile à vivre à elle seule. Ensemble, elles ont changé le quotidien.

Il avait perdu son emploi. Le deuil avait frappé sa famille. Il devenait plus difficile de trouver cette confiance qui aidait habituellement Geoff à passer d’un problème au suivant.

Et quelque part parmi ces pertes bien plus importantes, il y en avait une qui semblait plus insignifiante vue de l’extérieur.

Geoff n’avait plus envie de créer.

Il n’avait pas oublié comment coder.

Il comprenait toujours les systèmes. Le terminal n’avait pas changé. Le matériel posé sur le bureau ne lui était pas soudainement devenu étranger.

Ce qui avait changé, c’était la raison d’ouvrir quoi que ce soit.

C’est l’un des aspects les plus étranges lorsqu’on perd l’intérêt pour quelque chose qu’on aimait autrefois.

Le projet est toujours là.

Le savoir-faire aussi.

Parfois, même l’idée reste bonne.

Vous n’avez tout simplement plus envie de vous y consacrer.

Et comme personne ne vous paie pour terminer un passe-temps, rien ne vous oblige à retrouver l’envie.

Une chose inachevée peut simplement rester inachevée.

Il n’y a pas eu un moment précis où tout est revenu

La vie de Geoff ne s’est pas réinitialisée du jour au lendemain.

Il a avancé par petites étapes.

Un nouvel emploi a de nouveau donné une structure à ses semaines. Ses amis, ses collègues et ses mentors sont restés proches. Pendant une période où il lui était devenu difficile de voir sa propre valeur, des gens la lui ont rappelée.

Une moto lui a apporté une autre forme de mouvement.

Il y avait des kilomètres à parcourir, et plus seulement des choses derrière lui.

Et finalement, quelque chose de presque banal a commencé à se produire aussi.

Geoff s’est remis à penser au code.

Pas parce qu’il en avait besoin.

Parce qu’il en avait envie.

L’ancienne envie est revenue discrètement

Une idée technique inachevée semblait un peu moins lourde à porter.

Un problème devenait intéressant au lieu d’être épuisant.

Ouvrir un terminal évoquait de nouveau des possibilités plutôt qu’une obligation.

Le changement était si discret que quelqu’un d’autre aurait pu ne pas le remarquer.

Geoff l’a fait.

On a tendance à sous-estimer le mot « bidouiller ».

Cela paraît anodin.

Pour Geoff, cela représentait quelque chose de bien plus grand : sa curiosité lui appartenait de nouveau.

Cela n’effaçait pas le deuil. Cela ne mettait pas fin à cette période difficile. Cela ne signifiait pas que tous les aspects de sa vie étaient soudain revenus à la normale.

Cela signifiait simplement qu’il y avait de nouveau des choses qu’il avait envie de créer.

Et Geoff connaissait déjà depuis des années ce sentiment.

Son histoire avec les petits serveurs avait commencé des années auparavant

Bien avant cette période difficile, Geoff explorait déjà les possibilités du matériel x86 compact.

L’une des premières machines était le ZimaBoard original.

L’attrait ne venait pas du fait que la carte indiquait précisément à Geoff ce qu’elle devait devenir.

C’était tout le contraire.

Linux lui offrait un point de départ familier. Le SATA rendait possible le stockage directement connecté. Le PCIe laissait de la place pour une autre carte, une autre interface ou une autre idée.

Docker pouvait transformer cette même petite machine en quelque chose de complètement différent avant la fin de la soirée.

Les caractéristiques techniques étaient utiles.

Mais ce que Geoff y voyait vraiment, c’étaient des possibilités.

C’était toujours le même principe : commencer par quelque chose de petit, puis continuer à se demander ce qu’on pouvait en faire d’autre.

De petites expériences sont progressivement devenues des systèmes plus importants

Les laboratoires domestiques se complexifient rarement parce que quelqu’un décide dès le premier jour de construire quelque chose de complexe.

Ils grandissent parce qu’une chose utile en entraîne une autre.

Un service a besoin de stockage. Le stockage a besoin de davantage de disques. Plus de disques soulèvent des questions de configuration, de fiabilité, de refroidissement et de performances.

Une machine qui n’existait au départ que pour tester quelque chose commence à devenir une infrastructure.

Les projets de Geoff ont suivi cette voie.

Le stockage est devenu à lui seul un domaine d’expérimentation.

Le ZimaCube a donné plus d’espace à ces expériences de stockage

Quand Geoff travaillait avec le ZimaCube de première génération, les questions allaient bien au-delà de savoir si un petit serveur pouvait reconnaître un disque.

Il réfléchissait aux SSD, au NVMe, aux configurations RAID, aux performances et au comportement des différents choix de stockage dès lors qu’une machine devenait un système sur lequel il pourrait réellement compter.

La machine était plus grande que la carte d’origine, mais l’instinct à l’origine du projet n’avait pas changé.

Geoff voulait toujours avoir accès.

Il voulait toujours comprendre pourquoi une configuration se comportait différemment d’une autre.

Et il préférait toujours un système capable d’évoluer plutôt que d’imposer éternellement la même solution.

C’est l’une des raisons pour lesquelles les laboratoires domestiques peuvent être difficiles à décrire à ceux qui n’en ont pas.

Le but n’est pas toujours l’efficacité.

Parfois, le but est de comprendre.

On pouvait laisser une machine tranquille une fois qu’elle fonctionnait.

Ou bien, on pouvait changer encore une chose, juste pour voir ce qui se passerait.

Construire pour lui-même est peu à peu devenu utile aux autres

Au fil du temps, les projets ont fini par être utiles à d’autres qu’à Geoff.

Une photo pouvait montrer à quelqu’un d’autre comment un montage pouvait s’agencer.

Une configuration qui échouait pouvait faire gagner des heures à quelqu’un d’autre.

Un test de stockage pouvait répondre à une question qu’il était difficile de trancher à partir des seules spécifications.

La même habitude qui poussait Geoff à continuer d’expérimenter le rendait également utile à une communauté technique plus vaste : il était prêt à essayer des choses et à dire ce qui s’était réellement passé.

C’est ainsi que la relation avec Zima est devenue bien plus que le simple fait d’avoir du matériel sur un bureau.

Construire, tester, questionner et partager sont progressivement devenus les éléments d’un même processus.

Des années plus tard, une autre carte est apparue sur le bureau

La ZimaBoard 2 blanche est arrivée bien plus tard.

À ce moment-là, l’histoire de la personne qui l’utilisait était bien différente de celle de cette première carte.

Geoff avait construit davantage de systèmes. Testé des configurations de stockage plus importantes. Partagé ce qu’il avait appris.

Il avait aussi traversé une période où rien de tout cela ne lui avait semblé important.

La carte elle-même apportait du matériel plus récent.

Mais la raison pour laquelle elle convenait à Geoff lui était familière.

Le SATA offrait toujours un accès direct au stockage. Le PCIe permettait toujours de spécialiser davantage la machine. L’architecture x86 laissait toujours la place aux outils Linux habituels, aux conteneurs, au réseau et aux services auto-hébergés.

Une machine comme ZimaBoard 2 n’avait pas besoin d’arriver avec une idée finale déjà définie.

Pour quelqu’un comme Geoff, c’était là tout l’intérêt.

Le matériel ne lui a pas rendu sa vie

Il existe une version plus simple de cette histoire, qui ferait probablement une meilleure publicité.

Geoff a traversé une période terrible. Puis la technologie est revenue. Puis une autre machine est apparue. Tout est redevenu formidable.

Ce n’est pas ce qui s’est passé.

Un serveur ne pouvait pas remplacer les personnes que Geoff avait perdues.

Un nouveau matériel ne pouvait pas remplacer le travail personnel nécessaire pour se remettre d’un deuil, du chômage ou d’une période de mauvaise santé mentale.

Zima ne l’a pas sauvé.

Ce que ces projets lui ont apporté était beaucoup plus modeste — et beaucoup plus crédible.

Elles ont offert à sa curiosité renaissante un terrain familier où s’exprimer.

Une machine à modifier.

Une configuration à remettre en question.

Un problème à compliquer inutilement parce que le résoudre semblait à nouveau amusant.

Et peut-être qu’après une période où presque rien ne semblait familier, retrouver quelque chose de familier a compté.

Il y a encore des choses qui méritent d’être construites

La vie de Geoff n’est pas revenue à ce qu’elle était avant.

La vie a continué.

Il y a de nouveau du travail.

Il y a des amis, des collègues et des proches qui sont restés à ses côtés.

Il y a des chiens. Des routes qu’il reste à parcourir. Des projets qui prendront probablement plus de temps que prévu.

Et il y a encore des soirées où un problème technique est assez intéressant pour qu’on s’y attarde un peu plus longtemps.

C’est peut-être la partie de l’histoire de Geoff qui compte le plus.

Pas le serveur.

Pas le rack.

Même pas le code.

L’envie de créer quelque chose.

Regarder une machine et y voir à nouveau des possibilités.

Ouvrir le terminal sans avoir besoin d’une raison.

Et retrouver cette vieille question qui l’attendait :

Que pourrais-je construire avec ça ?

Pendant des années, Geoff a à peine eu à se poser cette question.

Puis, pendant un certain temps, cela a disparu.

C’est revenu.