Franchement, utiliser une distribution uniquement rolling release, je ne pourrais pas.
Parce que j'ai pas mal de machines à maintenir, et qu'il est hors de question d'être sur la brèche en permanence !
Je veux bien être en rolling sur ma machine perso, où je m'amuse, mais le reste, moins ça bouge et mieux c'est.
Et utiliser une distribution différente selon la machine ? J'ai autre chose à perdre de mon temps…
Debian c'est bien pour ça, avec la version stable et la version Sid.
Ou Slackware : la stable et la -current.
Comme ça c'est la même distrib partout, avec un vrai soucis de maintenance corrective et de sécurité sur la base en version stable, et de quoi jouer/tester avec la version instable.
« Le Mieux est l'ennemi du Bien »
S'il s'agit de la meilleure solution au sens où, comme l'écrit devnewton, on n'a pas trouvé mieux.
Ça n'empêche pas que la solution soit mauvaise, car comme tu l'écris, les brouteurs sont instables, bouffis, et terriblement trop complexes.
Mais en soi ce n'est pas tellement un problème, la technique brouteur-serveur-webapp n'est pas mauvaise en tant que telle.
Le problème c'est que ça entre en collision avec la navigation web classique où on va lire et partager du contenu.
Le problème c'est que c'est le même outil qui rend le service assez simple de te permettre d'accéder à wikipedia, et surfer sur ses millions d'articles dans plein de langues, que celui qui te sert à faire des jeux web super complexes, des webmails bouffis d'orgueil, et autres applications web dont la nature est totalement différente du contenu textuel avec hyperliens.
Et comment permettre un site tel que linuxFr, dédié au contenu texte, mais aussi à l'écriture de ce même contenu, et donc doit permettre une interaction et un dynamisme, tout en rejetant les webapps, parce que pas assez puissant et souple (et pourri jusqu'au trognon) ?
C'est à ça que mon âge canonique se voit…
J'ai gardé des tics de langage de l'époque des « sites optimisés pour IE5.5 en 1024x768 ».
Mais comme on est en train de revivre le passé en ayant remplacé Microsoft-IE par Google-Chrome, ça fait ressurgir des traumatismes…
La question à 100 francs donc : quel pourcentage des développeurs web d'aujourd'hui gardent en tête que le HTML est pensé et prévu pour laisser le client (ie: le navigateur) s'adapter aux contraintes locales ?
Que ce soit la taille ou l'orientation de l'écran, voire l'absence d'écran, ou les périphériques pour aveugles, etc.
Bref, pour ma part je n'utilise même pas d'user-agent-spoofing, si le site veut pas de mon Firefox+ublock, il veut pas de moi, au revoir, et au bout du compte ça ne change rien et tout le monde s'en fout (ils ne s'en rendent pas compte, et je suis allé voir ailleurs sans y penser plus que ça -> donc rien ne change).
J'ai une expérience différente sur mon ordinosaure, mais je suppose qu'on peut avoir un usage différent du web et une définition différente d'un ordinosaure.
Le mien est un DELL Inspiron 1501, 16 ans d'âge, maturé en fût de Slack : AMD Turion 64 dual-core mono-thread @1,6Ghz, 3600 bogomips pour donner une idée de la puissance.
Boosté à 4Go de RAM (2 à l'origine) et un SSD (le HDD d'origine a passé la tête de lecture à gauche).
Soyons honnêtes : ces deux changements sont la seule raison pour laquelle il est encore utilisable aujourd'hui.
J'ai eu testé divers brouteurs pour enhancer mon expérience utilisateur, et je suis finalement resté sur FF : meilleur compromis lourdeur, fonctionnalités, et addons pour se sauver la vie…
Mais je le laisse fermé tant que je n'en ai pas besoin, parce que si je lui laisse du temps (quelques jours et une vingtaine d'onglets non vidés) pour s'étaler, il met de la confiture dans le swap, et c'est collant.
Après, je ne vais pas trop sur des sites qui tuent la couche d'ozone tellement il faut de la puissance de broutage, j'ai démantelé ma centrale à charbon pour miner le bitcoin (nan, en vrai je n'ai jamais miné quoi que ce soit, à part des crayons).
D'où je ne suis toujours pas convaincu par les arguments techniques qui iraient en faveur de Chrome : à part certains sites bien bourrins totalement optimisés - sans honte et sans vergogne - pour Chrome, le reste du web est au moins aussi heureux sous Firefox.
Tu crois qu'en mettant une copie complète du code des lois, et en pointant simplement à la fin qu'il faut appliquer « l’article 6, Ⅲ, 2° de la loi 2004‑575 du 21 juin 2004. » ?
Dans le genre énoncé de partiel super long et la dernière question te dis de ne répondre qu'à la 2 et la 7…
Pour voir si tu suis.
Il y a des soucis politiques surtout.
Techniquement pas tellement, des goûts et des couleurs, et quand on force les gens à changer un bidule ça crie dans les chaumières.
À noter que Firefox bénéficie du fait qu'en tant que logiciel libre du côté Clair de la Force, on attend de lui qu'il soit parfait pour tout le monde et n'ait pas le moindre défaut aussi minime, ou correctible, soit-il.
Chose qu'on ne reproche pas à des outils propriétaires comme Edge, ou partiellement proprios comme Chrome, parce que bon, de la part des MAGAF on sait déjà que ce sont des pourris donc on leur pardonne d'être ce qu'ils sont.
C'est un peu comme de réélire un maire corrompu et condamné, étant donné que les politiques sont tous pourris, finalement ça ne choque pas et on réélit le mal qu'on connaît, plutôt que le concurrent que de-toute-façon-ça-sera-pareil.
Mais en vrai, si tu veux protéger ta vie privée, tu n'as pas des masses d'alternatives : tu pars d'une base de Firefox et tu corrige ses défauts, chose que tu peux faire mais qui n'est pas fait par défaut, contrairement à chrome où tu ne peux rien faire, et que c'est aussi par défaut note bien…
Ou tu vas sur un dérivé de FF, comme Seamonkey, Icecat, Palemoon (qui n'est plus basé sur Gecko d'ailleurs), voire tor-browser.
Perso, j'aime bien firefox-focus sous android. Le brouteur une page qui ne retient rien et recommence toujours tout depuis zéro dès que tu fermes la fenêtre. Indispensable comme navigateur par défaut !
« Le fascisme est un système politique autoritaire qui associe populisme, nationalisme et totalitarisme »
Soyons clairs : Zemmour a comme programme politique d'éliminer les contre-pouvoirs et de renforcer les attributs présidentiels.
S'il ne s'agit pas obligatoirement de Fascisme, il s'agit bien ici d'abattre la République pour aller vers l'Autocratie.
/!\ Je n'invente rien, c'est dans son programme politique, public, vérifiable, il ne s'agit pas de mon opinion.
Et donc les méthodes employées par son mouvement pour tenter de faire passer ses vessies pour nos lanternes (en l'occurrence la manipulation de wikipedia) entrent clairement dans la construction de son objectif final qui peut s'assimiler à un dérivé moderne du fascisme du siècle dernier (là c'est mon interprétation).
La question est-donc : parle-t-on technique et tentative de manipulation de wikipedia, ou politique et qui fait cette tentative et pourquoi ?
Sachant comme il a été écrit plus haut que l'individu en question est ouvertement raciste (si c'est public ce n'est pas de la diffamation, et des condamnations comme les siennes sont des informations publiques), on peut simplement considérer que des DLFP-nautes ont jugés qu'il s'agissait d'un sujet politique et non technique.
Probablement parce qu'on a déjà parlé par ailleurs de diverses tentatives de manipulations de wikipedia, et de ce qui en a résulté, et des moyens techniques, donc le côté technique a déjà été couvert.
Les étiquettes sont donc :
1- politiques ;
2- pertinentes.
On peut cependant se demander si un tel journal politique a sa place ici.
Mais traditionnellement le site a toujours laissé une marge de hors-sujet confortable, et tant que ça ne part pas hors de contrôle avec des dizaines de journaux sur le même thème, on est dans cette fameuse marge.
Je ne dis pas que ça ne devrait, ou ne pourrait, pas être des outils séparés.
D'ailleurs c'est bien plus philosophie UNIX de les avoir séparés.
Mais il y a un binaire soffice.bin qui au bout du compte est appelé par les localc, lobase, lowriter, etc.
Il n'y a qu'un seul logiciel LibreOffice, avec plusieurs modules, qui présentent une interface différente, et servent à gérer des types de fichiers différents, avec des formats différents.
Et ça va même plus loin : si j'ai une fenêtre writer, une autre pour calc, une autre pour base, etc. ouvertes en même temps, je n'ai toujours qu'un seul processus soffice.bin qui tourne, et gère tout ça en parallèle !
LibreOffice n'est pas composé de plusieurs outils juxtaposés.
Et s'il y a des paquets distincts, il doit y avoir énormément de fichiers communs, et un même binaire répété plusieurs fois.
Sauf si - peut-être ? - le code source permet de ne compiler et construire qu'un seul module à la fois, et qu'on peut répéter l'opération pour chacun, et avoir un binaire basé sur le même code source mais qui se restreint à une partie des possibilité.
En d'autres termes : LibreOffice.writer est bien - en pratique - un aspect de LibreOffice, sisi.
Mais bon, il y en a d'autres des systèmes d'init, qui résolvent le principal grief fait à systemV (qui n'est pas le système d'init de Slackware, on est plus sur un truc BSD compatible systemV) c'est à dire le démarrage de services en parallèle, pour avoir un système opérationnel plus rapidement (et la gestion de dépendances, là encore tiens !).
Aucun n'a fait autant jaser.
Et c'est lié à l'approche « je suis La Solution, virez tout le reste et ne laissez que Moi ! » du projet.
Et de multiples erreurs de communications comme d'envoyer chier les gens qui s'étonnaient que screen se fasse tuer par systemd.
Comment tu peux apprécier l'approche d'un développeur principal qui répond des choses du genre « bah c'est pas comme ça que je fais les choses, donc je m'en fous » ? Ok, c'est son logiciel, il le fait comme il veut, mais à un moment, si le logiciel est utilisé, ben tu peux plus.
Donc le projet est parti avec une réputation de merde, il casse des trucs qui fonctionnaient avant, oblige à changer ses habitudes et en apprendre de nouvelles, pour ne pas apporter forcément plus que ce que d'autres projets apportaient déjà.
C'est peut-être bien, mais tant que ça ne reste pas une obligation, et qu'on a le choix, on le prend…
Zenmap fait partie de nmap.
Tu as zenmap parce que tu as nmap.
Je ne sais pas si Debian découpe en deux paquets pour l'outil en ligne de commande et l'interface graphique, Slackware ne le fait pas.
nmap c'est une commande réseau de base utile, pas pour tout le monde, mais néanmoins utile de manière générale. Comme dhcp : en réseau domestique tu peux très bien bosser avec des IP fixes, et perdre quelques Mo d'espace disque pour rien…
Découper LibreOffice en ses différentes parties ?
Bigre, c'est possible ? Il n'y a pas un tel socle commun que ça serait super compliqué et/ou sans réel intérêt ?
On peut démarrer LibreOffice-Base et ouvrir un document Writer, un autre Calc, etc.
Je ne crois pas qu'il s'agisse d'outils distincts, mais bien de plusieurs aspects d'un unique outil pour le coup…
Les dépendances de développement viennent directement avec la compilation/installation depuis les sources.
En fait il faut faire un traitement spécifique manuel pour ne pas les inclure dans ton paquet.
La Slackware est un ensemble complet et fonctionnel, si tu l'installes alors tout fonctionne dedans et tu as tout ce dont tu as besoin pour que tout fonctionne dedans.
Ce (gros) bloc de base je l'aime bien parce que ça me simplifie la vie pour tout le reste : ce qui n'est pas inclus dans Slackware. Et j'aime l'équilibre : il y a beaucoup de choses mais pas tout et n'importe quoi, suffisamment pour faire presque tout ce que tu veux avec ta distrib sans rien ajouter, mais pas les besoins les plus spécifiques, ni toutes les alternatives possibles.
Tu as Apache mais pas Nginx (ni thttpd, ou darkhttpd, etc.), ergo tu as un serveur web, mais pas toutes les alternatives possibles.
Par exemple, je préfère utiliser PostgreSQL à MariaDB, or c'est MariaDB qui est inclus dans Slackware, mais installer PostgreSQL c'est un unique Slackbuild sans aucune dépendance.
Or PostgreSQL a besoin de la glibc, readline, zlib, libxml2, libxslt, openssl, perl, python et tcl.
Ces dépendances sont tellement utiles et standard pour un système Linux qu'elle sont juste là, tu n'as pas à chercher plus loin.
Et donc, si j'ai une Slackware complète (ou que j'assume mon choix de sélectionner mes paquets à la main, comme je le faisais il y a 20 ans - oui je compilais mon noyau paramétré aux petits oignons aussi pour chacune de mes machines), j'ai simplement à vérifier les dépendances des Slackbuilds (à 92% 0, 1 ou 2 paquets, automatisé par les outils de build type sbotools), alors la gestion de dépendances dans le gestionnaire de paquets ne me sert à rien, elle ne m'apporte rien.
Je suis d'accord qu'elle est utile pour construire un conteneur from scratch (une CFS ? 😀), mais dans le conteneur produit, c'est inutile, donc un autre moyen de générer ce conteneur pourrait remplacer un gestionnaire de paquets avec dépendances.
Pour moi c'est la plus-value de la gestion de dépendances en dur qui m'échappe dans la majorité des situations.
Et quand on voit l'enfer des autres systèmes de paquets avec gestion de dépendances complexes, type npm, composer, ou pip, et le bordel qu'ils provoquent, je ne suis pas sûr qu'il faille trop pousser le concept.
Cela dit je ne crois pas que ce genre de problèmes soient présents avec yum ou apt.
Bah c'est le ressenti de Patrick Volkerding, il s'agit ici d'une citation directe.
Elle est dans la ligne du traditionalisme Slackware qu'on pourrait traduire par : « fais chier de désapprendre un truc simple et qui fonctionne pour en apprendre un autre moins simple, même s'il fonctionne aussi ».
A saupoudrer de « ce que je connais est forcément plus simple que ce que je ne connais pas, si le service rendu est le même ».
A mon sens, il n'y a aucune haine envers systemd chez Slackware.
Mais comme je l'ai écrit dans la dépêche : c'est très disruptif, il faut changer toute la façon d'administrer sa machine, de gérer les services, d'aller chercher les logs, etc.
Comme tu le dis toi-même : il faut voir systemd comme GNU, et bien Slackware n'est pas une distribution systemd/Linux, mais GNU/Linux.
À la fois par tradition, et parce que ça convient à toute la communauté.
Ce qui fait beaucoup crier les gens autour de systemd c'est son côté hégémonique et prosélyte : les utilisateurs de Debian ou Redhat (et dérivées) se sont vus imposer de changer leur façon d'administrer leur machine, du jour au lendemain, sans avoir tellement le choix, parce qu'il est difficile de mettre ce truc là en option, ou de l'activer quand on veut, c'est tout ou rien, sans douceur.
Ben voilà, sous Slackware t'as tout, mais sans rien de systemd.
Et c'est un choix qui définit autant la distribution que celui de fournir XFCE/KDE mais pas Gnome.
Je trouve l'administration un poste sous Linux beaucoup plus simple et cohérente depuis l'introduction de systemd qui fait bien son job. Justement, tout est bien propre et découpé.
Je vais troller un peu (un peu, promis !), mais je pense que c'est parce que tu avais auparavant à administrer des Debian (ou Redhat ou dérivés), et qu'ils foutaient historiquement un bazar monstre et incompréhensible dans /etc pour permettre à des outils en clicodrôme d'administrer avec des gros boutons et des icônes colorées. Tu avais deux choses à apprendre : la façon de faire Debian et les spécificités de chaque logiciel.
Sous Slackware tu as les fichiers de conf des auteurs des logiciels, disponibles là où la doc officielle les place.
Et franchement, ça n'a rien ni de bordélique, ni de spécialement complexe.
Il faut juste éditer tes fichiers texte à la main, et lire la doc des auteurs des logiciels.
Systemd résout (aussi) des problèmes de Debian et de Redhat, un bon outil se contenterait de résoudre des problèmes de Linux.
En fait, je vois systemd comme une évolution de la philosophie d'administration système Linux développée ces (presque) trente dernières années par Debian et Redhat (qui se sont pas mal repompés leurs idées).
Et comme la philosophie Slackware n'a jamais suivi cette voie là, systemd y a nettement moins d'intérêt.
(Je préfère écrire Slackware en entier pour ne pas confondre avec Slack)
Si, justement : les paquets n'ont pas ces découpes fines.
Le choix de Debian c'est de tout découper finement : un paquet serveur, un paquet client, un paquet pour le dev, un paquet pour la doc, un paquet pour autre chose.
Et puis à partir d'une seule source construire plein de paquets, gérer finement les dépendances, et n'installer que ce qui te sert effectivement à quelque chose.
Ce qui a une très claire utilité pour un serveur le plus minimaliste possible (ou un conteneur type Docker).
Et qui - globalement - ne te sert pas à grand chose sur ton poste de travail où tu vas finir par tout installer, bout par bout le jour où tu en as besoin, et où tu seras dépendant de ta connexion au dépôt de paquets pour pouvoir bosser.
Le choix de Slackware c'est de ne pas découper.
Il y a un code source pour mariadb par exemple, il y a un seul paquet, et tout dedans comme tu l'aurais avec un ./configure && make && make install.
En contrepartie, un logiciel qui a une utilisation texte et une graphique, par exemple emacs, va venir complet même si tu n'as pas d'interface graphique. /usr/bin/emacs-no-x11 va fonctionner mais pas /usr/bin/emacs-with-x11.
Et oui, tu vas avoir tout l'emacs graphique qui ne te sert à rien.
Et c'est pas grave.
Laisse de côté des quelques mégaoctets morts, le reste est plus simple à gérer.
Mouais, je ne vois pas l'intérêt de la liberté de facilement faire de la merde.
Parce que ce n'est pas forcément de la merde.
Ce n'est pas parce que ce n'est pas de telle ou telle manière que les auteurs d'une distrib ont imaginés son utilisation, que ces façons de faire sont mauvaise.
Oui, tu peux tout casser, mais être root permet de tout casser très très facilement.
Je suis root sur toutes mes machines, j'ai rarement cassé grand chose, mais je vivrais très très mal de ne plus l'être parce que la distrib m'en empêche « pour mon bien » ou « par sécurité » !
Bah voilà : je peux tout casser et tout réparer comme je l'entends, si je veux, ou je veux et comme je veux.
Note bien : je suis très content de la gestion de dépendances Debian ou Redhat, quand je bosse sur des serveurs distants, souvent sous CentOS ces derniers temps, je trouve ça pratique de ne rien avoir à connaître du gestionnaire de paquet et juste faire yum install bidule.
Mais sur mes machines, ça ne m'intéresse pas du tout.
Dans un conteneur, je ne vois pas l'intérêt.
Bref, c'est une particularité de Slackware, que j'apprécie à sa juste valeur, avec ses bons et ses mauvais côtés (je préfère gérer les mauvais côté de Slackware que ceux de Debian, question de goût), et je pense qu'il est important de le préciser parce que ça fait une grosse différence avec toutes les Debian/Redhat.
Slackware et Debian ont peut-être démarrée en parallèle, mais ces deux projets sont très différents.
Là où avec Debian tu fais une installation minimale et tu ajoutes les outils dont tu as besoin, qui vont embarquer leurs dépendances avec eux, pour te faire un OS personnel, sous Slackware en général tu fais une « full install ».
Les paquets Slackware sont séparés en catégories, par exemple :
k - les sources du noyau Linux fourni par ailleurs ;
kde - tout KDE
xfce - tout XFCE
t - texlive
x - X.org / Wayland
xap - outils nécessitant un serveur graphique
n - outils réseau (apache, dovecot, dhcp, …)
etc.
Il est possible lors de l'installation de choisir chaque paquet un par un, mais en général on choisit l'option d'installation complète, ou on restreint par catégories.
Par exemple sur un serveur sans interface graphique, on va inclure [a, ap, l, n, y]
S'il faut les outils de développement on va rajouter d (gcc, autotools, git, etc.)
Bref, pour installer sudo, une fois que tu as installé ta Slackware, ben tu ne fais rien, c'est dispo, tu ne tires pas de dépendances, tu ne cherches pas, c'est là, ça fonctionne.
Le seule question qui se pose, c'est quid des logiciels qui ne sont pas disponibles.
Et là tu as Slackbuilds.org, qui va te présenter la liste des dépendances, et si tu utilises un outil type sbotools, il va construire les dépendances, les installer et tout te faire jusqu'à ton paquet final.
À noter qu'avec une base de Slackware complète, beaucoup de slackbuilds n'ont aucune dépendances (un grep vite fait me donne 60% sans dépendances, et 92% jusque deux dépendances).
le gestionnaire de paquet n’intègre pas de résolution de dépendances
En pratique tu as juste la main sur ce que tu fais : installer deux versions de la même lib ? Pas de soucis, si ça te sert à quelque chose, ça va être un peu le bazar et certains liens symboliques de .so seront en conflit entre les deux, mais si c'est ce que tu veux, personne ne t'en empêche, et tu pourras toujours utiliser les pkgtools pour supprimer, réinstaller, modifier comme tu veux.
Ça veut dire que tu peux parfaitement faire n'importe quoi et tout péter.
C'est ce que j'attends de mon système d'exploitation : qu'il me laisse tout casser si c'est ce que j'ai envie de faire !
D'ailleurs, fais gaffe, sous Slackware, un « rm fichier » ne te demande pas confirmation, tu n'es donc pas obligé de toujours écrire « rm -f fichier », et donc si « fichier » est protégé tu auras un avertissement visible, rare, et qui t'évites de faire des bêtises.
Aurora Store est une application libre permettant d'installer les applications du play store de Google.
Outre le fait qu'elle permette d'utiliser un compte anonyme pour installer les applications gratuites, un compte google est nécessaire pour stocker les achats, on peut l'utiliser avec Aurora pour les installer, mais c'est moins anonyme.
Aurora Store fonctionne sans les google apps, donc par exemple sur un LineageOS sans aucune gapps dessus.
Un des intérêts d'Aurora Store est d'inclure les résultats d'Exodus Privacy dans la description des applications, on peut ainsi aisément voir que l'application TousAntiCovid ne contient pas de traqueurs, mais que Outlook en contient 7 qui viennent de Microsoft, Google et aussi Facebook, entre autres…
Franchement, quitte à installer des applis du Play Store, utilisez Aurora Store, disponible dans tous les bons magasins F-Droid !
J’aurais voulu gentiment vanner les derniers des mohicans qui pensent que Slackware a une place ailleurs que dans l’histoire de la galaxie Linux en leur demandant s’ils comptaient écrire plus rapidement la dépêche que le développement de Slackware 15. > Mais comme ils sont arrivés à garder une dépêche en rédaction et en soumettre une directement à publication, je vais me taire. Ils sont peut-être plus nombreux et forts que ce que je pensais.
Je suis indestructible, invincible, et inébranlable !
Et puis franchement, je n'ai ni le temps ni l'envie d'apprendre une nouvelle distrib.
Je suis un authentique vieux con, campé sur mes idées reçues, et bien planté face au remous du reste du monde.
Na.
J'ai commencé avec celle-là aussi, mais depuis un CD-Rom dans un magazine !
Avec mon PC pourri bricolé de bric et de broc, aucune distribution plus user-friendly n'arrivait à faire fonctionner correctement le serveur graphique : déformé (mauvaise résolution), ou buggé (traits bizarres, clignotements), rien n'allait.
La Slackware, elle, n'avait pas ces soucis : elle ne cherchait même pas à lancer XF86, donc tout fonctionnait au poil !
J'ai regardé comment démarrer X dessus, il y avait les outils du genre xf86config, et l'édition de fichiers de conf à la main, les modeline manuels, etc. En quelques heures alors que je découvrais Linux, ça a fonctionné.
Et débarquer dans un monde avec gnome + enlightenment 0.16 alors que j'avais connu le DOS et win 95/98, c'était le jour et la nuit : beau, réactif, puissant, les bureaux multiples, indispensable !
Enfin pouvoir lire les vidéos qui saccadaient sous windows, avec Unreal Tournament dispo sous Linux, et Starcraft qui tournait au poil avec wine, j'ai pas gardé le double-boot bien longtemps…
L'alliance entre la tradition et le modernisme, ou comment ne pas subir les hypes de ces dernières années tout en restant moderne et en permettant à chacun d'utiliser son Linux comme il l'entend.
Slackware 15.0 reste dans la continuité de Slackware, pas de changement drastique, les habitudes sont conservées.
Slackbuilds.org aura sa version du dépôt 15.0 de près de 5000 paquets additionnels prêts pour la semaine prochaine à peu près (argh, faut que je bosse moi !).
[^] # Re: Presque le même parcours…
Posté par Yth (Mastodon) . En réponse au journal Comparaison entre Manjaro et Debian Sid. Évalué à 4. Dernière modification le 23 février 2022 à 14:37.
Ah, j'ai fait 7.0 -> 7.1 -> 8.0 -> 8.1 -> 9.0 -> 9.1 -> 10.0 -> 10.1 -> 10.2 -> 11.0 -> 12.0 -> 12.1 -> 12.2 -> 13.0 -> 13.1 -> 13.37 -> 14.0 -> 14.1 -> 14.2 -> current -> 15.0
:)
[^] # Re: ArchLinux
Posté par Yth (Mastodon) . En réponse au journal Comparaison entre Manjaro et Debian Sid. Évalué à 7.
Franchement, utiliser une distribution uniquement rolling release, je ne pourrais pas.
Parce que j'ai pas mal de machines à maintenir, et qu'il est hors de question d'être sur la brèche en permanence !
Je veux bien être en rolling sur ma machine perso, où je m'amuse, mais le reste, moins ça bouge et mieux c'est.
Et utiliser une distribution différente selon la machine ? J'ai autre chose à perdre de mon temps…
Debian c'est bien pour ça, avec la version stable et la version Sid.
Ou Slackware : la stable et la -current.
Comme ça c'est la même distrib partout, avec un vrai soucis de maintenance corrective et de sécurité sur la base en version stable, et de quoi jouer/tester avec la version instable.
[^] # Re: Je ne comprends pas trop ce qu'on reproche à FF
Posté par Yth (Mastodon) . En réponse au lien Est-ce que Firefox est en bonne santé?. Évalué à 4.
« Le Mieux est l'ennemi du Bien »
S'il s'agit de la meilleure solution au sens où, comme l'écrit devnewton, on n'a pas trouvé mieux.
Ça n'empêche pas que la solution soit mauvaise, car comme tu l'écris, les brouteurs sont instables, bouffis, et terriblement trop complexes.
Mais en soi ce n'est pas tellement un problème, la technique brouteur-serveur-webapp n'est pas mauvaise en tant que telle.
Le problème c'est que ça entre en collision avec la navigation web classique où on va lire et partager du contenu.
Le problème c'est que c'est le même outil qui rend le service assez simple de te permettre d'accéder à wikipedia, et surfer sur ses millions d'articles dans plein de langues, que celui qui te sert à faire des jeux web super complexes, des webmails bouffis d'orgueil, et autres applications web dont la nature est totalement différente du contenu textuel avec hyperliens.
Et comment permettre un site tel que linuxFr, dédié au contenu texte, mais aussi à l'écriture de ce même contenu, et donc doit permettre une interaction et un dynamisme, tout en rejetant les webapps, parce que pas assez puissant et souple (et pourri jusqu'au trognon) ?
[^] # Re: je l'utilise quasi plus jamais .. Hélas
Posté par Yth (Mastodon) . En réponse au lien Est-ce que Firefox est en bonne santé?. Évalué à 6.
C'est à ça que mon âge canonique se voit…
J'ai gardé des tics de langage de l'époque des « sites optimisés pour IE5.5 en 1024x768 ».
Mais comme on est en train de revivre le passé en ayant remplacé Microsoft-IE par Google-Chrome, ça fait ressurgir des traumatismes…
La question à 100 francs donc : quel pourcentage des développeurs web d'aujourd'hui gardent en tête que le HTML est pensé et prévu pour laisser le client (ie: le navigateur) s'adapter aux contraintes locales ?
Que ce soit la taille ou l'orientation de l'écran, voire l'absence d'écran, ou les périphériques pour aveugles, etc.
Bref, pour ma part je n'utilise même pas d'user-agent-spoofing, si le site veut pas de mon Firefox+ublock, il veut pas de moi, au revoir, et au bout du compte ça ne change rien et tout le monde s'en fout (ils ne s'en rendent pas compte, et je suis allé voir ailleurs sans y penser plus que ça -> donc rien ne change).
[^] # Re: je l'utilise quasi plus jamais .. Hélas
Posté par Yth (Mastodon) . En réponse au lien Est-ce que Firefox est en bonne santé?. Évalué à 10.
J'ai une expérience différente sur mon ordinosaure, mais je suppose qu'on peut avoir un usage différent du web et une définition différente d'un ordinosaure.
Le mien est un DELL Inspiron 1501, 16 ans d'âge, maturé en fût de Slack : AMD Turion 64 dual-core mono-thread @1,6Ghz, 3600 bogomips pour donner une idée de la puissance.
Boosté à 4Go de RAM (2 à l'origine) et un SSD (le HDD d'origine a passé la tête de lecture à gauche).
Soyons honnêtes : ces deux changements sont la seule raison pour laquelle il est encore utilisable aujourd'hui.
J'ai eu testé divers brouteurs pour enhancer mon expérience utilisateur, et je suis finalement resté sur FF : meilleur compromis lourdeur, fonctionnalités, et addons pour se sauver la vie…
Mais je le laisse fermé tant que je n'en ai pas besoin, parce que si je lui laisse du temps (quelques jours et une vingtaine d'onglets non vidés) pour s'étaler, il met de la confiture dans le swap, et c'est collant.
Après, je ne vais pas trop sur des sites qui tuent la couche d'ozone tellement il faut de la puissance de broutage, j'ai démantelé ma centrale à charbon pour miner le bitcoin (nan, en vrai je n'ai jamais miné quoi que ce soit, à part des crayons).
D'où je ne suis toujours pas convaincu par les arguments techniques qui iraient en faveur de Chrome : à part certains sites bien bourrins totalement optimisés - sans honte et sans vergogne - pour Chrome, le reste du web est au moins aussi heureux sous Firefox.
# Code des Lois
Posté par Yth (Mastodon) . En réponse au journal Évolution des Conditions Générales. Évalué à 3.
Tu crois qu'en mettant une copie complète du code des lois, et en pointant simplement à la fin qu'il faut appliquer « l’article 6, Ⅲ, 2° de la loi 2004‑575 du 21 juin 2004. » ?
Dans le genre énoncé de partiel super long et la dernière question te dis de ne répondre qu'à la 2 et la 7…
Pour voir si tu suis.
Là on doit pouvoir vaincre pas mal de CGU :)
[^] # Re: Je ne comprends pas trop ce qu'on reproche à FF
Posté par Yth (Mastodon) . En réponse au lien Est-ce que Firefox est en bonne santé?. Évalué à 10.
Il y a des soucis politiques surtout.
Techniquement pas tellement, des goûts et des couleurs, et quand on force les gens à changer un bidule ça crie dans les chaumières.
À noter que Firefox bénéficie du fait qu'en tant que logiciel libre du côté Clair de la Force, on attend de lui qu'il soit parfait pour tout le monde et n'ait pas le moindre défaut aussi minime, ou correctible, soit-il.
Chose qu'on ne reproche pas à des outils propriétaires comme Edge, ou partiellement proprios comme Chrome, parce que bon, de la part des MAGAF on sait déjà que ce sont des pourris donc on leur pardonne d'être ce qu'ils sont.
C'est un peu comme de réélire un maire corrompu et condamné, étant donné que les politiques sont tous pourris, finalement ça ne choque pas et on réélit le mal qu'on connaît, plutôt que le concurrent que de-toute-façon-ça-sera-pareil.
Mais en vrai, si tu veux protéger ta vie privée, tu n'as pas des masses d'alternatives : tu pars d'une base de Firefox et tu corrige ses défauts, chose que tu peux faire mais qui n'est pas fait par défaut, contrairement à chrome où tu ne peux rien faire, et que c'est aussi par défaut note bien…
Ou tu vas sur un dérivé de FF, comme Seamonkey, Icecat, Palemoon (qui n'est plus basé sur Gecko d'ailleurs), voire tor-browser.
Perso, j'aime bien firefox-focus sous android. Le brouteur une page qui ne retient rien et recommence toujours tout depuis zéro dès que tu fermes la fenêtre. Indispensable comme navigateur par défaut !
[^] # Re: Étiquettes non pertinentes
Posté par Yth (Mastodon) . En réponse au lien Tentative de manipulation de Wikipédia par l’équipe d’Éric Zemmour. Évalué à 3.
Donc on va dire qu'on a une sorte d'exception de notoriété publique, dans des journaux de grande diffusion, dans les mois qui précèdent ?
[^] # Re: Étiquettes non pertinentes
Posté par Yth (Mastodon) . En réponse au lien Tentative de manipulation de Wikipédia par l’équipe d’Éric Zemmour. Évalué à 9. Dernière modification le 21 février 2022 à 10:22.
« Le fascisme est un système politique autoritaire qui associe populisme, nationalisme et totalitarisme »
Soyons clairs : Zemmour a comme programme politique d'éliminer les contre-pouvoirs et de renforcer les attributs présidentiels.
S'il ne s'agit pas obligatoirement de Fascisme, il s'agit bien ici d'abattre la République pour aller vers l'Autocratie.
/!\ Je n'invente rien, c'est dans son programme politique, public, vérifiable, il ne s'agit pas de mon opinion.
Et donc les méthodes employées par son mouvement pour tenter de faire passer ses vessies pour nos lanternes (en l'occurrence la manipulation de wikipedia) entrent clairement dans la construction de son objectif final qui peut s'assimiler à un dérivé moderne du fascisme du siècle dernier (là c'est mon interprétation).
La question est-donc : parle-t-on technique et tentative de manipulation de wikipedia, ou politique et qui fait cette tentative et pourquoi ?
Sachant comme il a été écrit plus haut que l'individu en question est ouvertement raciste (si c'est public ce n'est pas de la diffamation, et des condamnations comme les siennes sont des informations publiques), on peut simplement considérer que des DLFP-nautes ont jugés qu'il s'agissait d'un sujet politique et non technique.
Probablement parce qu'on a déjà parlé par ailleurs de diverses tentatives de manipulations de wikipedia, et de ce qui en a résulté, et des moyens techniques, donc le côté technique a déjà été couvert.
Les étiquettes sont donc :
1- politiques ;
2- pertinentes.
On peut cependant se demander si un tel journal politique a sa place ici.
Mais traditionnellement le site a toujours laissé une marge de hors-sujet confortable, et tant que ça ne part pas hors de contrôle avec des dizaines de journaux sur le même thème, on est dans cette fameuse marge.
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Yth (Mastodon) . En réponse à la dépêche Tout arrive, même Slackware 15.0. Évalué à 2. Dernière modification le 11 février 2022 à 14:03.
Je ne dis pas que ça ne devrait, ou ne pourrait, pas être des outils séparés.
D'ailleurs c'est bien plus philosophie UNIX de les avoir séparés.
Mais il y a un binaire soffice.bin qui au bout du compte est appelé par les localc, lobase, lowriter, etc.
Il n'y a qu'un seul logiciel LibreOffice, avec plusieurs modules, qui présentent une interface différente, et servent à gérer des types de fichiers différents, avec des formats différents.
Et ça va même plus loin : si j'ai une fenêtre writer, une autre pour calc, une autre pour base, etc. ouvertes en même temps, je n'ai toujours qu'un seul processus soffice.bin qui tourne, et gère tout ça en parallèle !
LibreOffice n'est pas composé de plusieurs outils juxtaposés.
Et s'il y a des paquets distincts, il doit y avoir énormément de fichiers communs, et un même binaire répété plusieurs fois.
Sauf si - peut-être ? - le code source permet de ne compiler et construire qu'un seul module à la fois, et qu'on peut répéter l'opération pour chacun, et avoir un binaire basé sur le même code source mais qui se restreint à une partie des possibilité.
En d'autres termes : LibreOffice.writer est bien - en pratique - un aspect de LibreOffice, sisi.
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Yth (Mastodon) . En réponse à la dépêche Tout arrive, même Slackware 15.0. Évalué à 10.
J'avais prévenu que ça partait en troll hein :)
Mais bon, il y en a d'autres des systèmes d'init, qui résolvent le principal grief fait à systemV (qui n'est pas le système d'init de Slackware, on est plus sur un truc BSD compatible systemV) c'est à dire le démarrage de services en parallèle, pour avoir un système opérationnel plus rapidement (et la gestion de dépendances, là encore tiens !).
Aucun n'a fait autant jaser.
Et c'est lié à l'approche « je suis La Solution, virez tout le reste et ne laissez que Moi ! » du projet.
Et de multiples erreurs de communications comme d'envoyer chier les gens qui s'étonnaient que screen se fasse tuer par systemd.
Comment tu peux apprécier l'approche d'un développeur principal qui répond des choses du genre « bah c'est pas comme ça que je fais les choses, donc je m'en fous » ? Ok, c'est son logiciel, il le fait comme il veut, mais à un moment, si le logiciel est utilisé, ben tu peux plus.
Donc le projet est parti avec une réputation de merde, il casse des trucs qui fonctionnaient avant, oblige à changer ses habitudes et en apprendre de nouvelles, pour ne pas apporter forcément plus que ce que d'autres projets apportaient déjà.
C'est peut-être bien, mais tant que ça ne reste pas une obligation, et qu'on a le choix, on le prend…
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Yth (Mastodon) . En réponse à la dépêche Tout arrive, même Slackware 15.0. Évalué à 4.
Zenmap fait partie de nmap.
Tu as zenmap parce que tu as nmap.
Je ne sais pas si Debian découpe en deux paquets pour l'outil en ligne de commande et l'interface graphique, Slackware ne le fait pas.
nmap c'est une commande réseau de base utile, pas pour tout le monde, mais néanmoins utile de manière générale. Comme dhcp : en réseau domestique tu peux très bien bosser avec des IP fixes, et perdre quelques Mo d'espace disque pour rien…
Découper LibreOffice en ses différentes parties ?
Bigre, c'est possible ? Il n'y a pas un tel socle commun que ça serait super compliqué et/ou sans réel intérêt ?
On peut démarrer LibreOffice-Base et ouvrir un document Writer, un autre Calc, etc.
Je ne crois pas qu'il s'agisse d'outils distincts, mais bien de plusieurs aspects d'un unique outil pour le coup…
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Yth (Mastodon) . En réponse à la dépêche Tout arrive, même Slackware 15.0. Évalué à 7.
Les dépendances de développement viennent directement avec la compilation/installation depuis les sources.
En fait il faut faire un traitement spécifique manuel pour ne pas les inclure dans ton paquet.
La Slackware est un ensemble complet et fonctionnel, si tu l'installes alors tout fonctionne dedans et tu as tout ce dont tu as besoin pour que tout fonctionne dedans.
Ce (gros) bloc de base je l'aime bien parce que ça me simplifie la vie pour tout le reste : ce qui n'est pas inclus dans Slackware. Et j'aime l'équilibre : il y a beaucoup de choses mais pas tout et n'importe quoi, suffisamment pour faire presque tout ce que tu veux avec ta distrib sans rien ajouter, mais pas les besoins les plus spécifiques, ni toutes les alternatives possibles.
Tu as Apache mais pas Nginx (ni thttpd, ou darkhttpd, etc.), ergo tu as un serveur web, mais pas toutes les alternatives possibles.
Par exemple, je préfère utiliser PostgreSQL à MariaDB, or c'est MariaDB qui est inclus dans Slackware, mais installer PostgreSQL c'est un unique Slackbuild sans aucune dépendance.
Or PostgreSQL a besoin de la glibc, readline, zlib, libxml2, libxslt, openssl, perl, python et tcl.
Ces dépendances sont tellement utiles et standard pour un système Linux qu'elle sont juste là, tu n'as pas à chercher plus loin.
Et donc, si j'ai une Slackware complète (ou que j'assume mon choix de sélectionner mes paquets à la main, comme je le faisais il y a 20 ans - oui je compilais mon noyau paramétré aux petits oignons aussi pour chacune de mes machines), j'ai simplement à vérifier les dépendances des Slackbuilds (à 92% 0, 1 ou 2 paquets, automatisé par les outils de build type sbotools), alors la gestion de dépendances dans le gestionnaire de paquets ne me sert à rien, elle ne m'apporte rien.
Je suis d'accord qu'elle est utile pour construire un conteneur from scratch (une CFS ? 😀), mais dans le conteneur produit, c'est inutile, donc un autre moyen de générer ce conteneur pourrait remplacer un gestionnaire de paquets avec dépendances.
Pour moi c'est la plus-value de la gestion de dépendances en dur qui m'échappe dans la majorité des situations.
Et quand on voit l'enfer des autres systèmes de paquets avec gestion de dépendances complexes, type npm, composer, ou pip, et le bordel qu'ils provoquent, je ne suis pas sûr qu'il faille trop pousser le concept.
Cela dit je ne crois pas que ce genre de problèmes soient présents avec yum ou apt.
[^] # Re: "le monde Linux s’éloigne lentement mais sûrement de la philosophie UNIX"
Posté par Yth (Mastodon) . En réponse à la dépêche Tout arrive, même Slackware 15.0. Évalué à 10.
Bah c'est le ressenti de Patrick Volkerding, il s'agit ici d'une citation directe.
Elle est dans la ligne du traditionalisme Slackware qu'on pourrait traduire par : « fais chier de désapprendre un truc simple et qui fonctionne pour en apprendre un autre moins simple, même s'il fonctionne aussi ».
A saupoudrer de « ce que je connais est forcément plus simple que ce que je ne connais pas, si le service rendu est le même ».
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Yth (Mastodon) . En réponse à la dépêche Tout arrive, même Slackware 15.0. Évalué à 10.
A mon sens, il n'y a aucune haine envers systemd chez Slackware.
Mais comme je l'ai écrit dans la dépêche : c'est très disruptif, il faut changer toute la façon d'administrer sa machine, de gérer les services, d'aller chercher les logs, etc.
Comme tu le dis toi-même : il faut voir systemd comme GNU, et bien Slackware n'est pas une distribution systemd/Linux, mais GNU/Linux.
À la fois par tradition, et parce que ça convient à toute la communauté.
Ce qui fait beaucoup crier les gens autour de systemd c'est son côté hégémonique et prosélyte : les utilisateurs de Debian ou Redhat (et dérivées) se sont vus imposer de changer leur façon d'administrer leur machine, du jour au lendemain, sans avoir tellement le choix, parce qu'il est difficile de mettre ce truc là en option, ou de l'activer quand on veut, c'est tout ou rien, sans douceur.
Ben voilà, sous Slackware t'as tout, mais sans rien de systemd.
Et c'est un choix qui définit autant la distribution que celui de fournir XFCE/KDE mais pas Gnome.
Je vais troller un peu (un peu, promis !), mais je pense que c'est parce que tu avais auparavant à administrer des Debian (ou Redhat ou dérivés), et qu'ils foutaient historiquement un bazar monstre et incompréhensible dans /etc pour permettre à des outils en clicodrôme d'administrer avec des gros boutons et des icônes colorées. Tu avais deux choses à apprendre : la façon de faire Debian et les spécificités de chaque logiciel.
Sous Slackware tu as les fichiers de conf des auteurs des logiciels, disponibles là où la doc officielle les place.
Et franchement, ça n'a rien ni de bordélique, ni de spécialement complexe.
Il faut juste éditer tes fichiers texte à la main, et lire la doc des auteurs des logiciels.
Systemd résout (aussi) des problèmes de Debian et de Redhat, un bon outil se contenterait de résoudre des problèmes de Linux.
En fait, je vois systemd comme une évolution de la philosophie d'administration système Linux développée ces (presque) trente dernières années par Debian et Redhat (qui se sont pas mal repompés leurs idées).
Et comme la philosophie Slackware n'a jamais suivi cette voie là, systemd y a nettement moins d'intérêt.
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Yth (Mastodon) . En réponse à la dépêche Tout arrive, même Slackware 15.0. Évalué à 10.
(Je préfère écrire Slackware en entier pour ne pas confondre avec Slack)
Si, justement : les paquets n'ont pas ces découpes fines.
Le choix de Debian c'est de tout découper finement : un paquet serveur, un paquet client, un paquet pour le dev, un paquet pour la doc, un paquet pour autre chose.
Et puis à partir d'une seule source construire plein de paquets, gérer finement les dépendances, et n'installer que ce qui te sert effectivement à quelque chose.
Ce qui a une très claire utilité pour un serveur le plus minimaliste possible (ou un conteneur type Docker).
Et qui - globalement - ne te sert pas à grand chose sur ton poste de travail où tu vas finir par tout installer, bout par bout le jour où tu en as besoin, et où tu seras dépendant de ta connexion au dépôt de paquets pour pouvoir bosser.
Le choix de Slackware c'est de ne pas découper.
Il y a un code source pour mariadb par exemple, il y a un seul paquet, et tout dedans comme tu l'aurais avec un
./configure && make && make install.En contrepartie, un logiciel qui a une utilisation texte et une graphique, par exemple emacs, va venir complet même si tu n'as pas d'interface graphique. /usr/bin/emacs-no-x11 va fonctionner mais pas /usr/bin/emacs-with-x11.
Et oui, tu vas avoir tout l'emacs graphique qui ne te sert à rien.
Et c'est pas grave.
Laisse de côté des quelques mégaoctets morts, le reste est plus simple à gérer.
Parce que ce n'est pas forcément de la merde.
Ce n'est pas parce que ce n'est pas de telle ou telle manière que les auteurs d'une distrib ont imaginés son utilisation, que ces façons de faire sont mauvaise.
Oui, tu peux tout casser, mais être root permet de tout casser très très facilement.
Je suis root sur toutes mes machines, j'ai rarement cassé grand chose, mais je vivrais très très mal de ne plus l'être parce que la distrib m'en empêche « pour mon bien » ou « par sécurité » !
Bah voilà : je peux tout casser et tout réparer comme je l'entends, si je veux, ou je veux et comme je veux.
Note bien : je suis très content de la gestion de dépendances Debian ou Redhat, quand je bosse sur des serveurs distants, souvent sous CentOS ces derniers temps, je trouve ça pratique de ne rien avoir à connaître du gestionnaire de paquet et juste faire
yum install bidule.Mais sur mes machines, ça ne m'intéresse pas du tout.
Dans un conteneur, je ne vois pas l'intérêt.
Bref, c'est une particularité de Slackware, que j'apprécie à sa juste valeur, avec ses bons et ses mauvais côtés (je préfère gérer les mauvais côté de Slackware que ceux de Debian, question de goût), et je pense qu'il est important de le préciser parce que ça fait une grosse différence avec toutes les Debian/Redhat.
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Yth (Mastodon) . En réponse à la dépêche Tout arrive, même Slackware 15.0. Évalué à 10. Dernière modification le 10 février 2022 à 09:00.
Slackware et Debian ont peut-être démarrée en parallèle, mais ces deux projets sont très différents.
Là où avec Debian tu fais une installation minimale et tu ajoutes les outils dont tu as besoin, qui vont embarquer leurs dépendances avec eux, pour te faire un OS personnel, sous Slackware en général tu fais une « full install ».
Les paquets Slackware sont séparés en catégories, par exemple :
k - les sources du noyau Linux fourni par ailleurs ;
kde - tout KDE
xfce - tout XFCE
t - texlive
x - X.org / Wayland
xap - outils nécessitant un serveur graphique
n - outils réseau (apache, dovecot, dhcp, …)
etc.
Il est possible lors de l'installation de choisir chaque paquet un par un, mais en général on choisit l'option d'installation complète, ou on restreint par catégories.
Par exemple sur un serveur sans interface graphique, on va inclure [a, ap, l, n, y]
S'il faut les outils de développement on va rajouter d (gcc, autotools, git, etc.)
Bref, pour installer sudo, une fois que tu as installé ta Slackware, ben tu ne fais rien, c'est dispo, tu ne tires pas de dépendances, tu ne cherches pas, c'est là, ça fonctionne.
Le seule question qui se pose, c'est quid des logiciels qui ne sont pas disponibles.
Et là tu as Slackbuilds.org, qui va te présenter la liste des dépendances, et si tu utilises un outil type sbotools, il va construire les dépendances, les installer et tout te faire jusqu'à ton paquet final.
À noter qu'avec une base de Slackware complète, beaucoup de slackbuilds n'ont aucune dépendances (un grep vite fait me donne 60% sans dépendances, et 92% jusque deux dépendances).
Tu as donc le mauvais côté de la non gestion de dépendances : tu fais une installation complète, sans choisir précisément ce que tu veux, sinon tu te prends la tête à tirer tes dépendances à la main (personne ne fait ça je pense ?)
Mais le bon côté aussi : aucun « dependency hell » pas de paquet à-la-con©®™ qui a un sous-utilitaire graphique que tu n'utilises pas mais qui va t'installer tout X.org, et Qt5, etc.
Là tu vas avoir ton utilitaire ligne de commande, et aussi le sous-utilitaire graphique, c'est juste que ce dernier ne fonctionnera pas si tu as fait une installation pure console.
Le Slackware ne te dira rien, ne te prendra pas la tête, ne t'avertiras pas non plus : tu fais comme tu veux.
En pratique tu as juste la main sur ce que tu fais : installer deux versions de la même lib ? Pas de soucis, si ça te sert à quelque chose, ça va être un peu le bazar et certains liens symboliques de .so seront en conflit entre les deux, mais si c'est ce que tu veux, personne ne t'en empêche, et tu pourras toujours utiliser les pkgtools pour supprimer, réinstaller, modifier comme tu veux.
Ça veut dire que tu peux parfaitement faire n'importe quoi et tout péter.
C'est ce que j'attends de mon système d'exploitation : qu'il me laisse tout casser si c'est ce que j'ai envie de faire !
D'ailleurs, fais gaffe, sous Slackware, un « rm fichier » ne te demande pas confirmation, tu n'es donc pas obligé de toujours écrire « rm -f fichier », et donc si « fichier » est protégé tu auras un avertissement visible, rare, et qui t'évites de faire des bêtises.
# 15.0 disponible pour ARM aussi
Posté par Yth (Mastodon) . En réponse à la dépêche Tout arrive, même Slackware 15.0. Évalué à 10.
Et ce matin la version ARM est officiellement sortie en 15.0 aussi, une semaine après les versions ix86 et x86_64 !
# Aurora Store
Posté par Yth (Mastodon) . En réponse au lien Analyse les problèmes de vie privée dans les applications Android.. Évalué à 10.
Aurora Store est une application libre permettant d'installer les applications du play store de Google.
Outre le fait qu'elle permette d'utiliser un compte anonyme pour installer les applications gratuites, un compte google est nécessaire pour stocker les achats, on peut l'utiliser avec Aurora pour les installer, mais c'est moins anonyme.
Aurora Store fonctionne sans les google apps, donc par exemple sur un LineageOS sans aucune gapps dessus.
Un des intérêts d'Aurora Store est d'inclure les résultats d'Exodus Privacy dans la description des applications, on peut ainsi aisément voir que l'application TousAntiCovid ne contient pas de traqueurs, mais que Outlook en contient 7 qui viennent de Microsoft, Google et aussi Facebook, entre autres…
Franchement, quitte à installer des applis du Play Store, utilisez Aurora Store, disponible dans tous les bons magasins F-Droid !
[^] # Re: Chuis pô un Mohican...
Posté par Yth (Mastodon) . En réponse au journal Les dernières nouvelles du nettoyage de l'espace de rédaction. Évalué à 3.
36 versions en 29 ans, je vois pas de quoi tu parles.
# Chuis pô un Mohican...
Posté par Yth (Mastodon) . En réponse au journal Les dernières nouvelles du nettoyage de l'espace de rédaction. Évalué à 5.
Je suis indestructible, invincible, et inébranlable !
Et puis franchement, je n'ai ni le temps ni l'envie d'apprendre une nouvelle distrib.
Je suis un authentique vieux con, campé sur mes idées reçues, et bien planté face au remous du reste du monde.
Na.
Et en plus on est plusieurs.
[^] # Re: Souvenirs
Posté par Yth (Mastodon) . En réponse au lien Slackware 15.0 !. Évalué à 3.
J'ai commencé avec celle-là aussi, mais depuis un CD-Rom dans un magazine !
Avec mon PC pourri bricolé de bric et de broc, aucune distribution plus user-friendly n'arrivait à faire fonctionner correctement le serveur graphique : déformé (mauvaise résolution), ou buggé (traits bizarres, clignotements), rien n'allait.
La Slackware, elle, n'avait pas ces soucis : elle ne cherchait même pas à lancer XF86, donc tout fonctionnait au poil !
J'ai regardé comment démarrer X dessus, il y avait les outils du genre xf86config, et l'édition de fichiers de conf à la main, les modeline manuels, etc. En quelques heures alors que je découvrais Linux, ça a fonctionné.
Et débarquer dans un monde avec gnome + enlightenment 0.16 alors que j'avais connu le DOS et win 95/98, c'était le jour et la nuit : beau, réactif, puissant, les bureaux multiples, indispensable !
Enfin pouvoir lire les vidéos qui saccadaient sous windows, avec Unreal Tournament dispo sous Linux, et Starcraft qui tournait au poil avec wine, j'ai pas gardé le double-boot bien longtemps…
[^] # Re: Si c'est comme ça j'arrête de respirer!
Posté par Yth (Mastodon) . En réponse au lien Meta menace de ne plus proposer Facebook et Instagram en Europe (même pas cap'). Évalué à 8.
Ouais, un peu comme si Coca-Cola menaçait d'arrêter d'exporter en Europe parce que leurs sodas ont un nutri-score de F-, mwarff…
[^] # Re: KISS it good day !
Posté par Yth (Mastodon) . En réponse au lien Slackware 15.0 !. Évalué à 4. Dernière modification le 04 février 2022 à 17:30.
Hmm, il va donc falloir que j'affronte l'Espace de Rédaction.
J'ai un Nourjal en cours d'écriture…
(snip)
Apparemment seule la feuille de style par défaut permet une rédaction potable, je vais donc m'y atteler !
Enfin, participer…
# KISS it good day !
Posté par Yth (Mastodon) . En réponse au lien Slackware 15.0 !. Évalué à 9.
L'alliance entre la tradition et le modernisme, ou comment ne pas subir les hypes de ces dernières années tout en restant moderne et en permettant à chacun d'utiliser son Linux comme il l'entend.
Slackware 15.0 reste dans la continuité de Slackware, pas de changement drastique, les habitudes sont conservées.
Slackbuilds.org aura sa version du dépôt 15.0 de près de 5000 paquets additionnels prêts pour la semaine prochaine à peu près (argh, faut que je bosse moi !).