Il est presque utilisable pour les bases de données APT/DPKG/APTITUDE en plus, il faut 'juste' virer tous les dash ('-') et ajouter un nom de champ pour les entrées multi-lignes, par exemple:
cp /var/lib/dpkg/status /tmp/test
sed /tmp/test -i -e 's!^ .*$!Description:&!g' -e 's!^\([^:-]*\)-\([^:]*\)!\1\2!g'
recsel -i -e 'Package = "apt"' -P Version test
me sors 1.4.9 sur cette machine. Bon, c'est un peu plus lent que dpkg-query -W apt (en moyenne sur 4 essais: 0.16s avec system a 99% pour recsel, contre 0.01s avec system à 76% pour dpkg, selon time) et moins fiable (la modif pour le multi-ligne casse des trucs en vrai), mais peut s'avérer utile pour du post-mortem ou autre usages.
Merci du partage du coup (ça me servira pas sur apt, mais ça m'a permis de voir l'usage sur une DB déjà bien fournie).
Mais même si je ne suis qu’un « ingénieur » (non diplômé), j’ai du mal à voir l’intérêt au delà de la satisfaction personnelle.
Perso, je me considère plus comme un gêneur qu'un ingénieur, dans le sens ou j'empêche au mieux de mes capacités les gens qui me payent de faire de la merde. Et j'y mets toute mon ingéniosité, croyez-moi.
C'est quoi, déjà, l'expression… «l'enfer est pavé de bonnes intentions», c'est ça? Oui, c'est vieillot, comme quoi, on n'invente pas tant de choses que ça :)
En Pré-Scriptum: j'ai pas suivi les liens, je vais le faire, ça semble super intéressant. Je ne fais que réagir à tes arguments ici, qui sont intéressants.
L'intérêt est double:
sécurité
pardon, on m'a appris a considérer le mot sécurité comme un buzzword, quand il est tout seul.
Ça protège de quoi, et dans quelles limitations?
science computationnelle reproductible
Arf… pardonnes donc le pauvre auto-didacte que je suis du manque de connaissances théorique…. mais je renifle ici quand même… euh, pour être poli, 3 mots mis ensembles pour impressionner la galerie. Désolé si c'est crû. En fait, non, pas tant désolé que ça, ce coin du web reste un coin ou je peux m'exprimer et apprendre sans faussetés.
C'est le cas d'usage le plus courant. Mais il faut garder en tête :
Que vous n'avez aucune garantie que le compilateur n'a pas introduit de code frauduleux. C'est ce que l'on appelle la Trusting Trust attaque et le problème du bootstrapp.
Je le sais, je suis un nerd comme les autres. Enfin, p'tet moins doué, certes.
Mais, oui, on sait, tu peux être espionné dès lors que tu confies ton hard a un autre. On sait, même le CPU peut leak… ça fait que 2 ans qu'on a des preuves, certes.
Mais, y'a un moment, soit on fait abstinence, soit on reste un minimum optimiste, non? A noter que, j'ai lu 1984.
Cela permet de ré-écrire partiellement la recette d'une paquet.
Tu parles de science. Je te parle d'ingénierie. C'est p'tet la qu'on se comprend pas, je suis pas assez intelligent pour la science, mais je reste captivé par l'idée de supprimer toute contrainte inutile a l'humain. Il parait aussi que je suis pas idiot, mais, je connais pas de scientifique.
Bref, à quoi ça sert?
Je crois que RPM est capable de faire du transactionnel.
Atta… tu compares RPM, un format de fichier, avec APT, un exécutable et… nix, une distro?
Justement, parlons simples, parlons binaires, ça ressemble a quoi le format de nix?
Le fait d'être "fonctionnel" rend les transactions faciles à implémenter. Ou disons plus facile que dans les approches "classiques" de gestion de paquets.
Ah… le paradigme «silver bullet»… Java a essayé. Java a bien marché, mais n'a pas conquis le monde. Je vous souhaite le même succès.
Désolé, tu n'as pas fournis un seul fait réel, donc je me permets de faire de même, et, en bon dev c++, de troller le java :) (y'a des traditions que j'aime, c'est un peu le folklore de l'info).
Oui, c'est légitime comme question. Et à ma connaissance il n'y a pas encore vraiment de réponse par manque d'observation.
Bien. Ici, pas moyen de troller, on cause tech.
Par contre, j'ai un doute sur le "manque d'observation". Tu entends quoi? Si Nix est si robuste, faites donc du fuzzing. Il faut un stress root constant pour estimer le niveau de fragilité. Et même si vous avez des failles, hé, vous, au moins, vous permettez un certain parallélisme, et ça c'est un argument de vente pour moi. Parce que c'est fort, la vitesse.
Ou alors vous jouez la sécurité, le tout séquentiel, et alors votre paradigme, bah, il sers pas a grand chose.
Guix fait l'hypothèse (forte) qu'il y a suffisamment de stabilité dans le noyau, le système de fichiers, etc. pour ne pas influencer sur la transparence binaire. Mais oui il y a une question pertinente sur l'effet du hardware.
Tu vois, c'est justement par l'intermédiaire de Nix que j'ai appris cette faiblesse. Et de mon job. Je suis tellement curieux… j'ai cherché, j'ai voulu reproduire cette fiabilité supposée, et… j'ai trouvé que c'était de la poudre aux yeux.
Parce que le soft (le kernel est un soft) sous linux ne permets pas cette hypothèse. Et Nix/Guix l'affirment a chaque fois comme forte.
J'aime pas ça, c''est pas honnête.
Cependant, qui peut le plus peut le moins. ;-)
Pitié, non… Un dev sys ne seras jamais un bon dev web, un architecte ne sera jamais un bon maçon, et vice versa. Cette expression je la prend comme une forme de mépris. C'est désagréable, même si je sais que je l'ai moi aussi commise, cette erreur.
On peut avoir les notions des métiers adjacents, mais jamais on ne les fait aussi bien que des pros.
et cfengine? Je pose la question en toute innocence, mais je crois que c'est l'ancêtre, son but étant d'arriver a un état stable en tout temps? pas réussi à l'utiliser, mais pas eu le temps d'étudier non plus…
Pour partager du code le mieux ça reste de faire de la composition
C'est difficile de tout expliquer dans des commentaires ici et là. ;-)
A l'essentiel: Guix compose. :-)
On m'a dis la même de la PO (Programmation Object). Mais je suis resté à la POO (Programmation Orientée Objet). Parce que forcer une façon de penser, c'est brider.
Même les devs de systemd ont supporté le fait d'avoir des shells scripts, pour dire! (et pourtant, j'aime pas systemd).
Cette histoire d'inherit est un artefact dans la grande histoire de Guix. :-)
J'espère que tu espères pas convaincre des devs expérimentés en leur présentant un système nouveau qui a déjà des artefacts mis en avant? Parce que, bon, les artefacts, on (enfin, je) les accepte que quand ils sont obligatoire, hein.
Au point que, pour mes collègues j'ai écrit un script pour générer des .deb à partir d'un fichier ini-style. Certes, des debs castrés, mais ça marche et c'est simple.
C'est une astuce pour réécrire partiellement une recette de construction. Je ne vois pas en quoi cela casse la composition. En revanche oui, cela peut rendre plus fragile certains paquets.
Désolé, tu viens de contre-vendre le projet.
Moi, ce que je veux, c'est une distro qui concurrence la solidité et la simplicité réelle de debian. Et par simplicité réelle, j'entends… comment dire… ouvres donc un ficher .deb, tu verras.
Ce format "binaire", est tellement simple, que c'est tout sauf stupide, et certainement pas du conservatisme (oui, je crache sur KISS ici).
Je plussoie l'ensemble, mais j'ai tout de même une précision à apporter: il est tout à fait possible (et facile) de transformer un serveur MPD en diffuseur de son.
Concrètement, tu choisis ta source de sortie: elle peut être alsa (le module son du noyau), jackd (un daemon de gestion du son qui semble très aimé par les audiophiles), http, et bien d'autres.
Cela implique qu'il est possible d'utiliser n'importe quel lecteur ailleurs dans la maison (dont mpd, mais pas que) sur des machines dont le seul rôle serait d'émettre vers une sortie audio (casque, enceinte filaire ou bluetooth, etc), et du coup il est possible de centraliser le stockage des playlists (radio internet) et la sonothèque sur une seule machine sans forcément configurer un partage de fichiers.
Pour info, sur la conf de debian il semble que les sorties suivantes existent (via grep audio_output /etc/mpd.conf -A3 | grep '\<type' | sed 's![^"]*\(.*\)!* \1!g'):
J'avais cru comprendre que c'était Advanced Packaging Tools donc une suite d'outils pour manipuler les paquets Debian.
Dans la pratique, je dirais que ça manipule surtout le repo. En gros, ça regarde dans une BDD texte les dépendances d'un paquet, ça les Dl, et ensuite ça invoque un gros "dpkg -i $pkgs". Ça peut aussi potentiellement faire de la collecte de déchets, aussi.
Mais le vrai boulot, in fine, c'est à dire dépaqueter le cadeau, exécuter les scripts pré/post rm/inst dans le bon ordre, déplacer les fichiers, mettre à jour (ou pas) les fichiers de conf… tout ça, c'est dpkg. Donc pour moi, c'est bien dpkg le gestionnaire, apt, apt-*, aptitude, synaptics (j'ai toujours un doute sur son nom à lui)… eux, c'est juste des frontaux.
Concernant les services, c'est presque la même histoire que pour les paquets. ;-)
Je me doute, mais sur ce point, ce que je voulais dire, c'est que j'ai opté pour une politique différente que celle que debian opte. Autrement dit: installer un paquet contenant un daemon ne l'active pas automatiquement. D'un autre côté, je me base sur runit, donc c'est trivial, alors que Debian s'est longtemps basée sur rc.d, j'imagine que ça joue.
Je reconnaît que ce point était hors sujet pour le coup :)
Doit-on considérer que le même code source compilé par 2 compilateurs est la même version ou non ? Qu'est-ce qu'une même version ? Code source identique ? Binaire identique ? Résultat identique ?
Je ne vois pas vraiment l'intérêt pour un utilisateur d'avoir, au niveau système, plusieurs build d'un programme avec plusieurs compilos… pour un développeur, ok, mais un programmeur fera de toute façon ses tests dans un dossier local.
Le seul moment ou je vois un problème potentiellement posé par la compilation d'un même source avec les mêmes options de build par un compilateur différent, c'est pour une bibliothèque dont l'ABI peut changer. Et ce problème est habituellement contourné par les bibliothèques elles-mêmes quand elles sont bien foutues (par exemple en utilisant pimpl).
Les 3 paquets sont fonctionnels en soi. Il n'y a pas de "coquilles vides". C'est juste que la définition du paquet gnupg-2 hérite de la définition du paquet gnupg.
J'ai peut-être mal compris ce qu'était un méta-paquet.
Je pense plutôt que c'est moi qui ne comprend pas à quoi sert ton héritage ni (hum… c'est chiant en vrai de faire un ou inclusif en langage parlé…) comment ça marche.
Pour le coup, ça me ferait plutôt penser aux «recommends» du format deb: tu peux installer un paquet parce qu'il améliorera le paquet courant, mais c'est pas obligatoire.
Sauf que du coup, c'est pas de l'héritage tel qu'entendu en POO, vu que dans ce cas ça serait une dépendance forte, donc un «depends».
Par contre, effectivement un meta-paquet c'est un paquet vide, qui se compose juste d'une série de dépendances d'un type ou d'un autre (debian utilise surtout des dépendances fortes, mais rien n'empêcherais un méta-paquet qui bannit).
Toujours est-il que Guix utilise plein de choses existantes ailleurs. Une partie de l'originalité est de les rassembler de manière cohérente.
Je trouve honnêtement le concept intéressant, mais pour moi sa plus grosse et principale force, c'est le fait qu'il semblerait invalider complètement une suite d'actions si une installation échoue, et ça, dpkg ne sait pas le faire, ses frontaux non plus.
Par contre, je me demande si la raison est vraiment le fait que nix/guix soient fonctionnels, justement.
En soit, le format des paquets deb devrais largement permettre sans trop de hacks un gestionnaire de paquet bien plus puissant (parallélisé, avec rollbacks, install en mode user), mais l'histoire est là.
Merci de vos réponses, c'est un peu ce que je craignais pour «Fn». J'aurai préféré modifier son comportement puisque c'est honnêtement cette touche la qui fout le plus le bordel au final… bon, ben vais me rabattre sur «menu», je m'en servais à une époque, mais depuis que j'ai adopté le tiling et le terminal en masse, j'ai quasi oublié son existence.
En terme de gestion de paquets, le paradigme de Guix vient avec :
coexistence de différents outils incompatibles entre eux : profile et environment
générations / transactions : roll-back
configuration déclarative : fichier manifest
voyage dans le temps : time-machine
Autant les 3 premiers points peuvent être obtenus avec des gestionnaires de paquets "classiques" modulo un peu de d'habitude quand même, autant le voyage dans le temps est impossible—à ma connaissance.
Marrant, moi j'aurais dis que c'est le roll-back qui est chiant avec Debian. Le repro-build, c'est en cours pour Debian, et de ce que j'en sais (pas grand chose, outre mes compétences de développeur non-debian) je dirais que la cause est plutôt les recettes de compilations, notamment celles à base de CMake.
Du coup, je suis curieux, tu fais comment pour rollback une install d'un .deb qui foire?
Est-ce vraiment pertinent de prendre en compte le réseau? Pour moi, l'impact du gestionnaire de paquets, c'est sur l'overhead du calcul des dépendances et de l'install proprement dite qu'il faut le faire, pas sur le DL.
Toute la question est la définition de même version. Comme je demandais, est-ce que, considérant toutes les autres options exactement les mêmes,libfoo-1.2.3 compilée avec GCC 7 est-elle la même version que celle compilée avec GCC 8 ?
J'avais regardé un peu comment marchent ces 2 systèmes de paquet (guix/nix). En gros, les versions des paquets sont en fait un hash, pas la version réelle.
Un journal précédent posait d'ailleurs il me semble la question du nettoyage automatique, qui était inefficace, contrairement aux mécanismes plus classiques. Certes, ça n'impacte que les machines avec un espace disque restreint, mais bon, sur ma machine a moi, j'ai moins de 300Gio de disque (c'est un ssd pas tout neuf, certes), et ça me ferait chier que chaque distro dessus ait besoin de plus de 30Gio d'espace disque pour /.
La deuxième chose est que Guix (originellement Nix) est un changement de paradigme. Un gestionnaire de paquets comme APT peut être vu comme "impératif" tandis que Guix comme "fonctionnel". Tout ca avec des très gros guillemets ! :-)
À ce stade la, on est loin des guillemets…
DPKG (nope, APT n'est pas un gestionnaire de paquets, il se contente de télécharger un paquet et ses dépendances) est majoritairement "déclaratif" c'est à dire basé sur un simple fichier de configuration.
Pour rappel, un .deb, c'est une archive cpio qui contiens 3 fichiers: 1 fichier texte qui décris la version, 1 tarball avec les méta-données qui sont toutes, à ma connaissance, sous forme de texte déclaratif (ini-style) à l'exception des scripts pré/post rm/inst, et une tarball contenant les données.
Je sais que la compression est supportée, mais je ne sais exactement comment.
Quelques paquets utilisent en effet des scripts pré/post rm/inst, mais à mes yeux et rapport a ce que j'ai subi, c'est soit une erreur politique (gérer automatiquement les services plutôt que les faire gérer par l'install/suppression de paquets qui seraient en conflits) soit un workaround pour ces foutus sgbdr qui sont incapables de fournir des données binaires (faut reconstruire a partir d'un dump sql… long, lourd et pénible).
À noter qu'au taf, j'ai opté pour la création de paquets qui activent les services qu'on écrit, et qui sont parfois en conflit. Ben, c'est vachement plus simple qu'écrire les scripts pré/post inst/rm, et s'il nous venais l'envie d'utiliser systemd plutôt que runit, il n'y aurait pas besoin de refaire (et donc réinstaller) les paquets contenant les binaires: les paquets de services sont, en effet, à part.
Concrètement, que signifie 3 fois la même version ? Est-ce que la version libfoo-1.2.3 compilé par GCC 7 ou GCC 8 ou autre signifie la même version pour vous ?
Tout dépend de si GCC 7 et GCC 8 ont la même ABI. Si c'est pas le cas, c'est en effet le job de distro de gérer.
Mais bon, hé, vraiment, mauvais exemple ici (a moins que tu aies un bug causé par une incompat entre ces compilos?), tu aurais dû parler de GCC vs Clang, ou de la glibc vs musl. La réponse aurait été que, majoritairement, la différence de libc se sens, la différence de compilo C, non. Ah, je précise bien, de compilo C, pour les autres langages, c'est plus compliqué, d'où le modèle «hour-glass» pour construire des libs portables en C++, notamment.
Pour info, sache que, il y a 8 ans (quand j'étais sous win), on étais capables d'avoir des ABI compatibles sous windows entre GCC et VisualC++. Et ça fait longtemps que j'ai pas eu de problèmes parce que j'utilise un compilo différent de celui du système (pas sûr d'en avoir déjà eu)? Dans une certaine mesure, même utiliser une libc différente m'est pas mal transparent.
Par ailleurs, Guix a aussi la notion d'héritage (inherit) pour un paquet.
L'équivalent d'un méta-paquet qui dépend au choix d'un ou plusieurs paquets, ou l'équivalent d'un paquet qui fournit un paquet virtuel? Non, parce que bon, Debian implémente ça depuis que je m'en sers, soit au moins 10 ans.
Ça à l'air pas mal, mais il y a un point que j'aurai aimé qu'il précise: la température. Certains PC portables ont la bonne idée de tirer ou expulser l'air du dessous de la machine, ce qui les rends délicats a utiliser en «mode portable». D'autres encore en arrivent à avoir des surfaces clavier/touchpad brûlantes.
Du coup j'avoue être un peu déçu que ce point n'apparaisse nulle part.
Bon, c'est exactement la remarque que je craignais : Gopher est un protocole pas une application !
Je pensais avoir fait comprendre que le je comprenais… mais dans la pratique, il y a quoi qui permettre une navigation confortable, en mode graphique?
Mes explications ont-elles été suffisantes ou bien dois-je développer certains points ?
Citer un navigateur gopher moderne serait un excellent point :)
Tu pourrais aussi y ajouter un serveur, parce que si quelqu'un est convaincu par le navigateur, il serait dommage qu'il ne trouve que des serveurs obsolètes.
Honnêtement, je considère que le web actuel est flingué. Je ne sais utiliser que le web et des mailings lists que je trouve sur des sites webs, mais j'aimerais une alternative, un truc qui ne soit pas rebutant (le ncurses, je m'en sers en permanence, mais par choix, pour des applications dont je connais une alternative graphique).
Si vraiment tu veux pousser, commence une dépêche, colles-y des liens, j'essaierais d'aider.
Opera 12 clamait le permettre site par site. Je l'utilisais, et le faisais.
De nos jours, le seul autre navigateur le permettant, sans modules complémentaires, c'est otter. Qui ne s'intègre pas dans debian.
Donc, actuellement non, parce que ne peux plus le faire avec un navigateur qui fonctionne sous Debian stable sans faire confiance a un plugin.
D'autant que je suis devenu de moins en moins confiant sur le fait que de larges organisations de développeurs aient la moindre considérations envers un web respectueux de la vié privée, léger, rapide même avec moins de 200Kio/s pour le brouteur, etc etc.
Je garde malgré tout un oeil et une pensée sur otter-browser (je peux en lire le code, mon cerveau segfault pas), ou les navigateurs proprio qui au moins filent des options utilisables (hint: pas chrome ni safari ni edge à ma connaissance).
# presque utilisable pour apt...
Posté par freem . En réponse au lien GNU Recutils pour manipuler du texte comme une base de donnée. Évalué à 3.
Sympa, cet outil.
Il est presque utilisable pour les bases de données APT/DPKG/APTITUDE en plus, il faut 'juste' virer tous les dash ('-') et ajouter un nom de champ pour les entrées multi-lignes, par exemple:
me sors 1.4.9 sur cette machine. Bon, c'est un peu plus lent que
dpkg-query -W apt(en moyenne sur 4 essais: 0.16s avec system a 99% pour recsel, contre 0.01s avec system à 76% pour dpkg, selontime) et moins fiable (la modif pour le multi-ligne casse des trucs en vrai), mais peut s'avérer utile pour du post-mortem ou autre usages.Merci du partage du coup (ça me servira pas sur apt, mais ça m'a permis de voir l'usage sur une DB déjà bien fournie).
[^] # Re: Esprit potache es-tu là ?
Posté par freem . En réponse au lien signer la pétition pour libérer Windows 7. Évalué à 6.
Et cette même page fait remonter le terme à bien plus ancien:
Ce qui nous fait du 26 ans. Si ça a été fait pour un OS MS, ça doit être windows 3.1 :)
[^] # Re: grande valeur de 14 ou petite valeur de 16 ?
Posté par freem . En réponse au lien La recherche française inaugure Jean Zay, un supercalculateur de 14 pétaflops installé à l'Idris. Évalué à 4.
Tu veux dire que ce liens va faire un flop?
# me semblait pourtant qu'il existait déjà des outils pour passer de cvs à git?
Posté par freem . En réponse au journal Le compilateur GCC passe à Git. Évalué à 2.
tout est dans le titre
[^] # Re: Ça vous intéresse ?
Posté par freem . En réponse au journal Partage d’expérience : comment je suis devenu ingénieur diplômé par l’État à 44 ans. Évalué à 10.
Perso, je me considère plus comme un gêneur qu'un ingénieur, dans le sens ou j'empêche au mieux de mes capacités les gens qui me payent de faire de la merde. Et j'y mets toute mon ingéniosité, croyez-moi.
[^] # Re: Pistage des abonnés
Posté par freem . En réponse au journal Les entreprises et les utilisateurs. Évalué à 4.
C'est quoi, déjà, l'expression… «l'enfer est pavé de bonnes intentions», c'est ça? Oui, c'est vieillot, comme quoi, on n'invente pas tant de choses que ça :)
[^] # Re: ça dépend de la touche
Posté par freem . En réponse au message modifier le comportement de la touche «fn» ou «context». Évalué à 2.
ce clavier est usb…
[^] # Re: Mal connaître sa distribution
Posté par freem . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 4.
En Pré-Scriptum: j'ai pas suivi les liens, je vais le faire, ça semble super intéressant. Je ne fais que réagir à tes arguments ici, qui sont intéressants.
pardon, on m'a appris a considérer le mot sécurité comme un buzzword, quand il est tout seul.
Ça protège de quoi, et dans quelles limitations?
Arf… pardonnes donc le pauvre auto-didacte que je suis du manque de connaissances théorique…. mais je renifle ici quand même… euh, pour être poli, 3 mots mis ensembles pour impressionner la galerie. Désolé si c'est crû. En fait, non, pas tant désolé que ça, ce coin du web reste un coin ou je peux m'exprimer et apprendre sans faussetés.
Je le sais, je suis un nerd comme les autres. Enfin, p'tet moins doué, certes.
Mais, oui, on sait, tu peux être espionné dès lors que tu confies ton hard a un autre. On sait, même le CPU peut leak… ça fait que 2 ans qu'on a des preuves, certes.
Mais, y'a un moment, soit on fait abstinence, soit on reste un minimum optimiste, non? A noter que, j'ai lu 1984.
Tu parles de science. Je te parle d'ingénierie. C'est p'tet la qu'on se comprend pas, je suis pas assez intelligent pour la science, mais je reste captivé par l'idée de supprimer toute contrainte inutile a l'humain. Il parait aussi que je suis pas idiot, mais, je connais pas de scientifique.
Bref, à quoi ça sert?
Atta… tu compares RPM, un format de fichier, avec APT, un exécutable et… nix, une distro?
Justement, parlons simples, parlons binaires, ça ressemble a quoi le format de nix?
Ah… le paradigme «silver bullet»… Java a essayé. Java a bien marché, mais n'a pas conquis le monde. Je vous souhaite le même succès.
Désolé, tu n'as pas fournis un seul fait réel, donc je me permets de faire de même, et, en bon dev c++, de troller le java :) (y'a des traditions que j'aime, c'est un peu le folklore de l'info).
Bien. Ici, pas moyen de troller, on cause tech.
Par contre, j'ai un doute sur le "manque d'observation". Tu entends quoi? Si Nix est si robuste, faites donc du fuzzing. Il faut un stress root constant pour estimer le niveau de fragilité. Et même si vous avez des failles, hé, vous, au moins, vous permettez un certain parallélisme, et ça c'est un argument de vente pour moi. Parce que c'est fort, la vitesse.
Ou alors vous jouez la sécurité, le tout séquentiel, et alors votre paradigme, bah, il sers pas a grand chose.
Tu vois, c'est justement par l'intermédiaire de Nix que j'ai appris cette faiblesse. Et de mon job. Je suis tellement curieux… j'ai cherché, j'ai voulu reproduire cette fiabilité supposée, et… j'ai trouvé que c'était de la poudre aux yeux.
Parce que le soft (le kernel est un soft) sous linux ne permets pas cette hypothèse. Et Nix/Guix l'affirment a chaque fois comme forte.
J'aime pas ça, c''est pas honnête.
Pitié, non… Un dev sys ne seras jamais un bon dev web, un architecte ne sera jamais un bon maçon, et vice versa. Cette expression je la prend comme une forme de mépris. C'est désagréable, même si je sais que je l'ai moi aussi commise, cette erreur.
On peut avoir les notions des métiers adjacents, mais jamais on ne les fait aussi bien que des pros.
Merci pour ça
[^] # Re: Mal connaître sa distribution
Posté par freem . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 2.
Il suffit de dire qu'on doit accepter et prendre conscience de ça, le fait que l'on doit faire confiance a un organe initial?
[^] # Re: Mal connaître sa distribution
Posté par freem . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 2.
et cfengine? Je pose la question en toute innocence, mais je crois que c'est l'ancêtre, son but étant d'arriver a un état stable en tout temps? pas réussi à l'utiliser, mais pas eu le temps d'étudier non plus…
[^] # Re: Mal connaître sa distribution
Posté par freem . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à -1.
J'me permets, parce que c'est facile…
On m'a dis la même de la PO (Programmation Object). Mais je suis resté à la POO (Programmation Orientée Objet). Parce que forcer une façon de penser, c'est brider.
Même les devs de systemd ont supporté le fait d'avoir des shells scripts, pour dire! (et pourtant, j'aime pas systemd).
J'espère que tu espères pas convaincre des devs expérimentés en leur présentant un système nouveau qui a déjà des artefacts mis en avant? Parce que, bon, les artefacts, on (enfin, je) les accepte que quand ils sont obligatoire, hein.
Au point que, pour mes collègues j'ai écrit un script pour générer des .deb à partir d'un fichier ini-style. Certes, des debs castrés, mais ça marche et c'est simple.
Désolé, tu viens de contre-vendre le projet.
Moi, ce que je veux, c'est une distro qui concurrence la solidité et la simplicité réelle de debian. Et par simplicité réelle, j'entends… comment dire… ouvres donc un ficher .deb, tu verras.
Ce format "binaire", est tellement simple, que c'est tout sauf stupide, et certainement pas du conservatisme (oui, je crache sur KISS ici).
[^] # Re: PS: je ne suis pas audiophile
Posté par freem . En réponse au message Solution pour un serveur son à la maison. Évalué à 4.
Je plussoie l'ensemble, mais j'ai tout de même une précision à apporter: il est tout à fait possible (et facile) de transformer un serveur MPD en diffuseur de son.
Concrètement, tu choisis ta source de sortie: elle peut être alsa (le module son du noyau), jackd (un daemon de gestion du son qui semble très aimé par les audiophiles), http, et bien d'autres.
Cela implique qu'il est possible d'utiliser n'importe quel lecteur ailleurs dans la maison (dont mpd, mais pas que) sur des machines dont le seul rôle serait d'émettre vers une sortie audio (casque, enceinte filaire ou bluetooth, etc), et du coup il est possible de centraliser le stockage des playlists (radio internet) et la sonothèque sur une seule machine sans forcément configurer un partage de fichiers.
Pour info, sur la conf de debian il semble que les sorties suivantes existent (via
grep audio_output /etc/mpd.conf -A3 | grep '\<type' | sed 's![^"]*\(.*\)!* \1!g'):[^] # Re: Mal connaître sa distribution
Posté par freem . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 3.
Dans la pratique, je dirais que ça manipule surtout le repo. En gros, ça regarde dans une BDD texte les dépendances d'un paquet, ça les Dl, et ensuite ça invoque un gros "dpkg -i $pkgs". Ça peut aussi potentiellement faire de la collecte de déchets, aussi.
Mais le vrai boulot, in fine, c'est à dire dépaqueter le cadeau, exécuter les scripts pré/post rm/inst dans le bon ordre, déplacer les fichiers, mettre à jour (ou pas) les fichiers de conf… tout ça, c'est dpkg. Donc pour moi, c'est bien dpkg le gestionnaire, apt, apt-*, aptitude, synaptics (j'ai toujours un doute sur son nom à lui)… eux, c'est juste des frontaux.
Je me doute, mais sur ce point, ce que je voulais dire, c'est que j'ai opté pour une politique différente que celle que debian opte. Autrement dit: installer un paquet contenant un daemon ne l'active pas automatiquement. D'un autre côté, je me base sur runit, donc c'est trivial, alors que Debian s'est longtemps basée sur rc.d, j'imagine que ça joue.
Je reconnaît que ce point était hors sujet pour le coup :)
Je ne vois pas vraiment l'intérêt pour un utilisateur d'avoir, au niveau système, plusieurs build d'un programme avec plusieurs compilos… pour un développeur, ok, mais un programmeur fera de toute façon ses tests dans un dossier local.
Le seul moment ou je vois un problème potentiellement posé par la compilation d'un même source avec les mêmes options de build par un compilateur différent, c'est pour une bibliothèque dont l'ABI peut changer. Et ce problème est habituellement contourné par les bibliothèques elles-mêmes quand elles sont bien foutues (par exemple en utilisant pimpl).
Je pense plutôt que c'est moi qui ne comprend pas à quoi sert ton héritage ni (hum… c'est chiant en vrai de faire un ou inclusif en langage parlé…) comment ça marche.
Pour le coup, ça me ferait plutôt penser aux «recommends» du format deb: tu peux installer un paquet parce qu'il améliorera le paquet courant, mais c'est pas obligatoire.
Sauf que du coup, c'est pas de l'héritage tel qu'entendu en POO, vu que dans ce cas ça serait une dépendance forte, donc un «depends».
Par contre, effectivement un meta-paquet c'est un paquet vide, qui se compose juste d'une série de dépendances d'un type ou d'un autre (debian utilise surtout des dépendances fortes, mais rien n'empêcherais un méta-paquet qui bannit).
Je trouve honnêtement le concept intéressant, mais pour moi sa plus grosse et principale force, c'est le fait qu'il semblerait invalider complètement une suite d'actions si une installation échoue, et ça, dpkg ne sait pas le faire, ses frontaux non plus.
Par contre, je me demande si la raison est vraiment le fait que nix/guix soient fonctionnels, justement.
En soit, le format des paquets deb devrais largement permettre sans trop de hacks un gestionnaire de paquet bien plus puissant (parallélisé, avec rollbacks, install en mode user), mais l'histoire est là.
Enfin, l'histoire ainsi que le fait que le noyau linux (ou sont-ce extX les coupables?) ne permette pas, à ma connaissance, de réellement verrouiller un fichier: flock() places advisory locks only; given suitable permissions on a file, a process is free to ignore the use of flock() and perform I/O on the file. me font me demander d'à quel point nix/guix peuvent réellement garantir quoique ce soit.
[^] # Re: ça dépend de la touche
Posté par freem . En réponse au message modifier le comportement de la touche «fn» ou «context». Évalué à 2.
Merci de vos réponses, c'est un peu ce que je craignais pour «Fn». J'aurai préféré modifier son comportement puisque c'est honnêtement cette touche la qui fout le plus le bordel au final… bon, ben vais me rabattre sur «menu», je m'en servais à une époque, mais depuis que j'ai adopté le tiling et le terminal en masse, j'ai quasi oublié son existence.
[^] # Re: Quelques "killer features"
Posté par freem . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 2.
Marrant, moi j'aurais dis que c'est le roll-back qui est chiant avec Debian. Le repro-build, c'est en cours pour Debian, et de ce que j'en sais (pas grand chose, outre mes compétences de développeur non-debian) je dirais que la cause est plutôt les recettes de compilations, notamment celles à base de CMake.
Du coup, je suis curieux, tu fais comment pour rollback une install d'un .deb qui foire?
[^] # Re: Mal connaître sa distribution
Posté par freem . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 4. Dernière modification le 20 janvier 2020 à 22:53.
Est-ce vraiment pertinent de prendre en compte le réseau? Pour moi, l'impact du gestionnaire de paquets, c'est sur l'overhead du calcul des dépendances et de l'install proprement dite qu'il faut le faire, pas sur le DL.
[^] # Re: Mal connaître sa distribution
Posté par freem . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 2.
J'avais regardé un peu comment marchent ces 2 systèmes de paquet (guix/nix). En gros, les versions des paquets sont en fait un hash, pas la version réelle.
Un journal précédent posait d'ailleurs il me semble la question du nettoyage automatique, qui était inefficace, contrairement aux mécanismes plus classiques. Certes, ça n'impacte que les machines avec un espace disque restreint, mais bon, sur ma machine a moi, j'ai moins de 300Gio de disque (c'est un ssd pas tout neuf, certes), et ça me ferait chier que chaque distro dessus ait besoin de plus de 30Gio d'espace disque pour /.
[^] # Re: Mal connaître sa distribution
Posté par freem . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 2.
À ce stade la, on est loin des guillemets…
DPKG (nope, APT n'est pas un gestionnaire de paquets, il se contente de télécharger un paquet et ses dépendances) est majoritairement "déclaratif" c'est à dire basé sur un simple fichier de configuration.
Pour rappel, un .deb, c'est une archive cpio qui contiens 3 fichiers: 1 fichier texte qui décris la version, 1 tarball avec les méta-données qui sont toutes, à ma connaissance, sous forme de texte déclaratif (ini-style) à l'exception des scripts pré/post rm/inst, et une tarball contenant les données.
Je sais que la compression est supportée, mais je ne sais exactement comment.
Quelques paquets utilisent en effet des scripts pré/post rm/inst, mais à mes yeux et rapport a ce que j'ai subi, c'est soit une erreur politique (gérer automatiquement les services plutôt que les faire gérer par l'install/suppression de paquets qui seraient en conflits) soit un workaround pour ces foutus sgbdr qui sont incapables de fournir des données binaires (faut reconstruire a partir d'un dump sql… long, lourd et pénible).
À noter qu'au taf, j'ai opté pour la création de paquets qui activent les services qu'on écrit, et qui sont parfois en conflit. Ben, c'est vachement plus simple qu'écrire les scripts pré/post inst/rm, et s'il nous venais l'envie d'utiliser systemd plutôt que runit, il n'y aurait pas besoin de refaire (et donc réinstaller) les paquets contenant les binaires: les paquets de services sont, en effet, à part.
Tout dépend de si GCC 7 et GCC 8 ont la même ABI. Si c'est pas le cas, c'est en effet le job de distro de gérer.
Mais bon, hé, vraiment, mauvais exemple ici (a moins que tu aies un bug causé par une incompat entre ces compilos?), tu aurais dû parler de GCC vs Clang, ou de la glibc vs musl. La réponse aurait été que, majoritairement, la différence de libc se sens, la différence de compilo C, non. Ah, je précise bien, de compilo C, pour les autres langages, c'est plus compliqué, d'où le modèle «hour-glass» pour construire des libs portables en C++, notamment.
Pour info, sache que, il y a 8 ans (quand j'étais sous win), on étais capables d'avoir des ABI compatibles sous windows entre GCC et VisualC++. Et ça fait longtemps que j'ai pas eu de problèmes parce que j'utilise un compilo différent de celui du système (pas sûr d'en avoir déjà eu)? Dans une certaine mesure, même utiliser une libc différente m'est pas mal transparent.
L'équivalent d'un méta-paquet qui dépend au choix d'un ou plusieurs paquets, ou l'équivalent d'un paquet qui fournit un paquet virtuel? Non, parce que bon, Debian implémente ça depuis que je m'en sers, soit au moins 10 ans.
[^] # Re: Cool
Posté par freem . En réponse au lien Premières journées avec le Pinebook pro (un portable ARM libre à 200 $). Évalué à 2.
Ça à l'air pas mal, mais il y a un point que j'aurai aimé qu'il précise: la température. Certains PC portables ont la bonne idée de tirer ou expulser l'air du dessous de la machine, ce qui les rends délicats a utiliser en «mode portable». D'autres encore en arrivent à avoir des surfaces clavier/touchpad brûlantes.
Du coup j'avoue être un peu déçu que ce point n'apparaisse nulle part.
[^] # Re: nano
Posté par freem . En réponse au journal Broot le bien nommé. Évalué à 2.
Merci pour ce moment de bonheur.
En bonus, j'ai même appris quelques trucs en lisant…
# pas au siècle dernier...
Posté par freem . En réponse au journal KHTML c'est fini. Évalué à 8.
Tu voulais dire, au millénaire dernier?
Bon, ok, je sors.
[^] # Re: seule alternative crédible ?
Posté par freem . En réponse au journal Que penser du navigateur internet Brave ? (Et pourquoi je privilégie Firefox…). Évalué à 2.
Non, je dis juste que je préfère n'accorder ma confiance qu'a un nombre retreint de tiers, nuance.
Par l'usage intensifs de plugins, sans audit du code, on fait confiance a tous les fournisseurs de plugins en plus du logiciels qui les intègre.
[^] # Re: Et si on jetait le bébé avec l'eau du bain?
Posté par freem . En réponse au journal Que penser du navigateur internet Brave ? (Et pourquoi je privilégie Firefox…). Évalué à 3.
Je pensais avoir fait comprendre que le je comprenais… mais dans la pratique, il y a quoi qui permettre une navigation confortable, en mode graphique?
Citer un navigateur gopher moderne serait un excellent point :)
Tu pourrais aussi y ajouter un serveur, parce que si quelqu'un est convaincu par le navigateur, il serait dommage qu'il ne trouve que des serveurs obsolètes.
Honnêtement, je considère que le web actuel est flingué. Je ne sais utiliser que le web et des mailings lists que je trouve sur des sites webs, mais j'aimerais une alternative, un truc qui ne soit pas rebutant (le ncurses, je m'en sers en permanence, mais par choix, pour des applications dont je connais une alternative graphique).
Si vraiment tu veux pousser, commence une dépêche, colles-y des liens, j'essaierais d'aider.
[^] # Re: seule alternative crédible ?
Posté par freem . En réponse au journal Que penser du navigateur internet Brave ? (Et pourquoi je privilégie Firefox…). Évalué à 1.
Opera 12 clamait le permettre site par site. Je l'utilisais, et le faisais.
De nos jours, le seul autre navigateur le permettant, sans modules complémentaires, c'est otter. Qui ne s'intègre pas dans debian.
Donc, actuellement non, parce que ne peux plus le faire avec un navigateur qui fonctionne sous Debian stable sans faire confiance a un plugin.
D'autant que je suis devenu de moins en moins confiant sur le fait que de larges organisations de développeurs aient la moindre considérations envers un web respectueux de la vié privée, léger, rapide même avec moins de 200Kio/s pour le brouteur, etc etc.
Je garde malgré tout un oeil et une pensée sur otter-browser (je peux en lire le code, mon cerveau segfault pas), ou les navigateurs proprio qui au moins filent des options utilisables (hint: pas chrome ni safari ni edge à ma connaissance).
[^] # Re: Un autre avis négatif sur Brave
Posté par freem . En réponse au journal Que penser du navigateur internet Brave ? (Et pourquoi je privilégie Firefox…). Évalué à 4.
C'est habituel, de flooder ce média débile qu'est twitter comme ça? Je trouve ça drôle.
N'empêche, il aurait quand même pu caler un lien vers un artcile blog de brave sur le 1er lien, pour nous faciliter la lecture.