freem a écrit 5019 commentaires

Non mais, tu as fait le calcul toi-même… 80K/25M. Ca fait 3.2% du CA… il suffira de le prendre aux actionnaires ou au PDG, hein.

Pour les jeux en ligne aussi, pour le coup. Je peux par exemple citer Battlefield 2142 qui est encore joué plus de 10 après, les types ont du patcher le binaire serveur pour reconstruire une infra à peu près équivalente (modulo les évidentes fonctionnalités que l'on perds parce que pas critiques et que c'est compliqué de faire sans le code).

Même pas, parce que d'ici 3 ans, les changements libérés seront quotidiens ou presque (en fonction de leur rythme de développment).

Le problème, c'est que si c'est un clou microsoft, il risque bien de ne pas planter… (oui, je sais, c'est une vieille vanne, mais j'ai pas pu m'empêcher)

API est un sigle il me semble, donc j'imagine qu'on ne peut même pas dire qu'il s'agit d'un mot, tout court?

Sinon, le linky émets sur un bus RS232 de mémoire. Si tu veux vraiment ta roue, faire un montage avec une puce qui déchiffre les info et qui balance ça sur une roue codeuse ne devrais pas être trop complexe.
Pour ce qui est de la conso électrique d'un tel engin, je doute que ça atteigne 1W/h. Le tout devrais marcher sur du 12V, et pour moins de 100mA (oui, ça fait plus de 1W/h, mais je n'ai aucun chiffre, et je pense vraiment que 100mA c'est trop pour ça). Ca devrais pouvoir tourner avec une bête cellule photovoltaïque et un circuit RLC pour accumuler le jus, en mode calculatrice solaire des années 90, pour ceux qui sont assez vieux :)

Le lien est en anglais, le drapeau est celui de la France.

D'autant que l'on peut faire des sockets nommés, ce qui est assez pratique par exemple avec un tas de machines qui établissent un tunnel inversé sur un serveur qui permets de rebondir (bon, évidemment, une vraie architecture réseau serait plus efficace, mais on n'a pas tous le temps et les compétences pour ça, d'où l'usage de bouts de ficelles et de scotch parfois)

Discrimination! Je suis outré par ce comportement qui exclue les habitants de la Normandie sans raison. D'ailleurs, on sait s'affirmer: la preuve, on sait que le Mont Saint Michel, c'est pas breton!

/me ->[]

Maintenant, ça peut faire peur aux nouveaux de voir qu'on est des extrémistes ici…

Ou le contraire, des gens pourraient se dire qu'ici, il y a de la suite dans les idées, ce qui peut être perçu comme positif.

De toute façon, proposer des alternatives n'est pas vraiment de l'extrémisme. De l'extrémisme, ça serait de virer automatiquement tout lien vers une solution non libre, et de vérifier le navigateur: si pas libre, rediriger vers un site pour Dl un brouteur libre. Et on en est très, très loin.

Qualifier tout et n'importe quoi d'extrème est juste une manière de disqualifier des options sans avoir a trop réfléchir.

J'y pense, un moyen de réduire le problème serait peut-être d'utiliser des liens vers invidio.us? Sans résoudre le problème (parce que ça reste du proxy, et pas vraiment des solutions alternatives à mon avis), ça réduirait peut-être son impact.

Cool! LDAP fait partie de ces trucs que j'ai envie de me déployer dans un petit labo maison (et a terme pour gérer mon LAN perso), vu que je ne suis pas sysadmin et du coup n'ai pas l'occasion de le manipuler.

Pour info, je trouve le site un peu confusant: la page de téléchargement par exemple donne l'impression que l'on va télécharger openLDAP, et non des outils pour openLDAP.
La présentation de la page d'accueil me donne l'impression que les 4 lignes en dessous de "COMPILATION OF TOOLS FOR LDAP ADMINISTRATORS" sont des liens, mais non.

Enfin, merci en tout cas, je vais creuser ça.

PS: si jamais quelqu'un a des liens pour apprendre LDAP par un débutant (débutant LDAP, hein, pas débutant debian ou en shell) ça m'intéresserait.
J'ai déjà un peu joué avec, je me souviens notamment que l'un des outils pour l'intégrer dans PAM sur debian segfaultait, mais je n'ai pas été très loin.

Lien cassé? [edit] c'est le ":" à la fin, voici le bon lien.

De toute façon je crois me souvenir d'une rétrospective sur le sujet ou il était admis qu'ils n'étaient pas vraiment modérés. C'est dommage du coup de faire "genre on modère" alors qu'en fait que dalle. Après, je comprend que c'est du boulot de modérer, sachant que les liens, ben, ça reste ce qui tombe le plus (après les commentaires, j'espère quand même, mais bon).
Il serait peut-être pertinent de mettre à jour les règles officielles si elles ne sont pas appliquées.

En fait, la personne derrière cet effort de portage vise les 250 maps, aux dernières nouvelles (et est a plus de 200). Bon, à l'origine, elle parlait d'atteindre seulement les 100, donc, à voir la valeur qu'on accorde a cette "limite" :) (mais la valeur de l'effort, elle, est bien réelle, c'est une évidence).

A mon avis, le problème c'est que ni le titre, ni le lien lui-même n'indiquent le sujet. Et comme en plus, c'est youtube, donc privateur et, "pire" google… voila quoi.

Cela dis je suis entièrement d'accord sur le fait que les liens sont plus que régulièrement sans aucun… lien, justement, avec la ligne éditoriale de linuxfr (et il me semble que, contrairement aux journaux, les liens doivent la suivre un minimum. Malheureusement je ne trouve pas les règles de modérations qui s'appliquent aux diverses sections, donc je ne peux pas citer).

Exemple typique au sujet du hors-sujet: https://linuxfr.org/users/gbetous/liens/travailler-avec-les-francais-temoignages-de-17-etrangers-venant-de-12-pays
Il n'y a ni rapport avec linux, ni rapport avec le libre, ni rapport avec même juste le logiciel.

Ça tombe bien, je n'ai jamais parlé de réinventer la roue mais d'avoir des défauts.

C'est difficile, mais tout le monde réinvente la roue sans trop de poser de question, malheureusement.

Pour le fait que le format pourrait être mis à jour, je suis d'accord, sur la théorie du moins (en pratique, forcément, c'est pas la même done).

courant pour certains langages.

D'ailleurs, je me dis, Perl utilise un repo, et je n'ai pas souvenir d'avoir vu ce type de problèmes dans les infos?
Pour ceux qui ont été affectés, je dirait: JS, python, et… c'est tout, non? Rust n'as pas encore été ciblé? Quels autres langages ont été affectés, en fait?

Si, ça arrive.

C'est vrai, il peut y avoir des cas d'usages. Désolé d'avoir été aussi péremptoire. Mais je pense que c'est loin d'être la majorité, ou alors tu va me dire que tu utilises du haskell, du java, du C#, du C, du python, du JS, du perl et whatnot dans la même boîte?
Bon, techniquement, perl sous debian t'as pas le choix, python n'est pas le plus simple a esquiver et maintenant ils commencent a mettre JS en dépendance obligatoire des paquets de documentation (ce qui me fait vraiment chier, au passage), mais l'idée est la: je doute sincèrement que l'accès à la totalité de l'archive Debian soit nécessaire dans la plupart des cas.

Par contre oui, ça se fait, et plutôt bien, tant qu'on a l'espace disque. L'avantage est qu'il suffit de pomper la totalité d'un repo http sur un serveur et ça juste roule avec des outils comme reprepro.

mais est très peu utilisé en comparaison

Il fut une époque ou python était très peu utilisé, lui aussi. Troll à part, tu as raison, mais il n'empêche qu'on ne peux pas parler de réinventer la roue quand quelqu'un utilise ar, surtout quand le projet en question est loin d'être jeune.
Je ne connais pas l'historique derrière ce choix, mais il me semble très clair que pour critiquer ce choix, il faut critiquer en fonction de l'existant à l'époque, et des performances des autres solutions à ce moment. De nos jours, changer ça risquerais de casser bien des systèmes pour un gain bien faible (si ça marche, ne répares pas!).
Et de ce point de vue, l'usage de tar pour tout et n'importe quoi est aussi risible: le besoin initial était d'archiver sans perte de place sur des lecteurs de bande!

Je serais curieux de connaître la raison du choix de ar au lieu de tar ou des autres formats de l'époque cela dit (zip?). Si quelqu'un à une info ou une piste, je suis preneur.

Juste un commentaire quand même, pour préciser que ces logiciels (enfin, au moins claws, mais je doute que sylpheed n'en ait pas) ont un plugin pour faire le rendu HTML directement.
Pour ma part, je ne l'utilise pas, et en effet, quand je peux utiliser claws mail, mes mails sont… juste efficaces.

Oui, c'est du rendu texte, mais personne ne s'en est jamais offusqué, tout comme je ne m'offusque pas qu'ils utilisent du html… pour la simple et bonne raison que je ne m'aperçois pas qu'ils utilisent html, et qu'eux ne s'aperçoivent pas que j'utilise du texte brut avec une fonte mono-space.
La seule chose qu'ils voient, c'est que je ne mets pas de couleur dans mon texte, et qu'au lieu de souligner, mettre en gras, italique, etc, j'utilise en gros du markdown (qui tire ses origines… du mail, justement, me semble?).

Bref, ça juste marche. Le seul moment ou ça ne marche pas, c'est pour les rendez-vous, mais je n'ai pas testé depuis un bail (peut pas utiliser claws a mon poste actuel, malheureusement… je dois me farcir les horribles outlook lourd et web qui sont totalement inutilisable à mes yeux) ça a peut-être changé (extension vcalandar? Je ne sais pas ce qu'elle supporte exactement.)

WireGuard est disponible nativement dans le noyau Linux depuis la version 5.6 et est disponible comme un module externe pour les noyaux 3.10 et ultérieur (en utilisant le support dynamique de chargements de modules DKMS).

Je ne sais pas a quel point le noyau supporte d'avoir 2 implémentations du même module chargés?

À la place du .txt tu peux faire du latex, ça se versionne tout aussi bien.

C'est ce que j'utilisais pour les documentations "read-only" pas techniques. Pour que ça soit plus joli. Au passé, parce que j'ai changé de métier et je n'ai plus ce besoin du coup, sinon LaTeX est effectivement mon outil préféré à l'heure actuelle, même si je m'en sers une fois tous les 36 du mois.

Pour dpkg sans root il y a FakeRoot : https://wiki.debian.org/FakeRoot

C'est un truc qu'il faudrait que j'arrive a me motiver pour utiliser, mais bon, entre fakeroot, fakechroot, fakeroot-ng, et leurs configs, j'avoue avoir la flemme et avoir tendance a juste chroot. Simple, efficace, même si ça requiert un compte root.

Je pense qu'il y a moyen en fait de faire tourner dpkg sans les droits root. D'ailleurs, un essai rapide avec:

mkdir /tmp/foobar
cp /var/cache/apt/archives/busybox-static*.deb /tmp/foobar
cd /tmp/foobar
PATH=/sbin:/usr/sbin:$PATH dpkg --root=./ --force-not-root -i busybox*

Ca semble marcher.
Du coup, lui dire qu'on s'en fiche de pas être root, parce que bon, hein… et spécifier le chemin qu'on veut. Je pensais que ça aurait été plus compliqué en fait. Comme quoi, suffit parfois vraiment de se sortir les doigts.

Bon, j'ai pris busybox-static pour une raison: c'est le moins risqué.
Mais dans l'hypothèse ou l'on a des paquets qui sont conçus pour ne pas nécessiter un accès root à l'installation, ça devrais vraiment pouvoir fonctionner. Typiquement, pour des programmes interprétés, et non compilés (parce que pour les compilés, ldconfig & consorts)…

ceux qui lisent pas la doc, sont aussi ceux qui ne l’écrivent pas ceci dit en passant…

C'est marrant ça. Parce que moi, quand j'écrivait de la doc (tout le temps quand j'était au taf, a divers niveaux de qualité en fonction de l'urgence et de la finition) c'était pour tout le monde, les autres, et moi.
Je préfère avoir une doc qui me permette de revenir 3 mois plus tard a un code que j'ai oublié parce qu'entre temps je suis passé sur 2 ou 3 autres sections du système, et très honnêtement, je sais pertinemment que pour de la doc, mieux vaut ne pas attendre après les autres…

Donc, si tu veux de la doc utile, c'est pas compliqué: tu te sors les doigts quand tu fais ton projet, tu commences par documenter l'archi du proto, puis tu code, puis tu mets à jour la doc. C'est p'tet pas agile, c'est pas non du plus du V, mais ça a très bien marché pour moi. Et quand un collègue venait me sortir qu'il avait trouvé un bug dans mon code, je demandais 2 choses: les logs, et 5 minutes pour qu'il me dise pourquoi il avais mal interprété la doc. Que je la mette à jour.

Alors, quand je parle de doc, hein, je parle pas de ces horreurs de fichiers word. Je parle d'un simple .txt posé dans le repo, et quand ça deviens trop massif, je le divise (typiquement: utilisation, déploiement et maintenance, déjà ça rend les choses plus simples).
Oui c'est moche le .txt, y'a pas de couleurs, pas de gras… mais on peut faire des paragraphes et des retours à la ligne sans se prendre la tête, on peut utiliser son éditeur de code préféré pour maintenir/visualiser, et ça se versionne super bien. Tant qu'on ne s'amuse pas trop a coller des URI à rallonge en brut dans le texte, mais ça de toute façon on peut pas y faire grand chose (enfin si: les mettre dans un index, mais de toute façon c'est rare que je colle des URIs longues dans une doc technique).

Genre #include et démerde-toi pour que ça soit la bonne version dans le path.

Je pense que tu es au courant, mais certaines libs, genre les libs standard de C et de C++, ainsi que leurs variantes des divers compilateurs, définissent des symboles que l'on peut vérifier pour s'assurer d'avoir les fonctionnalités dont on a besoin.
Je ne dis pas que c'est parfait, mais je dirais que ça semble marcher, et peut-être que personne n'a rien trouvé de mieux, parce que le problème n'est pas trivial.

"réinventer la route"

Je voulais bien entendu dire "réinventer la roue", pas la route.