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 !).
Sous Slackware, les paquets qui dépendent de polkit sont : GConf, accountsservice, gvfs, polkit-gnome, polkit-qt, udisks, udisks2, et xfce4-session.
Donc on peut très facilement s'en passer dans une installation serveur headless oui.
Et donc la majorité des machines Linux ne sont probablement pas affectées, seuls presque tous les postes de travail ou machines persos, ce qui ne fait pas la majorité, loin de là :)
Et là aussi, je ne parle pas forcément du particulier dans son garage.
Mais une collaboration universitaire avec lancement de startups, c'est plus crédible quand tu n'as pas à payer des licences de malade.
Maintenant, il faut un projet qui propose vraiment quelque chose avec de l'Open Hardware.
Et c'est sûr que par rapport à bricoler avec un SoC ARM existant, on risque d'avoir du mal à voir la différence pratique. Et tout ça pour plus cher…
Et donc quelle sera la bonne idée qui fera décoller un projet ?
Si tu as les compétences pour faire du design de puces électronique, tu as probablement ce matériel à ta disposition.
C'est un peu comme de dire que tu ne peux pas contribuer à du code sans avoir d'ordinateur : si tu es développeur, tu dois certainement avoir accès au matériel ad-hoc.
Et je n'ai pas parlé de rentabilité ni rien, j'ai juste parlé du ticket d'entrée pour concevoir un nouveau design, et le site OpenCores montre qu'il y a déjà des gens qui s'intéressent au sujet…
La commercialisation c'est toujours un autre problème, et il n'y a bien qu'avec le logiciel que ces coûts sont abordables de façon individuelle.
Encore une fois, dans mon message je crois avoir été assez clair sur le fait que ça ne va probablement rien changer, mais ça permet des choses que le hardware fermé ne permet pas (cf OpenCores finalement, super exemple !).
Je n'ai jamais prétendu que d'un seul coup un monde tout entier et merveilleux allait s'ouvrir : comme avec le logiciel libre, c'est du temps et des efforts l'open-hardware.
Et ça se fait bout par bout.
Mais si à la base tu n'as rien pour faire de l'open hardware, c'est quand même salement plus complexe d'imaginer comment arriver à quelque chose d'utile et d'utilisable.
Et qui peut dire si le buzz autour de RISC-V ne peut pas avoir l'intérêt de voir émerger à un moment un acteur qui va avoir une bonne idée et changer les choses ?
On voit arriver des cartes et des ordinateurs avec du RISC-V. J'en ai pas vu des masses (et toi non plus) avec de l'OpenSparc, comme quoi il y a déjà plus de mouvement…
C'est un peu comme si on te disait que si on avait tous les plans d'un A320, on pourrait créer nos propres avions.
On pourrait en modifier le design, faire des évolutions, et proposer des plans basés sur l'A320 mais différents.
Et oui, il y a besoin d'un sacré bagage technique derrière pour savoir ce qu'on fait.
Mais si tu as les plans, libres, tu peux proposer un A320-barmic.
Alors que va proposer un Xeon-barmic : sans bosser chez Intel, c'est mort.
Ou même un ARM-barmic : sans licence ARM, tu ne peux pas, tu peux avoir toutes les compétences du monde en design de puce électronique, ça sert à rien.
Ah t'es balaise toi quand même !
La phrase c'est : « travail collaboratif sans ticket d'entrée autre qu'un bagage technique minimal »
Ça veut dire que tu as quand même besoin d'un bagage technique minimal en deçà duquel tu ne vas rien pouvoir faire.
J'ai clairement écrit qu'il y avait une marche technique, mais ce que je veux exprimer c'est qu'il n'y a que ça.
Un peu comme de contribuer au noyau Linux : il n'y a qu'une marche technique.
Les mêmes que celle du logiciel libre.
- travail collaboratif sans ticket d'entrée autre qu'un bagage technique minimal ;
- pérennité puisque tous les design resteront toujours disponibles ;
- possibilité de forker une puce pour un usage spécifique ou pour expérimenter, sans avoir à bosser chez Intel ou AMD, ou sans avoir à acheter de licence ARM ;
- possibilité d'avoir des cartes-mères sans ME ou autre saloperies du genre…
Bref, cherche ce qui t'es interdit avec un processeur Intel aujourd'hui, et… ben ça ne l'est plus avec un matériel ouvert.
Alors comme d'hab hein, entre Photoshop et Gimp, ça va pas révolutionner ta vie, mais le second a un potentiel que n'a pas l'autre. Alors entre ARM, x86 et RISC-V, ça va pas forcément changer grand chose non plus.
Il y a beaucoup d'exemple de logiciels dont la liberté apporte quelque chose de très conséquent, au pif Blender, SQLite, Linux, VLC… Et plein d'autres ou pas vraiment.
Pour savoir ce qu'apportera précisément l'open hardware, il n'y a qu'une - et une seule - solution : en avoir et voir ce que ça va donner.
Je vois bien venir des priorités différentes de celles des processeurs mainstream modernes, comme une réduction de la dépendance aux métaux rares par une conception différente.
Mais ça fait pas mal d'année que ce n'est plus mon dealer de jeux…
Le support est assez pourri pour les bundle, souvent sans mises à jour.
Et c'est pire pour les bundle Android (oui, j'ai aussi cédé il y a quelques années de ça, un bundle de platal Asmodée, qui n'a vu passer aucune mise à jour !).
Comparer à un jeu avec avec version Linux, sans DRM, acheté sur GoG, ya pas photo…
Si tu lis les discussion dans le journal tu te feras une idée de la validité de cette étude, dont on peut débattre (là-bas), mais selon un certain nombre de critères somme toute assez objectifs, France Soir est la pire source d'information grand public française.
Derrière les sites de désinformation russes que sont Russia Today et Sputnik News…
Donc bon, France Soir quoi, c'est un site de désinformation, réputé comme tel parmi les gens qui vérifient les informations qu'ils lisent sur internet, avant de les recopier ailleurs sur internet…
On n'est pas tellement dans l'ad hominem ici, on est plutôt dans la notoriété publique, voire le fait avéré.
Mouais, enfin, si t'avais quelque chose d’intéressant à dire, tu faisais un journal, avec du texte et des mots, pour mettre en exergue tes liens, avec un bout d'argumentation ou à minima de présentation.
Juste des liens en vrac comme ça, c'est inutile, et c'est techniquement du spam.
Un lien sans explication ça peut aller - à la rigueur - si on est dans le thème du site : les logiciels libres, Linux, le libre en général. Si le titre est explicite, et contient une information utile - ici - en lui-même.
Ce que tu fais là c'est de la désinformation : des « informations » non organisées, en vrac, non vérifiées, non présentées, hors-sujet, et sous une forme assimilable à du spam.
Tu ne peux pas te faire des amis, et ce n'est pas de la censure : c'est de la qualité éditoriale.
[^] # 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 !).
[^] # Re: Liens supplémentaires
Posté par Yth (Mastodon) . En réponse au lien Local Privilege Escalation avec polkit - patchez vos machines. Évalué à 4.
Sous Slackware, les paquets qui dépendent de polkit sont : GConf, accountsservice, gvfs, polkit-gnome, polkit-qt, udisks, udisks2, et xfce4-session.
Donc on peut très facilement s'en passer dans une installation serveur headless oui.
Et donc la majorité des machines Linux ne sont probablement pas affectées, seuls presque tous les postes de travail ou machines persos, ce qui ne fait pas la majorité, loin de là :)
[^] # Re: Liens supplémentaires
Posté par Yth (Mastodon) . En réponse au lien Local Privilege Escalation avec polkit - patchez vos machines. Évalué à 2.
Pareil sous Slackware.
[^] # Re: Exciting times
Posté par Yth (Mastodon) . En réponse au lien The RISC-V experience. Évalué à 3.
Et là aussi, je ne parle pas forcément du particulier dans son garage.
Mais une collaboration universitaire avec lancement de startups, c'est plus crédible quand tu n'as pas à payer des licences de malade.
Maintenant, il faut un projet qui propose vraiment quelque chose avec de l'Open Hardware.
Et c'est sûr que par rapport à bricoler avec un SoC ARM existant, on risque d'avoir du mal à voir la différence pratique. Et tout ça pour plus cher…
Et donc quelle sera la bonne idée qui fera décoller un projet ?
[^] # Re: Exciting times
Posté par Yth (Mastodon) . En réponse au lien The RISC-V experience. Évalué à 4.
Si tu as les compétences pour faire du design de puces électronique, tu as probablement ce matériel à ta disposition.
C'est un peu comme de dire que tu ne peux pas contribuer à du code sans avoir d'ordinateur : si tu es développeur, tu dois certainement avoir accès au matériel ad-hoc.
Et je n'ai pas parlé de rentabilité ni rien, j'ai juste parlé du ticket d'entrée pour concevoir un nouveau design, et le site OpenCores montre qu'il y a déjà des gens qui s'intéressent au sujet…
La commercialisation c'est toujours un autre problème, et il n'y a bien qu'avec le logiciel que ces coûts sont abordables de façon individuelle.
Encore une fois, dans mon message je crois avoir été assez clair sur le fait que ça ne va probablement rien changer, mais ça permet des choses que le hardware fermé ne permet pas (cf OpenCores finalement, super exemple !).
Je n'ai jamais prétendu que d'un seul coup un monde tout entier et merveilleux allait s'ouvrir : comme avec le logiciel libre, c'est du temps et des efforts l'open-hardware.
Et ça se fait bout par bout.
Mais si à la base tu n'as rien pour faire de l'open hardware, c'est quand même salement plus complexe d'imaginer comment arriver à quelque chose d'utile et d'utilisable.
Et qui peut dire si le buzz autour de RISC-V ne peut pas avoir l'intérêt de voir émerger à un moment un acteur qui va avoir une bonne idée et changer les choses ?
On voit arriver des cartes et des ordinateurs avec du RISC-V. J'en ai pas vu des masses (et toi non plus) avec de l'OpenSparc, comme quoi il y a déjà plus de mouvement…
[^] # Re: Exciting times
Posté par Yth (Mastodon) . En réponse au lien The RISC-V experience. Évalué à 3.
On pourrait en modifier le design, faire des évolutions, et proposer des plans basés sur l'A320 mais différents.
Et oui, il y a besoin d'un sacré bagage technique derrière pour savoir ce qu'on fait.
Mais si tu as les plans, libres, tu peux proposer un A320-barmic.
Alors que va proposer un Xeon-barmic : sans bosser chez Intel, c'est mort.
Ou même un ARM-barmic : sans licence ARM, tu ne peux pas, tu peux avoir toutes les compétences du monde en design de puce électronique, ça sert à rien.
[^] # Re: Exciting times
Posté par Yth (Mastodon) . En réponse au lien The RISC-V experience. Évalué à 3.
Ah t'es balaise toi quand même !
La phrase c'est : « travail collaboratif sans ticket d'entrée autre qu'un bagage technique minimal »
Ça veut dire que tu as quand même besoin d'un bagage technique minimal en deçà duquel tu ne vas rien pouvoir faire.
J'ai clairement écrit qu'il y avait une marche technique, mais ce que je veux exprimer c'est qu'il n'y a que ça.
Un peu comme de contribuer au noyau Linux : il n'y a qu'une marche technique.
[^] # Re: Exciting times
Posté par Yth (Mastodon) . En réponse au lien The RISC-V experience. Évalué à 4.
Les mêmes que celle du logiciel libre.
- travail collaboratif sans ticket d'entrée autre qu'un bagage technique minimal ;
- pérennité puisque tous les design resteront toujours disponibles ;
- possibilité de forker une puce pour un usage spécifique ou pour expérimenter, sans avoir à bosser chez Intel ou AMD, ou sans avoir à acheter de licence ARM ;
- possibilité d'avoir des cartes-mères sans ME ou autre saloperies du genre…
Bref, cherche ce qui t'es interdit avec un processeur Intel aujourd'hui, et… ben ça ne l'est plus avec un matériel ouvert.
Alors comme d'hab hein, entre Photoshop et Gimp, ça va pas révolutionner ta vie, mais le second a un potentiel que n'a pas l'autre. Alors entre ARM, x86 et RISC-V, ça va pas forcément changer grand chose non plus.
Il y a beaucoup d'exemple de logiciels dont la liberté apporte quelque chose de très conséquent, au pif Blender, SQLite, Linux, VLC… Et plein d'autres ou pas vraiment.
Pour savoir ce qu'apportera précisément l'open hardware, il n'y a qu'une - et une seule - solution : en avoir et voir ce que ça va donner.
Je vois bien venir des priorités différentes de celles des processeurs mainstream modernes, comme une réduction de la dépendance aux métaux rares par une conception différente.
[^] # Re: Suppression des archives Linux... pour l'abonnement seulement ?
Posté par Yth (Mastodon) . En réponse au lien Suppression des archives LINUX de Humble Bundle au 31 janvier 2022. Évalué à 3.
Réponse :
- Trop.
- Environ le tiers quand même !
Mais ça fait pas mal d'année que ce n'est plus mon dealer de jeux…
Le support est assez pourri pour les bundle, souvent sans mises à jour.
Et c'est pire pour les bundle Android (oui, j'ai aussi cédé il y a quelques années de ça, un bundle de platal Asmodée, qui n'a vu passer aucune mise à jour !).
Comparer à un jeu avec avec version Linux, sans DRM, acheté sur GoG, ya pas photo…
[^] # Re: Poubelle !!!
Posté par Yth (Mastodon) . En réponse au lien Psychopathologie du totalitarisme 1/3. Évalué à 6.
Dans un journal très récent présenté ici même : https://linuxfr.org/users/booga/liens/le-top-10-des-mesinformateurs-francophones
Se trouve un lien vers une étude de la fiabilité des informations de différents sites d'information français : https://www.newsguardtech.com/fr/special-reports/rapport-les-listes-de-2021/
Si tu lis les discussion dans le journal tu te feras une idée de la validité de cette étude, dont on peut débattre (là-bas), mais selon un certain nombre de critères somme toute assez objectifs, France Soir est la pire source d'information grand public française.
Derrière les sites de désinformation russes que sont Russia Today et Sputnik News…
Donc bon, France Soir quoi, c'est un site de désinformation, réputé comme tel parmi les gens qui vérifient les informations qu'ils lisent sur internet, avant de les recopier ailleurs sur internet…
On n'est pas tellement dans l'ad hominem ici, on est plutôt dans la notoriété publique, voire le fait avéré.
[^] # Re: mesures à prendre
Posté par Yth (Mastodon) . En réponse au lien Vaccination Covid-19 : les effets indésirables graves augmentent de manière exponentielle. Évalué à 10.
Mouais, enfin, si t'avais quelque chose d’intéressant à dire, tu faisais un journal, avec du texte et des mots, pour mettre en exergue tes liens, avec un bout d'argumentation ou à minima de présentation.
Juste des liens en vrac comme ça, c'est inutile, et c'est techniquement du spam.
Un lien sans explication ça peut aller - à la rigueur - si on est dans le thème du site : les logiciels libres, Linux, le libre en général. Si le titre est explicite, et contient une information utile - ici - en lui-même.
Genre « Blender sort en version 3.0 - https://www.blender.org/download/releases/3-0/ »
Pas besoin de plus pour intéresser ici.
Ce que tu fais là c'est de la désinformation : des « informations » non organisées, en vrac, non vérifiées, non présentées, hors-sujet, et sous une forme assimilable à du spam.
Tu ne peux pas te faire des amis, et ce n'est pas de la censure : c'est de la qualité éditoriale.
[^] # Re: Du ressort d'un professionnel?
Posté par Yth (Mastodon) . En réponse au lien Psychopathologie du totalitarisme 1/3. Évalué à 4.
Foutaises !