Logo journal du hacker middle
    1. 1

      Il y a quelques erreurs et approximations parfois hasardeuses dans cet article. Si vous avez besoin d’aide pour le corriger vous pouvez me contacter.

      1. 1

        Mon petit doit me dit qu’il ne va pas tarder à forker…

        1. 1

          Voilà il existe déjà, c’est ici : https://github.com/cookiengineer/audacity

        1. [Comment removed by author]

          1. 3

            (wow sacré commentaire !)

            Le rapport de l’ADEME concernant la consommation des mails est complètement à côté de la plaque et malheureusement est utilisé constamment. Il mériterait d’être refait et réévalué surtout que depuis le temps les technologies ont évoluéesk

            La blague d’imprimmer un mail pour être plus écolo au lieu de le lire sur un écran est quand même la meilleure.

            1. 2

              Excellent commentaire !

              J’ajouterais qu’étant moi même hébergeur de multiple solutions, je peux garantir que le mail est une part infime de la consommation en bande passante des foyers (serveur familial). Le mail, et le trafic web classique sont ridiculement petits face à la consommation de vidéo et de musique. Dans mon foyer avec les serveurs pour toute la famille élargie qui tournent (mail, site web et cloud) Youtube, Peertube et Netflix représente à eux seul autours de 90% du trafic. Pourtant on est pas de de gros consommateur de vidéo. Si tu ajoutes que pour beaucoup aujourd’hui le trafic télévision (en HD) passe aussi par la box magique, je pense qu’aujourd’hui, au moins 95 % du trafic web français serait d’une manière ou d’une autre de la vidéo.

              Même en messagerie instantanée, le trafic texte et voix (qui est très compressé) est extrêmement faible face à un appel vidéo.

            1. [Comment removed by author]

              1. 2

                Ce n’est pas ce que je comprends à la lecture des réactions. Ce que je comprend et partage, c’est d’une part la méthode utilisé, mais si la colère peut la justifier, il est sain de la dénoncer et de la considérer non constructive (mais probablement que ça aura fait du bien à l’autrice). Bref avoir un regard critique indépendamment des considérations idéologiques.

                D’autre part je considère normal de dénoncer la généralisation : ce n’est jamais sain d’attribuer à tout un groupe des comportements individuels, quand bien même ces comportement pourrait être majoritaire. Et si tu dis qu’il le sont, il faut le démontrer. Chaque fois que l’humanité s’est mise a accuser de différent maux une partit de la population du simple fait qu’elle appartient à tel ou tel autre groupe de personnes, ça a toujours conduit à des trucs plutôt vraiment dégueulasse…

                D’autre part il y a un facteur que les féministes exclues toujours d’amblé : les femmes qui rejettent dans leur grande majorité les études technique (et pas seulement informatique). Il y a plusieurs explication, comme incompétence acquise, l’environnement socioculturel notamment à travers les jouets ou contenus culturels à destination des enfants qui sont genré par les parents… Mon expérience (qui vaut ce qu’elle vaut) m’a plutôt montrer que bien avant que les femmes puissent avoir une quelconque idée de ce que puisse être leur futur environnement professionnel, excluaient de faire de telles études.

                Le route sera longue, mais la voie ne sera libre que si nous commençons collectivement par enlever le sexisme de l’éducation des enfants.

                1. 1

                  Dans les autres facteurs, tu peux également ajouter la biologie avec les modifications qu’engendrent les hormones sur le cerveau et le corps en général ainsi que sur l’humeur. Tu as également des modifications des hormones en fonction de l’environnement de l’individu.

                  Ces modifications impactent également les centres d’intérêt des individus.

                  1. 1

                    Il n’y a pas de consensus scientifique sur le sujet donc je me garderais de toute prise de position, surtout sur des sujet aussi inflammable…

                    Toutefois j’ai un point de vu un peu différent du fait de mes voyages au Philippines et à Singapour ou le sexisme est très différent. Notamment les déséquilibres dans les filières de formation sont nettement moins marqués. Les asiatiques sont poussés dans les études quelque soit leur sexe et la notion de genre dans la pratique d’un métier est beaucoup plus faiblement marqué. Par contre, c’est très fort sur les jouets, la répartition des tâche quotidienne, et les évolution de carrières.

                    D’un autre coté, les femmes ont souvent autorité dans le foyer, y compris la gestion du budget, et sur l’éducation des enfants. Il n’est pas rare que les hommes aient à demander de l’argent de poche à leur femme pour pouvoir sortir, même si les moyens de paiement électronique, infiniment moins répandu que chez nous, viennent limiter ce pouvoir des femmes. Aussi beaucoup de femmes continue de travailler lors de l’arrivé du premier enfant dont l’éducation est confiée au parents ou grand parents (en Asie, il est d’usage que la maison familiale accueillent 3 ou 4 générations).

              1. 1

                Twitter ? Cet espèce d’immense tribunal à ciel ouvert doublé de fosse à purrain de l’esprit critique ? C’est tout à fait dispensable…

                1. 1

                  Je n’ai pas été assez vigilant sur la qualité de l’info (et je ne suis pas très au courant de ce qui se passe chez Mozilla)… Bref, j’ai masqué l’article. Désolé !

                  1. 1

                    Salute,

                    Pour info “masquer” ne masque l’article que pour toi.

                    Tcho !

                    1. 1

                      Ha mince… Pas moyen de la dégager définitivement ? Ça arrive de se tromper !

                  1. [Comment removed by author]

                    1. 1

                      Déjà que ces panneaux me fatigue… Si en plus ils se mettent à moucharder, je risque bien en effet d’avoir très envie de les vandaliser !

                    1. 1

                      Super initiative. Pour ma part j’utilise l’extension Firefox Dark Reader qui fait un très bon boulot. Il faudrait que l’image du logo du JDH utilise un fond transparent pour améliorer le rendu (que ce soit avec Dark Reader ou ton CSS)…

                      1. 1
                          1. 1

                            Une faille exploitable seulement avec une mauvaise configuration de sudo, mais malheureusement beaucoup de configuration par défaut comme ça.

                            Sudo devrait seulement être configurer avec une liste blanche et non avec une liste noire.

                            1. 1

                              Je n'ai au contraire jamais croisé la règle (ALL, !root), pas même en configuration par défaut. Ou peut-être que c'est la règle par défaut dans Mac OS, ce qui expliquerait pourquoi c'est eux qui ont trouvé la faille :).

                              1. 2

                                Quand je dis par défaut, pas out of box, mais je l'ai souvent rencontré en entreprise, car plus simple niveau configuration.

                                La configuration par défaut est par contre une faille en elle même, donner tout les droits à un utilisateur, ce n'est pas secure.

                                Autre que pour le nom de la machine, et dans le cas d'une infra mono-serveur, mono-utilisateur, le terme ALL ne devrait jamais être utilisé

                                1. 1

                                  Jamais rencontré en entreprise non plus, je n'en ai pas écumé des centaines cela dit mais s'amuser à donner tous les droit sauf root à un utilisateur est de toute façon une mauvais pratique. Un responsable DSI sérieux ne laisserait jamais faire ça.

                                  Mais autrement, totalement d'accord avec ton commentaire.

                                  1. 1

                                    Pour moi c'est simplement installer sudo qui est une mauvaise pratique…

                                    1. 1

                                      ça reste mieux que de donner les mots de passe des utilisateurs spécifique à plusieurs personnes, ou pire l'utilisateur root. En serveur perso ou tu es tout seul dessus, pas de soucis, mais en entreprise, quand tu dois avoir 50 personnes qui sont susceptible de devoir faire des actions, y'a rien de mieux que sudo (ou doas pour openBSD), par exemple quand tu as un services de supervision en 24/7, c'est bien qu'ils puissent être autonome dans la relance de service, sans pour autant leur donner les droits full root pour le faire.

                                      1. 1

                                        Non, ce ne sont quand même pas de bonne pratique, j'insiste. Les groupes et les ACLs c'est fait pour ça, et ça fonctionne très bien. Dans mon labo de recherche on fonctionne comme ça et tout le monde peut bosser sans aucun problème, y compris des développeurs ou des gens qui conçoivent des outils de mesure et les trucs qui vont avec (et qui finiront dans des satellites). Vu le fric que ça coute je t'assure qu'ont ne fait pas d'économie sur les tests.

                                        Après c'est sur c'est moins pratique et il faut bosser, mais notre niveau et exigence forcément très élevé de sécurité n'est pas compromis par ce genre d'outil, ce qui dans notre cas n'est pas négociable.

                                        1. 1

                                          Je ne vois pas comment tu peux faire de l'administration système grâce au ACLs, à part en jouant avec le SUID et GUID, ce qui reste pire que sudo, tu augmentes grandement la surface d'attaque. Car dans ce cas ça veut dire que les administrateurs et techniciens ont des comptes avec des permissions élevés, sous Unix, un utilisateur doit être un simple utilisateur, et demander des permissions élevés temporairement (via compte root ou sudo). D'ailleurs ça m'agace de voir des connexions root sur les serveurs.

                                          De plus avec les ACLs, tu peux seulement limiter l'accès (rwx) sur un fichier, par exemple tu ne peux pas dire qu'un utilisateur ne peux utiliser que l'argument status de systemctl, mais seulement l'autoriser à utiliser systemctl ou non.

                                          1. 1

                                            Tu viens de démontrer la supériorité des scripts init. Chez nous Systemd n'est pas du tout le bienvenu. En plus ce truc est une faille de sécurité à lui tout seul. Les évaluations en termes de sécurité et qualité de code des travaux de Lennart Poetering sont assez catastrophique…

                                            Nos outils disposent des permissions nécessaire pour être utilisés. S'il le faut nos scripts init peuvent appartenir au groupe qui pourra les manipuler (c'est ultra rare par ailleurs, ils peuvent faire une quantité astronomique de choses en espace utilisateur). Les rares qui veulent être admin de leur machine sont dans un réseau à part (bac à sable). On peut aussi jouer avec des outils comme Policykit mais dans notre cas ça n'a jamais été nécessaire. Et bien évidemment personne à part les deux ASR habilité n'a de mot de passe root, jamais.

                                            Alors, oui, il arrive que parfois un utilisateur viennent nous voir pour nous demander de faire un truc qu'il ne peut pas faire sans être root, mais c'est notre boulot et au passage ça nous permet d'évaluer la pertinence de la demande et de la valider ou la rejeter (et proposer une alternative). Quoi qu'il en soit, nous n'avons jamais trouvé de bonne raison ou de cas ou l'usage de sudo serait nécessaire.

                                            1. 1

                                              Pour les applications métiers je comprends, c'est d'ailleurs ce qu'on fait, chaque applications à son propre utilisateur, et son lancer par un script init perso, donc chaque opérateur à le droit de lancer sudo -u UserAppli pour lancer les taches de maintenance de cette appli. Après de mon cotés, aucun outils n'est exécuter en local sur les machines, les utilisateurs n'ont que des IHM. Les devs n'ont par contre en aucun cas accès au machine, les environnements sont généré à la volée via jenkins.

                                              Par exemple dans ma boite on compte plus de 500 informaticiens (tout métier confondu), dont environs 100 pour la gestion de l'infrastructure (15 techniciens d'exploitation/supervision présent H24, 7/7j, une 20ène d'admin et ingé, les intégrateurs, les analystes etc …), chacun doit être capable à n'importe qu'elle moment de pouvoir redémarrer un serveur, ou simplement un service système ou une application, pas le choix d'avoir un accès “root” pour redémarrer sshd par exemple.
                                              Franchement j'aimerai me passer de sudo, mais franchement je ne vois pas comment faire pour que si user1 lance un script d'init d'un service, ce script se lance avec les permissions de userX.
                                              A part utiliser que des comptes génériques ou technique où on partage les mdps, on a essayé, jusqu'a ce qu'un petit malin décide de changer des mdps sans prévenir personnes.

                                              1. 1

                                                Les évaluations en termes de sécurité et qualité de code des travaux de Lennart Poetering sont assez catastrophique…

                                                Tu aurais une source à ce sujet stp ? Ca m'intéresserait.

                                                1. 3

                                                  C'est le résultat d'une étude interne qui a simplement consisté en la lecture de quelque fichiers pris au hasard dans différents de ses projets. Ensuite il y a les fréquentes alertes de sécurité à propos de Systemd (mais aussi PulseAudio et d'autre trucs, internet t'en dira long), au hasard : * https://www.itprotoday.com/linux/linuxs-systemd-hit-three-security-holes * https://news.slashdot.org/story/18/10/27/196227/new-systemd-vulnerability-discovered

                                                  À noter qu'à l'inverse je n'ai jamais entendu parler de graves failles de sécurité dans SystemV init ou BSD init.

                                                  Il y a aussi les pétages de câbles légendaires de Linus Tovald sur le comportement de Poettering et de certains de ses développeurs. Par exemple, je ne ferait jamais confiance en des devs qui se comportent comme ça (et je comprend parfaitement la position de Torvalds) : * https://news.ycombinator.com/item?id=19023232 * https://www.phoronix.com/scan.php?page=news_item&px=mty1mza

                                                  Sans compter que par principe, le processus 1 (init) doit être ultra protégé et qu'un plantage de ce processus provoque l'effondrement de tout le système. Idéalement, c'est du KISS. Et enfin le non respect des principes fondamentaux d'Unix (un outils, une tâche) ne sont pas de bon augure non plus.

                              1. 1

                                Putty, un émulateur ? Sérieusement ? Ils ont fumé quoi chez Dévelopez ? Encore un Windowseux qui ne comprend rien à la ligne de commande !

                                1. 1

                                  PuTTY est un émulateur de terminal doublé d'un client pour les protocoles SSH, Telnet, rlogin, et TCP brut. Cf. Wikipedia.

                                  Dans le sens où il émule un terminal.

                                1. 1

                                  Le problème, c'est que c'est écrit par un éditorialiste économique…

                                  1. 1

                                    C'est sûr, ça doit jouer… Ils en tiennent quand même une sacrée couche ! J'aurais préféré un article écrit par un technicien, y'a vraiment des choses à dire là dessus. Ici la formulation est gerbante.

                                    1. 1

                                      …ou comment on fait un concours de bite avec un numéro de version !

                                      1. 2

                                        Mouai je trouve ça réducteur.

                                        En vrai ils veulent juste sortir des versions plus fréquemment… C'est juste dommage de pas passer en rolling carrément. Ou au moins à des numéros de versions sous forme de date.

                                        1. 1

                                          Sauf que vouloir faire plus et plus vite ça va forcément impacter la qualité du code qui n'est déjà pas un exemple à suivre. Mozilla n'a pas la puissance de frappe de Google donc selon moi, c'est sûrement pas la meilleure approche. Il ferait mieux de se démarquer avec des fonctionnalités originales.

                                      1. 5

                                        Les cons ça oses tout, c'est même à ça qu'on les reconnais…

                                          1. 1

                                            Pour info, c'est du Cobol qui pique les yeux…

                                            1. 1

                                              … et y'a une erreur assez basique dans un de ses fichiers. Article à venir, sur dénonciation d'un coboliste.

                                              1. 1

                                                J'y connais rien en Cobol, trop vieux (et en voyant du code, ça donne pas envie)

                                            1. [Comment removed by author]

                                              1. 1

                                                Oui en espérant que la version de Huawei ce soit pas trop blindée de saloperies… Toutefois ça peux quand même apporter sont lot de nouveaux développeurs/testeurs, ce qui reste une bonne chose.