Si la feuille apparaît bleutée, c'est que l'écran n'est pas assez bleu ; si la feuille apparaît jaunâtre ou rougeâtre, c'est que l'écran est trop bleu.
Pas tout à fait, ça dépend aussi de la qualité de l'éclairage (si il est midi solaire dans un ciel sans nuage on est bon, sinon…) et de l'environnement. Si il y a des objets qui rayonnent dans le spectre visible sur la feuille, celle ci va prendre partiellement leurs couleurs.
Ensuite tous les cônes ne s'adaptent pas à la même vitesse et ne traduisent pas la luminosité de la même façon. Grosso-modo, une lumière rouge cohérente aussi vive que possible paraitra plus terne qu'une lumière bleue, qui elle même paraitra plus terne qu'une lumière verte.
De fait si on veut calibrer le blanc d'un écran, on est systématiquement obliger de passer par des appareils assez couteux.
Tu as raison, mais par contre ça ne marche pas si tu passes "rapidement" d'un environnement à l'autre.
Non il y a deux soucis différents. Tu as effectivement l'adaptation chromatique si tu changes rapidement entre deux cibles optiques avec de fortes différences chromatiques ou lumineuses.
Il y a également un soucis Dans l’interprétation des couleurs notamment dans les tons (c'est ce que met en évidence l'ombre sur le damier). Il va nécessairement y avoir une différence d’interprétation pour ton cerveau entre une feuille de papier (qui est une source lumineuse secondaire) et l'écran (qui est une source lumineuse primaire). Même si le papier et l'écran paraissent tous les deux blancs en étant cote à cote, il suffit généralement de prendre une photo (ou d'utiliser un appareil de mesure - mais c'est plus difficile à trouver et plus cher) avec la feuille juste à coté de l'écran pour se rendre compte du boulot de compensation fait par le cerveau.
Non, c'est faux. Si le rétro-éclairage de nos écrans sollicitait davantage nos cônes sensibles au bleu, il n'apparaîtrait pas blanc, mais bleuté.
Non c'est faux, la perception des couleurs est toujours relative à l'environnement. De fait un bleu lumineux sera interprété comme référence de blanc par le cerveau, et toutes les autres couleurs seront décalés en fonction de cette référence. C'est bien pour ça qu'on se casse les pieds à faire des balances de blanc en photo ou en vidéo.
Le cerveau compense la sur-sensibilisation des cônes pour obtenir une information cohérente. C'est même d'ailleurs sont métier. Mais sur les couleurs ça pose quelques soucis (ombre sur le damier , Adaptation chromatique ) En plus les capteurs hyper sollicités sur une période donné finissent par remonter une information moins forte que ce que leur sollicitation impliquerait.
En bref l'être humain est analogique, et n’interprète l'information que par rapport à une référence. Si ce qu'il "sait" être blanc est en fait blanc, il l'interprétera quand même comme blanc et décalera toutes les autres couleurs vers le jaune.
quels sont les équivalents postgresql de rman et expdp s'il te plaît (lien ou au moins le nom) que je potasse un peu
Pour rman :
- Backup à chaud intègre cohérent : pg_dump marche bien
- Backup à chaud + transaction en cours simple : pg_rman (des soucis dans le passé, pas eu de soucis avec depuis 2 ans) pg_rman
- Backup à chaud + Physique/logique + transaction : pgbarman - rien à redire, à peine plus complexe à utiliser que pg_rman et beaucoup plus puissant. pgbarman
Pour impdp/expdp :
- Import/export de base : pg_dump/pg_backup Doc Officielle
- Duplication pour dev/analyse/test : pg_dump/pg_backup again avec l'option --serializable-deferrable éventuellement.
- Clone logique : pg_basebackup (pour les clusters) ou pgbarman ou vraiment dans des conditions ultra particulières l'option --oids de pg_dump (Par condition ultra particulière je veux dire que vous êtres en train de développer une extension postgresql et qu'il y a un soucis - généralement dans les fonctions de transfo entre le format interne et le format SQL)
Tu as PostgreSQL qui suffirait largement la plupart du temps
J'imagine que c'est une façon de parler, mais les cas ou PostgreSQL ne suffit pas commencent franchement à se compter sur les doigts de la main d'un manchot.
En geospatial le couple PostGIS/QGIS avec éventuellement GRASS n'a plus grand chose à envier à ArcGIS sur Oracle Spatial. Et si vraiment les quelques outils ArcGIS qui manquent encore à PostGIS sont nécessaires, on peut l'installer sur PostGIS aujourd'hui.
En maintenance/sauvegarde/migration/montée de version, les outils Postgres sont désormais devant les outils Oracle à mon sens. 2nd Quadrant, Entreprise DB et Dalibo ont fait un boulot fantastique au cours des dernières années.
En liaison avec des DB extérieures et fonctionnalités ETL, Postgresql met une pile à Oracle depuis l'arrivée des Foreign Data Wrapper. Et c'est pas l'arrivée de la 9.5 avec les import automatiques de schémas qui va arrangé les chose. Essayez Multicorn…
En granularité des droits : On a pas encore les privilèges par colonne (mais ça arrive en 9.5), mais sinon les réécritures dynamiques de requêtes ou les tables fonctionnelles permettent de limiter grandement les éléments accédés par un utilisateur. Personnellement je préfère - mais ça demande un peu plus de dev.
En ce qui concerne les framework de développement rapide : MWAHAHAHA … Désolé, j'ai pas pu m'en empécher.
Le dernier point ou Oracle a encore un gros avantage sur PostgreSQL c'est sur les clusters actifs/actifs pour des bases de données de plusieurs Go (voire To) sur lesquelles aucun partitionnement n'est raisonnablement envisageable. Mais déjà ça se réduit à chaque version, et ensuite dans le pire des cas il suffit souvent de faire appel à Entreprise DB (ou plus rarement à Citus si vraiment les besoins en I/O sont très élevé) pour résoudre le problème avec un cout de licence sans commune mesure avec Oracle.
C'est la preuve qu'être SysAdmin, c'est une pathologie incurable ?
Pas tout à fait, mais la plupart des SysAdmin souffre d'inutilisatite aigüe, et l'usage du LART n'est pas encore totalement accepté socialement - ce qui accroit encore la nuisance ressentie lors d'une infestation par des inutilisateur.
le pognon n'avait pas encore totalement envahi Internet
En parlant de ça, 10 pubs sur la page principales, plus un onglet partenaire qui est à peine dans les clous, un bandeau d'en tête qui en sort pas mal (des clous) et une recherche intra site by Google.
On ajoute à ça 9 liens directs vers Linagora ou des projets Linogara.
J'ai rien contre Toolinux ou Linagora - mais là je pense qu'on a atteint un point ou il est difficile de se plaindre de l'invasion d'internet par le pognon.
Il n'empêche que la proximité de pensée que j'ai relevé dans mon journal est, à mon sens, l'indice fort de la dangerosité de la loi sur le renseignement.
Blague à part, pas complètement. Il faut bien faire la différence entre une procédure "terrible" lors du jugement qui était ce que prônait Robespierre, et une surveillance généralisée en dehors de toute procédure ou cadre juridique.
Bien qu'il y ait fondamentalement une similitude, dans le sens ou la loi peut facilement être abusée et être utilisée comme arme - le contexte et le fonctionnement sont très différents.
Les opposants aux lois terribles de Robespierre pouvaient légitimement craindre les "coups montés" et donc un régime d’exécutions sommaires (et historiquement on ne peut pas dire que leurs inquiétudes étaient dénuées de tout fondement).
En ce qui concerne les lois sur le renseignement, elles donnent un outil de pression fort de la part des collecteurs de renseignements sur le citoyen lambda. Cet outil pouvant assez facilement être utilisé de façon anti-démocratique.
Il est très facile de faire peut à une personne quand on connait l'adresse de l'école de ses enfants. Il est très simple de harceler ou de faire harceler une personne si son numéro de téléphone ou son mail sont publics. Il est très simple de faire éclater un groupe d'importance quand on connait le vécu de chacun de ses membres, et donc les choses que chaque membre aime ou déteste etc.
C'est pourquoi les libertés individuelles ne sont pas un jouet, mais le garant principal de la démocratie. La vie privée permet la pensée critique libre - qui a son tour permet la démocratie.
Source ? J'ai jamais vu ça sur Amstrad CPC. Par ailleurs sur Amstrad les cycles CPU étaient également contraints par les accès mémoire (partagés entre le CRTC et le CPU), et donc en pratique toutes les instructions prenaient un multiple de 4 cycles.
Pour la source ça va être complexe - il s'agit d'utilisation assez complexe d'instructions non documentés. Dans DAMS il fallait les passer à la mano et dans MAMS elles ne passaient pas toutes.
Après en utilisant les registres d'index et les registres d'index étendus (IXH, IYH) il y a moyen de faire des rotations, des incrémentations et des décrémentations de registre ou des res/set de bit et de charger un registre dans la même instruction.
Après je ne sait plus comment Prodatron arrivait à faire 2 opérations en équivalent 3 NOP.Mais c'était encore plus prise de tête à comprendre que le cls le plus rapide du monde (si tu connais).
C'était B & C dans BC, D & E dans DE, H & L dans HL (et non H & M). A & F étaient combinables uniquement pour des instructions de chargement (PUSH / POP, ainsi que EX AF,AF'), pas pour de l'arithmétique (de l'arithmétique sur les flags, ça aurait fait désordre :-)).
Tout à fait.
Encore qu'on ne pouvait faire pas mal de chose sur F tout seul dans mes souvenirs.
Le moyen le plus rapide de faire des transferts mémoire était d'utiliser PUSH et POP
Le z80 est un 8 bits en interne et l'ALU est sur 4 bits, il faut 2 cycles pour traiter un registre entier.
Attention à ne pas confondre plusieurs choses
l'ALU z80 est sur deux fois 4 bits - donc les calculs se font en un seul cycle, c'est le retour des valeurs dans les registres qui demande un cycle de plus. Après on peut s'amuser un peu pour pousser l'ALU à écrire la valeur aussi tôt qu'elle a été calculé (donc en un cycle seulement) - mais faut pas venir se plaindre de la valeur de la carry. Apparemment ça n'est pas dispo sur toutes les archi z80, mais sur Amstrad c'était possible.
Également on pouvait combiner 2 registres pour faire un registre 16 bits en l’occurrence A et E dans AE et D & F dans DF. Là suivant les cas et les opérations demandées la pure partie calcul ALU pouvait demander entre 2 et 4 cycles. (Et toujours un cycle de plus pour le retour des valeurs dans les registres)
Le post de référence est celui de Blount qui parle de faire le distinguo entre certification et chiffrement - et je répond à Groumly qui dit
Le chiffrement ne sert strictement a rien si tu ne sais pas a qui appartient la cle avec laquelle tu chiffre.
en disant que la certification par tiers de confiance n'est ni la seule méthode, ni la panacée quand il s'agit de connaitre le propriétaire légitime d'une clef publique. En fait toutes les personnes qui possèdent un CA ont nécessairement utilisé une de ces nombreuses méthodes alternatives pour faire valider ce CA par le tiers de confiance.
En ce qui concerne la transmission de fingerprint, la méthode que j'utilise personnellement est archive chiffrée par mail/envoi physique + mot de passe de l'archive par téléphone. Quand on a "que" quelques centaines de clients, c'est très largement gérable par une équipe de 3 personnes.
Les tiers de confiance ne devraient intervenir que dans le cas ou quelqu'un que je ne connais pas cherche à se connecter chez moi et s'assurant qu'il est bien chez la bonne personne. Là effectivement pas d'autre solutions que de passer par une personne qui nous connait tous les deux.
Pour finir le système de CA est plutôt déficient - de l'avis même de ceux qui opèrent ce genre de système. C'est pour ça qu'on a des certifications "extended validation" et en banque des certificats doublement voire triplement contre-signés - le tout sur des lignes dédiées.
Très honnêtement madame Michu connait beaucoup mieux son agence et son chargé de compte que la société Verisign ou DigiCert. La faire passer par un CA tiers quand elle veut se connecter pour lire ses comptes en ligne ne fait pas sens du point de vue de la sécurité. Donc même en HTTPx sur des utilisations ultra classiques, la certification directe sans tiers de confiance devrait avori son rôle à jouer.
Après reste le problème du coût de mise en place et de l'adoption par les utilisateurs - qui est un problème réel - mais de là à jeter aux orties toute certification directe ou auto-certification…
Pour clarifier, je ne dis pas que la certification SSH est inutile, mais que la certification par tiers SSH est superflue.
Une entreprise A monte un serveur SSH, une entreprise B veut accéder à ce SSH (typiquement pour faire du SFTP) dans 99,9% des cas elles ne passeront pas par une entreprise C.
Après il y a pas mal de méthode pour permettre à la société B de valider le certificat quand même. De la visite des locaux de l'entreprise A à un simple coup de fil.
C'est d'autant plus vrai que dans la majorité des cas (je pense) la société A et la société B sont une seule et même entité.
De toutes les façons SSH ne dispose pas de moyen de valider un certificat tiers dans les implémentations les plus courantes. Il va se contenter de vérifier que la clef publique est connue. Si on veut des mécanismes d'expiration, de renouvellement ou de révocation de clef il faut mettre en place des procédures spécifiques - le plus souvent en dehors de SSH.
Pour le chiffrement des données par un serveur en utilisant ma clef publique, cela ne permet effectivement rien d'autre que la protection des données elles-mêmes. Ni l'expéditeur ni la connexion ne sont protégés, seul le contenu l'est. Ça ne sert effectivement que si tu peux faire le tri entre les données désirées et des données non sollicités. Le bon vieux problème ham/spam qui n'a pas franchement empêché les emails de fonctionner.
Le chiffrement ne sert strictement a rien si tu ne sais pas a qui appartient la cle avec laquelle tu chiffre.
Et la certification par tiers n'est qu'une des nombreuses façons de s'assurer du propriétaire. Pour SSH par exemple la certification par tiers est superflue.
De plus que tu connaisses le propriétaire de la clef de chiffrement ou non, tu passes quand même de la situation "tout le monde peut intercepter la communication" à "seules les personnes avec la clef privée peuvent intercepter la communication". Ça fait malgré tout une vraie différence.
Pour finir, on peut imaginer un protocole ou tu demandes au serveur de te répondre en utilisant ta clef publique - là la certification ne sert plus à rien. Et il y aurait pas mal d'applications - en fait à chaque fois que la réponse est sensible, mais pas la question.
Ouais, génial. Donc il faut changer d'init,
Parcequ'avec systemd on ne change pas d'init j'imagine…
ou au moins avoir plusieurs outils pour tenter de savoir si un service est démarré ou non (pratique…).
On peut aussi avoir un admin système compétent à la place. Le fait que Debian prévoit plusieurs scénarios pour lancer sshd ne veut pas dire que tu es obligé de tous les garder. Si tu as besoin de 50 outils pour savoir si oui ou non un service est lancé c'est un soucis à voir avec ton admin système, SysV init n'y est pour rien. Et puis très honnêtement si tu es en mode rescue, mono utilisateur, mono console tu es supposé t'en rendre compte. Si /usr ne s'est pas monté et que seuls les services primaires compilés en statique tournent, tu es supposé le voir aussi assez rapidement. Donc bon le mec qui se demande si par hasard sshd ne se serait pas lancé via un des autres scripts, il est supposé avoir une excellente raison de le faire.
En ce qui concerne ta longue citation, c'est l'opinion du monsieur. J'ai exactement l'opinion inverse. Je suis très content avec un système d'init qui en fait le minimum et qui me laisse le champs libre pour choisir ce que je veux pour faire le reste. Je peux prendre les outils de monitoring que je veux, utiliser les cgroups comme bon me semble, décider seul des mécanismes de respawn etc.
Le problème de la daemonisation a déjà été évoqué. Ca n'a rien à avoir avec SysV init, daemoniser un processus c'est complexe quel que soit la raison pour laquelle on a besoin de le faire. SysV init demande juste à ce qu'on lui rende la main - il se moque complètement de savoir comment. Dire que pour être compatible avec SysV init un processus doit passer par les quinze étapes de la daemonisation est juste faux.
En ce qui concerne les ports, c'est une des façons de faire, il y en a d'autres. Par exemple, aucun de mes services n'a jamais les droit root à part ssh, du coup je n'ai jamais à dropper de privilèges. Si un service a besoin d'un port privilégié par exemple, ben il ouvre un port non privilégié sur une interface interne et ce sont des règles firewall qui font le mapping.
Pour finir avec les logs, oui les logs sont une fonctionnalité que chaque service doit ré-implémenter. Mais là je suis curieux de savoir comment faire autrement. Le monsieur a une machine qui permet de déterminer la pertinence d'une info interne à une appli et de la remonter toute seule vers les logs ? Parceque sinon ca va rester le boulot du dev de l'appli de gérer les logs. Quant aux metadatas infalsifiables ajoutés par journald, il y a des fois ou c'est juste pénible. (par exemple un routeur téléphonique de petit opérateur va générer environ 1000 lignes de logs par secondes - logs que l'on est légalement obligé de conserver). On est parti pour 15-20ko/s d'I/O, de bande passante et d'espace disque gaspillé chaque seconde par routeur.
Tout ça pour dire ce sont des points de vue, je les comprend mais j'ai des problématiques et des besoins différents qui font qu'à aujourd'hui systemd ne peut pas me servir.
Euh, juste non. SysV a un vrai problème pour surveiller les services de manière fiable.
Et pour cause, c'est pas son job. Regarde plutôt du coté de runit ou daemontools.
Sans compter que SysV s'attend à ce que chaque script réimplémente la même chose (le fait de se mettre en daemon, d'être compatible avec le LSM du jour, etc…)
Non plus, SysV init s'attend juste à ce que le process rende la main. Ca peut être fait de pleins de façons différentes, la plus courante étant la daemonisation via double fork, mais c'est loin d'être la seule (hint : bsd).
Après pour simplifier la maintenance et avoir un peu cohérence dans les scripts, des templates ont été créés. Ils ne sont ni nécessaires ni forcément pertinents.
Sérieusement, SysV ou Upstart, c'était vachement plus cassé que systemd.
C'est une question de point de vue. Voici une petite liste de choses cassées dans systemd
- Logs centralisés distants sans I/O locaux (on peut configurer un syslog pour qu'il rebalance les logs à distance, mais pas rediriger les logs directement sur le réseau)
- Chiffrement non LUKS (c'est à dire juste les banques, l'armée et pas mal de matos médical - une paille en terme de clients pros, et je laisse de coté les éditeurs propriétaires qui pensent qu'en réinventant la roue leur appli sera mieux protégée)
- cgroups (oui, oui on peut vouloir faire autres choses avec les cgroups que ce que systemd à décidé - voire le nombre de patch à ce sujet dans docker pour comprendre)
- services dynamiques (ie services lancés - éventuellement par un autre service - avec une floppée de paramètres pour le configurer dynamiquement)
- contrôle de services par utilisateur sans droits root (avec SE Linux pour l'instant on ne peut qu'élever les droits d'un utilisateur pour lui donner un accès root au dbus "system")
- initialisation synchrone de périphériques (parfois nécessaire par exemple si il faut initialiser une carte avant de pouvoir initialiser le matos qui est derrière) - en cours de correction, mais je sens que le bébé va être refilé au kernel.
Toute ces choses (et de nombreuses autres) marchent très bien dans upstart, sysV init, runnit, daemontools, rc.d, openrc etc.
Il se trouve que dans certains environnements les fonctions citées plus haut sont absolument nécessaires.
Je suis content pour toi si systemd résout tes problèmes, mais il est loin d'être iso-fonctionnel avec les inits historiques et il ne prend pas vraiment le bon chemin pour le devenir.
Mon avis, sur systemd c'est que ça permet de faire un filtrage des administrateur systèmes incompétents/non-passionnés qui ne font pas de veille.
Entièrement d'accord. Un admin système qui n'est pas capable de citer au moins trois gros défaut de systemd, ou qui te dit sans rire que systemd c'est génial parce que ça apporte au choix du boot parallélisé, du tag de processus par cgroups ou des vrais outils de suivi des services - ben tu sais tout de suite que c'est une personne qui n'est pas sorti des forums de sa distrib favorite voire des site de news open source. Le genre de mec qui voulait mettre tous les fichiers de config en XML il y a cinq ans ou qui voulait remplacer les proxys par des scripts en python3 JIT/numba il y a deux ans.
Personnellement tout ce que m'apporte systemd c'est le log très tôt dans le boot, tout le reste je l'avais déjà ou je n'en ai pas l'utilité (voire ca me bloque) - je vais donc rester dans le camps des incompétents aigris et réactionnaires encore un peu, et écrire des scripts d'init qui ne ressemblent pas du tout mais alors pas du tout du tout à /etc/init.d/skeleton.
Bah… faut arrêter le véhicule dans les deux cas, non ? :)
"Un agent de la force publique vous fait signe de vous arrêter…"
Mode Jean Yanne ON
"Et ben je passe !"
Il s'agit d'un agent hors de la trajectoire (bien entendu), immobile,éventuellement loin (ça peut être grand un carrefour) mais face au véhicule et qui fait signe de s'arrêter.
Il me semble qu'il faudrait de l'ordre de la centaine de millions de kilomètres parcourus pour commencer à avoir un ordre d'idée de la fiabilité en utilisation réelle de ces machines.
On peut déjà comparer le nombre d'accident des google cars vis à vis du nombre d'accident qu'aurait eu un conducteur moyen dans des circonstances similaires (c'est une statistique qui est très bien connue des assurances)
Pour la Google car on est à deux accrochages léger où la voiture google n'est pas fautive et 0 accident moyen ou grave. De plus d'après Google pour un des deux accidents la voiture était piloté par un conducteur humain. (difficile à vérifier toutefois) et dans l'autre la voiture s'est arrêté à un feu rouge et s'est fait emboutir par l'arrière (donc la responsabilité de la voiture est nulle). Pour finir ces deux accidents datent de 2010 et 2011, la voiture a fait des progrès depuis.
Statistiquement les assurances s'accordent à dire qu'un conducteur lambda aurait eu plus d'accidents (mais ne sont pas très loquaces sur un chiffre exact, les stats pour une assurance c'est un peu comme les codes sources pour une société qui fait du logiciel propriétaire, si on peut éviter de les montrer…)
Maintenant il faut aussi bien voir qu'on est encore en phase 1 du prototypage qui en comptera au minimum 3. Et que cette phase 1 est loin d'être terminée.
La phase 1 consiste à faire rouler la voiture en toute circonstance, hors la technologie lidar a de grosse limitation, elle ne marche pas en cas de fortes précipitations, elle peut facilement être trompée (une feuille poussée par le vent, un sac en plastique qui s'accroche au capteur, un miroir avec le bon taux de réflexivité etc.). Les algorithmes ont du mal à faire le distinguo entre un piéton au milieu de la rue et un policier qui fait signe de s'arrêter, à prioriser le marquage ou la signalisation temporaire par rapport à la signalisation permanente (en cas de travaux par exemple) ou à détecter certains trou dans la route.
Après reste la phase 2, à savoir qu'est-ce qui se passe quand il y a 200 google cars sur un tronçon de route. Déjà il y a 200 lidars qui se bombardent les uns les autres, ensuite il faut être sur que les réactions des voitures les unes sur les autres ne vont pas générer un "auto feedback" c'est à dire que les voitures ne vont pas se mettre à réagir les unes aux autres de façon de plus en plus violente (un peu comme un larsen dans un micro trop près d'un haut parleur). Et surement tout un tas d'autres problèmes que l'on n'imagine pas encore mais qui ne manqueront pas de se produire.
Pour finir il y aura une phase 3 de lutte contre les nuisibles. C'est à dire des gens qui pour tout un tas de raisons (arnaque à l'assurance, activisme anti-robot, possession d'action chez les constructeurs traditionnels etc.) vont chercher à faire planter la google car exprès. C'est à dire à mettre la google car dans une situation qu'elle évalue mal et devant laquelle elle fait n'importe quoi. La on aura typiquement le genre de course que l'on a aujourd'hui dans le monde informatique dans la catégorie sécurité VS malware.
Google espère finir la phase 1 en 2020. On a encore un peu de marge avant que les premières voitures complètement automatisées et fonctionnelles en toute circonstance soient disponibles pour monsieur tout le monde (allez, mode madame Irma ON : 2045).
ça ne colle pas. La symbolique associé aux scorpions ne peut pas coller avec l'innocence supposée des civils.
C'est là toute la force de l'analogie. On imagine que les cavaliers auraient fait s’arrêter les enfants si ils avaient pris le temps de voir ce qu'ils faisaient, et par prolongation le spectateur est supposé être "choqué" par la torture de ces "pauvres" scorpions. Par contre les enfants et les prostitués que les deux camps méprisent n'ont même pas la considération qu'aurait eu un scorpion. La prostitué qui se retrouve exactement dans la situation du scorpion (jetée en pâture à une mort atroce sans espoir de défense) est le point d'orgue de cette analogie. Au final elle bénéficie de la même miséricorde que le scorpion : aucune. Au final dans une situation similaire les civils ne bénéficient même pas de l'empathie que l'on prêtait aux scorpions.
Non, sinon, je pense le contraire, la perversité (c'est à dire le fait de prendre du plaisir à être méchant)
DH-0
Je ne peux pas te laisser dire ça, tu manques manifestement de connaissances sur la psychologie humaine,
DH-1
c'est une chose malheureusement courante chez les personnes techniques en général, et les ingénieurs informaticiens en particulier - les diverses formations "appliquées" faisant très rapidement l'impasse sur l'enseignement philosophique, la sociologie et la psychologie. Tout au plus y-a-t-il une année d'initiation à la philosophie au cours du cursus (mais avec un coefficient tellement faible qu'une totale incompréhension de la matière n'est pas réellement pénalisante)
DH-2
Donc non, la perversité n'est pas l’intérêt à la méchanceté
DH-3
La perversité ne se limite pas au plaisir d'être méchant, et la méchanceté n'est que rarement présente là ou se trouve la perversité
DH-4
tout d'abord parce que la méchanceté contient en elle-même la notion d’intérêt. La méchanceté traduit une volonté consciente de faire du mal - le mal involontaire relève d'autres traits de caractères (inconséquence, insensibilité, immaturité etc.) Mais surtout parce que la perversité est totalement déconnecté de la notion de mauvaiseté.
DH-5
Pervers viens de per virtutes qui signifie littéralement "en dehors de la droiture". La perversion s'entend comme étant une déviance par rapport à ce qui est communément admis et accepté par tous. Ça va des préférences sexuelles à la façon d'assaisonner sa cuisine. Au sens fort pervers signifie qui est hors de la qualité (sous entendu de la qualité reconnue socialement) - c'est à dire toute action qui pourrait être faite d'une façon considérée comme louable par le regard sociale mais qui est effectuée différemment. Autant dire tout de suite que suivant le regard social que l'on considère (que ce soit dans le temps ou dans l'espace) la notion de perversion change radicalement. Ce qui est pervers pour un taliban ne le sera pas forcément pour un occidental athée, et ce qui était pervers en 1322 ne le sera probablement plus aujourd'hui.
DH-6
En fait tu sembles confondre de nombreux éléments et arriver à une conclusion fallacieuse de ce fait. Des enfants qui font dévorer un scorpion par des fournis c'est de la cruauté, c'est à dire la mentalité à prendre plaisir à la souffrance d'un autre être vivant. Même si il est généralement accepté qu'une personne cruelle finira par avoir un rôle actif dans l'infliction de cette souffrance (sadisme), l'effet défoulant qu'il y a à assister à la déchéance ou à la souffrance d'autrui, le coté confortant qu'il y a à voir ceux qui ont voulu monter trop haut ou risquer trop gros se faire descendre en flammes, c'est la catharsis. Aucun plaisir sadique dans la catharsis - juste un sentiment de légitimité à être resté à sa place. Après il y tout le distinguo entre socio-psychopathie, violence et brutalité.
Le socio-psychopathe ne tire aucun plaisir à infliger de la douleur, mais ne voit pas non plus l’intérêt qu'il y a faire des efforts pour éviter de faire souffrir autrui. La brutalité est le fait de recourir à l'usage de la force, généralement physique, pour obtenir un état que l'on pourrait probablement pas avoir autrement. C'est généralement un aveu d'impuissance ou d'incompétence (même si cet aveu d'incompétence peut être lointain de l'acte de brutalité, comme par exemple le mari qui bat sa femme car il est incapable de gérer une situation passée ou présente dans laquelle sa femme n'est absolument pas impliquée). La violence est juste l'expression d'une volonté consciente de destruction. Certes l'action de tuer un manifestant pacifique est violente, mais l'action d'extraire une tumeur d'un corps malade l'est aussi. Détruire les préjugés d'un autre temps (comme par exemple l'homophobie) est également une action violente, elle est d'ailleurs perçue comme une agression par l'autre bord.
Une fois toutes ces distinctions en main, il convient de remarquer que bien qu'il y ait un parallèle entre la scène d'introduction du film et la scène de bataille, ce n'est pas sur les similitudes que Peckinpah s'attarde mais sur les différences. Dans la scène d'ouverture toutes les classes sociales d'enfants sont présentes, et les cavaliers jouent le rôle du regard social. Ils n'arrivent pas à voir ce que font les enfants et passent leur chemin, les enfants eux sont soulagés de ne pas avoir été pris la main dans le sac (ils ont donc pleinement conscience de la mauvaiseté de leurs actes). Et la curiosité n'est levée qu'au dernier moment, elle reste donc une excuse pour les adultes responsables que les spectateurs sont supposés être. Ils ne pouvaient pas s'indigner, ils ne savaient pas ce qu'il se passait. Et quand ils l'apprennent on passe à la scène suivante.
Rien à voir dans l'esprit avec la scène du fortin. Là les classes sociales sont clairement séparés, le regard social de chaque coté pousse à la brutalité. Tout le monde sait ce qui se passe au sein du fortin (aussi bien les protagonistes que les spectateurs). Sauf que cette fois ci il s'agit d'humains. Les combattants jouent le rôle des fourmis, les civils sont les scorpions. On sait que les fourmis sont innombrables et que les scorpions ne peuvent pas se défendre et se feront dévorer d'une façon ou d'une autre. La plus belle illustration est quand un soldat utilise une prostituée comme bouclier humain et charge un soldat adverse ainsi protégé (après tout ce n'est qu'un scorpion, elle mérite de mourir).
Il ne s'agit donc pas ici de dénoncer la brutalité comme inhérente à l'homme, mais c'est au contraire l'inhibition du sens moral qui est visé. Les enfants savent que ce qu'ils font est mal, mais il continuent, les cavaliers savent que les enfants sont en train de faire une bêtise mais passe leur chemin. C'est cette capacité d'inhibition qui poussée à son paroxysme donne la scène du fortin, les différents protagonistes combattants finissent par ne plus avoir conscience de l'horreur de leurs actes au nom d'un pays, d'un idéal, d'un échappatoire, d'une exultation quelconque, le tout avec la bénédiction des regards sociaux respectifs.
C'est donc aussi bien la capacité d'inhibition de la sensibilité à la mauvaiseté qui est visée, que l'acceptation tacite de la société vis à vis de cette inhibition (qui n'est donc plus une perversion par définition).
N.B : j'ai conscience que faire les DH- dans l'ordre est extrèmement agressif, diplomatiquement il aurait mieux valu les faire en sens inverse. Mais le lecteur se serait cassé les pieds…
Donc sa position me parait juste démagogique, et cherche à faire peur sans donner de vrais problèmes qui pourrait être corriger à temps.
J'ai bien conscience que Roger Leigh n'est pas très connu du "grand public linuxien" si tant est que cette expression veuille dire quelque chose, mais là quand même. Ca fait depuis 2010 qu'il travaille avec Lennart Pottering, Kay Sievers et les mainteneurs Debian vis à vis de systemd (et des sytèmes d'init en général).
Même si il n'explique pas en profondeur toutes les raisons de sa volonté de participer à un fork de Debian (Il est bon de rappeler que ce n'est pas lui qui forke d'une part, et qu'il n'a jamais dit qu'il arrêterait de participer à Debian en même temps d'autre part) il donen quand même pas mal de piste.
Mais surtout toute personne curieuse qui fait un poil de recherche se rend compte que des problèmes dans systemd il a en relevé pas mal au cours de ses dernières années et qu'à chaque fois qu'il a relevé un problème il a proposé une solution. Il est arrivé sur le projet Debian en 2002 à 22 ans avec déjà pas mal de package et de travaux à son actif. Il était très favorable à systemd au début systemd is right at the top of the list et ce après avoir jeté un oeuil à d'autres implémentations comme OpenRC.
Il a notamment longuement participé à la discussion sur la séparation du /usr (qui est parfaitement supportée par Debian) et des conséquences que systemd pourrait avoir, ainsi que les diverses solutions que l'on peut apporter mount /user during init et de façon générale il a très longuement discuté son point de vue pendant la troisième partie du sondage init : Mailing List Debian
Donc des arguments il en a sorti des pelletées. Il n'a pas jugé utile de tous les rappeler dans son mail dans lequel il se dit prêt à participer à un fork - mais très honnêtement ce n'était ni le lieu ni le moment.
Donc
a) Roger Leigh n'est pas à l'origine du Fork (du moins pas à ma connaissance).
b) Il n'abandonnera probablement pas Debian même si il aide sur Devuan.
c) Il expose son opinion et ses arguments depuis des années.
systemd va bien au delà du système d'init, il controle les cgroups, le système de log, la création des devices aussi bien au boot que dynamiquement, la création des consoles, les sessions utilisateurs etc.
Pour l'instant on a des alternatives possibles pour la plupart des éléments séparément, mais au fur et à mesure que systemd avance ces alternatives deviennent de plus en plus complexe, et certaines sont impossibles. Par exemple les cgroups sont hardlockés et le système de log doit passer par systemd si systemd est installé (et en plus il faut faire pas mal de modifications pour que systemd daigne renvoyer des infos ET les logs sont dans un format différents du format habituel cf http://www.freedesktop.org/wiki/Software/systemd/syslog/ )
Prochaine étape annoncée : pas moyen de dialoguer avec udev si kdbus n'est pas présent dans le noyau (http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html)
Ensuite kmscon obligatoire, plus de getty ? On ne sait pas.
Donc non, le problème de systemd est très loin d'être la partie init (qui est même plutôt bonne en fait - bien qu'insuffisante poru certains besoins spécifiques). Mais bon c'est juste un daemontools inittabisé donc pas de crainte à avoir de ce coté là .Le problème de systemd c'est tout le reste.
je ne crois pas que systemd soit si tentatuculaire qu'il va impacter 10 000 paquets ou plus.
Non juste les paquets qui utilisent les libs systèmes (et par ricochet tous les paquets qui reposent sur des paquets qui utilisent des libs systèmes).
Donc potentiellement tous oui. On est pas encore tout à fait au point ou on peut considérer que Linux avec systemd et Linux sans systemd sont deux OS distincts (Comme GNU/Linux et Android) mais on s'en rapproche vite.
[^] # Re: Au moins une erreur
Posté par Kaane . En réponse au journal Lumière bleue, attention les yeux.. Évalué à 4.
Pas tout à fait, ça dépend aussi de la qualité de l'éclairage (si il est midi solaire dans un ciel sans nuage on est bon, sinon…) et de l'environnement. Si il y a des objets qui rayonnent dans le spectre visible sur la feuille, celle ci va prendre partiellement leurs couleurs.
Ensuite tous les cônes ne s'adaptent pas à la même vitesse et ne traduisent pas la luminosité de la même façon. Grosso-modo, une lumière rouge cohérente aussi vive que possible paraitra plus terne qu'une lumière bleue, qui elle même paraitra plus terne qu'une lumière verte.
De fait si on veut calibrer le blanc d'un écran, on est systématiquement obliger de passer par des appareils assez couteux.
[^] # Re: Au moins une erreur
Posté par Kaane . En réponse au journal Lumière bleue, attention les yeux.. Évalué à 4.
Non il y a deux soucis différents. Tu as effectivement l'adaptation chromatique si tu changes rapidement entre deux cibles optiques avec de fortes différences chromatiques ou lumineuses.
Il y a également un soucis Dans l’interprétation des couleurs notamment dans les tons (c'est ce que met en évidence l'ombre sur le damier). Il va nécessairement y avoir une différence d’interprétation pour ton cerveau entre une feuille de papier (qui est une source lumineuse secondaire) et l'écran (qui est une source lumineuse primaire). Même si le papier et l'écran paraissent tous les deux blancs en étant cote à cote, il suffit généralement de prendre une photo (ou d'utiliser un appareil de mesure - mais c'est plus difficile à trouver et plus cher) avec la feuille juste à coté de l'écran pour se rendre compte du boulot de compensation fait par le cerveau.
[^] # Re: Au moins une erreur
Posté par Kaane . En réponse au journal Lumière bleue, attention les yeux.. Évalué à 8.
Non c'est faux, la perception des couleurs est toujours relative à l'environnement. De fait un bleu lumineux sera interprété comme référence de blanc par le cerveau, et toutes les autres couleurs seront décalés en fonction de cette référence. C'est bien pour ça qu'on se casse les pieds à faire des balances de blanc en photo ou en vidéo.
Le cerveau compense la sur-sensibilisation des cônes pour obtenir une information cohérente. C'est même d'ailleurs sont métier. Mais sur les couleurs ça pose quelques soucis (ombre sur le damier , Adaptation chromatique ) En plus les capteurs hyper sollicités sur une période donné finissent par remonter une information moins forte que ce que leur sollicitation impliquerait.
En bref l'être humain est analogique, et n’interprète l'information que par rapport à une référence. Si ce qu'il "sait" être blanc est en fait blanc, il l'interprétera quand même comme blanc et décalera toutes les autres couleurs vers le jaune.
[^] # Re: Don't be evil
Posté par Kaane . En réponse au journal Petite prévision pour l'avenir. Oracle !. Évalué à 10.
Pour rman :
- Backup à chaud intègre cohérent : pg_dump marche bien
- Backup à chaud + transaction en cours simple : pg_rman (des soucis dans le passé, pas eu de soucis avec depuis 2 ans) pg_rman
- Backup à chaud + Physique/logique + transaction : pgbarman - rien à redire, à peine plus complexe à utiliser que pg_rman et beaucoup plus puissant. pgbarman
Pour impdp/expdp :
- Import/export de base : pg_dump/pg_backup Doc Officielle
- Duplication pour dev/analyse/test : pg_dump/pg_backup again avec l'option --serializable-deferrable éventuellement.
- Clone logique : pg_basebackup (pour les clusters) ou pgbarman ou vraiment dans des conditions ultra particulières l'option --oids de pg_dump (Par condition ultra particulière je veux dire que vous êtres en train de développer une extension postgresql et qu'il y a un soucis - généralement dans les fonctions de transfo entre le format interne et le format SQL)
[^] # Re: Don't be evil
Posté par Kaane . En réponse au journal Petite prévision pour l'avenir. Oracle !. Évalué à 10.
Tu as PostgreSQL qui suffirait largement la plupart du temps
J'imagine que c'est une façon de parler, mais les cas ou PostgreSQL ne suffit pas commencent franchement à se compter sur les doigts de la main d'un manchot.
En analyse statistique le cstore_fdw https://github.com/citusdata/cstore_fdw est tout simplement bluffant d'efficacité.
En geospatial le couple PostGIS/QGIS avec éventuellement GRASS n'a plus grand chose à envier à ArcGIS sur Oracle Spatial. Et si vraiment les quelques outils ArcGIS qui manquent encore à PostGIS sont nécessaires, on peut l'installer sur PostGIS aujourd'hui.
En maintenance/sauvegarde/migration/montée de version, les outils Postgres sont désormais devant les outils Oracle à mon sens. 2nd Quadrant, Entreprise DB et Dalibo ont fait un boulot fantastique au cours des dernières années.
En liaison avec des DB extérieures et fonctionnalités ETL, Postgresql met une pile à Oracle depuis l'arrivée des Foreign Data Wrapper. Et c'est pas l'arrivée de la 9.5 avec les import automatiques de schémas qui va arrangé les chose. Essayez Multicorn…
En granularité des droits : On a pas encore les privilèges par colonne (mais ça arrive en 9.5), mais sinon les réécritures dynamiques de requêtes ou les tables fonctionnelles permettent de limiter grandement les éléments accédés par un utilisateur. Personnellement je préfère - mais ça demande un peu plus de dev.
En ce qui concerne les framework de développement rapide : MWAHAHAHA … Désolé, j'ai pas pu m'en empécher.
Le dernier point ou Oracle a encore un gros avantage sur PostgreSQL c'est sur les clusters actifs/actifs pour des bases de données de plusieurs Go (voire To) sur lesquelles aucun partitionnement n'est raisonnablement envisageable. Mais déjà ça se réduit à chaque version, et ensuite dans le pire des cas il suffit souvent de faire appel à Entreprise DB (ou plus rarement à Citus si vraiment les besoins en I/O sont très élevé) pour résoudre le problème avec un cout de licence sans commune mesure avec Oracle.
[^] # Re: Créer une journée des SysAdmin...
Posté par Kaane . En réponse à la dépêche 31 juillet 2015 : la journée des SysAdmin !. Évalué à 2.
C'est la preuve qu'être SysAdmin, c'est une pathologie incurable ?
Pas tout à fait, mais la plupart des SysAdmin souffre d'inutilisatite aigüe, et l'usage du LART n'est pas encore totalement accepté socialement - ce qui accroit encore la nuisance ressentie lors d'une infestation par des inutilisateur.
# Paille, poutre toussa...
Posté par Kaane . En réponse au journal Toolinux : on s'était dit rendez-vous dans 15 ans..... Évalué à 10.
le pognon n'avait pas encore totalement envahi Internet
En parlant de ça, 10 pubs sur la page principales, plus un onglet partenaire qui est à peine dans les clous, un bandeau d'en tête qui en sort pas mal (des clous) et une recherche intra site by Google.
On ajoute à ça 9 liens directs vers Linagora ou des projets Linogara.
J'ai rien contre Toolinux ou Linagora - mais là je pense qu'on a atteint un point ou il est difficile de se plaindre de l'invasion d'internet par le pognon.
[^] # Re: Je ne sais pas si il craignait les lois terribles ou pas.
Posté par Kaane . En réponse au journal Robespierre et la loi sur le renseignement. Évalué à 9.
Blague à part, pas complètement. Il faut bien faire la différence entre une procédure "terrible" lors du jugement qui était ce que prônait Robespierre, et une surveillance généralisée en dehors de toute procédure ou cadre juridique.
Bien qu'il y ait fondamentalement une similitude, dans le sens ou la loi peut facilement être abusée et être utilisée comme arme - le contexte et le fonctionnement sont très différents.
Les opposants aux lois terribles de Robespierre pouvaient légitimement craindre les "coups montés" et donc un régime d’exécutions sommaires (et historiquement on ne peut pas dire que leurs inquiétudes étaient dénuées de tout fondement).
En ce qui concerne les lois sur le renseignement, elles donnent un outil de pression fort de la part des collecteurs de renseignements sur le citoyen lambda. Cet outil pouvant assez facilement être utilisé de façon anti-démocratique.
Il est très facile de faire peut à une personne quand on connait l'adresse de l'école de ses enfants. Il est très simple de harceler ou de faire harceler une personne si son numéro de téléphone ou son mail sont publics. Il est très simple de faire éclater un groupe d'importance quand on connait le vécu de chacun de ses membres, et donc les choses que chaque membre aime ou déteste etc.
C'est pourquoi les libertés individuelles ne sont pas un jouet, mais le garant principal de la démocratie. La vie privée permet la pensée critique libre - qui a son tour permet la démocratie.
# Je ne sais pas si il craignait les lois terribles ou pas.
Posté par Kaane . En réponse au journal Robespierre et la loi sur le renseignement. Évalué à 10.
Mais il a été décapité quand même.
[^] # Re: Ah on voit les classes moyennes et hautes qui se détachent
Posté par Kaane . En réponse au sondage Mon processeur préféré ?. Évalué à 2.
Pour la source ça va être complexe - il s'agit d'utilisation assez complexe d'instructions non documentés. Dans DAMS il fallait les passer à la mano et dans MAMS elles ne passaient pas toutes.
La liste des instructions non documentés est là :
http://www.z80.info/z80undoc.htm
Après en utilisant les registres d'index et les registres d'index étendus (IXH, IYH) il y a moyen de faire des rotations, des incrémentations et des décrémentations de registre ou des res/set de bit et de charger un registre dans la même instruction.
Après je ne sait plus comment Prodatron arrivait à faire 2 opérations en équivalent 3 NOP.Mais c'était encore plus prise de tête à comprendre que le cls le plus rapide du monde (si tu connais).
Tout à fait.
Encore qu'on ne pouvait faire pas mal de chose sur F tout seul dans mes souvenirs.
Ah… désactiver SP et faire le goret avec la pile…
[^] # Re: Ah on voit les classes moyennes et hautes qui se détachent
Posté par Kaane . En réponse au sondage Mon processeur préféré ?. Évalué à 3.
Attention à ne pas confondre plusieurs choses
l'ALU z80 est sur deux fois 4 bits - donc les calculs se font en un seul cycle, c'est le retour des valeurs dans les registres qui demande un cycle de plus. Après on peut s'amuser un peu pour pousser l'ALU à écrire la valeur aussi tôt qu'elle a été calculé (donc en un cycle seulement) - mais faut pas venir se plaindre de la valeur de la carry. Apparemment ça n'est pas dispo sur toutes les archi z80, mais sur Amstrad c'était possible.
Également on pouvait combiner 2 registres pour faire un registre 16 bits en l’occurrence A et E dans AE et D & F dans DF. Là suivant les cas et les opérations demandées la pure partie calcul ALU pouvait demander entre 2 et 4 cycles. (Et toujours un cycle de plus pour le retour des valeurs dans les registres)
[^] # Re: Mélange
Posté par Kaane . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 7.
Le post de référence est celui de Blount qui parle de faire le distinguo entre certification et chiffrement - et je répond à Groumly qui dit
en disant que la certification par tiers de confiance n'est ni la seule méthode, ni la panacée quand il s'agit de connaitre le propriétaire légitime d'une clef publique. En fait toutes les personnes qui possèdent un CA ont nécessairement utilisé une de ces nombreuses méthodes alternatives pour faire valider ce CA par le tiers de confiance.
En ce qui concerne la transmission de fingerprint, la méthode que j'utilise personnellement est archive chiffrée par mail/envoi physique + mot de passe de l'archive par téléphone. Quand on a "que" quelques centaines de clients, c'est très largement gérable par une équipe de 3 personnes.
Les tiers de confiance ne devraient intervenir que dans le cas ou quelqu'un que je ne connais pas cherche à se connecter chez moi et s'assurant qu'il est bien chez la bonne personne. Là effectivement pas d'autre solutions que de passer par une personne qui nous connait tous les deux.
Pour finir le système de CA est plutôt déficient - de l'avis même de ceux qui opèrent ce genre de système. C'est pour ça qu'on a des certifications "extended validation" et en banque des certificats doublement voire triplement contre-signés - le tout sur des lignes dédiées.
Très honnêtement madame Michu connait beaucoup mieux son agence et son chargé de compte que la société Verisign ou DigiCert. La faire passer par un CA tiers quand elle veut se connecter pour lire ses comptes en ligne ne fait pas sens du point de vue de la sécurité. Donc même en HTTPx sur des utilisations ultra classiques, la certification directe sans tiers de confiance devrait avori son rôle à jouer.
Après reste le problème du coût de mise en place et de l'adoption par les utilisateurs - qui est un problème réel - mais de là à jeter aux orties toute certification directe ou auto-certification…
[^] # Re: Mélange
Posté par Kaane . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 1.
Pour clarifier, je ne dis pas que la certification SSH est inutile, mais que la certification par tiers SSH est superflue.
Une entreprise A monte un serveur SSH, une entreprise B veut accéder à ce SSH (typiquement pour faire du SFTP) dans 99,9% des cas elles ne passeront pas par une entreprise C.
Après il y a pas mal de méthode pour permettre à la société B de valider le certificat quand même. De la visite des locaux de l'entreprise A à un simple coup de fil.
C'est d'autant plus vrai que dans la majorité des cas (je pense) la société A et la société B sont une seule et même entité.
De toutes les façons SSH ne dispose pas de moyen de valider un certificat tiers dans les implémentations les plus courantes. Il va se contenter de vérifier que la clef publique est connue. Si on veut des mécanismes d'expiration, de renouvellement ou de révocation de clef il faut mettre en place des procédures spécifiques - le plus souvent en dehors de SSH.
Pour le chiffrement des données par un serveur en utilisant ma clef publique, cela ne permet effectivement rien d'autre que la protection des données elles-mêmes. Ni l'expéditeur ni la connexion ne sont protégés, seul le contenu l'est. Ça ne sert effectivement que si tu peux faire le tri entre les données désirées et des données non sollicités. Le bon vieux problème ham/spam qui n'a pas franchement empêché les emails de fonctionner.
[^] # Re: Mélange
Posté par Kaane . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 1.
Et la certification par tiers n'est qu'une des nombreuses façons de s'assurer du propriétaire. Pour SSH par exemple la certification par tiers est superflue.
De plus que tu connaisses le propriétaire de la clef de chiffrement ou non, tu passes quand même de la situation "tout le monde peut intercepter la communication" à "seules les personnes avec la clef privée peuvent intercepter la communication". Ça fait malgré tout une vraie différence.
Pour finir, on peut imaginer un protocole ou tu demandes au serveur de te répondre en utilisant ta clef publique - là la certification ne sert plus à rien. Et il y aurait pas mal d'applications - en fait à chaque fois que la réponse est sensible, mais pas la question.
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par Kaane . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 4.
Parce que la fonction principale d'un init est d'assurer la mise en place et le maintien de l'espace utilisateur.
[^] # Re: C'est là tout le problème
Posté par Kaane . En réponse au journal systemd: je me lance. Évalué à 6.
Ouais, génial. Donc il faut changer d'init,
Parcequ'avec systemd on ne change pas d'init j'imagine…
ou au moins avoir plusieurs outils pour tenter de savoir si un service est démarré ou non (pratique…).
On peut aussi avoir un admin système compétent à la place. Le fait que Debian prévoit plusieurs scénarios pour lancer sshd ne veut pas dire que tu es obligé de tous les garder. Si tu as besoin de 50 outils pour savoir si oui ou non un service est lancé c'est un soucis à voir avec ton admin système, SysV init n'y est pour rien. Et puis très honnêtement si tu es en mode rescue, mono utilisateur, mono console tu es supposé t'en rendre compte. Si /usr ne s'est pas monté et que seuls les services primaires compilés en statique tournent, tu es supposé le voir aussi assez rapidement. Donc bon le mec qui se demande si par hasard sshd ne se serait pas lancé via un des autres scripts, il est supposé avoir une excellente raison de le faire.
En ce qui concerne ta longue citation, c'est l'opinion du monsieur. J'ai exactement l'opinion inverse. Je suis très content avec un système d'init qui en fait le minimum et qui me laisse le champs libre pour choisir ce que je veux pour faire le reste. Je peux prendre les outils de monitoring que je veux, utiliser les cgroups comme bon me semble, décider seul des mécanismes de respawn etc.
Le problème de la daemonisation a déjà été évoqué. Ca n'a rien à avoir avec SysV init, daemoniser un processus c'est complexe quel que soit la raison pour laquelle on a besoin de le faire. SysV init demande juste à ce qu'on lui rende la main - il se moque complètement de savoir comment. Dire que pour être compatible avec SysV init un processus doit passer par les quinze étapes de la daemonisation est juste faux.
En ce qui concerne les ports, c'est une des façons de faire, il y en a d'autres. Par exemple, aucun de mes services n'a jamais les droit root à part ssh, du coup je n'ai jamais à dropper de privilèges. Si un service a besoin d'un port privilégié par exemple, ben il ouvre un port non privilégié sur une interface interne et ce sont des règles firewall qui font le mapping.
Pour finir avec les logs, oui les logs sont une fonctionnalité que chaque service doit ré-implémenter. Mais là je suis curieux de savoir comment faire autrement. Le monsieur a une machine qui permet de déterminer la pertinence d'une info interne à une appli et de la remonter toute seule vers les logs ? Parceque sinon ca va rester le boulot du dev de l'appli de gérer les logs. Quant aux metadatas infalsifiables ajoutés par journald, il y a des fois ou c'est juste pénible. (par exemple un routeur téléphonique de petit opérateur va générer environ 1000 lignes de logs par secondes - logs que l'on est légalement obligé de conserver). On est parti pour 15-20ko/s d'I/O, de bande passante et d'espace disque gaspillé chaque seconde par routeur.
Tout ça pour dire ce sont des points de vue, je les comprend mais j'ai des problématiques et des besoins différents qui font qu'à aujourd'hui systemd ne peut pas me servir.
[^] # Re: C'est là tout le problème
Posté par Kaane . En réponse au journal systemd: je me lance. Évalué à 4.
Euh, juste non. SysV a un vrai problème pour surveiller les services de manière fiable.
Et pour cause, c'est pas son job. Regarde plutôt du coté de runit ou daemontools.
Sans compter que SysV s'attend à ce que chaque script réimplémente la même chose (le fait de se mettre en daemon, d'être compatible avec le LSM du jour, etc…)
Non plus, SysV init s'attend juste à ce que le process rende la main. Ca peut être fait de pleins de façons différentes, la plus courante étant la daemonisation via double fork, mais c'est loin d'être la seule (hint : bsd).
Après pour simplifier la maintenance et avoir un peu cohérence dans les scripts, des templates ont été créés. Ils ne sont ni nécessaires ni forcément pertinents.
Sérieusement, SysV ou Upstart, c'était vachement plus cassé que systemd.
C'est une question de point de vue. Voici une petite liste de choses cassées dans systemd
- Logs centralisés distants sans I/O locaux (on peut configurer un syslog pour qu'il rebalance les logs à distance, mais pas rediriger les logs directement sur le réseau)
- Chiffrement non LUKS (c'est à dire juste les banques, l'armée et pas mal de matos médical - une paille en terme de clients pros, et je laisse de coté les éditeurs propriétaires qui pensent qu'en réinventant la roue leur appli sera mieux protégée)
- cgroups (oui, oui on peut vouloir faire autres choses avec les cgroups que ce que systemd à décidé - voire le nombre de patch à ce sujet dans docker pour comprendre)
- services dynamiques (ie services lancés - éventuellement par un autre service - avec une floppée de paramètres pour le configurer dynamiquement)
- contrôle de services par utilisateur sans droits root (avec SE Linux pour l'instant on ne peut qu'élever les droits d'un utilisateur pour lui donner un accès root au dbus "system")
- initialisation synchrone de périphériques (parfois nécessaire par exemple si il faut initialiser une carte avant de pouvoir initialiser le matos qui est derrière) - en cours de correction, mais je sens que le bébé va être refilé au kernel.
Toute ces choses (et de nombreuses autres) marchent très bien dans upstart, sysV init, runnit, daemontools, rc.d, openrc etc.
Il se trouve que dans certains environnements les fonctions citées plus haut sont absolument nécessaires.
Je suis content pour toi si systemd résout tes problèmes, mais il est loin d'être iso-fonctionnel avec les inits historiques et il ne prend pas vraiment le bon chemin pour le devenir.
[^] # Re: C'est là tout le problème
Posté par Kaane . En réponse au journal systemd: je me lance. Évalué à 1.
Mon avis, sur systemd c'est que ça permet de faire un filtrage des administrateur systèmes incompétents/non-passionnés qui ne font pas de veille.
Entièrement d'accord. Un admin système qui n'est pas capable de citer au moins trois gros défaut de systemd, ou qui te dit sans rire que systemd c'est génial parce que ça apporte au choix du boot parallélisé, du tag de processus par cgroups ou des vrais outils de suivi des services - ben tu sais tout de suite que c'est une personne qui n'est pas sorti des forums de sa distrib favorite voire des site de news open source. Le genre de mec qui voulait mettre tous les fichiers de config en XML il y a cinq ans ou qui voulait remplacer les proxys par des scripts en python3 JIT/numba il y a deux ans.
Personnellement tout ce que m'apporte systemd c'est le log très tôt dans le boot, tout le reste je l'avais déjà ou je n'en ai pas l'utilité (voire ca me bloque) - je vais donc rester dans le camps des incompétents aigris et réactionnaires encore un peu, et écrire des scripts d'init qui ne ressemblent pas du tout mais alors pas du tout du tout à /etc/init.d/skeleton.
[^] # Re: Et pourtant une autre révolution est en marche
Posté par Kaane . En réponse au journal Tesla Motors VS the rest of the world. Évalué à 3.
"Un agent de la force publique vous fait signe de vous arrêter…"
Mode Jean Yanne ON
"Et ben je passe !"
Il s'agit d'un agent hors de la trajectoire (bien entendu), immobile,éventuellement loin (ça peut être grand un carrefour) mais face au véhicule et qui fait signe de s'arrêter.
[^] # Re: Et pourtant une autre révolution est en marche
Posté par Kaane . En réponse au journal Tesla Motors VS the rest of the world. Évalué à 10.
Il me semble qu'il faudrait de l'ordre de la centaine de millions de kilomètres parcourus pour commencer à avoir un ordre d'idée de la fiabilité en utilisation réelle de ces machines.
On peut déjà comparer le nombre d'accident des google cars vis à vis du nombre d'accident qu'aurait eu un conducteur moyen dans des circonstances similaires (c'est une statistique qui est très bien connue des assurances)
Pour la Google car on est à deux accrochages léger où la voiture google n'est pas fautive et 0 accident moyen ou grave. De plus d'après Google pour un des deux accidents la voiture était piloté par un conducteur humain. (difficile à vérifier toutefois) et dans l'autre la voiture s'est arrêté à un feu rouge et s'est fait emboutir par l'arrière (donc la responsabilité de la voiture est nulle). Pour finir ces deux accidents datent de 2010 et 2011, la voiture a fait des progrès depuis.
Statistiquement les assurances s'accordent à dire qu'un conducteur lambda aurait eu plus d'accidents (mais ne sont pas très loquaces sur un chiffre exact, les stats pour une assurance c'est un peu comme les codes sources pour une société qui fait du logiciel propriétaire, si on peut éviter de les montrer…)
Maintenant il faut aussi bien voir qu'on est encore en phase 1 du prototypage qui en comptera au minimum 3. Et que cette phase 1 est loin d'être terminée.
La phase 1 consiste à faire rouler la voiture en toute circonstance, hors la technologie lidar a de grosse limitation, elle ne marche pas en cas de fortes précipitations, elle peut facilement être trompée (une feuille poussée par le vent, un sac en plastique qui s'accroche au capteur, un miroir avec le bon taux de réflexivité etc.). Les algorithmes ont du mal à faire le distinguo entre un piéton au milieu de la rue et un policier qui fait signe de s'arrêter, à prioriser le marquage ou la signalisation temporaire par rapport à la signalisation permanente (en cas de travaux par exemple) ou à détecter certains trou dans la route.
Après reste la phase 2, à savoir qu'est-ce qui se passe quand il y a 200 google cars sur un tronçon de route. Déjà il y a 200 lidars qui se bombardent les uns les autres, ensuite il faut être sur que les réactions des voitures les unes sur les autres ne vont pas générer un "auto feedback" c'est à dire que les voitures ne vont pas se mettre à réagir les unes aux autres de façon de plus en plus violente (un peu comme un larsen dans un micro trop près d'un haut parleur). Et surement tout un tas d'autres problèmes que l'on n'imagine pas encore mais qui ne manqueront pas de se produire.
Pour finir il y aura une phase 3 de lutte contre les nuisibles. C'est à dire des gens qui pour tout un tas de raisons (arnaque à l'assurance, activisme anti-robot, possession d'action chez les constructeurs traditionnels etc.) vont chercher à faire planter la google car exprès. C'est à dire à mettre la google car dans une situation qu'elle évalue mal et devant laquelle elle fait n'importe quoi. La on aura typiquement le genre de course que l'on a aujourd'hui dans le monde informatique dans la catégorie sécurité VS malware.
Google espère finir la phase 1 en 2020. On a encore un peu de marge avant que les premières voitures complètement automatisées et fonctionnelles en toute circonstance soient disponibles pour monsieur tout le monde (allez, mode madame Irma ON : 2045).
[^] # Re: The wild troll
Posté par Kaane . En réponse au journal Comment réfuter. Évalué à 4.
ça ne colle pas. La symbolique associé aux scorpions ne peut pas coller avec l'innocence supposée des civils.
C'est là toute la force de l'analogie. On imagine que les cavaliers auraient fait s’arrêter les enfants si ils avaient pris le temps de voir ce qu'ils faisaient, et par prolongation le spectateur est supposé être "choqué" par la torture de ces "pauvres" scorpions. Par contre les enfants et les prostitués que les deux camps méprisent n'ont même pas la considération qu'aurait eu un scorpion. La prostitué qui se retrouve exactement dans la situation du scorpion (jetée en pâture à une mort atroce sans espoir de défense) est le point d'orgue de cette analogie. Au final elle bénéficie de la même miséricorde que le scorpion : aucune. Au final dans une situation similaire les civils ne bénéficient même pas de l'empathie que l'on prêtait aux scorpions.
[^] # Re: The wild troll
Posté par Kaane . En réponse au journal Comment réfuter. Évalué à 10.
DH-0
Je ne peux pas te laisser dire ça, tu manques manifestement de connaissances sur la psychologie humaine,
DH-1
c'est une chose malheureusement courante chez les personnes techniques en général, et les ingénieurs informaticiens en particulier - les diverses formations "appliquées" faisant très rapidement l'impasse sur l'enseignement philosophique, la sociologie et la psychologie. Tout au plus y-a-t-il une année d'initiation à la philosophie au cours du cursus (mais avec un coefficient tellement faible qu'une totale incompréhension de la matière n'est pas réellement pénalisante)
DH-2
Donc non, la perversité n'est pas l’intérêt à la méchanceté
DH-3
La perversité ne se limite pas au plaisir d'être méchant, et la méchanceté n'est que rarement présente là ou se trouve la perversité
DH-4
tout d'abord parce que la méchanceté contient en elle-même la notion d’intérêt. La méchanceté traduit une volonté consciente de faire du mal - le mal involontaire relève d'autres traits de caractères (inconséquence, insensibilité, immaturité etc.) Mais surtout parce que la perversité est totalement déconnecté de la notion de mauvaiseté.
DH-5
Pervers viens de per virtutes qui signifie littéralement "en dehors de la droiture". La perversion s'entend comme étant une déviance par rapport à ce qui est communément admis et accepté par tous. Ça va des préférences sexuelles à la façon d'assaisonner sa cuisine. Au sens fort pervers signifie qui est hors de la qualité (sous entendu de la qualité reconnue socialement) - c'est à dire toute action qui pourrait être faite d'une façon considérée comme louable par le regard sociale mais qui est effectuée différemment. Autant dire tout de suite que suivant le regard social que l'on considère (que ce soit dans le temps ou dans l'espace) la notion de perversion change radicalement. Ce qui est pervers pour un taliban ne le sera pas forcément pour un occidental athée, et ce qui était pervers en 1322 ne le sera probablement plus aujourd'hui.
DH-6
En fait tu sembles confondre de nombreux éléments et arriver à une conclusion fallacieuse de ce fait. Des enfants qui font dévorer un scorpion par des fournis c'est de la cruauté, c'est à dire la mentalité à prendre plaisir à la souffrance d'un autre être vivant. Même si il est généralement accepté qu'une personne cruelle finira par avoir un rôle actif dans l'infliction de cette souffrance (sadisme), l'effet défoulant qu'il y a à assister à la déchéance ou à la souffrance d'autrui, le coté confortant qu'il y a à voir ceux qui ont voulu monter trop haut ou risquer trop gros se faire descendre en flammes, c'est la catharsis. Aucun plaisir sadique dans la catharsis - juste un sentiment de légitimité à être resté à sa place. Après il y tout le distinguo entre socio-psychopathie, violence et brutalité.
Le socio-psychopathe ne tire aucun plaisir à infliger de la douleur, mais ne voit pas non plus l’intérêt qu'il y a faire des efforts pour éviter de faire souffrir autrui. La brutalité est le fait de recourir à l'usage de la force, généralement physique, pour obtenir un état que l'on pourrait probablement pas avoir autrement. C'est généralement un aveu d'impuissance ou d'incompétence (même si cet aveu d'incompétence peut être lointain de l'acte de brutalité, comme par exemple le mari qui bat sa femme car il est incapable de gérer une situation passée ou présente dans laquelle sa femme n'est absolument pas impliquée). La violence est juste l'expression d'une volonté consciente de destruction. Certes l'action de tuer un manifestant pacifique est violente, mais l'action d'extraire une tumeur d'un corps malade l'est aussi. Détruire les préjugés d'un autre temps (comme par exemple l'homophobie) est également une action violente, elle est d'ailleurs perçue comme une agression par l'autre bord.
Une fois toutes ces distinctions en main, il convient de remarquer que bien qu'il y ait un parallèle entre la scène d'introduction du film et la scène de bataille, ce n'est pas sur les similitudes que Peckinpah s'attarde mais sur les différences. Dans la scène d'ouverture toutes les classes sociales d'enfants sont présentes, et les cavaliers jouent le rôle du regard social. Ils n'arrivent pas à voir ce que font les enfants et passent leur chemin, les enfants eux sont soulagés de ne pas avoir été pris la main dans le sac (ils ont donc pleinement conscience de la mauvaiseté de leurs actes). Et la curiosité n'est levée qu'au dernier moment, elle reste donc une excuse pour les adultes responsables que les spectateurs sont supposés être. Ils ne pouvaient pas s'indigner, ils ne savaient pas ce qu'il se passait. Et quand ils l'apprennent on passe à la scène suivante.
Rien à voir dans l'esprit avec la scène du fortin. Là les classes sociales sont clairement séparés, le regard social de chaque coté pousse à la brutalité. Tout le monde sait ce qui se passe au sein du fortin (aussi bien les protagonistes que les spectateurs). Sauf que cette fois ci il s'agit d'humains. Les combattants jouent le rôle des fourmis, les civils sont les scorpions. On sait que les fourmis sont innombrables et que les scorpions ne peuvent pas se défendre et se feront dévorer d'une façon ou d'une autre. La plus belle illustration est quand un soldat utilise une prostituée comme bouclier humain et charge un soldat adverse ainsi protégé (après tout ce n'est qu'un scorpion, elle mérite de mourir).
Il ne s'agit donc pas ici de dénoncer la brutalité comme inhérente à l'homme, mais c'est au contraire l'inhibition du sens moral qui est visé. Les enfants savent que ce qu'ils font est mal, mais il continuent, les cavaliers savent que les enfants sont en train de faire une bêtise mais passe leur chemin. C'est cette capacité d'inhibition qui poussée à son paroxysme donne la scène du fortin, les différents protagonistes combattants finissent par ne plus avoir conscience de l'horreur de leurs actes au nom d'un pays, d'un idéal, d'un échappatoire, d'une exultation quelconque, le tout avec la bénédiction des regards sociaux respectifs.
C'est donc aussi bien la capacité d'inhibition de la sensibilité à la mauvaiseté qui est visée, que l'acceptation tacite de la société vis à vis de cette inhibition (qui n'est donc plus une perversion par définition).
N.B : j'ai conscience que faire les DH- dans l'ordre est extrèmement agressif, diplomatiquement il aurait mieux valu les faire en sens inverse. Mais le lecteur se serait cassé les pieds…
[^] # Re: Sur un autre sujet
Posté par Kaane . En réponse au journal Devuan forks Debian: un choc ou c'était inévitable?. Évalué à 10.
Donc sa position me parait juste démagogique, et cherche à faire peur sans donner de vrais problèmes qui pourrait être corriger à temps.
J'ai bien conscience que Roger Leigh n'est pas très connu du "grand public linuxien" si tant est que cette expression veuille dire quelque chose, mais là quand même. Ca fait depuis 2010 qu'il travaille avec Lennart Pottering, Kay Sievers et les mainteneurs Debian vis à vis de systemd (et des sytèmes d'init en général).
Même si il n'explique pas en profondeur toutes les raisons de sa volonté de participer à un fork de Debian (Il est bon de rappeler que ce n'est pas lui qui forke d'une part, et qu'il n'a jamais dit qu'il arrêterait de participer à Debian en même temps d'autre part) il donen quand même pas mal de piste.
Mais surtout toute personne curieuse qui fait un poil de recherche se rend compte que des problèmes dans systemd il a en relevé pas mal au cours de ses dernières années et qu'à chaque fois qu'il a relevé un problème il a proposé une solution. Il est arrivé sur le projet Debian en 2002 à 22 ans avec déjà pas mal de package et de travaux à son actif. Il était très favorable à systemd au début systemd is right at the top of the list et ce après avoir jeté un oeuil à d'autres implémentations comme OpenRC.
Il a notamment longuement participé à la discussion sur la séparation du /usr (qui est parfaitement supportée par Debian) et des conséquences que systemd pourrait avoir, ainsi que les diverses solutions que l'on peut apporter mount /user during init et de façon générale il a très longuement discuté son point de vue pendant la troisième partie du sondage init : Mailing List Debian
Donc des arguments il en a sorti des pelletées. Il n'a pas jugé utile de tous les rappeler dans son mail dans lequel il se dit prêt à participer à un fork - mais très honnêtement ce n'était ni le lieu ni le moment.
Donc
a) Roger Leigh n'est pas à l'origine du Fork (du moins pas à ma connaissance).
b) Il n'abandonnera probablement pas Debian même si il aide sur Devuan.
c) Il expose son opinion et ses arguments depuis des années.
Voilà voilà.
[^] # Re: Trop facile résumé...
Posté par Kaane . En réponse au journal Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 8.
mais juste changer de système d'init
systemd va bien au delà du système d'init, il controle les cgroups, le système de log, la création des devices aussi bien au boot que dynamiquement, la création des consoles, les sessions utilisateurs etc.
Pour l'instant on a des alternatives possibles pour la plupart des éléments séparément, mais au fur et à mesure que systemd avance ces alternatives deviennent de plus en plus complexe, et certaines sont impossibles. Par exemple les cgroups sont hardlockés et le système de log doit passer par systemd si systemd est installé (et en plus il faut faire pas mal de modifications pour que systemd daigne renvoyer des infos ET les logs sont dans un format différents du format habituel cf http://www.freedesktop.org/wiki/Software/systemd/syslog/ )
Prochaine étape annoncée : pas moyen de dialoguer avec udev si kdbus n'est pas présent dans le noyau (http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html)
Ensuite kmscon obligatoire, plus de getty ? On ne sait pas.
Donc non, le problème de systemd est très loin d'être la partie init (qui est même plutôt bonne en fait - bien qu'insuffisante poru certains besoins spécifiques). Mais bon c'est juste un daemontools inittabisé donc pas de crainte à avoir de ce coté là .Le problème de systemd c'est tout le reste.
[^] # Re: Trop facile résumé...
Posté par Kaane . En réponse au journal Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 7.
je ne crois pas que systemd soit si tentatuculaire qu'il va impacter 10 000 paquets ou plus.
Non juste les paquets qui utilisent les libs systèmes (et par ricochet tous les paquets qui reposent sur des paquets qui utilisent des libs systèmes).
Donc potentiellement tous oui. On est pas encore tout à fait au point ou on peut considérer que Linux avec systemd et Linux sans systemd sont deux OS distincts (Comme GNU/Linux et Android) mais on s'en rapproche vite.