Un petit en vrac’ pour un confinement qui est bien parti pour durer au moins 6 semaines, le deuxième à mi-chemin de la fin… Avec un peu de chance !

Côté informatique et internet ?

• Préparez les parapluies. Une avalanche d’articles et de vidéos vont arriver… La seule bêta de la Ubuntu 20.04 est officiellement disponible !
• On aurait pu croire à un poisson d’avril pas frais, mais non. La clownesque Makulu Linux 2020 Flash est bien sortie le 1er avril 2020.
• Largement plus sérieux, la révision 8.2 de NetBSD est aussi disponible.
• Linux Mint a avancé quelques détails sur sa version 20, qui sera basée sur Ubuntu 20.04 : trois environnements, à savoir Cinnamon, Mate et Xfce mais uniquement en 64 bits…
• Pour les personnes ayant une FreeBox Revolution et utilisant une distribution GNU/Linux, voici une petite vidéo qui permet de contourner un bug chiant… Qui sera présent tant que Free ne mettra pas à jour la partie Samba de la logithèque de sa FreeBox Révolution… C’est pas demain la veille !

Côté culture ?

• Aythis propose sur son espace bandcamp son excellent deuxième album « Glacia ».
• Le groupe de post-rock « Have The Moskovik » vient de sortir un nouvel opus, « Répétition générale », uniquement en numérique à prix libre.

C’est tout pour aujourd’hui. Bon courage !

Article et vidéo créés le 16 mars 2020.

Dans le petit monde des trousses bureautiques allégées, Microsoft Works est le standard de facto. J’ai déjà parlé de l’outil en question en février 2017, dans l’épisode 74 de la série « Vieux Geeks ».

Un outil moins connu a commencé sa carrière sur les machines d’Apple avant de faire un tour sur les PC entre 1993 et 1997, aussi bien pour MS-Windows 3.1x que 95. La dernière version, Claris Works 5 sortira en 1997 avant qu’Apple ne rachète l’outil en 1998 et ne le renomme AppleWorks.

J’ai donc utilisé PCEm et réussi à faire fonctionner un MS-Windows 95 OSR 2.5 dans lequel j’ai installé Claris Works 5. Merci à WinWorldPC pour l’archive.

Vous avez pu le voir, on était toujours dans un outil bureautique simplifié, mais qui permettait de faire de nombreuses tâches basiques sans avoir à dégainer un monstre comme Microsoft Word ou Microsoft Excel. AppleWorks sera mis à mort quelques années plus tard, en janvier 2005 avec l’ensemble iWork contenant Pages (le traitement de texte), Numbers (le tableur) et Keynote (l’outil de création de présentations).

Dans un précédent article, je parlais de l’arrivée d’une version moisie – une version de développement vieille de près de 4 mois – de Samba sur Archlinux.

Outre le fait qu’il y avait un bug lié à Python 3.8 qui cassait le fonctionnement de samba-tool, une deuxième couche du problème est rapidement apparu, et ne concerne que certains périphériques.

La version 4.12.0 – on en est à la 4.12.0-3 en ce 2 avril 2020 – est arrivée sur les dépôts de test. J’ai donc profité de l’occasion pour débloquer les paquets ignorés. Un redémarrage plus tard, j’avais toujours le même problème : impossible d’accéder aux partages de ma FreeBox Revolution serveur.

Après quelques recherches, je me suis aperçu que le code de la FreeBox pour cette fonctionnalité est restée bloquée sur le protocole SMBv1… Un bug a été ouvert sur l’outil de suivi de Free en octobre 2017 et n’est toujours pas clos.

Si on en croit les commentaires, c’est le passage du code en GPLv3 qui bloque la montée en version du protocole.

Bref, c’est la mouise… Comment le contourner ? Si vous avez un périphérique bloqué sur cet ancien protocole déprécié et que vous utilisez une Archlinux, il faut modifier le fichier /etc/samba/smb.conf et rajouter dans la section [global] ceci, dixit un message de David C. Rankin sur la liste de publication arch-general.


client min protocol = NT1
server min protocol = NT1


Une autre option étant d’employer CORE à la place de NT1.

Au démarrage suivant, on accède à nouveau aux partages au protocole obsolète SMBv1, la preuve en image.

Cependant, il reste un énorme problème : on ne peut pas créer, copier ou supprimer de fichiers sur le partage samba en question… J’ai ouvert un fil sur le forum d’Archlinux. Il faudra juste que j’ouvre un bug dès que possible, mais avec le confinement, j’ai d’autres choses à faire !

Je contourne actuellement le problème en utilisant le protocole afp directement dans Caja. Un peu laxatif, mais c’est toujours mieux que rien

Bref, une affaire à suivre

Note préliminaire : article et vidéo créés le 2 mars 2020.

Si pour nombre de personnes quand on parle de DOS, c’est MS-DOS qui est synonyme, il ne faut cependant pas oublier un des concurrents dans ce domaine, DR-DOS. Il a été développé par Digital Research de Gary Kildall, papa de CP/M. Puis, le projet a été racheté par Novell dont Caldera achètera les droits en 1996.

Dans un précédent épisode, j’ai parlé du projet DosShell de Microsoft. Mais Novell a aussi développé un projet identique – quoiqu’un peu plus développé – pour DR-DOS, j’ai nommé ViewMax. Sa version 1.0 sort en 1990 avec DR-DOS 5.0, mais n’a pas grand chose à envier à DosShell.

En 1991, sa version 2.0 est disponible et elle est aussi avancée, sinon plus que MS-Windows 3.0, produit phare de Microsoft à l’époque. Ce dernier n’étant pas très partageur, il répondra avec un certain code AARD qui rendait impossible l’installation de la version beta 1 du futur MS-Windows 3.1 avec DR-DOS.

Mais le mieux est de montrer ViewMax 2.0 en action

Vous avez pu le voir, on était loin du DosShell, incapable de faire un simple glisser-déposer d’icones. Cependant, l’arrivée de MS-Windows 3.0 en 1990 était un des principaux clous dans le cercueil pour les interfaces graphiques à la DosShell. MS-Windows 3.1 sera le coup de grâce et le début d’une longue domination dans le domaine des interfaces graphiques qui continue près de 30 ans plus tard.

Je m’étais promis de ne plus parler des distributions GNU/Linux, mais cette fois, je suis obligé de pousser une gueulante sur une manipulation malheureuse d’Archlinux.

Depuis le mois de novembre 2019, il y a un bug qui traîne sur l’outil de suivi d’Archlinux liée à l’arrivée de Python 3.8 : il devient impossible d’accéder aux partages Samba. https://bugs.archlinux.org/task/64537

J’avais été obligé à l’époque d’utiliser l’outil downgrade et de bloquer la liste des paquets suivants :

1. samba
2. libwclient
3. smbclient
4. ldb

Le blocage passant par la modification de la ligne IgnorePkg dans le fichier /etc/pacman.conf :

IgnorePkg = samba libwbclient smbclient ldb

J’ai constaté en ce matin du 29 mars que l’équipe d’Archlinux avait envoyé une version cassée de Samba – et de ses dépendances – sur le dépôt extra. Une sacrée erreur.

Voici ce qui arrive avec la version cassée de Samba quand on veut accéder à un partage samba, le tout dans une machine virtuelle avec EndeavourOS à l’intérieur.

Le correctif temporaire, jusqu’à ce que des paquets fonctionnels arrivent sur le dépôt extra ?

1. Installer l’outil downgrade disponible sur AUR
2. Rétrograder samba libwbclient smbclient ldb dans une version plus ancienne
3. Redémarrer l’ensemble et magie, tout fonctionne !

La preuve en image, toujours sur l’EndeavourOS avec les paquets concernés bloqués dans une version antérieure.

Comme quoi, aucune distribution n’est parfaite et même celle que j’utilise depuis l’année 2009 peut parfois chier dans la colle.

Donc si quelqu’un vous dit qu’il utilise une distribution parfaite, c’est une personne qui ment comme un dentiste à l’approche de la retraite.

Maintenant à vous de voir qui prendre au sérieux… Le premier venu qui change de distributions comme de chemise ou une personne qui utilise la même base depuis 2009 ?

Quoiqu’à notre époque où le premier plouc se prend pour un toubib en ayant fait une recherche de 15 secondes sur doctissimo… Il est vrai que l’expérience, c’est tellement surcôtée…