Il ne font pas la même chose. Pour être exact iptables/nftables peuvent faire tout ce que fait ufw, mais la réciproque n'est pas vraie.
Mais le problème n'est même pas la. On a une personne (seb95) qui commence son article en disant :
Frugalware arrive avec un firewall configuré pour fonctionner out of the box (directement sans rien faire). Il autorise toutes les connections sortantes, et les paquets entrants pour les connexions établies. Il n'autorise les paquets entrants standards (NDT: comprendre hors connexion établie) pour aucun port.
Traduction : pour les débutants et les gens qui ne veulent pas mettre les mains dans le cambouis, on a déjà réglé le problème.
Sous entendu : le reste de l'article est destiné à des utilisateurs avancés ou à des gens qui veulent mettre les mains dans le cambouis.
Et là on se rend compte qu'il s'agit de règles préconfigurées, et tout ce qu'il y a à faire pour une personne qui voudrait autoriser les fonctions ssh, ou activer les téléchargements torrent, doit juste savoir lire et retirer un caractère #.
Niveau simplicité, c'est clairement au dessus de ufw.
En plus seb95 prend bien le temps de faire la mise en contexte, d'expliquer ce qu'il fait et ne fait aucun prosélitisme pour sa solution. C'est un tutorial rapide certes, mais tout à fait neutre de ton.
J'en déduis donc que pour Sébastien Maccagnoni-Munch c'est l'idée même que quelqu'un puisse avoir d'autres besoins que le siens ou puisse vouloir faire autrement que lui qui est fondamentalement ridicule et méprisable. Le fait de voir une telle attitude dans un cadre simple sur un exemple isolé me permet réellement de mieux comprendre certains projets open source.
Pourquoi ne pas utiliser un logiciel fait pour simplifier la gestion du pare-feu !?
(par exemple ufw)
Merci tu viens de m'expliquer instantanément le pourquoi de Gnome 3 systemd et du masquage du terminal dans de nombreuses distrib.
(j'ai quand même inutilisé ton post parceque je suis un aigri.)
En n'importe quel binaire, on peut faire exactement comme pour ton "texte"
Non, on ne peut pas. Sur un fichier texte avec des corruptions (mettons 3% de caractères soit remplacés, soit tronqués, soit illisibles) on arrive encore humainement à faire les corrections qui vont bien si c'est possibles.
Sur un fichier binaire, surtout comme ceux de journald avec une entête qui défini la taille de l'objet, si il manque un seul octet c'est la mort.
Les mecs qui écrivent journald, disent eux même que c'est extrêmement compliqué de corriger un fichier binaire, que ce soit automatiquement ou humainement.
Da façon générale si j'ai une corruption unique dans un fichier texte, je vais avoir une ligne de logs inexploitable. Si j'ai une unique corruption dans un fichier au format journald, ca peut aller jusqu'à faire que toutes les entrées suivant la corruption sont inexploitables. (Cas de corruption de tag)
qui n'a pas l'air de déranger ceux qui choisissent systemd (et ils sont nombreux), sans doute parce que les avantages de leur format compensent les quelques désavantages.
Je n'ai pas dit que le format binaire n'avait que des défauts et qu'il était idiot. Néanmoins dire que le format binaire, surtout tel que choisit par journald présente exactement la même résistance à la corruption que les fichiers, chose que même les créateurs du format réfutent, est une connerie.
On peut parfaitement préférer journald à syslog, c'est une question de choix, de besoin et de gouts personnels. Mais dire que le format de logs texte est extrèmement résistant à la corruption alors que le format journald est extrèmement sensible à cette même corruption est un fait. Ne pas être d'accord avec l'impact de la corruption sur les journaux journald, c'est comme ne pas être d'accord avec le fait que 2+2=4. Tout le monde est libre d'avoir son opinion, mais là ca ne va pas changer grand chose au résultat.
The only way to deal with journal corruptions, currently, is to ignore them: Yupp, journal corruptions result in rotation, and when reading we try to make the best of it. they are nothing we really need to fix hence.
La corruption d'un journal binaire est très compliqué à corriger, surtout si des extensions sont activés ou si c'est un tag qui est altéré.
Dans le cas de l'altération d'un tag, toutes les entrées à la suite du tag sont bonne à mettre à la poubelle.
A noter que jorunald n'a pas d'équivalent fsck au boot ou de controle continue. Il se peut donc parfaitement qu'il continue à écrire dans un journal corrompu, et ce même après un reboot. Je recommande vivement à tous les utilisateurs systemd qui utilisent journald de faire un renvoi des logs vers un logger fiable, et de lancer journalctl --verify de temps en temps.
A noter également qu'un journal parfaitement valide, mais qui n'aura pas été indexé, ou pas tagué (par exemple suite à une perte brutale de l'alimentation) sera lui considéré comme corrompu, et sera donc remplacé par un nouveau fichier.
Alors je reprends lentement.
Phase 1:
Renault déclare dans son post qu'il est normal que l'init utilise des fonctionnalités spécifiques du noyeau, vu que c'ets un composant proche du noyau
Phase 2:
Je répond que l'init n'est pas plus proche du noyau que n'importe quel autre processus qui tourne en root.
Phase 3:
Renault surrenchérit en disant que l'init est bien proche du noyau car c'est le noyau qui fournit les abstractions qui permettent de gérer entre autres, porcessus et cgroups
Phase 4:
Je signale tout d'abord que le noyau ne fournit pas d'abstractions (je reviens dessus dans un instant) mais des interfaces et que le noyau fournissant de façon générale toute les interfaces, dire qu'un processus est privilégié parcequ'il a besoin d'interragir avec le noyau est pas franchement discriminant.
Je reste sur ma lancé, l'init processus comme les autres qui n'a ni plus ni moins de raisons que les autres d'utiliser des fonctionnalités spécifiques de Linux.
C'est sur ce post là que tu interviens. Je n'ai pas encore commencé à taper sur systemd (ce que je ferai plus tard, suites aux provocations de Barret Michel)
Tout ce que j'ai dit pour l'instant c'est que au niveau des interractions avec le kernel, l'init est un processus root comme les autres.
Maintenant ton propos :
Ce que je relève, cette abstraction dans le cas /proc est faite directement par le kernel et pas du tout par l'init
a) je n'ai jamais dit que /proc était fait par l'init. J'ai même dit à plusieurs reprise que l'init n'avait pas plus de prise sur les abstractions que n'importe quel processus root. Si l'init était nécessairement à l'origine du /proc, je me serais abstenu.
b) L'abstraction n'est pas faite directement par le kernel. Le kernel (si on a les bonnes options de compilation) peut, si on lui en fait la demande créer une interface secondaire pour le suivi des processus, réserver une zone mémoire, et créer une abstraction filesystem sous forme de pseudo-device mappé en ram et présentée en userland. Dire que cet abstraction est fournie directement par le kernel c'est comme de dire que l'abstraction /media/vcdrom de montage d'une image iso est fournie directement par le kernel. A ce compte là tout est fourni directement par le kernel. Ce que l'on considère directement fourni par le kernel se sont les interfaces, c'est à dire des fonctions userland pour envoyer des commandes au kernel et recevoir ses réponses sans passer par des drivers. Et niveau drivers /proc est plutôt chargé (ram mapping + pseudoFS + moniteur).
Et ça m'inspire surtout "so what ?". Le kernel aussi, et alors ?
La gestion de processus par le kernel, à savoir l'attribution de PID, l'ordonnancement, l'attribution mémoire et son mapping, présentation des appels systèmes d'attentes etc, n'a rien à voir avec la gestion userland des processus. Une fois de plus je ne fais que répondre à Renault qui me dit que l'init est proche du noyau car il participe à la gestion des processus. Je ne fais que lui répondre qu'il ne participe pas plus à la gestion des processus que d'autres processus lancés en root qu'on va avoir du mal à considérer comme proche du noyau (psDoom franchement…)
Je comprends bien que tu n'aimes pas systemd pour des raisons qui te sont propres, mais il faut un minimum rester cohérent dans les arguments.
Je comprends que tu n'aimes pas les gens qui n'aiment pas systemd, mais il faut lire un minimum les threads auquels tu réponds. A l'instant ou tu réponds dans le thread je n'ai pas dit un mot sur systemd ni spécifiquement en tant qu'init, ni généralement en tant que framework. La seule et unique chose que je défends est que vis à vis des interractions avec le noyau, l'init a exactement les mêmes accès et besoins que n'importe quel autre processus.
Deuxièmement quand on attaque une personne sur la cohérence de ses arguments, il faut un minimum vérifier que les arguments qu'on lui prête sont véritables.
Euh, /proc n'est pas directement fourni par le kernel ?
C'est un pseudo file-systeme, si tu ne le montes pas ca ne dérange en rien le kernel et tu peux quand même intéragir avec les processus (mais c'est plus compliqué.)
C'est quoi le rapport entre la gestion des processus et le system d'init ?
Là quand même, un système d'init se doit un minimum de pouvoir lancer au moins un processus, de vérifier qu'il s'est bien lancé et de réessayer de le lancer un peu plus tard le cas échéant. Et puis l'init est supposé surveiller tous les processus en dessous ou rataché à lui pour éviter un remake de la nuit des morts-vivants…
"dans tous les sens" ? Carrément ? Ça veut dire quoi pour toi dans tous les sens ?
Ben le login, le réseau, les cgroups, certains paramètres LXC, certaines fonctionnalités acpi/apm, et bien entendu toute la couche d'interface DBus de discussion avec les processus (et j'en passe). Je pense que dans tous les sens est assez approprié dans ce cas.
Sérieusement ? Va falloir réexpliquer l'intérêt de l'utilisation des cgroup dans l'init ? T'es juste ridicule.
Oui il va falloir réexpliquer encore et encore. Par exemple l'intéret qu'il y a de lancer un résolveur local unique dans un cgroup. Il existe en une seule instance, le mapping service/pid est évident, il ne spawnera jamais de fils, son empreinte mémoire et CPU ne varira pas et si je veux de la sécurisation il faudra de toute façon que je passe par des MAC. Donc pourquoi le caller dans un cgroup et exiger les droits root pour pouvoir modifier sa config ?
Mais surtout pourquoi m'obliger à passer par systemd pour gérer mes cgroups. Contrairement à ce que tu impliques je connais et j'utilise les cgroups depuis un bon moment, et par exemple je veux que certains de mes services soit dans le même cgroup. Avant systemd c'était très simple, avec systemd à jour avec les slices et les scopes c'est une horreur (de l'aveu de Lennart lui même, c'est une des raisons pour laquelle il est en train de modifier complètement les intefaces cgroup).
Les cgroups sont très interressant dans certains cas, à savoir tague des processus qui sont potentiellement capables de faire spawner d'autres processus, ou suivre une instance spécifique d'un service que l'on lance en 25 exemplaires. Mais pour une majorité de cas c'est juste un overhead dont on aurait pu se passer.
ces logiciels peuvent toujours se servir des cgroups
Dans le nouvelle version de systemd avec lock exclusif sur les cgroups ca n'est possible que si
a) le processus en question possède les libs DBus et systemd qui vont bien
b) le processus en question a les droits root
c) la gestion des cgroups voulues par les processus n'est pas en conflit avec le tagging cgroup de systemd.
ces logiciels ne se sont JAMAIS servi des cgroups
Magie du code respectueux de la philosophie Unix, même si ces logiciels n'ont jamais implémenté de fonctionnalités cgroups en interne, il était tout à fait possible pour un admin de gérer et de faire gérer par ces processus des cgroup. En d'autres termes c'était flexible. L'inconviennient de systemd est que désormais les cgroup ne peuvent plus être appelés qe d'une seule façon et depuis un seul point d'entrée. En plus la modification d'appartenance d'un processus à un cgroup avant de le relancer est devenue une tache complexe. (Modifier dynamiquement la slice d'une unit est loin d'être uen sinécure) etc.
c'est une problématique d'intégration. L'administrateur d'un site d'e-commerce peu vouloir gérer ça différemment de celui qui fait de l'hébergement. Donc c'est forcément au niveau de l'intégration dans l'OS que ça va devoir se gérer
Donc le fait que systemd oblige tout le monde à utiliser le même tuyau de la même façon est une pénalité non ?
Et en quoi c'est différent avec systemd ? Il y a dans le noyau des if (init == SYSTEMD) ?
J'ai jamais dit qu'il y avait des différences avec l'init systemd. C'est bien le truc, il n'y a aucune raison pour que l'init soit considéré comme "proche" du noyau, du moins ni plus ni moins que n'importe quel autre processus.
Par contre la nébuleuse systemd elle, en mettant des locks exclusifs dans tous les sens créé une vraie différence avec le déroulement traditionnel d'un init. Ca apporte de bonnes choses et des choses moins bonnes, mais ça change réellement la donne. Systemd en tant que gestionnaire système (c'est à dire tout ce qui va au delà de l'init) change complètement les interactions avec les processus.
Pour ce qu'il voulait dire, je pense qu'il dit que c'est cool de voir des init qui utilisent toute la puissance du noyau sous-jacent
Et ce que je veux dire c'est qu'il n'y a pas de raison que ce soit plus cool pour l'init que pour n'importe quel autre processus. A part le fait qu'il ne doit pas mourir sous peine de faire s’arrêter le système, l'init est un processus comme les autres. Je ne vois pas en quoi c'est un vrai plus que l'init tire partie des fonctionnalités avancées du noyau, du moins pas plus que si il s'agit d'Apache, de MySQL ou de Xorg.
Le but de l'init est d'initialiser tout le système
Tout dépend de ce que tu appelles le système. Si tu parles de la partie userland, l'init peut effectivement mettre en place l'ensemble du userland, mais ce n'est en rien une obligation. Un certain nombre d'autres éléments peuvent s'en charger. L'init va lancer le premier processus qui a son tour peut lancer d'autres processus. Sur des terminaux type NCD l'inti va juste lancer un listener qui lui lancera le reste des applications en fonction des demandes.
Par contre pour que l'init puisse se lancer il faut que le système non userland soit déjà dans un état très avancé.
Pour faire tout ceci correctement l'init est proche du noyau car c'est ce dernier qui offre des abstractions pour gérer des processus
Le kernel n'offre pas des abstractions pour gérer les processus, il fournit des interfaces userland. Généralement ces interfaces sont utilisées ensuite pour créer des abstractions (typiquement le pseudo file system /proc ). Mais l'init (traditionnel, systemd étant en train de changer la donne à ce niveau là) n'a aucun avantage au niveau de ses interfaces ou des pseudo-fs comparé à n'importe quel processus avec les droits root. D'ailleurs de nombreux logiciel de gestion des processus (de nice à psDoom) bypassent complètement l'init.
De façon générale le noyau offre toute les fonctionnalités possibles et imaginables de l'OS. C'est le seul à pouvoir attribuer de la mémoire, du temps d'éxécution, un PID, des droits d'accès sur les devices ou les pseudo-devices, des changements de contexte etc.
On pourrait dire que pour faire son travail correctement Postgresql est proche du noyau parceque c'est ce dernier qui offre la ram et les accès disque dont il a beson pour faire son travail correctement. Ou encore que ping est proche du noyeau parceque c'est lui qui offre les accès réseau et les abstractions ICMP dont il a besoin.
L'init est juste un processus comme les autres, lancé en premier et avec les droits root. Il n'est pas plus "proche" du noyeau que n'importe quel autre processus. Le fait que systemd commence par fermer la porte à double tour pour s'assurer que l'on ne puisse pas lui piquer le contrôle des cgroups ne change rien à celà. C'est exactement comme si un init traditionnel bloquait le port 80 en se mettant dessus.
(et un moment, Ubuntu utilisait logind sans systemd)
Non, Ubuntu utilisait logind sans utiliser l'init systemd, mais faisait quand même appel à une palanqué d'outils systemd, bidouillés à fond les ballons pour que ca marche. Les libsystemd-* qui permettent plus ou moins d'avoir les fonctionnalités systemd même quand systemd n'est pas lancé en tant qu'init avec un PID 1
Personnellement je trouve douteux la démarche de vouloir un système d'init portable qui est par essence un composant proche du noyau
GNI ???
Le système d'init un composant proche du noyau ?
Le système d'init est un jeu d'outils pur userland. Je suis conscient qu'avec la main mise de systemd sur tout un tas de fonctions qui n'ont pas grand chose à voir avec l'init on peut être dans la confusion, mais /bin/bash est un init tout à fait convenable - il suffit de faire rw init=/bin/bash dans grub pour s'en rendre compte.
De même une ligne de commande qui va simplement monter les disques pour ensuite lancer (même pas en mode démonisé) un petit serveur genre apache statique, ça se fait très bien.
L'init traditionnel n'a aucun rapport avec le noyau, du moins pas plus de rapport qu'un utilisateur root qui lance des commandes depuis un terminal.
Posté par Kaane .
En réponse à la dépêche Firefox 32.
Évalué à 10.
C'est bien joli en théorie mais combien de projets, libres ou non, ont un audit de sécurité permanent ?
Le truc c'est que quand tu veux être une autorité de certification, tu est tenu d'avoir un audit permanent, contrôler qui a le droit de faire quoi, qui le fait, qui a les clefs, et qui s'en sert à chaque action est la définition même d'une autorité de confiance.
Certainement pas openSSL, et pourtant il est bien massivement utilisé :)
Tu confonds deux types distincts d'audit, un audit technique et un audit production. L'audit technique d'OpenSSL a péché assez largement, mais son audit production est plutôt bon (on sait qui fait quoi, quand il le fait, les droits de commit sont plutôt bien validé etc.)
Une autorité de confiance n'est pas une organisation qui peut demander aux utilisateurs de reprendre leurs transactions d'il y a 15 jours pour les patcher.
une entité communautaire non-crédible face aux entités commerciales crédibles
Je pense que CACert a très largement sous-estimé la charge de travail pour devenir une autorité de certification et que le boulot qu'elle accompli aujourd'hui est de mauvaise qualité. Par mauvaise qualité je veux dire en dessous des "gros" comme Verisign qui font déjà un travail de qualité tout à fait médiocre. Pour avoir testé un certain nombre d'autorité de certification je peux te dire qu'il n'y en a pas une qui tienne la route comparé aux autorités tiers du système bancaire*, mais qu'elle sont toutes largement devant CACert.
Ca ne veut pas dire qu'une autorité de confiance communautaire ne peut pas exister, mais CACert est loin d'avoir les arguments nécessaire pour être reconnu.
L'audit est en cours (certes depuis longtemps) et a apparement subit de nombreux rebondissements, je n'en connais pas les raisons
TLDR : La dernière fois qu'on a eu des nouvelles d'un auditeur c'était pour dire que l'organisation était chaotique, l'infrastructure en morceau, le système de validation inopérant et les relations entre CACert et les autres assureurs ou clients complètement déséquilibrées.
Depuis plus rien.
La création d'un nouveau certificat se passe généralement de façon assez propre chez les gros (sauf chez le plus gros qui est aussi en charge des nom de domaine et qui a racheté le produit du créateur d'Ubuntu) - par contre au renouvellement c'est souvent un festival.
Même le F-35 se vend, c'est dire à quel point les ventes d'un avion de chasse sont totalement décorrelées de ses performances réelles.
Oui enfin il se pré-vend. Il est toujours pas fini le F-35, il ne tiendra pas ses promesses en termes d'autonomie ou de longueur de piste de décollage, et le soft embarqué est apparemment une catastrophe.
Ceci dit aux USA ils peuvent espionner les accords commerciaux en tout quiétude, faire des offres totalement contraire aux accords internationaux au point de faire bondir l'ITC (et dieu sait qu'il en faut) - forcément ca aide à vendre un produit. Surtout qu'ils estiment le coup de développement et mise en service total du F-35 à 1000 milliards de dollars aujourd'hui (on a déjà éclaté les 400 Milliards en dev pur), il faut bien qu'ils rentabilisent.
Pour en revenir au Rafale, suite à la démonstration en Libye qui a infirmé pas mal de rumeurs qui couraient sur lui (rumeurs initiées par une puissance alliée de longue date et fervente défenderesse de la démocratie) et du coup le carnet de commande commence à se remplir pas mal.
L'astuce (100% légal, je ne sais pas car je ne me suis pas renseigné à fond dessus vu que ça ne m'interesse pas pour moi, mais c'est un classique que j'ai déjà vu) consiste à filer la gérance à papa/maman (ou autre qui n'est pas toi) et être salarié "normal" avec un CDI bien comme il faut…
Oui enfin en cas de pépins, si le gérant de droit est requalifié en prête-nom (ie considéré comme un gérant de paille), le gérant de fait (ie celui qui dirige vraiment l'entreprise) se prend un redressement de charges sociales pas piqué des hannetons.
Par contre les deux gérants (de droit et de fait) ont les mêmes responsabilités au niveau pénal.
C'est très mal vu et généralement puni quand on se fait prendre (de façon générale, en France faut pas chercher à contourner l'URSSAF)
Et pourtant, j'ai retrouvé hier un serveur Debian bloqué sur /etc/init.d/opsview start et ssh n'était pas démarré…
Attention, le fait qu'il soit possible d'écrire des scripts propres ne veut pas dire que tous les scripts sont propres.
Même sous systemd si je suis assez bête pour créer un service qui fait "while 1" avec un timeout à 0 et que je rend tout mon boot dépendant strictement de la fin de l’exécution de ce service - ben mon boot va figer.
Pour freezer le boot d'un systemd il faut y aller, alors que sous les inits classiques il faut faire attention pour éviter toute possibilité de freeze. C'est un plus de systemd (mais qui a un prix au niveau logs/processus/mémoire) mais clairement pas une exclusivité.
Ceci dit quand on commence à définir des scopes et des slices à la mano, on a vite fait de faire des boots qui freezent. (Peu de gens joueront à ce jeu. Certes)
Et surtout avec systemd, ça bloquera pas la fin du boot de l'OS…
Autant les logs activé dès les premières phases du boot je suis assez fan, autant ça fait longtemps que le plantage/le freeze d'un daemon au démarrage ne bloque plus le boot à moins qu'il ne soit strictement nécessaire (c'est clair que si lo plante, ou si le FS échoue le montage en RW c'est foutu - mais c'est le cas pour tout le monde.)
L'immense majorité de systèmes d'init de nos jours font du démarrage parallèle et sont capables d'envoyer des SIGTERM/SIGKILL à un daemon qui reste bloqué. Ca fait des années que tous les BSD ont ce type de système, et même sous Debian (pourtant gros partisans du SysV init jusque très récemment) depuis Wheezy on a tout ce qu'il faut.
Le kernel Linux n'est sans doute pas la chose à laquelle il est techniquement le plus facile de contribuer.
Mauvais exemple, il est très très facile de contribuer au kernel en temps que débutant. Le nombre d'aspects même fondamentaux du kernel qui ont été chamboulés par un étudiant universitaire première année (notamment gestion mémoire, priorisation des processus, ordonnancement etc.) est considérable. J'étais en première année, avec moins de 6 mois de C dans les pattes quand j'ai participé au module smbfs, pendant qu'un autre étudiant pas meilleur que moi écrivait un pilote pour la prise en charge du retour de force sous Linux.
Si tu as un sujet qui intéresse, même si tu est nul en C, tu vas avoir pleins de contributeurs qui vont te prendre par la main et t'aider à mener ton truc à terme.
Bon sur certains sujets tu te fais allumer (genre changer le code des VT), mais en général le kernel Linux c'est plutôt sympa, même avec les newbies. Honnêtement c'est beaucoup plus facile d'aller dans le Kernel pour écrire un petit module rigolo que d'aller sur la glibc, DBus ou tout un tas de truc Gnome… (Et Xfree a "disparu", mais la il fallait avoir le cuir du dos bien tanné pour rentrer.)
La liberté d'un logiciel, c'est une techniquement question de licence, pas de complexité plus ou moins grande du code concerné.
Ça se discute, la liberté c'est surtout la capacité technique et légale de pouvoir adapter un logiciel à ses besoins. La capacité technique peut toujours s’acquérir en signant un gros chèque si besoin est. Enfin elle pouvait avant systemd. Si systemd rigidifie encore l'OS il n'y aura bientôt plus moyen de passer outre sans créer de toute pièce une nouvelle distrib et en la maintenant. Ça fait un vraiment gros chèque là quand même. Techniquement Linux en tant qu'OS sera toujours libre, mais si il devient impossible d'utiliser cette liberté on aura quand même perdu quelque chose. En théorie je suis libre de marcher sur la planète Mars, en pratique ça me fait une belle jambe.
Peut-être. Les technos en question n'en sont pas moins libres et documentées.
Documentées il faut le dire vite. Au niveau interface déjà c'est loin d'être évident, pour systemd sur les scopes et les environnements j'en ai soupé avant que la doc ne soit claire et à jour. Pour tout un tas de trucs genre journald, même si on nous explique comment s'en servir, bien malin qui est capable de dire comment ca fonctionne aujourd'hui - et même Lennart ne doit pas savoir comment ca fonctionnera dans six mois.
Par contre coté mécanique, les entrailles de la bête sont en constante évolution. C'est tous les jours une surprise. Un jour on fait un hold-up sur les cgroups, le lendemain on rajoute un démon NTP - tiens on a encore changé le format interne de networkd etc. La roadmap de systemd ressemble à un mauvais trip sous acide, j'aimerai vraiment pas avoir besoin de faire un dev spécifique pour cet init (vous savez le genre de trucs pour faire fonctionner une interface ou un périph très peu utilisé au sein de la communauté systemd…)
Et pour celui s'intéressant au basses couches du système, je ne doute pas qu'il saura s'adapter.
Ben écoute personellement, étant quelqu'un pour qui les couches basses du systèmes sont à la fois mon gagne pain, mon domaine d'expertise et ma passion - je ne te cacherai pas que j'ai des doutes. Je passe autant de temps que possible sur systemd (c'est à dire environ 10h par mois, j'ai une prod à faire tourner, d'autres trucs à surveiller et une vie sociale déjà bien assez maigre) et j'ai plus l'impression de me faire distancer par systemd que d'apprendre à le maitriser.
Ça va foutre des mainteneurs de paquets au chômage, ça.
C'est ce que se disait IBM avec System/370 - compatibilité maximale avec l'existant (System/360) et prise en compte bas niveau des hiérarchies pour éviter les émulateurs à la con et les compilations depuis les sources.
Ah, la terminologie "System 370 compatible" - si vous avez un dino sous la main, demandez-lui de vous raconter. C'est drôle…
C'est ce que c'est dit Multics, avec ses répertoires fixes et son unique langage de programmation PL/I. Le bas niveau (gestion I/O et mémoire) étant écrit en assembleur et ne devant jamais être accessible à qui que ce soit autre que les fabriquants. Unix ne serait pas ce qu'il est sans toutes les erreurs de Multics.
Netware/ZenWorks est un bel exemple de truc qui aurait vraiment pu marcher. Quel dommage que les protocoles routables aient gagnés la guerre. Au moment ou Novell s'est réveillé et a commencé à rendre leur protocole routable (au début avec du tunneling) ben il y avait plus personne.
Dans le genre il y en a eu un paquet d'autres… Qui ont fini par se vautrer aussi, il faut croire que l'informatique n'aime pas les carcans et les structures rigides.
Ceci dit j'ai toute confiance en Lennart pour réussir avec brio là ou IBM, Digital, le MIT, Novell et tant d'autres ont échoués, mais bon si j'étais mainteneur de paquet je commencerai pas ma reconversion immédiatement quand même.
Vu que le blog existe depuis 5 ans, il n'y a pas une prescription à 3 ans ?
C'est deux ans après avoir découvert l'infraction si je me souviens bien.
Je doute que "parisienne" seul puisse être déposé.
On peut déposer "La Parisienne", d'ailleurs une rapide recherche INPI remonte des quantités non négligeables de marques "La Parisienne" (dont en plus plusieurs se marchent sur les pieds au niveau des classes enregistrées) - mais très honnêtement à part protéger le logo ça doit pas faire grand chose.
Le mot étant un nom commun, utilisé ici dans un cadre descriptif (incroyable, le blog d'une parisienne qui s'appelle "The Parisienne") je ne vois pas trop comment on peut la condamner à quoi que ce soit. A noter par ailleurs que "La Blogueuse Parisienne" et "Miss Parisienne" sont également des marques déposées dont je me demande sincèrement combien de temps ça tiendrait en tribunal.
Également il y a 172 marque enregistrées avec le mot "Parisienne" pour les classes 16, 41 et 35 Donc cinq marques "La Parisienne" dans les 100 premier résultats. Je crois qu'on va pouvoir dire que le terme "La Parisienne" pour faire de l'édition et de la publicité n'est pas discriminant.
Curieusement si "La Parisienne" doit être horriblement complexe à défendre, "The Parisienne" par contre possède un caractère distinctif assez fort (avec son "The"), et devrait donc être plus facile à protéger (en toute relativité, ca doit quand même tenir de la gageure).
Je doute que menacer de 20k€ d’intérêt soit légal.
C'est tendu.
D'un coté dans une optique "Business as usual" c'est une façon très répandue de dire "On t'a signalé que tu violais notre droits des marques, tu as continué, on monte d'un cran la pression"
D'un autre coté compte tenu du fait que la destinataire du message est une particulier pour qui une telle somme est très élevée, ça peut être assimilé à une tentative d’intimidation et/ou d'extorsion.
Mais très honnêtement sur ce coup là seul le batonier peut décider.
ce genre de choses ne peut changer que s'il y a un large consensus de la communauté qui reconnaît un problème et veut le résoudre, et pour l'instant je n'ai pas l'impression que ce soit le cas.
Pour ma part je pense que le problème est identifié, que la communeauté veut le résoudre et que c'est la source de ce que tu appelles le "vitriol". Si l'on en croit ce sondage : https://linuxfr.org/sondages/vous-avez
On a environ 65% de la population de linuxfr qui avait entre 26 et 45 ans en 2008 (40.8+13.6+10.8 (oui parce que si vous vous identifiez à un highlander sans être né entre 1973 et 1985 il faut songer à consulter)) aujourd'hui ils ont donc entre 30 et 50 ans. Il s'agit de la génération informatique, de la seule vraie génération informatique, coincée entre les "comprend rien" et les "LOL achète un mac avec ton iphone". Ca ne veut pas dire que tous les membres de cette génération sont bon en informatique (très loin de là) ni que tous les membres des autres générations sont nuls en informatique (très loin de là aussi), mais dans l'ensemble cette génération a une vision assez pertinente de ce qu'est l'informatique. Sur un site plutôt pointu comme Linuxfr (même si le niveau baisse inexorablement - c'était mieux avant toussa), qui a tendance a attirer des gros calibres du monde informatique, cette vision est généralement assez abrupte. Par abrupte je veux dire qu'il faut un certain bagage pour pouvoir prétendre rentrer dans certaines discussions.
Je me suis fait violamment calmer sur des discussions sur Scheme/Racket et sur Erlang qui sont pourtant des langages peu courants. Généralement ca se passe de la façon suivante, on voit un débat sur un sujet que l'on pense connaitre, on essaye (en toute bonne foi, sans même chercher à troller) de participer et généralement on ne fait que démontrer avec brio que l'on avait même pas compris le sujet de la discussion. Ce qui entrainne généralement une magnifique séance de X contre un, ou X est égal au nombre de participants au débat sauf nous.
Est-ce que ca pique ? Oui. Est-ce que ca donne envie d'envoyer tout le monde ballader en de passer en mode insulte ? Oui. Est-ce qu'il serait souhaitable de changer ce comportement ? Non.
Lors d'un débat sur un point technique B (donc avant C) entre tout un tas de personnes qui n'auraient pas forcément eu l'occasion de se croiser autrement, il n'y a pas trop de place pour la pédagogie. Si tu as le niveau nécessaire tu contribues au débat, si tu ne l'as pas tu sors.
En quoi est-ce souhaitable comme situation ? Et bien Linuxfr réussit à éviter assez bien ce que j'appelle les commentaires amazon. C'est à dire les commentaires de type "J'ai essayé, ca marche pas, c'est nul", ou encore les mecs qui nous chantent les louanges de PHP pendant des heures dans une news sur Javascript ou Ruby.
Un autre syndrome que l'on évite également est celui du "ca se fait en deux lignes de Perl". C'est à dire dans une news ou un journal il y a un débat sur une nouvelle fonctionnalité du langage ou de l'application et sur comment l'utiliser proprement, et là un commentaire va signaler que la fonctionnalité n'a rien de nouveau, qu'elle existe dans un autre langage qui n'a rien à voir depuis 1987 et que dans ce langage c'est trivial. Ce commentaire a des chances non négligeables de se retrouver à -10 sans une seule explication. Pourquoi ? Parceque
a) Les gens qui débattent sont (souvent) au courant
b) Le commentaire n'apporte rien au débat en cours
c) C'est bien beau de pouvoir solutionner un problème en deux lignes de Perl, mais bon là on est en train de décrire un ordonanceur système, donc le Perl ca va pas être possible.
Après il y a le mec qui s'accroche. Il fait un commentaire à coté le de la plaque et se prend un -10, il surenchérit d'un autre commentaire disant que son premier commentaire à coté de la plaque est factuellement vrai (ce que personne ne conteste) et se reprend un -10, il hurle à la cable contre lui et se prend un troisième -10. Strike, batteur éliminé.
Celui là je comprend qu'il soit un peu ennervé (je le comprend d'autant mieux que je suis pas totalement certain de pas avoir été lui une fois ou deux.)
Maintenant ce système d'amélioration du ratio signal/bruit n'est pas parfait. Il a quelques effets vicieux.
Le premier effet vicieux est le rebond. Le rebond est un effet qui se déclenche quand une bonne ame se dévoue pour essayer de faire de la pédagogie et cherche à expliquer à une personne pourquoi il se prend -10. Dans le cas des deux lignes de Perl par exemple on va avoir une personne qui va expliquer que la fonctionnalité Perl n'apporte rien dans le cas présent. Magie de la lecture en diagonale, de l'énnervement et de la mise en valeur des posts non lus, au moins un perliste va lire "la fonctionnalité Perl n'apporte rien" et zapper la partie "dans le cas présent". Et là vous pouvez aller chercher le pop-corn parceque ca va être un match magnifique entre les initiateurs du débat original qui vont chercher à recentrer le débat sur le problème qui les interresse, les pro-perl gonflés à bloc qui vont pas laisser leur langage favori se faire maltraiter de la sorte, les anti-perl qui verront l'occasion de régler certains comptes et les pédagogues (dont le pédagogue original) qui vont chercher à expliquer d'abord calmement, puis violamment que c'est PAS CA DONT ON EST EN TRAIN DE PARLER BOR#@!
Le second effet vicieux est l'auto-débat. Un auto-débat est un débat qui se met automatiquement en place d'une façon prédéfinie si vous essayer d'aller à l'encontre d'un mouvement général. Par exemple : on annonce le support de l'UTF-8 sur tel ou tel système de fichier ou outil système ou terminal. Aujourd'hui je me retiens, mais avant j'aurais eu tendance à dire que l'UTF-8 (ou 16 ou 32) au niveau système c'est idiot - pour la simple et bonne raison qu'il existe en UTF-X des caractères ou des suites de caractères invalides, et que ca ne me parait pas une bonne idée de permettre à un système de fichier de pouvoir contenir des noms de fichiers avec des caractères invalides dedans, généralement j'ajoute qu'un codage 16bits strict est probablement plus pertinent au niveau système. Quelque soit le nombre de précautions oratoires prises, le débat va virer ASCII vs UTF-8 et au moins une personne dira qu'il en a rien à foutre du Quenya et/ou du Klingon.
les auto-débats existent sur IPv6, systemd et ip/ifconfig principalement. Il y en avait un sur XML mais il semble en voie de disparition. Il s'agit généralement de sujets sur lesquels il y a un consensus assez fort (soit sur le site, soit au sein de la communeauté libre) et sur lesquels les chasseurs de karma se ruent.
Le troisième effet vicieux est sur tout ce qui touche aux licences et à la notion d'attribution (comme par exemple remettre un prix à un mathématicien). Ce sont des notions fondamentales du logiciel libre, et honnêtement toute tentative de discussion sur le sujet se finit soit en une salve de -10 pour un des deux bords, soit en troll sur la notion de plus ou moins libre.
C'est celà qui a explosé au nez de Keyser, involontairement ou non il a remis en cause la notion d'attribution et de reconnaissance, à partir de la on ne pouvait plus rien pour lui. Il est entrée nu et tartiné de sauce barbecue dans la fosse aux lions pour précher les bienfait d'une alimentation végétarienne. L'attribution est le principe fondateur de toute licence libre sérieuse (Toutes mes excuses à MM. Kemiyatorn et Hocevar), quand à la reconnaissance c'est le seul paiement demandé par une grosse majorité des contributeurs du libre. Dire "L'attribution et la reconnaissance c'est nul" implique nécessairement que "Le libre c'est nul" - il ne faut donc pas s'étonner de prendre des clauqes quand on le clame sur un site qui s'appelle LinuxFR…
Si tu veux fabriquer toi même de l'explosif dans ton garage le mieux c'est certainement d'employer du sucre glace et du chlorate de sodium
Ou alors tu va gentiment en acheter en vente libre dans la station service la plus proche. Mais bon un explosif n'est pas une bombe. Fabriquer un explosif c'est pas très difficile (de la farine ou du chocolat instantané en poudre peuvent faire des explosifs convenables) , fabriquer une bombe par contre c'est pas la même.
Ceci étant dit, les amateurs qui font des explosifs dans leur garage font généralement une seule victime (mais c'est casse pied parce que ça réveille le voisinage.)
Rappel : on peut forker les vieux projets, et les maintenir, vive le libre.
C'est vrai pour une grosse majorité de projets, mais au niveau des systèmes d'init c'est nettement plus compliqué que ça. Forker un système d'init revient quasiment à forker l'ensemble de la distrib "pour de vrai" (ie on est pas en train de rajouter deux applis à une debian pour en faire une distrib spécialisé).
Ça demande une quantité de boulot, d'utilisateurs et de machines différentes absolument démesurée juste pour pouvoir tester le strict minimum de situations. Bref ça fait quasiment un job à plein temps juste pour un résultat médiocre.
Petit avant propos qui va faire mal au karma :
Oh les gnomes, c'est pas bientôt fini de moinsser Zenitram comme des gorets ? On est à j+2 sur une digression de définition issue d'un journal semi-trollesque qui a été posté un vendredi. Je rappelle que selon la convention de genièvre les journaux trolls du vendredi servent justement de caisse à savon à Linuxfr. Allez plutôt sur http://en.wikipedia.org/wiki/Soapbox voir ce qu'est une caisse à savon.
Pour moi, être libriste c'est être pour toute analyse, modification, rediffusion. Les 4 libertés du libre élargies à tout (et pas comme Stallman, qui bizarrement n'a rien à foutre du libre pour de la doc, cf par exemple la GFDL avec sections invariantes)
Rien dans le le librisme ne s'oppose aux caméras, ni ne va faire dire que les caméras c'est des méchants trucs contre la démocratie.
Une fois de plus la question n'est pas de savoir si le libriste doit être automatiquement pour ou automatiquement contre les caméras de surveillance, on peut être libriste pour, contre ou sans opinion définie assez facilement. Le problème est que le libriste, justement parce qu'il cherche à protéger les 4 libertés fondamentales du logiciel libre se doit de se poser la question.
Une fois de plus toutes les positions sur les caméras sont compatibles avec le librisme sauf la position "j'en ai rien à foutre".
On est tout à fait libre de penser que la situation ou une entreprise (ou une instance gouvernementale) vous refusera un travail ou autre en raison d'enregistrements fait à votre insu ne se produira jamais, ou de penser comme le fait RMS que toute information personnelle non strictement nécessaire à la réalisation d'un projet ne devrait jamais être divulguée sans l'accord de l’intéressé. Et toutes les positions entre les deux.
Néanmoins la question de la surveillance peut avoir un impact fort sur la capacité à tirer parti des 4 libertés du logiciel libre (Par exemple faire de la crypto en Chine, c'est pas forcément évident, même si ça s'assouplit lentement depuis 2000). Et de fait je ne vois pas un libriste, qui a à coeur de défendre les 4 libertés, éluder la question des caméras.
[^] # Re: Bienvenue en 1995 !
Posté par Kaane . En réponse au journal Frugalware: Configuration du parefeu . Évalué à 7.
Il ne font pas la même chose. Pour être exact iptables/nftables peuvent faire tout ce que fait ufw, mais la réciproque n'est pas vraie.
Mais le problème n'est même pas la. On a une personne (seb95) qui commence son article en disant :
Traduction : pour les débutants et les gens qui ne veulent pas mettre les mains dans le cambouis, on a déjà réglé le problème.
Sous entendu : le reste de l'article est destiné à des utilisateurs avancés ou à des gens qui veulent mettre les mains dans le cambouis.
Et là on se rend compte qu'il s'agit de règles préconfigurées, et tout ce qu'il y a à faire pour une personne qui voudrait autoriser les fonctions ssh, ou activer les téléchargements torrent, doit juste savoir lire et retirer un caractère #.
Niveau simplicité, c'est clairement au dessus de ufw.
En plus seb95 prend bien le temps de faire la mise en contexte, d'expliquer ce qu'il fait et ne fait aucun prosélitisme pour sa solution. C'est un tutorial rapide certes, mais tout à fait neutre de ton.
J'en déduis donc que pour Sébastien Maccagnoni-Munch c'est l'idée même que quelqu'un puisse avoir d'autres besoins que le siens ou puisse vouloir faire autrement que lui qui est fondamentalement ridicule et méprisable. Le fait de voir une telle attitude dans un cadre simple sur un exemple isolé me permet réellement de mieux comprendre certains projets open source.
[^] # Re: Bienvenue en 1995 !
Posté par Kaane . En réponse au journal Frugalware: Configuration du parefeu . Évalué à 2.
Merci tu viens de m'expliquer instantanément le pourquoi de Gnome 3 systemd et du masquage du terminal dans de nombreuses distrib.
(j'ai quand même inutilisé ton post parceque je suis un aigri.)
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Kaane . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 5.
En n'importe quel binaire, on peut faire exactement comme pour ton "texte"
Non, on ne peut pas. Sur un fichier texte avec des corruptions (mettons 3% de caractères soit remplacés, soit tronqués, soit illisibles) on arrive encore humainement à faire les corrections qui vont bien si c'est possibles.
Sur un fichier binaire, surtout comme ceux de journald avec une entête qui défini la taille de l'objet, si il manque un seul octet c'est la mort.
Les mecs qui écrivent journald, disent eux même que c'est extrêmement compliqué de corriger un fichier binaire, que ce soit automatiquement ou humainement.
Da façon générale si j'ai une corruption unique dans un fichier texte, je vais avoir une ligne de logs inexploitable. Si j'ai une unique corruption dans un fichier au format journald, ca peut aller jusqu'à faire que toutes les entrées suivant la corruption sont inexploitables. (Cas de corruption de tag)
qui n'a pas l'air de déranger ceux qui choisissent systemd (et ils sont nombreux), sans doute parce que les avantages de leur format compensent les quelques désavantages.
Je n'ai pas dit que le format binaire n'avait que des défauts et qu'il était idiot. Néanmoins dire que le format binaire, surtout tel que choisit par journald présente exactement la même résistance à la corruption que les fichiers, chose que même les créateurs du format réfutent, est une connerie.
On peut parfaitement préférer journald à syslog, c'est une question de choix, de besoin et de gouts personnels. Mais dire que le format de logs texte est extrèmement résistant à la corruption alors que le format journald est extrèmement sensible à cette même corruption est un fait. Ne pas être d'accord avec l'impact de la corruption sur les journaux journald, c'est comme ne pas être d'accord avec le fait que 2+2=4. Tout le monde est libre d'avoir son opinion, mais là ca ne va pas changer grand chose au résultat.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Kaane . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 2.
Qu'est-ce qui te fais dire que ce n'est pas le cas des log binaires de systemd ?
Zbigniew Jedrzejewski-Szmek et Lennart Pottering en l'occurence.
https://bugs.freedesktop.org/show_bug.cgi?id=64116
The only way to deal with journal corruptions, currently, is to ignore them:
Yupp, journal corruptions result in rotation, and when reading we try to make the best of it. they are nothing we really need to fix hence.
La corruption d'un journal binaire est très compliqué à corriger, surtout si des extensions sont activés ou si c'est un tag qui est altéré.
Dans le cas de l'altération d'un tag, toutes les entrées à la suite du tag sont bonne à mettre à la poubelle.
A noter que jorunald n'a pas d'équivalent fsck au boot ou de controle continue. Il se peut donc parfaitement qu'il continue à écrire dans un journal corrompu, et ce même après un reboot. Je recommande vivement à tous les utilisateurs systemd qui utilisent journald de faire un renvoi des logs vers un logger fiable, et de lancer journalctl --verify de temps en temps.
A noter également qu'un journal parfaitement valide, mais qui n'aura pas été indexé, ou pas tagué (par exemple suite à une perte brutale de l'alimentation) sera lui considéré comme corrompu, et sera donc remplacé par un nouveau fichier.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Kaane . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 6. Dernière modification le 26 septembre 2014 à 22:36.
Alors je reprends lentement.
Phase 1:
Renault déclare dans son post qu'il est normal que l'init utilise des fonctionnalités spécifiques du noyeau, vu que c'ets un composant proche du noyau
Phase 2:
Je répond que l'init n'est pas plus proche du noyau que n'importe quel autre processus qui tourne en root.
Phase 3:
Renault surrenchérit en disant que l'init est bien proche du noyau car c'est le noyau qui fournit les abstractions qui permettent de gérer entre autres, porcessus et cgroups
Phase 4:
Je signale tout d'abord que le noyau ne fournit pas d'abstractions (je reviens dessus dans un instant) mais des interfaces et que le noyau fournissant de façon générale toute les interfaces, dire qu'un processus est privilégié parcequ'il a besoin d'interragir avec le noyau est pas franchement discriminant.
Je reste sur ma lancé, l'init processus comme les autres qui n'a ni plus ni moins de raisons que les autres d'utiliser des fonctionnalités spécifiques de Linux.
C'est sur ce post là que tu interviens. Je n'ai pas encore commencé à taper sur systemd (ce que je ferai plus tard, suites aux provocations de Barret Michel)
Tout ce que j'ai dit pour l'instant c'est que au niveau des interractions avec le kernel, l'init est un processus root comme les autres.
Maintenant ton propos :
a) je n'ai jamais dit que /proc était fait par l'init. J'ai même dit à plusieurs reprise que l'init n'avait pas plus de prise sur les abstractions que n'importe quel processus root. Si l'init était nécessairement à l'origine du /proc, je me serais abstenu.
b) L'abstraction n'est pas faite directement par le kernel. Le kernel (si on a les bonnes options de compilation) peut, si on lui en fait la demande créer une interface secondaire pour le suivi des processus, réserver une zone mémoire, et créer une abstraction filesystem sous forme de pseudo-device mappé en ram et présentée en userland. Dire que cet abstraction est fournie directement par le kernel c'est comme de dire que l'abstraction /media/vcdrom de montage d'une image iso est fournie directement par le kernel. A ce compte là tout est fourni directement par le kernel. Ce que l'on considère directement fourni par le kernel se sont les interfaces, c'est à dire des fonctions userland pour envoyer des commandes au kernel et recevoir ses réponses sans passer par des drivers. Et niveau drivers /proc est plutôt chargé (ram mapping + pseudoFS + moniteur).
La gestion de processus par le kernel, à savoir l'attribution de PID, l'ordonnancement, l'attribution mémoire et son mapping, présentation des appels systèmes d'attentes etc, n'a rien à voir avec la gestion userland des processus. Une fois de plus je ne fais que répondre à Renault qui me dit que l'init est proche du noyau car il participe à la gestion des processus. Je ne fais que lui répondre qu'il ne participe pas plus à la gestion des processus que d'autres processus lancés en root qu'on va avoir du mal à considérer comme proche du noyau (psDoom franchement…)
Je comprends que tu n'aimes pas les gens qui n'aiment pas systemd, mais il faut lire un minimum les threads auquels tu réponds. A l'instant ou tu réponds dans le thread je n'ai pas dit un mot sur systemd ni spécifiquement en tant qu'init, ni généralement en tant que framework. La seule et unique chose que je défends est que vis à vis des interractions avec le noyau, l'init a exactement les mêmes accès et besoins que n'importe quel autre processus.
Deuxièmement quand on attaque une personne sur la cohérence de ses arguments, il faut un minimum vérifier que les arguments qu'on lui prête sont véritables.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Kaane . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 4.
Euh, /proc n'est pas directement fourni par le kernel ?
C'est un pseudo file-systeme, si tu ne le montes pas ca ne dérange en rien le kernel et tu peux quand même intéragir avec les processus (mais c'est plus compliqué.)
C'est quoi le rapport entre la gestion des processus et le system d'init ?
Là quand même, un système d'init se doit un minimum de pouvoir lancer au moins un processus, de vérifier qu'il s'est bien lancé et de réessayer de le lancer un peu plus tard le cas échéant. Et puis l'init est supposé surveiller tous les processus en dessous ou rataché à lui pour éviter un remake de la nuit des morts-vivants…
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Kaane . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 9.
"dans tous les sens" ? Carrément ? Ça veut dire quoi pour toi dans tous les sens ?
Ben le login, le réseau, les cgroups, certains paramètres LXC, certaines fonctionnalités acpi/apm, et bien entendu toute la couche d'interface DBus de discussion avec les processus (et j'en passe). Je pense que dans tous les sens est assez approprié dans ce cas.
Sérieusement ? Va falloir réexpliquer l'intérêt de l'utilisation des cgroup dans l'init ? T'es juste ridicule.
Oui il va falloir réexpliquer encore et encore. Par exemple l'intéret qu'il y a de lancer un résolveur local unique dans un cgroup. Il existe en une seule instance, le mapping service/pid est évident, il ne spawnera jamais de fils, son empreinte mémoire et CPU ne varira pas et si je veux de la sécurisation il faudra de toute façon que je passe par des MAC. Donc pourquoi le caller dans un cgroup et exiger les droits root pour pouvoir modifier sa config ?
Mais surtout pourquoi m'obliger à passer par systemd pour gérer mes cgroups. Contrairement à ce que tu impliques je connais et j'utilise les cgroups depuis un bon moment, et par exemple je veux que certains de mes services soit dans le même cgroup. Avant systemd c'était très simple, avec systemd à jour avec les slices et les scopes c'est une horreur (de l'aveu de Lennart lui même, c'est une des raisons pour laquelle il est en train de modifier complètement les intefaces cgroup).
Les cgroups sont très interressant dans certains cas, à savoir tague des processus qui sont potentiellement capables de faire spawner d'autres processus, ou suivre une instance spécifique d'un service que l'on lance en 25 exemplaires. Mais pour une majorité de cas c'est juste un overhead dont on aurait pu se passer.
ces logiciels peuvent toujours se servir des cgroups
Dans le nouvelle version de systemd avec lock exclusif sur les cgroups ca n'est possible que si
a) le processus en question possède les libs DBus et systemd qui vont bien
b) le processus en question a les droits root
c) la gestion des cgroups voulues par les processus n'est pas en conflit avec le tagging cgroup de systemd.
ces logiciels ne se sont JAMAIS servi des cgroups
Magie du code respectueux de la philosophie Unix, même si ces logiciels n'ont jamais implémenté de fonctionnalités cgroups en interne, il était tout à fait possible pour un admin de gérer et de faire gérer par ces processus des cgroup. En d'autres termes c'était flexible. L'inconviennient de systemd est que désormais les cgroup ne peuvent plus être appelés qe d'une seule façon et depuis un seul point d'entrée. En plus la modification d'appartenance d'un processus à un cgroup avant de le relancer est devenue une tache complexe. (Modifier dynamiquement la slice d'une unit est loin d'être uen sinécure) etc.
c'est une problématique d'intégration. L'administrateur d'un site d'e-commerce peu vouloir gérer ça différemment de celui qui fait de l'hébergement. Donc c'est forcément au niveau de l'intégration dans l'OS que ça va devoir se gérer
Donc le fait que systemd oblige tout le monde à utiliser le même tuyau de la même façon est une pénalité non ?
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Kaane . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 6.
Et en quoi c'est différent avec systemd ? Il y a dans le noyau des if (init == SYSTEMD) ?
J'ai jamais dit qu'il y avait des différences avec l'init systemd. C'est bien le truc, il n'y a aucune raison pour que l'init soit considéré comme "proche" du noyau, du moins ni plus ni moins que n'importe quel autre processus.
Par contre la nébuleuse systemd elle, en mettant des locks exclusifs dans tous les sens créé une vraie différence avec le déroulement traditionnel d'un init. Ca apporte de bonnes choses et des choses moins bonnes, mais ça change réellement la donne. Systemd en tant que gestionnaire système (c'est à dire tout ce qui va au delà de l'init) change complètement les interactions avec les processus.
Pour ce qu'il voulait dire, je pense qu'il dit que c'est cool de voir des init qui utilisent toute la puissance du noyau sous-jacent
Et ce que je veux dire c'est qu'il n'y a pas de raison que ce soit plus cool pour l'init que pour n'importe quel autre processus. A part le fait qu'il ne doit pas mourir sous peine de faire s’arrêter le système, l'init est un processus comme les autres. Je ne vois pas en quoi c'est un vrai plus que l'init tire partie des fonctionnalités avancées du noyau, du moins pas plus que si il s'agit d'Apache, de MySQL ou de Xorg.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Kaane . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 10.
Le but de l'init est d'initialiser tout le système
Tout dépend de ce que tu appelles le système. Si tu parles de la partie userland, l'init peut effectivement mettre en place l'ensemble du userland, mais ce n'est en rien une obligation. Un certain nombre d'autres éléments peuvent s'en charger. L'init va lancer le premier processus qui a son tour peut lancer d'autres processus. Sur des terminaux type NCD l'inti va juste lancer un listener qui lui lancera le reste des applications en fonction des demandes.
Par contre pour que l'init puisse se lancer il faut que le système non userland soit déjà dans un état très avancé.
Pour faire tout ceci correctement l'init est proche du noyau car c'est ce dernier qui offre des abstractions pour gérer des processus
Le kernel n'offre pas des abstractions pour gérer les processus, il fournit des interfaces userland. Généralement ces interfaces sont utilisées ensuite pour créer des abstractions (typiquement le pseudo file system /proc ). Mais l'init (traditionnel, systemd étant en train de changer la donne à ce niveau là) n'a aucun avantage au niveau de ses interfaces ou des pseudo-fs comparé à n'importe quel processus avec les droits root. D'ailleurs de nombreux logiciel de gestion des processus (de nice à psDoom) bypassent complètement l'init.
De façon générale le noyau offre toute les fonctionnalités possibles et imaginables de l'OS. C'est le seul à pouvoir attribuer de la mémoire, du temps d'éxécution, un PID, des droits d'accès sur les devices ou les pseudo-devices, des changements de contexte etc.
On pourrait dire que pour faire son travail correctement Postgresql est proche du noyau parceque c'est ce dernier qui offre la ram et les accès disque dont il a beson pour faire son travail correctement. Ou encore que ping est proche du noyeau parceque c'est lui qui offre les accès réseau et les abstractions ICMP dont il a besoin.
L'init est juste un processus comme les autres, lancé en premier et avec les droits root. Il n'est pas plus "proche" du noyeau que n'importe quel autre processus. Le fait que systemd commence par fermer la porte à double tour pour s'assurer que l'on ne puisse pas lui piquer le contrôle des cgroups ne change rien à celà. C'est exactement comme si un init traditionnel bloquait le port 80 en se mettant dessus.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Kaane . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 3.
(et un moment, Ubuntu utilisait logind sans systemd)
Non, Ubuntu utilisait logind sans utiliser l'init systemd, mais faisait quand même appel à une palanqué d'outils systemd, bidouillés à fond les ballons pour que ca marche. Les libsystemd-* qui permettent plus ou moins d'avoir les fonctionnalités systemd même quand systemd n'est pas lancé en tant qu'init avec un PID 1
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Kaane . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 10.
Personnellement je trouve douteux la démarche de vouloir un système d'init portable qui est par essence un composant proche du noyau
GNI ???
Le système d'init un composant proche du noyau ?
Le système d'init est un jeu d'outils pur userland. Je suis conscient qu'avec la main mise de systemd sur tout un tas de fonctions qui n'ont pas grand chose à voir avec l'init on peut être dans la confusion, mais /bin/bash est un init tout à fait convenable - il suffit de faire rw init=/bin/bash dans grub pour s'en rendre compte.
De même une ligne de commande qui va simplement monter les disques pour ensuite lancer (même pas en mode démonisé) un petit serveur genre apache statique, ça se fait très bien.
L'init traditionnel n'a aucun rapport avec le noyau, du moins pas plus de rapport qu'un utilisateur root qui lance des commandes depuis un terminal.
[^] # Re: Pourquoi je vois les captures, sous Firefox, justement ?
Posté par Kaane . En réponse à la dépêche Firefox 32. Évalué à 10.
Le truc c'est que quand tu veux être une autorité de certification, tu est tenu d'avoir un audit permanent, contrôler qui a le droit de faire quoi, qui le fait, qui a les clefs, et qui s'en sert à chaque action est la définition même d'une autorité de confiance.
Tu confonds deux types distincts d'audit, un audit technique et un audit production. L'audit technique d'OpenSSL a péché assez largement, mais son audit production est plutôt bon (on sait qui fait quoi, quand il le fait, les droits de commit sont plutôt bien validé etc.)
Une autorité de confiance n'est pas une organisation qui peut demander aux utilisateurs de reprendre leurs transactions d'il y a 15 jours pour les patcher.
Je pense que CACert a très largement sous-estimé la charge de travail pour devenir une autorité de certification et que le boulot qu'elle accompli aujourd'hui est de mauvaise qualité. Par mauvaise qualité je veux dire en dessous des "gros" comme Verisign qui font déjà un travail de qualité tout à fait médiocre. Pour avoir testé un certain nombre d'autorité de certification je peux te dire qu'il n'y en a pas une qui tienne la route comparé aux autorités tiers du système bancaire*, mais qu'elle sont toutes largement devant CACert.
Ca ne veut pas dire qu'une autorité de confiance communautaire ne peut pas exister, mais CACert est loin d'avoir les arguments nécessaire pour être reconnu.
A ma connaissance toutes les demandes d'inclusion ont été retirées en 2007. Tout l'historique du truc est ici :
https://bugzilla.mozilla.org/show_bug.cgi?id=215243
TLDR : La dernière fois qu'on a eu des nouvelles d'un auditeur c'était pour dire que l'organisation était chaotique, l'infrastructure en morceau, le système de validation inopérant et les relations entre CACert et les autres assureurs ou clients complètement déséquilibrées.
Depuis plus rien.
[^] # Re: mouais
Posté par Kaane . En réponse au journal La France bientôt chassée du podium mondial des vendeurs d'armes ?. Évalué à 10.
Oui enfin il se pré-vend. Il est toujours pas fini le F-35, il ne tiendra pas ses promesses en termes d'autonomie ou de longueur de piste de décollage, et le soft embarqué est apparemment une catastrophe.
Ceci dit aux USA ils peuvent espionner les accords commerciaux en tout quiétude, faire des offres totalement contraire aux accords internationaux au point de faire bondir l'ITC (et dieu sait qu'il en faut) - forcément ca aide à vendre un produit. Surtout qu'ils estiment le coup de développement et mise en service total du F-35 à 1000 milliards de dollars aujourd'hui (on a déjà éclaté les 400 Milliards en dev pur), il faut bien qu'ils rentabilisent.
Pour en revenir au Rafale, suite à la démonstration en Libye qui a infirmé pas mal de rumeurs qui couraient sur lui (rumeurs initiées par une puissance alliée de longue date et fervente défenderesse de la démocratie) et du coup le carnet de commande commence à se remplir pas mal.
[^] # Re: Intérêt financier
Posté par Kaane . En réponse à la dépêche Vivre du logiciel libre - MediaArea.net trois ans plus tard. Évalué à 5.
Oui enfin en cas de pépins, si le gérant de droit est requalifié en prête-nom (ie considéré comme un gérant de paille), le gérant de fait (ie celui qui dirige vraiment l'entreprise) se prend un redressement de charges sociales pas piqué des hannetons.
Par contre les deux gérants (de droit et de fait) ont les mêmes responsabilités au niveau pénal.
C'est très mal vu et généralement puni quand on se fait prendre (de façon générale, en France faut pas chercher à contourner l'URSSAF)
Un petit lien assez complet : http://www.legavox.fr/blog/maitre-joan-dray/gerance-paille-responsabilites-10041.htm
[^] # Re: vers la "privatisation" du système
Posté par Kaane . En réponse au journal Marque page sur l'unification possible des systèmes Linux. Évalué à 5.
Et pourtant, j'ai retrouvé hier un serveur Debian bloqué sur /etc/init.d/opsview start et ssh n'était pas démarré…
Attention, le fait qu'il soit possible d'écrire des scripts propres ne veut pas dire que tous les scripts sont propres.
Même sous systemd si je suis assez bête pour créer un service qui fait "while 1" avec un timeout à 0 et que je rend tout mon boot dépendant strictement de la fin de l’exécution de ce service - ben mon boot va figer.
Pour freezer le boot d'un systemd il faut y aller, alors que sous les inits classiques il faut faire attention pour éviter toute possibilité de freeze. C'est un plus de systemd (mais qui a un prix au niveau logs/processus/mémoire) mais clairement pas une exclusivité.
Ceci dit quand on commence à définir des scopes et des slices à la mano, on a vite fait de faire des boots qui freezent. (Peu de gens joueront à ce jeu. Certes)
[^] # Re: vers la "privatisation" du système
Posté par Kaane . En réponse au journal Marque page sur l'unification possible des systèmes Linux. Évalué à 4.
Et surtout avec systemd, ça bloquera pas la fin du boot de l'OS…
Autant les logs activé dès les premières phases du boot je suis assez fan, autant ça fait longtemps que le plantage/le freeze d'un daemon au démarrage ne bloque plus le boot à moins qu'il ne soit strictement nécessaire (c'est clair que si lo plante, ou si le FS échoue le montage en RW c'est foutu - mais c'est le cas pour tout le monde.)
L'immense majorité de systèmes d'init de nos jours font du démarrage parallèle et sont capables d'envoyer des SIGTERM/SIGKILL à un daemon qui reste bloqué. Ca fait des années que tous les BSD ont ce type de système, et même sous Debian (pourtant gros partisans du SysV init jusque très récemment) depuis Wheezy on a tout ce qu'il faut.
[^] # Re: vers la "privatisation" du système
Posté par Kaane . En réponse au journal Marque page sur l'unification possible des systèmes Linux. Évalué à 10.
Mauvais exemple, il est très très facile de contribuer au kernel en temps que débutant. Le nombre d'aspects même fondamentaux du kernel qui ont été chamboulés par un étudiant universitaire première année (notamment gestion mémoire, priorisation des processus, ordonnancement etc.) est considérable. J'étais en première année, avec moins de 6 mois de C dans les pattes quand j'ai participé au module smbfs, pendant qu'un autre étudiant pas meilleur que moi écrivait un pilote pour la prise en charge du retour de force sous Linux.
Si tu as un sujet qui intéresse, même si tu est nul en C, tu vas avoir pleins de contributeurs qui vont te prendre par la main et t'aider à mener ton truc à terme.
Bon sur certains sujets tu te fais allumer (genre changer le code des VT), mais en général le kernel Linux c'est plutôt sympa, même avec les newbies. Honnêtement c'est beaucoup plus facile d'aller dans le Kernel pour écrire un petit module rigolo que d'aller sur la glibc, DBus ou tout un tas de truc Gnome… (Et Xfree a "disparu", mais la il fallait avoir le cuir du dos bien tanné pour rentrer.)
Ça se discute, la liberté c'est surtout la capacité technique et légale de pouvoir adapter un logiciel à ses besoins. La capacité technique peut toujours s’acquérir en signant un gros chèque si besoin est. Enfin elle pouvait avant systemd. Si systemd rigidifie encore l'OS il n'y aura bientôt plus moyen de passer outre sans créer de toute pièce une nouvelle distrib et en la maintenant. Ça fait un vraiment gros chèque là quand même. Techniquement Linux en tant qu'OS sera toujours libre, mais si il devient impossible d'utiliser cette liberté on aura quand même perdu quelque chose. En théorie je suis libre de marcher sur la planète Mars, en pratique ça me fait une belle jambe.
Documentées il faut le dire vite. Au niveau interface déjà c'est loin d'être évident, pour systemd sur les scopes et les environnements j'en ai soupé avant que la doc ne soit claire et à jour. Pour tout un tas de trucs genre journald, même si on nous explique comment s'en servir, bien malin qui est capable de dire comment ca fonctionne aujourd'hui - et même Lennart ne doit pas savoir comment ca fonctionnera dans six mois.
Par contre coté mécanique, les entrailles de la bête sont en constante évolution. C'est tous les jours une surprise. Un jour on fait un hold-up sur les cgroups, le lendemain on rajoute un démon NTP - tiens on a encore changé le format interne de networkd etc. La roadmap de systemd ressemble à un mauvais trip sous acide, j'aimerai vraiment pas avoir besoin de faire un dev spécifique pour cet init (vous savez le genre de trucs pour faire fonctionner une interface ou un périph très peu utilisé au sein de la communauté systemd…)
Ben écoute personellement, étant quelqu'un pour qui les couches basses du systèmes sont à la fois mon gagne pain, mon domaine d'expertise et ma passion - je ne te cacherai pas que j'ai des doutes. Je passe autant de temps que possible sur systemd (c'est à dire environ 10h par mois, j'ai une prod à faire tourner, d'autres trucs à surveiller et une vie sociale déjà bien assez maigre) et j'ai plus l'impression de me faire distancer par systemd que d'apprendre à le maitriser.
[^] # Re: Wahou
Posté par Kaane . En réponse au journal Marque page sur l'unification possible des systèmes Linux. Évalué à 10.
Ça va foutre des mainteneurs de paquets au chômage, ça.
C'est ce que se disait IBM avec System/370 - compatibilité maximale avec l'existant (System/360) et prise en compte bas niveau des hiérarchies pour éviter les émulateurs à la con et les compilations depuis les sources.
Ah, la terminologie "System 370 compatible" - si vous avez un dino sous la main, demandez-lui de vous raconter. C'est drôle…
C'est ce que c'est dit Multics, avec ses répertoires fixes et son unique langage de programmation PL/I. Le bas niveau (gestion I/O et mémoire) étant écrit en assembleur et ne devant jamais être accessible à qui que ce soit autre que les fabriquants. Unix ne serait pas ce qu'il est sans toutes les erreurs de Multics.
Netware/ZenWorks est un bel exemple de truc qui aurait vraiment pu marcher. Quel dommage que les protocoles routables aient gagnés la guerre. Au moment ou Novell s'est réveillé et a commencé à rendre leur protocole routable (au début avec du tunneling) ben il y avait plus personne.
Dans le genre il y en a eu un paquet d'autres… Qui ont fini par se vautrer aussi, il faut croire que l'informatique n'aime pas les carcans et les structures rigides.
Ceci dit j'ai toute confiance en Lennart pour réussir avec brio là ou IBM, Digital, le MIT, Novell et tant d'autres ont échoués, mais bon si j'étais mainteneur de paquet je commencerai pas ma reconversion immédiatement quand même.
[^] # Re: Nuance
Posté par Kaane . En réponse au journal Le Parisien attaque un blog pour contrefaçon, ou comment se tirer une balle dans le pied. Évalué à 5.
Vu que le blog existe depuis 5 ans, il n'y a pas une prescription à 3 ans ?
C'est deux ans après avoir découvert l'infraction si je me souviens bien.
Je doute que "parisienne" seul puisse être déposé.
On peut déposer "La Parisienne", d'ailleurs une rapide recherche INPI remonte des quantités non négligeables de marques "La Parisienne" (dont en plus plusieurs se marchent sur les pieds au niveau des classes enregistrées) - mais très honnêtement à part protéger le logo ça doit pas faire grand chose.
Le mot étant un nom commun, utilisé ici dans un cadre descriptif (incroyable, le blog d'une parisienne qui s'appelle "The Parisienne") je ne vois pas trop comment on peut la condamner à quoi que ce soit. A noter par ailleurs que "La Blogueuse Parisienne" et "Miss Parisienne" sont également des marques déposées dont je me demande sincèrement combien de temps ça tiendrait en tribunal.
Également il y a 172 marque enregistrées avec le mot "Parisienne" pour les classes 16, 41 et 35 Donc cinq marques "La Parisienne" dans les 100 premier résultats. Je crois qu'on va pouvoir dire que le terme "La Parisienne" pour faire de l'édition et de la publicité n'est pas discriminant.
Curieusement si "La Parisienne" doit être horriblement complexe à défendre, "The Parisienne" par contre possède un caractère distinctif assez fort (avec son "The"), et devrait donc être plus facile à protéger (en toute relativité, ca doit quand même tenir de la gageure).
Je doute que menacer de 20k€ d’intérêt soit légal.
C'est tendu.
D'un coté dans une optique "Business as usual" c'est une façon très répandue de dire "On t'a signalé que tu violais notre droits des marques, tu as continué, on monte d'un cran la pression"
D'un autre coté compte tenu du fait que la destinataire du message est une particulier pour qui une telle somme est très élevée, ça peut être assimilé à une tentative d’intimidation et/ou d'extorsion.
Mais très honnêtement sur ce coup là seul le batonier peut décider.
[^] # Re: Vous reprendrez bien bien un peu d'acide fluorhydrique avec votre vitriol.
Posté par Kaane . En réponse au journal Pourquoi LinuxFr sent-il le vitriol?. Évalué à 0.
Belle démonstration par l'exemple !
Ah ben oui mais le meta-humour auto-critique non Gödelien c'est pas franchement à la portée de tout le monde aussi.
Par exemple :
Ce post est drôle mais va être inutilisé OU ALORS Ce post n'est pas drôle mais va être pertinenté.
[^] # Re: Vous reprendrez bien bien un peu d'acide fluorhydrique avec votre vitriol.
Posté par Kaane . En réponse au journal Pourquoi LinuxFr sent-il le vitriol?. Évalué à 5.
Personnellement j'aime bien la double variante troll combo shuttlepowered :
Mir ca va être deux cents fois mieux que Wayland, déjà il y a une vraie licence libre…
# Vous reprendrez bien bien un peu d'acide fluorhydrique avec votre vitriol.
Posté par Kaane . En réponse au journal Pourquoi LinuxFr sent-il le vitriol?. Évalué à 10.
Pour ma part je pense que le problème est identifié, que la communeauté veut le résoudre et que c'est la source de ce que tu appelles le "vitriol". Si l'on en croit ce sondage :
https://linuxfr.org/sondages/vous-avez
On a environ 65% de la population de linuxfr qui avait entre 26 et 45 ans en 2008 (40.8+13.6+10.8 (oui parce que si vous vous identifiez à un highlander sans être né entre 1973 et 1985 il faut songer à consulter)) aujourd'hui ils ont donc entre 30 et 50 ans. Il s'agit de la génération informatique, de la seule vraie génération informatique, coincée entre les "comprend rien" et les "LOL achète un mac avec ton iphone". Ca ne veut pas dire que tous les membres de cette génération sont bon en informatique (très loin de là) ni que tous les membres des autres générations sont nuls en informatique (très loin de là aussi), mais dans l'ensemble cette génération a une vision assez pertinente de ce qu'est l'informatique. Sur un site plutôt pointu comme Linuxfr (même si le niveau baisse inexorablement - c'était mieux avant toussa), qui a tendance a attirer des gros calibres du monde informatique, cette vision est généralement assez abrupte. Par abrupte je veux dire qu'il faut un certain bagage pour pouvoir prétendre rentrer dans certaines discussions.
Je me suis fait violamment calmer sur des discussions sur Scheme/Racket et sur Erlang qui sont pourtant des langages peu courants. Généralement ca se passe de la façon suivante, on voit un débat sur un sujet que l'on pense connaitre, on essaye (en toute bonne foi, sans même chercher à troller) de participer et généralement on ne fait que démontrer avec brio que l'on avait même pas compris le sujet de la discussion. Ce qui entrainne généralement une magnifique séance de X contre un, ou X est égal au nombre de participants au débat sauf nous.
Est-ce que ca pique ? Oui. Est-ce que ca donne envie d'envoyer tout le monde ballader en de passer en mode insulte ? Oui. Est-ce qu'il serait souhaitable de changer ce comportement ? Non.
Lors d'un débat sur un point technique B (donc avant C) entre tout un tas de personnes qui n'auraient pas forcément eu l'occasion de se croiser autrement, il n'y a pas trop de place pour la pédagogie. Si tu as le niveau nécessaire tu contribues au débat, si tu ne l'as pas tu sors.
En quoi est-ce souhaitable comme situation ? Et bien Linuxfr réussit à éviter assez bien ce que j'appelle les commentaires amazon. C'est à dire les commentaires de type "J'ai essayé, ca marche pas, c'est nul", ou encore les mecs qui nous chantent les louanges de PHP pendant des heures dans une news sur Javascript ou Ruby.
Un autre syndrome que l'on évite également est celui du "ca se fait en deux lignes de Perl". C'est à dire dans une news ou un journal il y a un débat sur une nouvelle fonctionnalité du langage ou de l'application et sur comment l'utiliser proprement, et là un commentaire va signaler que la fonctionnalité n'a rien de nouveau, qu'elle existe dans un autre langage qui n'a rien à voir depuis 1987 et que dans ce langage c'est trivial. Ce commentaire a des chances non négligeables de se retrouver à -10 sans une seule explication. Pourquoi ? Parceque
a) Les gens qui débattent sont (souvent) au courant
b) Le commentaire n'apporte rien au débat en cours
c) C'est bien beau de pouvoir solutionner un problème en deux lignes de Perl, mais bon là on est en train de décrire un ordonanceur système, donc le Perl ca va pas être possible.
Après il y a le mec qui s'accroche. Il fait un commentaire à coté le de la plaque et se prend un -10, il surenchérit d'un autre commentaire disant que son premier commentaire à coté de la plaque est factuellement vrai (ce que personne ne conteste) et se reprend un -10, il hurle à la cable contre lui et se prend un troisième -10. Strike, batteur éliminé.
Celui là je comprend qu'il soit un peu ennervé (je le comprend d'autant mieux que je suis pas totalement certain de pas avoir été lui une fois ou deux.)
Maintenant ce système d'amélioration du ratio signal/bruit n'est pas parfait. Il a quelques effets vicieux.
Le premier effet vicieux est le rebond. Le rebond est un effet qui se déclenche quand une bonne ame se dévoue pour essayer de faire de la pédagogie et cherche à expliquer à une personne pourquoi il se prend -10. Dans le cas des deux lignes de Perl par exemple on va avoir une personne qui va expliquer que la fonctionnalité Perl n'apporte rien dans le cas présent. Magie de la lecture en diagonale, de l'énnervement et de la mise en valeur des posts non lus, au moins un perliste va lire "la fonctionnalité Perl n'apporte rien" et zapper la partie "dans le cas présent". Et là vous pouvez aller chercher le pop-corn parceque ca va être un match magnifique entre les initiateurs du débat original qui vont chercher à recentrer le débat sur le problème qui les interresse, les pro-perl gonflés à bloc qui vont pas laisser leur langage favori se faire maltraiter de la sorte, les anti-perl qui verront l'occasion de régler certains comptes et les pédagogues (dont le pédagogue original) qui vont chercher à expliquer d'abord calmement, puis violamment que c'est PAS CA DONT ON EST EN TRAIN DE PARLER BOR#@!
Le second effet vicieux est l'auto-débat. Un auto-débat est un débat qui se met automatiquement en place d'une façon prédéfinie si vous essayer d'aller à l'encontre d'un mouvement général. Par exemple : on annonce le support de l'UTF-8 sur tel ou tel système de fichier ou outil système ou terminal. Aujourd'hui je me retiens, mais avant j'aurais eu tendance à dire que l'UTF-8 (ou 16 ou 32) au niveau système c'est idiot - pour la simple et bonne raison qu'il existe en UTF-X des caractères ou des suites de caractères invalides, et que ca ne me parait pas une bonne idée de permettre à un système de fichier de pouvoir contenir des noms de fichiers avec des caractères invalides dedans, généralement j'ajoute qu'un codage 16bits strict est probablement plus pertinent au niveau système. Quelque soit le nombre de précautions oratoires prises, le débat va virer ASCII vs UTF-8 et au moins une personne dira qu'il en a rien à foutre du Quenya et/ou du Klingon.
les auto-débats existent sur IPv6, systemd et ip/ifconfig principalement. Il y en avait un sur XML mais il semble en voie de disparition. Il s'agit généralement de sujets sur lesquels il y a un consensus assez fort (soit sur le site, soit au sein de la communeauté libre) et sur lesquels les chasseurs de karma se ruent.
Le troisième effet vicieux est sur tout ce qui touche aux licences et à la notion d'attribution (comme par exemple remettre un prix à un mathématicien). Ce sont des notions fondamentales du logiciel libre, et honnêtement toute tentative de discussion sur le sujet se finit soit en une salve de -10 pour un des deux bords, soit en troll sur la notion de plus ou moins libre.
C'est celà qui a explosé au nez de Keyser, involontairement ou non il a remis en cause la notion d'attribution et de reconnaissance, à partir de la on ne pouvait plus rien pour lui. Il est entrée nu et tartiné de sauce barbecue dans la fosse aux lions pour précher les bienfait d'une alimentation végétarienne. L'attribution est le principe fondateur de toute licence libre sérieuse (Toutes mes excuses à MM. Kemiyatorn et Hocevar), quand à la reconnaissance c'est le seul paiement demandé par une grosse majorité des contributeurs du libre. Dire "L'attribution et la reconnaissance c'est nul" implique nécessairement que "Le libre c'est nul" - il ne faut donc pas s'étonner de prendre des clauqes quand on le clame sur un site qui s'appelle LinuxFR…
[^] # Re: Frontières
Posté par Kaane . En réponse au journal Internet: projet de loi « sur le terrorisme » . Évalué à 6.
Si tu veux fabriquer toi même de l'explosif dans ton garage le mieux c'est certainement d'employer du sucre glace et du chlorate de sodium
Ou alors tu va gentiment en acheter en vente libre dans la station service la plus proche. Mais bon un explosif n'est pas une bombe. Fabriquer un explosif c'est pas très difficile (de la farine ou du chocolat instantané en poudre peuvent faire des explosifs convenables) , fabriquer une bombe par contre c'est pas la même.
Ceci étant dit, les amateurs qui font des explosifs dans leur garage font généralement une seule victime (mais c'est casse pied parce que ça réveille le voisinage.)
[^] # Re: Tu sais
Posté par Kaane . En réponse au journal Centos / Redhat 7 : coup de gueule sur systemd. Évalué à 7.
Rappel : on peut forker les vieux projets, et les maintenir, vive le libre.
C'est vrai pour une grosse majorité de projets, mais au niveau des systèmes d'init c'est nettement plus compliqué que ça. Forker un système d'init revient quasiment à forker l'ensemble de la distrib "pour de vrai" (ie on est pas en train de rajouter deux applis à une debian pour en faire une distrib spécialisé).
Ça demande une quantité de boulot, d'utilisateurs et de machines différentes absolument démesurée juste pour pouvoir tester le strict minimum de situations. Bref ça fait quasiment un job à plein temps juste pour un résultat médiocre.
[^] # Re: Comprendre...
Posté par Kaane . En réponse au journal [RMLL 2014] Surveillance vidéo de la foule à l’insu des visiteurs. Évalué à 4.
Petit avant propos qui va faire mal au karma :
Oh les gnomes, c'est pas bientôt fini de moinsser Zenitram comme des gorets ? On est à j+2 sur une digression de définition issue d'un journal semi-trollesque qui a été posté un vendredi. Je rappelle que selon la convention de genièvre les journaux trolls du vendredi servent justement de caisse à savon à Linuxfr. Allez plutôt sur http://en.wikipedia.org/wiki/Soapbox voir ce qu'est une caisse à savon.
Une fois de plus la question n'est pas de savoir si le libriste doit être automatiquement pour ou automatiquement contre les caméras de surveillance, on peut être libriste pour, contre ou sans opinion définie assez facilement. Le problème est que le libriste, justement parce qu'il cherche à protéger les 4 libertés fondamentales du logiciel libre se doit de se poser la question.
Une fois de plus toutes les positions sur les caméras sont compatibles avec le librisme sauf la position "j'en ai rien à foutre".
On est tout à fait libre de penser que la situation ou une entreprise (ou une instance gouvernementale) vous refusera un travail ou autre en raison d'enregistrements fait à votre insu ne se produira jamais, ou de penser comme le fait RMS que toute information personnelle non strictement nécessaire à la réalisation d'un projet ne devrait jamais être divulguée sans l'accord de l’intéressé. Et toutes les positions entre les deux.
Néanmoins la question de la surveillance peut avoir un impact fort sur la capacité à tirer parti des 4 libertés du logiciel libre (Par exemple faire de la crypto en Chine, c'est pas forcément évident, même si ça s'assouplit lentement depuis 2000). Et de fait je ne vois pas un libriste, qui a à coeur de défendre les 4 libertés, éluder la question des caméras.