Écrire un article sur la langue française est un exercice périlleux, surtout de ma part. Cependant, une manière amusante de tester les LLMs (aka les IAs) est de leur soumettre des questions, plus ou moins intéressantes, sur la conjugaison ou la grammaire française.
Continue reading
Dernièrement, j’ai dû faire des tests sur une distribution RedHat RHL 7.2/7.3. Notez bien RHL pour « RedHat Linux » et non RHEL (RedHat Enterprise Linux). L’absence du mot « Enterprise » est important ici. Cette version date du début des années 2000 (circa 2002) et correspond, grosso-modo, à une RHEL AS 2.1 (RedHat Enterprise Linux – Advanced Server). Je vous laisse consulter la page de Wikipedia pour essayer de décrypter les différentes appellations commerciales des distributions RedHat.
Mon problème était de trouver les médias d’installation originaux pour créer une machine virtuelle (VM) sous VMware et/ou Proxmox (KVM). En fait cette version (et bien d’autres) est téléchargeable directement depuis le site d’archive de RedHat. Pour info, la version 7.2 démarre mais se fige (sans kernel panic) dès qu’on active le réseau (Proxmox 8.3). La version 7.3 fonctionne correctement avec les paramètres suivants:
Mais l’important n’est pas là: au cours de mes recherches archéologiques, j’ai trouvé un site qui archive des systèmes d’exploitation plus ou moins obsolètes, à savoir l’incroyable fsck.technologies.
Ce site renferme quelques pépites dont, dans le désordre, NextStep/OpenStep, Apple A/UX, SCO UNIX et Xenix, Novell Netware, BeOS, QNX 3, UNIX AT&T SVR4, IRIX, les légendaires UNIX BSD 4x (dont BSDi) et même une version d’AIX (v4.1.4) qu’Apple livrait avec ses Network servers. Ça m’étonnerait qu’elles soient Y2K compatibles.
1 : Ne boote pas avec le classique NCR53C810 après installation↑
2 : Proxmox ne propose pas de WD8003E ou de NE2000: Une honte!↑
2 : Un système d’exploitation complet avec le réseau, une GUI (Photon) et un navigateur, le tout tenant sur 2 disquettes 1.44Mo. ↑
Le plugin « Open remote – SSH » pour VSCode permet d’éditer/exécuter du code sur une machine distante depuis votre ordinateur de bureau. C’est très pratique pour du dev sur des machines hébergées ou des ordinateurs monocarte sans écran, genre Nanopi/Raspberry PI (ARMv7 ou Aarch64).
On pourrait faire ça avec des partages SMB et un simple xterm, mais là tout est intégré, il y a même un plugin pour utiliser des Makefiles sur la machine distante 😜: le confort de la vie moderne.
Ça fonctionne parfaitement avec des machines Linux (Testé sur Debian 12 et Rocky 8/9). Pour FreeBSD, la documentation indique d’installer manuellement « vscodium-server » mais ne décrit pas la méthode.
Une autre solution, plus rapide, est d’installer la couche de compatibilité Linux. Cela permet de faire passer la machine distante pour un Linux. Avec ça, l’installation se fera sans douleur. Dans l’ordre:
linux au démarrage/proc, /dev/shm, etc.)sudo sysrc linux_enable="YES" sudo service linux start sudo pkg install linux_base-c7
Si vous êtes plus familier avec les distributions de type Debian, vous pouvez installer un environnement Debian ou Ubuntu avec debootstrap.
Enfin, sur votre ordinateur de bureau (celui où vous utilisez VSCode/VSCodium), éditez le fichier $HOME/.ssh/config et ajoutez une entrée pour votre machine FreeBSD préférée avec les options suivantes:
Host unxdev
HostName unxbox
User luc
RequestTTY force
SetEnv PATH="/compat/linux/usr/sbin:/compat/linux/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
Attention, l’installation peut modifier votre configuration git sur la machine distante. Pensez à sauvegarder le fichier $HOME/.gitconfig.
Il est préférable d’utiliser VSCodium plutôt que VSCode pour éviter d’envoyer des informations chez son éditeur (VSCodium est un clone de VSCode où la télémétrie est désactivée par défaut).
Si vous l’avez manquée, la version officielle de DiscoBSD 2.11 est sortie. Pour les plus téméraires, elle peut se construire « out-of-the-box » depuis FreeBSD, OpenBSD ou Ubuntu Linux.
Sinon la version binaire est téléchargeable à la même adresse.
Lorsqu’on doit livrer des scripts ou des programmes, on constitue un « package ». C’est la solution classique, mais elle est dépendante de l’OS ou de la distribution utilisée: il faut créer autant de paquet que d’OS (au format txz, deb, rpm, lpp, pkg, etc.). On peut aussi envoyer un fichier au format « tgz » ou « tar.gz » avec une procédure d’installation, mais faire de la doc, c’est chiant.
Continue reading