De nouvelles images ISO du projet Parabola GNU/Linux sont disponibles. Elles sont datées du 11 juin 2018. Apparement, uniquement en mode ligne de commande avec soit OpenRC, soit systemd.
Ultra important et pourtant on pourrait s’en battre les gonades : on peut avoir LibreOffice sur Haïku… Déjà sortir une version bêta, ce serait bien non ?
Un billet rapide pour prévenir de la mise à jour en cours de mois du guide. En effet, j’ai mis en ligne une version qui intègre une version modernisée du support de l’UEFI.
C’est officiel. Depuis la début du mois de juin 2018, Microsoft a racheté Github. Les projets libres hébergés sur l’ancien roi de l’outil git – au point d’en devenir synonyme – commence à connaître des défections : un exemple qui m’est proche, c’est la migration des projets en relation avec Manjaro Linux sur gitlab.
Que Microsoft ait commencé un long jeu d’étouffement des gros projets du libre avec de WSL (Windows Subsystem for Linux) permettant de faire tourner en natif Ubuntu, Debian, SuSE Linux Enterprise Server ou encore Kali Linux depuis MS-Windows 10 16.07, est-il besoin de le prouver plus avant ?
Quand Microsoft aime une technologie qu’il n’a pas développé en interne, ça pue pour la technologie en question…
Mais cette microsoftisation du monde Linux n’est pas une nouveauté. Il faut être honnête : l’apparence générale d’un KDE ou d’un Cinnamon fait penser à l’ergonomie générale d’un MS-Windows en dehors de la période 8.x de l’OS de Redmond.
Combien de distributions propose une barre de tâches avec l’heure en bas à droite, une zone de notification et un menu jaillissant en bas à gauche ?
Cependant, il n’y a pas que l’apparence qui est recopiée désormais. Je vais commettre un crime de lèse-majesté, pardon, de lèse-Mintité en évoquant les grandes nouveautés de la Linux Mint 19 qui est encore en bêta au moment où je rédige cette article. D’où l’obligation de mettre une image caricaturale avant de continuer cet article.
Il y a aussi un autre point que je considère être casse gueule au possible, c’est la possibilité d’activer l’installation automatique des mises à jour. Je me suis exprimé dans une vidéo qui m’a voulu une volée de bois vert.
Heureusement les développeurs ont eu la conscience de ne pas cocher cette case par défaut. Mais rien que l’idée d’une telle option me fait peur.
Que la reine des distributions GNU/Linux durant des années se décide à rajouter ce duo entre la restaurations système et les mises à jour automatiques me fait dire que le monde du libre dans le domaine des distributions GNU/Linux est vraiment devenu un suiveur. Microsoft a tout le temps devant lui pour tuer le monde du libre. Vu le panurgisme des distributions grand public, le monde linux est loin d’être sorti de l’ornière.
Pour tout dire, le rachat de github m’en touche l’une sans me faire bouger l’autre. C’est cela qui est le plus terrible au final.
No, I didn’t call it 5.0, even though all the git object count numerology was in place for that. It will happen in the not _too_ distant future, and I’m told all the release scripts on kernel.org are ready for it, but I didn’t feel there was any real reason for it. I suspect that around 4.20 – which is I run out of fingers and toes to keep track of minor releases, and thus start getting mightily confused – I’ll switch over. That was what happened for 4.0, after all.
Une traduction ?
Non, je ne l’ai pas appelé 5.0, même si tous les objets git numérotés étaient en place pour ça. Cela arrivera dans un avenir pas trop lointain, et on m’a dit que tous les scripts de version sur kernel.org sont prêts, mais je n’ai pas senti qu’il y avait une vraie raison à cela. Je soupçonne qu’aux environs du 4.20 – ce qui veut dire que je suis à court de doigts et d’orteils pour garder une trace des versions mineures, et que cela commence ainsi à devenir vraiment confus – je vais basculer. C’est ce qui est arrivé pour 4.0, après tout.
Le cycle de développement est le suivant, à compter du jour du publication.
2 semaines pour rajouter les nouvelles fonctionnalités, qui donnent la RC1.
6 à 7 semaines de stabilisation, ce qui nous fait arriver à une RC7 voire un RC8 si nécessaire.
1 semaine de confirmation pour avoir le noyau suivant en x.y.0
Donc une moyenne de 9 à 10 semaines, ce qui fait 5 révisions mineures du noyau par an.
Linus ayant pris l’habitude de s’arrêter à la 20e révision d’un noyau, la x.19.0, on peut calculer rapidement la date de sortie du noyau linux 4.0. Si on compte 9 semaines, cela fait 180 semaines, soit 45 mois, soit 3 ans et 9 mois.
Donc, si on prend la même durée, à savoir les 45 mois en partant d’avril 2015, ça nous donne quoi ? Janvier 2019 ?
Sachant que le noyau 4.17 est sorti début juin 2018, ça nous donne vers la mi-août 2018 pour le noyau 4.18. Le noyau 4.19 ? Courant octobre 2018 ? Ce qui pourrait justifier une sortie du noyau linux 5.0 pour fin décembre 2018, début janvier 2019…
On verra bien, mais j’apprécierai comme cadeau de noël un noyau linux 5.0. Pas vous ?
