freem a écrit 5019 commentaires

Si je voulais troller, je dirais qu'un programme peut être imprimé sur un livre, et que du coup ça ne t'importerais pas qu'on n'ai pas le droit de modifier le-dit programme.

Si je voulais troller de façon plus subtile, je parlerais des livres scientifiques et des manuels scolaires, peu importe leur support: ils sont, eux-aussi, soumis a perpétuelle évolution.

Dans les romans eux-mêmes, on peut trouver de nombreuses fautes, de syntaxe, de grammaire, d'orthographe… des bugs, quoi.
Il peut également y avoir des erreurs factuelles, qui ne sont pas nécessairement volontaires de la part de la personne qui a écrit le texte et n'apportent donc rien, voire enlèvent, à la qualité de l'ouvrage.

Quant au problème de la rémunération, qui est bien réel, c'est de la qu'est partie l'idée des romans-feuilletons je crois: des romans dont une partie est publiée à chaque itération d'un périodique, qui lui est payant. Un peu comme ce type d'oeuvre, à la différence qu'ici le modèle économique est totalement basé sur des dons, des goodies, et un offset temporel pour ceux qui donnent.
C'est au final une variante de ce qu'un professionnel du logiciel libre fait: du support.

historiquement c'est Windows le gros truc monolithique, avec l'affichage qui est prioritaire sur le multi-tâches.

Le noyau Linux aussi est « monolithique »

Selon wikipedia, le noyau de windows NT est de type hybride, alors que linux est monolithique. Juste pour info.
Ce qui tendrais donc a indiquer qu'au niveau le plus bas, windows est plus unix que les distrib linux :D (selon cette métrique, du moins).

Chacun se fera son opinion de la pertinence de la différence, bien sûr, mais bon, wikipedia reste une référence assez utilisée et reconnue il me semble.

C'est valable avec des GUI aussi, ça. La différence c'est que dans un terminal, par défaut, ça se voit que t'es root (pas pour le sudo par contre), légèrement, certes, mais quand même ( # au lieu de % ou $)

ar contre, on doit faire très attention dès qu'on fait des opérations impactant le système globalement et ce que ce soit en ligne de commande ou avec un outil graphique

Un collègue a récemment supprimé par erreur un PC de l'AD (pas admin, tech, mais peu importe). Alors on peut se poser des questions sur la granularité des droits, mais aussi sur, en effet, le problème qu'une interface graphique, si on glisse un peu, on fait assez vite une connerie.
De mon côté, j'ai un script powershell pour ça (et qui génère en plus des trucs qu'il faut copier coller parce que moi flemme), ça m'évite de supprimer par erreur.

Tout ça pour dire, je suis bien d'accord :)

Enfin, pas "toujours", ou du moins pas en juste faisant un apt-get install, mais très certainement toujours depuis avant que debian ne passe à systemd par défaut.

Mettons que je sois fondé à vouloir utiliser un init codé dans la philosophie Unix. Bah j'ai dû aller chercher quelque chose d'autre que Debian

Je me demande comment tordre le cou à ce mythe… j'utilise Debian sous runit, ça juste marche, pas de soucis et, non, je n'ai pas compilé runit, j'ai juste sélectionné le paquet.
Je devrais le compiler, d'ailleurs, parce que le lien symbolique me coûte environ 1.5Mio de RSS par daemon géré, alors que si je compilais soit en statique soit en lien avec muslc au lieu de glibc, ça serait 8Kio (parce qu'en fait j'ai 2 process additionnels par daemon: le gestionnaire, et le logger).
Et ce, depuis avant qu'ils ne mettent systemd par défaut. Je veux bien qu'on tape sur Debian et systemd, mais ça serait pas mal de rester factuel au lieu de répandre des légendes: ça aiderait a garder le débat serein.

Il a toujours été possible d'installer, via le système de paquets et les paquets officiels, un init différent sous Debian (quant a ce que sysVinit+rc.d soient de la "philosophie Unix" je n'en ai pas tant que ça la certitude, après tout, cette philosophie indique que l'outil doit faire une seule tâche, la faire bien, et communiquer avec l'extérieur via stdin/stdout, entres autres?).

Après, malgré que je sois moi-même plutôt contre systemd, il faut reconnaître que c'est un outil qui a eu plusieurs mérites:

• gestion des dépendances
• watchdog
• gestion des journaux

Tout ça, c'est lié, et sysVinit ne le fait pas. Rc.d non plus.

Le chien de garde (watchdog), est notamment une fonctionnalité utile quand on commence a vouloir des systèmes autonomes qui s'auto-réparent (dans les limites du faisable). Oui, ça veut dire qu'il est souhaitable qu'un service qui tombe redémarre tout seul (pour éviter de cramer du fioul sur 400Km juste pour faire un redémarrage, par exemple).
C'est faisable avec runit (et les daemontools de manière générale) mais ce n'est pas a franchement parler efficace, en pratique on laisse le travail de gérer les dépendances aux daemons eux-mêmes. Je le sais: je l'ai fait.

Ce simple fait indique que les daemons ne peuvent, de facto, pas faire "une seule chose et la faire bien", et ça encourage a hard-coder la dépendance à un truc tiers, donc a réduire le choix de l'admin pour ses outils.
De ce point de vue, systemd est plus UNIX que sysVinit+rc.d, qu'il a remplacés sur de nombreux systèmes.

Pour ce qui est de la gestion des journaux, il n'est pas impossible que si l'on ne s'était pas farci sysVinit+rc.d pendant des décennies, les daemons auraient adopté plus tôt un comportement plus générique, c'est à dire: émettre par défaut sur stdout ou stderr, en laissant au gestionnaire de services le soin de les rediriger et traiter ou il faut, au lieu de s'appuyer sur syslog, qui est un outil unique pour toutes les instances, fait qui implique que s'il tombe, est corrompu, ou autre, on perds potentiellement tous les logs.
On peut également citer le double-fork-trick.

Encore une fois, systemd (et ici daemontools et ses héritiers le font aussi bien) est largement plus UNIX que les outils qu'il a permis de remplacer.

Moi, bien que je n'aime pas du tout systemd, je lui suis reconnaissant: sans systemd et les problèmes autour, je n'aurai jamais su qu'il était possible aussi simplement de s'affranchir de sysVinit+rc.d, je n'aurai probablement jamais (ou alors bien plus tard) trouvé runit, mon init+gestionnaire de services actuel.

Systemd a beau être une usine à gaz, un monstre de complexité, un framework alors que je préfère les bibliothèques, avoir eu des failles de sécurité réseau… je le trouve malgré tout largement préférable à la situation dont il nous a sortis.

En fait, ironiquement, c'est grâce à systemd que certaines distro, dont debian, ont commencé à supporter plusieurs systèmes d'init pour de vrai (le support des init autres que sysVinit+rc.d dans Debian reste parcellaire, soit, mais avant c'était le vide inter-sidéral).

Et le pire dans tout ça, c'est que malgré mon discours ici plutôt en faveur de systemd, ben, je refuse toujours de l'utiliser, pour mes raisons propres (un init qui dépend de dbus est le genre de trucs qui me chatouillent un peu par exemple).

et à mon sens ça me paraît évident que l'usage de la ligne de commande nécessite de faire attention à ce qu'on fait

Le problème c'est que j'ai l'impression que les gens pensent "sous linux, la ligne de commande est normal, c'est la routine". Du coup, peut-être qu'il y a un combo de deux biais culturels en conflit direct ici? Je sais pas, hein. Mais alors, vraiment pas. Je suis trop biaisé pour ça, je ne me rend pas compte de ce qui est compliqué en info pour les utilisateurs normaux, et je crois même, pour en avoir quelques un en collègues ces temps-ci, que même parmi les tech, le niveau moyen de linuxfr est plutôt très élevé (même si je ne suis pas du tout dans le top…).
C'est peut-être prétentieux de ma part cela dit.

Je suis pour ma part curieux de savoir le retour d'utilisateurs normaux sur les outils de mise à jour automatique, je crois que debian les as "hérité" d'ubuntu, je ne connais pas leur nom, je sais juste que ça existe. Je ne sais même pas s'il est possible de faire des MàJ majeures avec?

Évidemment, je salue le travail et les raisons du choix politique (car c'est clairement politique ici, politique du LL), il se fait rare, ces derniers temps, de défendre la polyculture qui est la force originelle de linux (qui n'est qu'un noyau «inutile» en soit, sans le reste du code, le CPU n'est qu'un bout de sable raffiné…).

Evidemment, ça ne serait pas intégré au moins avant longtemps, mais j'imagine qu'il est possible de demander. Vu que je ne sais pas comment faire moi-même, j'ai un peu cherché, et j'ai trouvé ça mais je ne sais pas comment soumettre de nouveaux paquets a cette liste (qui devrons évidemment trouver un mainteneur qui ait la volonté de le faire sur son temps libre, certes).

Je suis d'accord et pas d'accord.
L'avantage des noms de code, c'est que c'est plus parlant j'imagine, mais je préfère aussi me référer à ma Debian par son numéro de version quand je décris un problème, l'avantage étant qu'un nom de version permettra toujours a quelqu'un d'avoir une estimation de l'âge du truc (trop de sites ne mettent pas la date des messages malheureusement, et de toute façon pour un fichier versionné ou ce genre de truc, bon, c'est pas le plus pratique de devoir faire de la pêche aux infos).

Malheureusement je ne crois pas qu'il soit possible de l'utiliser dans /etc/apt/sources (et du coup j'utilise old-stable, stable, testing, unstable et experimental, qui sont des noms bien plus parlants que des numéros, pour le coup… enfin, ça dépend, si j'ai besoin de pin-point un paquet ou non…).

IL n'y a pas d'alias de distro chez fedora?

Je veux dire, un système comme chez Debian, dans lequel les distrib ont d'une part un nom de code (stretch, sid, potato… oui, je sais, sid est pas recommendée et les autres obsolètes depuis fort longtemps) et un "état": old-stable, stable, testing, unstable et experimental.

Ceux qui veulent ne pas se prendre la tête se contentent d'utiliser "stable" dans le source, et la distro se démerde toute seule pour savoir quelle version récupérer. D'ici a dire que c'est une bonne idée, je ne suis pas sûr, mais ça évite clairement le genre de problème du journal.
Il me semble que Fedora est censée être une vitrine technologique de RHEL, mais quand même.

Et le dernier clou, la sauvegarde dans le cloud. Ahah. Ça, c'est l'argument massue pour me faire m'en aller : tous mes mots de passe, au même endroit, chez un prestataire que je paie pas et qui ne me dois rien.

En même temps, tu avais tout mis dans le titre, non? Et si le F.B.I. (ou autre, selon la nation qui héberge le PC de stockage) a besoin de tes codes pour différentes raisons? Evidemment, il faut insérer des mécanismes de backdoor, mais avec les bonnes lois ça peut se faire.

Celles qui ne l'ont pas été ont nécessité pas mal de réparations.

J'aurai de manière générale bien plus confiance dans du bois brut pour durer que dans du contre-plaqué. Sans avoir forcément d'explication rationnelle sur ce point, par contre: je n'y connais rien :)

Ok, effectivement du coup… reste qu'une release c'est assez peu prévisible au final.

C'est bien à celle-ci que je faisais référence, j'ai juste adapté un peu à la situation :)

Bon lien.
J'ajouterais pour ma part ce lien qui cause de comment faire un binaire vraiment standalone sous *nix: "you'll need on retainer a UNIX graybeard".

Par exemple par défaut si un service dont on dépend s'arrête, par exemple le réseau, celui qui en dépend, par exemple ntp, ne s'arrête pas. On peut toutefois le forcer.

Je n'ai aucune expérience avec dinit, vu que j'ai appris son existence hier soir en tombant sur ce journal, mais j'ai un peu lu la doc et il me semble qu'il est censé supporter cette fonctionnalité, si la dépendance est "hard"?

colord a une dépendance stricte à udev

Pour rappel, systemd-udevd ne dépend absolument pas de systemd (ou en tout cas, pas la version présente dans debian stable) et ne contiens "systemd-" dans le nom que parce que le projet est maintenant maintenu par la même "organisation" que systemd. C'est même un truc que les pro-systemd répète à l'envi (et à raison je suppose?).
Pour ce qui est de eudev, je n'en vois que peu l'intérêt personnellement, si je devais reprocher un truc à udev, c'est son côté usine à gaz et… eudev le partage, vu que c'est "juste" un fork.
Et avant qu'on me pose la question, non, je n'ai pas expérimenté avec les alternatives (et bien que j'aie 2-3 liens sur mon PC perso qu'il faut que je me sorte les doigts pour tester, ça reste un élément de TODO-list).

Je me demande quand même si cet outil est utilisé par la chaîne de bouchers dont le produit n'est pas lié à l'informatique… Ca a l'air vraiment très lié à de l'informatique pure, ils parlent bien de "large scale".

Je ne trouve absolument pas déconnant qu'une entreprise doive mettre la main à la pâte pour utiliser un produit qui leur permets d'économiser. Dans le pire des cas, elles peuvent utiliser la version qui est plus vieille de 3 ans. C'est bien moins pire que les nombreux outils pas libres qui coûtent plus cher, et pour lesquels tu peux te brosser si ils décident d'arrêter le support pour la version que tu utilises, et te disent donc que tu dois cracher au bassinet a nouveau, sans parler des formations à payer et des risques de problèmes lors de la migration.

sinon ils le feraient déjà, car ce serait moins cher.

Je n'en suis pas si sûr. Pour ça, il faut pratiquer les rotations et donc ne pas se spécialiser, et je ne serais pas surpris que ça soit un élément très bloquant.

ils mettent donc en avant les très bonnes performances énergétiques du bâtiment (ils comparent à la brique).

On présente souvent le bois comme une solution écologique et tout, et c'est vrai que c'est un matériau plutôt sympa de ce côté comparé au béton (en même temps, c'est pas dur, si je puis dire), mais c'est aussi un matériau qui nécessite beaucoup d'entretien.
Quand j'étais gamin, les boiseries étaient traitées assez régulièrement chez mes parents (tous les 2-3 ans?), et je doute que ces traitements soient à franchement parler très sympa… il me semble bien que le xylophène, notamment (et si ma mémoire est bonne), avait une odeur pas tout à fait discrète, qui fleure bon la chimie lourde made in Le Havre.

Pour ce qui est des briques, c'est sûr qu'en soit, ce n'est pas super isolant (encore que… des briques creuse, ça peut être plutôt efficace de ce point de vue), mais l'un des avantages du minéral, c'est qu'il permets d'accumuler la chaleur, ce qui est moins vrai du bois.
Si le bois était si intéressant, je me demande bien pourquoi en (certains endroits de) Normandie les maisons traditionnelles (chaumières, par exemple) ne sont pas en bois? Elles ont bien sûr des poutres, mais c'est loin d'être le composant majeur des bâtisses (c'est utilisé pour l'infrastructure, le soutènement, pas pour le remplissage).
C'est plutôt du torchis, qui est le composant majeur pour remplir les murs, par dessus une base de silex, et de la chaume pour le toit. L'avantage de ces matériaux étant au final assez évident: on les trouve à côté.
On trouve aussi pas mal de briques et d'ardoises (pas pour les chaumières), les briques étant un matériau facile a produire (c'est de la terre cuite) et les ardoises… je ne sais pas d'où elles viennent, j'avoue.
Le bois n'est pas non plus une ressource rare dans le coin, il suffit de regarder la carte pour s'en rendre compte…
Pour ce qui est de la production, la pierre de taille ou brute (silex) n'est pas à franchement parler le truc le plus simple a produire ou trimballer, comparé à du bois.

Alors pourquoi tant de bâtisses, construites à une époque ou l'énergie était rare et chère, la technologie d'isolation moins avancée, et le climat plus froid, utilisent-elles autant de minéral si c'est mauvais pour le confort? Je ne crois pas que les anciens aimaient l'incofort ou étaient idiots: eux étaient capables de préserver de la glace toute l'année sans énergie, par exemple, nous… pas vraiment. Et ces frigos étaient basiquement des trous dans la terre, dont les murs étaient renforcés par: de la pierre, de ce que j'ai vu. Jje n'ai vu qu'une seule glacière, pour le coup, donc mon expérience est très limitée, mais les seules traces de bois étaient les portes du sas et l'échelle.

Je n'ai rien contre le bois, loin de la, mais je me demande quand même si c'est vraiment la solution à tous les problèmes, qui est l'idée que je ressent (ça n'est pas exprimé tel quel, c'est vraiment juste mon ressenti) dès lors que quelqu'un viens parler de bâtiments écologiques.
Est-ce que l'isolation est vraiment la meilleure solution? A quel problème exactement?
Le fait d'utiliser la pierre comme "condensateur" à énergie ne serait-il pas tout aussi pertinent, tout en nécessitant moins d'entretien et donc, à moyen et long terme, moins de dépenses énergétique (pas besoin de rendre la pierre imputrescible, et même en étant imputrescible, le bois il faut le changer toutes les N décennies, ce qui implique un acheminement, et de nos jours, l'acheminement n'est pas vraiment super écologique. Certes, la pierre c'est lourd a transporter, le bois étant plus léger, mais, par exemple dans le cas d'une carrière en hauteur, avec des camions électriques, ça permets de produire plus d'énergie que ça n'en coûte, de la descendre).
Ici, on parle même de contreplaqué… reste-t-il des constructions en contre-plaqué, même des meubles, hein, après 1 sciècle? Le contre-plaqué semble avoir été inventé au 18e, et avoir pris son essors fin 19e… nous sommes au 21e, donc on devrais avoir un peu de recul sur la durabilité de la chose.
Des bâtisses avec du bois brut, j'en connais quelques unes, qui sont loin d'être toute neuves. Des objets en contre-plaqué de plus de 20 ans? Ca ne me dit rien.

Mais une moule agréable

Difficile d'être agréable quand on se lève de la mauvaise valve j'imagine

Nourrir les animaux d'élevage

Pour le coup, il y avais hier une émission sur france culture sur le sujet de l'élevage, et l'un des invités (éleveur, celui-ci) a dit un truc que j'ai trouvé pertinent.
C'était un truc du style:
En fait, ça dépend. Parce que l'élevage, ça pollue surtout en fonction de ce que l'on donne a manger aux animaux. Les animaux qui pâturent (par opposition a ceux nourris au grain et autres farines de triste mémoire) ne coûtent que peu de nourriture, et aident les pâturages a se renouveler (déjections animales), ce qui permets donc de réduire la part d'engrais et pesticides à utiliser lors de la rotation du pâturage en champs.

Un truc de ce genre. Je n'ai pas tout écouté ni entendu, j'étais en voiture pour aller en intervention. Mais cette idée m'a frappé par son aspect logique.
Evidemment, la question qu'un tel modèle adopté en masse suffirait à couvrir nos besoins actuel est réelle, je n'ai pas plus d'info ni d'opinion que ça sur le sujet, mais du coup, l'élevage est-il réellement polluant et mauvais pour l'environnement, ou est-ce l'élevage intensif et déraisonné qui l'est?
J'avoue avoir du mal à m'imaginer que les vaches qui glandent toute la journée dans les champs autour de chez moi soient si mauvaises pour l'environnement.
Et j'ai aussi appris que ces animaux, élevés pour les veaux et le lait, sont ceux qui produisent également pas mal de viande (le sujet a ce moment était l'augmentation des prix du steak haché).

Oups, erreur de lecture de calculette de ma part. Bref, ça reste un investissement plus que raisonnable pour une boîte avec un CA de 25M.

Bien d'accord. Accessoirement, le "l'intérieur est propre" des machines industrielles, je me demande si c'est pas surtout pour empêcher ou rendre difficile les modifications, justement. Par exemple, les blocs de glue qu'ils foutent la-dedans pour empêcher de remplacer des condo et autres puces… Ca fait "propre", mais c'est surtout pour emmerder le monde.