La rente de Microsoft c'est toujours Windows et MS Office
Oui et non. Le chiffre d'affaire en 2019 de la division "intelligent cloud" (produits serveurs et services cloud, Microsoft Azure…) est au même niveau que la division "Informatique Personnelle" (Windows, Microsoft Surface, Xbox, search…) et que la division "Productivité et entreprise" (Office 365 et Office, LinkedIn, Microsoft Dynamics…)
Aux alentours de 11 milliards de dollars chacune pour le 4ieme trimestre 2019..
ça sent le manque de Ram, ou une incompatibilité matériel coté carte graphique. N'aurais-tu pas activé des préférences de fonctions expérimentales liées à la CG dans Firefox ? Essaye avec un profil vierge.
Bientôt on pourra se passer des sysadmins et c'est une bonne chose
Alors déjà : non (voir plus bas).
Ensuite, c'est marrant que tu dises ça, alors que plus loin :
Mais dans un contexte de PROD et d'exploitation :
quand il y a un soucis de performance comment cela se passe ?
Quand tu as ça, tu fais justement appel… à un admin système.
À moins que tu sois tout seul à tout faire dans ta boite, ce n'est pas aux développeurs de s'occuper de la prod, de s'occuper de l'infra et de ses problèmes. C'est aux admin sys que tu crois qu'ils vont disparaître.
Admin sys est un vrai travail, un vrai métier, qui est utile pour faire en sorte que ce que produisent les développeurs (du code, des services et éventuellement sous forme de conteneurs Docker), soit opérationnel dans la vrai vie (le laptop du dev, ce n'est pas la vrai vie, c.a.d, n'a pas les contraintes d'un environnement de production).
Opérationnel veut dire :
monitorer pour détecter les pannes, les ralentissements, les problèmes
configurer l'infra de manière à ce que tout puisse tourner correctement, qu'il y ait une petite charge ou une grosse charge, que le produit des développeurs soit nickel ou codé avec les pieds
sécuriser
sauvegarder
faire des plan de reprise d'activité
remplacer le matériel défectueux ou en fin de vie (quoique il peut y avoir du personnel dédié à ça dans des grosses boites ou datacenter)
etc etc etc…
Et pour répondre plus précisément à ta question, quand il y a des soucis de perfs, d'abord c'est grâce à l'admin que tu peux savoir d'où ça vient (à moins que toi en tant que dev, tu n'a rien d'autres à foutre que de surveiller et d'analyser les problèmes de prod), et ensuite, c'est soit la faute à l'admin sys (ne dimensionne pas/ne configure pas correctement les machines et les réseaux), soit la faute à l'architecte logiciel (ex: pas de système de cache ou a fait des choix techniques merdiques), soit la faute au développeur qui a codé de la m..de, avec par exemple des empilements de framework à tout va, des milliers de paquets npm, des algo foireux ou encore a utilisé Java [1]
Disclaimer: je suis avant tout un dev, mais aussi admin sys à mes heures perdues, et je n'aurais jamais cette prétention de pouvoir remplacer un vrai admin sys. C'est juste impossible de tenir les 2 rôles correctement dans une boite qui veut grandir.
J’espère sérieusement que tu ne chiffres pas tes partitions avec une clef stocké en clair sur la même machine.
Je ne chiffres pas les partitions de mes serveurs, puisque je n'en vois pas trop l'interet.
Par contre, vraie question : si la clé n'est pas sur le serveur, comme fait-on pour avoir un serveur qui puisse rebooter tout seul ? Ou comment fait-on pour indiquer la clé au redémarrage d'un serveur distant ?
Je crois savoir l'intérêt (relatif): une fois que tu rend la machine, celle-ci est louée à une autre personne. Cette personne pourrait analyser le contenu du disque, et essayer de récupérer le contenu des anciennes partitions (avec beaucoup de patience).
Si les partitions sont chiffrés, cela devient bien plus compliqué. Il faut pouvoir retrouver la clé de déchiffrement de la partition. Ce qui, il me semble, est d'autant plus compliqué qu'il y a de forte chance que l'endroit ou elle était stockée ait été écrasé lors de la réinstallation du système.
Toutefois, cette précaution de chiffrer une partition n'est utile que pour les serveurs physiques. Pour les VM et autres conteneurs "cloud", ce sont des disques virtuels donc, données irrécupérables après recréation des partitions virtuelles.
Et encore, pour les serveurs physiques, OVH dit qu'il détruit toutes les données sur les disques avant de remettre le serveur en location. Par contre je n'ai pas trouvé l'information qui explique en quoi consistait exactement cette destruction.
Mouai.. En imaginant qu'un "indélicat" arrive à se procurer un snapshot. Rien ne l'empêche de le remonter sur sa becane avec les bons outils. La VM démarre, déchiffre le disque. Et… au final le chiffrement du disque ne protège rien.
Sauf si le chiffrement s'est fait avec une clé avec passphrase. Mais pas très pratique pour un serveur. D'ailleurs je doute qu'on puisse indiquer la passphrase au lancement d'un serveur sur OVH…
Perso, je préfère leur système actuel, la première solution.
Et moi aucune des deux.
La vrai solution, et la plus sécurisée : tu met ta clé publique dans ton compte OVH, tu la choisi lors de l'installation de la machine. Tu reçois un mail sans mot de passe et tu n'as pas de souci de pirate qui scruterai ta boite mail.
Au sujet du compte OVH piraté : ça ne devrait pas arriver. Si cela arrive, c'est que tu n'as pas assez sécurisé son accès (par une double authentification par exemple).
Bref, comme tu dis, OVH ne sont pas des débutants…
Si tu parles du compte OVH, heureusement que le mot de passe root n'est pas indiqué au moment où tu créés ton compte, car cela signifie alors qu'il est stocké/haché quelque part. Conséquence : sécurité moyenne, et surtout, si tu changes ton mot de passe root sur la machine, celui stocké dans ton compte OVH n'est plus valide.
Si tu parles du compte root proprement dit, que tu saisirais dans le formulaire d'installation de la machine, je ne vois pas l’intérêt. Parce que là, tout comme sa génération automatique et envoi par mail comme aujourd'hui, tu ne sais pas où le mot de passe est passé et stocké (même temporairement) lors du processus OVH d'installation de la machine, donc de toute façon, il faut le changer à la première connexion sur ta machine.
Et puis de toute façon, c'est une hérésie d'utiliser un mot de passe pour le compte root : dés la première connexion, la première chose à faire est de changer le mot de passe, poser sa clé ssh, et interdire les connexions par mot de passe (au moins pour le root) dans la config du serveur ssh de la machine.
"voila, vous pouvez vous logguer via l'utilisateur root avec le password 123456". J'exagère sur le password, il y avait aussi des lettres, mais la taille est a peu près celle-ci. Ah, et bien sûr, le fingerprint du ssh du serveur…
C'est surtout de ta faute : si tu n'indiques pas de clé ssh dans ton profil, il faut bien, que puisses te connecter sur ton VPS fraîchement installé. Tu veux qu'ils t'envoient ton mot de passe par télépathie ?
Ensuite, faut vraiment pas avoir de bol pour se faire pirater son VPS fraîchement installé, entre le moment où ils t'envoient le mail, et le moment où tu te connectes la première fois et que tu changes ton mot de passe ;-).
Si ça existe, j'ai pas trouvé
"mon compte > services > clés ssh"
je ne mentionne pas le fait que le /etc/sources.list, de mémoire, n'utilise pas les serveurs debian, mais un repo OVH, ce que je peux comprendre, mais j'aurais préféré un proxy genre apt-cacher-ng
Les dépôts sont ceux d'OVH, pour plusieurs raisons :
ils sont sur leur lan, ça va donc plus vite à installer (et pas de bande passante à payer pour eux vers l’extérieur)
ils peuvent avoir des noyaux optimisés pour leur matos
cela permet d'installer leur outil de monitoring pour que tu ais de beaux graphiques dans le manager.
Mais :
tu peux changer tout ça en faisant pointer sur des dépôts originaux (et d'ailleurs, si je ne me trompe pas, en faisant un apt update && apt upgrade, tu remarqueras probablement qu'au final, il ne réinstalle rien : ce sont les paquets originaux)
tu peux même installer un noyau vanilla (et même t'installer un noyau custom, on le fait sur certaines machines)
tu peux virer leur outil de monitoring.
Pour le reste, peut être que l'offre VPS n'est pas ce qu'il te faut pour ton besoin. Je ne sais plus pour les VPS, mais je sais qu'en prenant un serveur physique (j'en gère des dizaines), tu partitionnes comme tu veux avant l'installation de l'OS.
J'aimerais bien un retour d'expérience pour les VPS chez d'autres hébergeurs, voir si c'est aussi "compliqué" de partitionner et de chiffrer…
Luanit est un framework de tests unitaires. Dans un projet, il est donc susceptible d'être lancé à chaque push sur le dépôt du projet, si il y a de l'intégration continue.
Normalement, dans un système d'intégration continue bien fait et bien configuré, les dépendances externes ne sont installés au moment du lancement des tests que quand leur version change ou qu'elles sont nouvelles. Dans gitlab-ci, il est ainsi possible de mettre par exemple un répertoire de dépendances comme node_modules (paquets npm), dans un cache. À chaque lancement de l'intégration continue, gitlab-ci, créé les répertoires de dépendances à partir de son cache. Cela évite au packageur (ici npm), de re-télécharger tous les paquets.
Mais ça c'est quand c'est bien fait.
Il y a des projets où c'est mal foutu : utilisation d'un outil d'intégration continue pas cool, ou mal configuré.
Du coup, à chaque push sur le dépôt d'un de ces projets, téléchargement systématique des dépendances. Sur un projet bien actif, cela peut en provoquer des dizaines par jour. (Pour SlimerJS, j'avais eu des soucis d'un serveur de je ne sais où qui téléchargeait toutes les 2-3 minutes le paquet : il me bouffait toute la bande passante de mon serveur d’hébergement !)
Du coup, les statistiques ne veulent pas dire grand chose. Cela ne correspond pas au nombre d'utilisateurs, donc à la popularité de l'outil.
Disons que c'est une popularité artificielle, qui peut avoir tout de même un bénéfice : avec des stats gonflées ainsi artificiellement, cela propulse le paquet dans les hauteurs des classements des "projets les plus utilisés", donc ça incite plus facilement à ceux qui doivent choisir, d'utiliser le projet en question. Ce qui fait encore plus gonfler les stats etc..
Parce que j'utilise Thunderbird depuis sa toute première version, et à chaque mise à jour, il y a des évolutions, en particulier depuis ces 2-3 dernières années. Ok, au niveau fonctionnalités, il n'y a pas de révolution à chaque fois. Mais ça bouge. Beaucoup même ces derniers temps.
Et j'en sais quelque chose : je maintiens pour un client une appli mail qui repose sur thunderbird (c'est un thunderbird avec une tout autre interface, sans passer par une extension, donc il y a des patchs, des modules XUL additionnels etc), et à chaque upgrade, j'ai toujours eu des problèmes de compatibilité avec les api internes, et donc des adaptations à faire, parce que justement, ça bouge.
Et c'est de pire en pire depuis 2-3 ans, surtout en ce moment, car XUL/XBL/etc commence à disparaître de Gecko, donc de TB. Là, concrètement, pour faire le passage à TB 68, l'appli mail du client est toute cassée. Faut que je refasse plein de trucs.
Donc non. TB n'est pas immobile. Peut-être que tu trouves qu'au niveau fonctionnalité ça ne bouge pas trop, mais je t'assure qu'ils font beaucoup de boulot "qui ne se voit pas", pour tuer le code legacy et pouvoir, dans un future proche, bouger encore plus vite.
En théorie. Seulement en théorie. Un moteur de navigateur, c'est pas un hello world. C'est très complexe, très gros. Il faut avoir les moyens financiers d'une grosse boite pour forker un tel projet. Même Microsoft ne s'y est pas risqué.
Ce qui peut être gênant, c'est d'avoir un fournisseur final majoritaire (Google) qui du coup peut dicter un peu plus le futur, pas que le moteur soit unique.
ça ne peut pas être gênant. ça peut être TRÈS gênant. Voir cauchemardesque. Qu'une boite, commerciale, dicte le futur de standards ouverts, c'est toujours mauvais à long terme.
je l'aime beaucoup ce IP qui a tué toutes les diversités
IP est un protocole, pas une implémentation. Fort heureusement, il y a plusieurs implémentations, qui ont permis à IP d'exister et de se répandre !
la responsabilité est de ton côté
Trop facile de balancer la responsabilité du coté des utilisateurs. Comme si tout le monde pouvait, savait, modifier un navigateur.
Tout d'abord il y a au moins une autre application non liée à Mozilla qui s'en sert : Songbird
Oui, mais non. Songbird n'était pas une application qui embarquait gecko, mais qui reposait sur gecko, ou plus exactement XulRunner. Comme la majeure partie d'application XUL de cette époque. Songbird était loin d'être la seule, il y a en a eu plein d'autres : Thunderbird, Nvu, Komodo Ide, Chatzilla et j'en passe.
Il y a une différence entre embarquer Gecko, le moteur de rendu et utiliser XulRunner comme runtime. Le second, c'est en gros Firefox sans son interface : on a donc Gecko, mais aussi tout un framework et des composants XUL ou techniques prêt à l'emploi.
Gecko, c'était vraiment que la partie moteur de rendu et XPCOM (système de composants binaire ou JS).
Il fut un temps où il y avait la possibilité d'embarquer Gecko, c'est à dire d'avoir un lib avec une API, permettant d'instancier un moteur de rendu, de le manipuler (charger une page etc).
Camino, mais aussi d'autres navigateurs de l'époque, utilisaient cette lib. (donc ce n'était pas des applis XUL).
XulRunner, plus simple à utiliser pour développer une application, avait pris le dessus, entre autre parce que Thunderbird l'utilisait et que donc Mozilla le maintenait, et Mozilla du coup mettait moins de moyen sur la partie "embeddable" de Gecko.
L'API embed fut donc de moins en moins maintenue. Et quand Mozilla decida d'abandonner XulRunner puis le XUL, c'était trop tard pour relancer le projet embed. Presque plus personne n'utilisait cette API (Camino était mort…).
Ensuite, il y avait peu de contributeurs sur cette api embed.
En clair, contrairement à ce qui s'est dit, ce n'est pas une vraie volonté de Mozilla de ne pas rendre Gecko embarquable, c'est juste que les moyens manquaient, et qu'il y avait d'autres priorités à l'époque.
Il y a bien eu quelques workshops (il y a de cela 10 ans) pour tenter de relancer le projet de cette API, (j'avais assisté à l'un d'entre eux), mais la mayonnaise n'a pas pris.
Depuis, ils se sont un peu rattrapés : Servo, le moteur 100% en rust de mozilla est fait depuis le début pour être embarqué. Et il y a une lib embarquant gecko pour les navigateurs pour Android, geckoView, qu'utilise Firefox pour Android (ou d'autres variantes, je n'ai pas trop suivi).
Je ne sais pas ce qu'il en est aujourd'hui de cette API embed de Gecko.
non, du moment que le travail demandé est fait dans les temps.
Bosser sur des projets perso, ça fait partie de la "veille" selon moi. D'ailleurs c'est pas pour rien que chez Google ou d'autres boites, les développeurs peuvent passer (ou pouvaient, je ne sais plus si c'est le cas chez Google) 20% de leur temps pour développer sur des projets libres de leur choix.
Une boite qui ne laisse pas faire de la veille à ses devs, c'est une boite à fuir. En tout cas de mon point de vue.
Il faudrait revoir je pense l'affichage des pastilles qui indiquent le nombre de permis. Leur position n'est pas très cohérente avec la réalité du terrain. Un exemple: à un certain niveau de zoom, je me suis retrouvé avec une grosse pastille affichant 152 en plein milieu de belle-île en mer, alors qu'en fait il y en a une vingtaine sur l'île.
Il faudrait donc les positionner géographiquement, par communes par exemple, plutôt qu'en grille (regrouper par "carré", ça n'a pas de sens selon moi).
Le CV que tu montres indique que quand Netscape a libéré Mozilla, Tristan Nitot a fait de la promotion de Mozilla
Oui, donc, Tristan Nitot faisait du libre AVANT de quitter Netscape, pas après, contrairement à ton commentaire précédent.
À moins que pour toi, faire du libre, c'est forcément une activité non payée ? Ou c'est forcément taper des lignes de code ?
Pourtant tu as aussi écrit qu'il est resté salarié 10 ans chez Mozilla. Donc bon ça a dû payer à un moment
Bien sûr qu'il a en quelque sorte créé son poste. mais quand on créé son poste dans ces conditions, à savoir du bénévolat sans salaire pendant plusieurs mois, c'est aussi et surtout par conviction, par envie de travailler sur le projet en question. Pas pour des raisons purement pécuniaire.
Sinon, on en parle des locaux de luxe de Mozilla Europe à Paris?
C'est quoi le rapport avec Tristan ? Une boite qui fait du libre n'a pas le droit de louer des locaux dans un bâtiment comme celui-ci ? (qui ne sont pas aussi cher que l'on pourrait croire, car monument historique, donc beaucoup de contraintes techniques, dont le fait par exemple de ne pas pouvoir accrocher des équipements réseaux aux murs etc..)
Au passage : Mozilla n'est plus dans ces locaux depuis quelques semaines…
Comment on peut prétendre faire la promotion du libre si on n'utilise pas un système libre?
Parce que le libre ne se résume pas à Linux !!
Quand à l'excuse des vidéoprojecteurs, elle est bancale. Il y a des tonnes de conférenciers qui ont des ordinateurs sous Linux dans toutes les confs d'informatique où je vais et ça marche
Aujourd'hui oui. Il y a 10 ans (l'époque dont on discute) non.
Tu ne veux pas utiliser Linux, c'est ton droit,
Franchement, faut apprendre à lire hein. Je n'ai absolument pas écris que je n'utilisais pas Linux. Je l'ai écrit et je le réécrit : Linux est mon OS principal depuis 18 ans, sur mes machines pro et perso !
dans le cas de Nitot, c'était assumé,
Oui, tout à fait. Où ai-je écris le contraire ? Il ne voulait pas s’embêter avec ces problèmes de compatibilité de matériel. C'est ce que j'ai voulu expliqué.
je dis juste que ce n'est pas le gentil libriste désintéressé qui est parfois présenté, c'est tout.
C'est ton avis, mais avant d'avoir ce genre d'avis sur des gens, on essaye de le connaître..
Tu te caches derrière ton pseudo, donc je ne sais pas qui tu es ou ce que tu as fait pour le libre, mais il y a forte chances qu'il en a fait beaucoup plus que toi, qu'il soit désintéressé ou pas.
Pas par des lignes de codes, mais par avoir fait connaître Firefox, Mozilla et les logiciels libres en général. Par avoir, avec sa bonne humeur, ses convictions, donné l'envie à bon nombre de contributeurs francophone, de contribuer au projet (code, doc, localisation etc…) ou même sur d'autres projets, qui a leur tour en ont entraîné d'autres dans l'aventure etc..
Je voudrais rajouter aussi une raison de l'utilisation de MacOs plutôt que Linux, en particulier pour un utilisateur qui doit souvent se brancher sur un video-projecteur, pour des conférences ou des réunions.
Comme je le disais, j'utilise Linux depuis 18 ans. Ça fait beaucoup d'occasions de faire des conférences ou des réunions, et donc des occasions d'avoir à brancher un video-projecteur sur mon laptop linux.
Au début de chaque conf/réunion, ça a toujours été le stress de savoir si le branchement sur le vidéo-projecteur allait fonctionner. 1 fois sur 2 (et je suis gentils), ça ne fonctionnait pas du premier coup. Y avait toujours un truc à régler ici ou là, à trouver le pourquoi du non-fonctionnement, avec parfois obligation de rebooter avec la prise déjà branchée pour que le video-projecteur soit reconnu. Bref, Linux et la video-projection : c'était la galère. ça s'est amélioré ces dernières années, avec la généralisation du hdmi, et l'amélioration des interfaces utilisateurs pour les réglages. Mais franchement, c'était pas la joie.
Entre 2009 et 2011, j'ai utilisé un Mac au boulot. Chaque fois que je devais faire une présentation, quelque soit le vidéo projecteur (en vga ou hdmi) : je branchais, ça marchait. Toujours. Et j'ai rarement vu un conférencier galérer avec son Mac.
Donc franchement, quand on est un communiquant, surtout dans les années 2000-2010, je comprend tout à fait qu'on choisisse un Mac. Le job d'un communiquant, ce n'est pas faire de la ligne de commande pour débugger l'affichage d'un vidéo projecteur. C'est de communiquer.
Oui en tant que responsable marketing, son combat est le thème de son poste. Quoi de plus normal en effet.
Mais note qu'avec ses compétences et son CV, il aurait très bien pu, après Mozilla, aller chez Microsoft, ou tout autre grosse boite "du mauvais coté". Si il n'avait pas de convictions comme tu sembles le prétendre, ça se serait fait en un claquement de doigt, j'en suis certain (1).
Mais il ne l'a pas fait. Il a préféré une petite boite qui faisait du libre et qui défendait la vie privée (Cozy Cloud), puis une boite qui défend aussi la vie privée (Qwant).
Cela montre quand même qu'il a des convictions (libre, vie privée etc), et qu'il ne fait pas ça "juste pour le poste" comme tu dis plus haut.
(1) je l'ai côtoyé régulièrement pendant plus de 10 ans quand il était chez Netscape et Mozilla, je connais un peu le bonhomme.
Il a passé ses dernières années à Netscape à faire la promotion des standards du web et la promotion des technologies du projet de navigateur libre, Mozilla.org (aka la suite Mozilla et vers la fin, Firefox).
Il a essayé de se créer un poste à Mozilla
Essayé ? Il est resté salarié 10 ans chez Mozilla. On n'essaye pas pendant 10 ans. Il a fait énormément de choses pour promouvoir Firefox en Europe notamment.
à mon avis c'était plus pour le poste que par conviction
Visiblement, tu es passé à coté de la période où il a dirigé bénévolement l'association Mozilla Europe, avec aucun salaire pendant un an. On ne fait pas ça pour "un poste".
Visiblement, tu aurais dû contribué à Mozilla pour te rendre compte que ton avis est basé… sur rien.
il utilisait un Mac et semblait préférer Apple à Linux
Et ? Comme la majorité des devs Mozilla à l'époque. Ce n'est pas parce qu'on fait la promo d'un logiciel libre, qu'il faut absolument utiliser Linux.
J'utilise Linux comme OS principal pour faire du dev depuis 2001. Mais franchement, "Linux prêt pour le desktop de mr michu", avant les années 2010, c'était pas encore tout à fait ça, quoi que tu puisses en penser.
# Autre choix
Posté par Laurent J (site web personnel, Mastodon) . En réponse au sondage Allez‑vous installer l’application de traçage gouvernementale StopCovid ?. Évalué à 10.
[^] # Re: Ils y sont toujours (du mauvais côté)
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Compétition : faites exploser les compteurs du trolomètres. Évalué à 5.
Oui et non. Le chiffre d'affaire en 2019 de la division "intelligent cloud" (produits serveurs et services cloud, Microsoft Azure…) est au même niveau que la division "Informatique Personnelle" (Windows, Microsoft Surface, Xbox, search…) et que la division "Productivité et entreprise" (Office 365 et Office, LinkedIn, Microsoft Dynamics…)
Aux alentours de 11 milliards de dollars chacune pour le 4ieme trimestre 2019..
https://www.informatiquenews.fr/microsoft-un-ca-en-croissance-de-14-et-benefice-qui-explose-62815
Bref, la rente Windows et Office "baisse" (en proportion du total du CA) au fil des ans, au profit de Azure &co.
[^] # Re: mail
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal [IDIOTIE] Proposition d'amélioration de bitcoin. Évalué à 9.
non parce qu'il y a 99,9% de chance que l'adresse mail soit bidon, ou qu'elle soit celle d'une personne qui n'a rien avoir avec cette histoire.
Des fois même l'adresse de l'expéditeur est celle du destinataire.
[^] # Re: a
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 73. Évalué à 3. Dernière modification le 26 février 2020 à 10:25.
ça sent le manque de Ram, ou une incompatibilité matériel coté carte graphique. N'aurais-tu pas activé des préférences de fonctions expérimentales liées à la CG dans Firefox ? Essaye avec un profil vierge.
et essaye d'utiliser la version vanilla plutôt que celle buildée par ta distro. https://www.mozilla.org/fr/firefox/new/
[^] # Re: Petite question de béotien
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal L'Écosystème containeurs. Évalué à 5.
Alors déjà : non (voir plus bas).
Ensuite, c'est marrant que tu dises ça, alors que plus loin :
Quand tu as ça, tu fais justement appel… à un admin système.
À moins que tu sois tout seul à tout faire dans ta boite, ce n'est pas aux développeurs de s'occuper de la prod, de s'occuper de l'infra et de ses problèmes. C'est aux admin sys que tu crois qu'ils vont disparaître.
Admin sys est un vrai travail, un vrai métier, qui est utile pour faire en sorte que ce que produisent les développeurs (du code, des services et éventuellement sous forme de conteneurs Docker), soit opérationnel dans la vrai vie (le laptop du dev, ce n'est pas la vrai vie, c.a.d, n'a pas les contraintes d'un environnement de production).
Opérationnel veut dire :
etc etc etc…
Et pour répondre plus précisément à ta question, quand il y a des soucis de perfs, d'abord c'est grâce à l'admin que tu peux savoir d'où ça vient (à moins que toi en tant que dev, tu n'a rien d'autres à foutre que de surveiller et d'analyser les problèmes de prod), et ensuite, c'est soit la faute à l'admin sys (ne dimensionne pas/ne configure pas correctement les machines et les réseaux), soit la faute à l'architecte logiciel (ex: pas de système de cache ou a fait des choix techniques merdiques), soit la faute au développeur qui a codé de la m..de, avec par exemple des empilements de framework à tout va, des milliers de paquets npm, des algo foireux ou encore a utilisé Java [1]
Disclaimer: je suis avant tout un dev, mais aussi admin sys à mes heures perdues, et je n'aurais jamais cette prétention de pouvoir remplacer un vrai admin sys. C'est juste impossible de tenir les 2 rôles correctement dans une boite qui veut grandir.
[1] oui je sais, on n'est pas vendredi. Désolé.
[^] # Re: intérêt difficile à déterminer.
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal installation d'une debian chiffrée via LUKS sur un VPS. Évalué à 2.
ok, trouvé : https://benediktkr.github.io/ops/2015/05/01/remote-fde.html
[^] # Re: intérêt difficile à déterminer.
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal installation d'une debian chiffrée via LUKS sur un VPS. Évalué à 1.
Je ne chiffres pas les partitions de mes serveurs, puisque je n'en vois pas trop l'interet.
Par contre, vraie question : si la clé n'est pas sur le serveur, comme fait-on pour avoir un serveur qui puisse rebooter tout seul ? Ou comment fait-on pour indiquer la clé au redémarrage d'un serveur distant ?
[^] # Re: intérêt difficile à déterminer.
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal installation d'une debian chiffrée via LUKS sur un VPS. Évalué à 2.
Je crois savoir l'intérêt (relatif): une fois que tu rend la machine, celle-ci est louée à une autre personne. Cette personne pourrait analyser le contenu du disque, et essayer de récupérer le contenu des anciennes partitions (avec beaucoup de patience).
Si les partitions sont chiffrés, cela devient bien plus compliqué. Il faut pouvoir retrouver la clé de déchiffrement de la partition. Ce qui, il me semble, est d'autant plus compliqué qu'il y a de forte chance que l'endroit ou elle était stockée ait été écrasé lors de la réinstallation du système.
Toutefois, cette précaution de chiffrer une partition n'est utile que pour les serveurs physiques. Pour les VM et autres conteneurs "cloud", ce sont des disques virtuels donc, données irrécupérables après recréation des partitions virtuelles.
Et encore, pour les serveurs physiques, OVH dit qu'il détruit toutes les données sur les disques avant de remettre le serveur en location. Par contre je n'ai pas trouvé l'information qui explique en quoi consistait exactement cette destruction.
[^] # Re: intérêt difficile à déterminer.
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal installation d'une debian chiffrée via LUKS sur un VPS. Évalué à 3.
Mouai.. En imaginant qu'un "indélicat" arrive à se procurer un snapshot. Rien ne l'empêche de le remonter sur sa becane avec les bons outils. La VM démarre, déchiffre le disque. Et… au final le chiffrement du disque ne protège rien.
Sauf si le chiffrement s'est fait avec une clé avec passphrase. Mais pas très pratique pour un serveur. D'ailleurs je doute qu'on puisse indiquer la passphrase au lancement d'un serveur sur OVH…
[^] # Re: Fatiguant ce bashing ovh
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal installation d'une debian chiffrée via LUKS sur un VPS. Évalué à 3.
Tu réponds à qui ?
Les deux.
Et moi aucune des deux.
La vrai solution, et la plus sécurisée : tu met ta clé publique dans ton compte OVH, tu la choisi lors de l'installation de la machine. Tu reçois un mail sans mot de passe et tu n'as pas de souci de pirate qui scruterai ta boite mail.
Au sujet du compte OVH piraté : ça ne devrait pas arriver. Si cela arrive, c'est que tu n'as pas assez sécurisé son accès (par une double authentification par exemple).
Bref, comme tu dis, OVH ne sont pas des débutants…
[^] # Re: Fatiguant ce bashing ovh
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal installation d'une debian chiffrée via LUKS sur un VPS. Évalué à 9.
De quel compte parles-tu ?
Si tu parles du compte OVH, heureusement que le mot de passe root n'est pas indiqué au moment où tu créés ton compte, car cela signifie alors qu'il est stocké/haché quelque part. Conséquence : sécurité moyenne, et surtout, si tu changes ton mot de passe root sur la machine, celui stocké dans ton compte OVH n'est plus valide.
Si tu parles du compte root proprement dit, que tu saisirais dans le formulaire d'installation de la machine, je ne vois pas l’intérêt. Parce que là, tout comme sa génération automatique et envoi par mail comme aujourd'hui, tu ne sais pas où le mot de passe est passé et stocké (même temporairement) lors du processus OVH d'installation de la machine, donc de toute façon, il faut le changer à la première connexion sur ta machine.
Et puis de toute façon, c'est une hérésie d'utiliser un mot de passe pour le compte root : dés la première connexion, la première chose à faire est de changer le mot de passe, poser sa clé ssh, et interdire les connexions par mot de passe (au moins pour le root) dans la config du serveur ssh de la machine.
[^] # Re: Fatiguant ce bashing ovh
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal installation d'une debian chiffrée via LUKS sur un VPS. Évalué à 8.
Ce dont on parle, c'est le mot de passe root de la machine qui vient d'être installé. Rien à voir avec le mot de passe de ton compte OVH.
Ce mot de passe root est généré aléatoirement lors de l'installation du système.
# Fatiguant ce bashing ovh
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal installation d'une debian chiffrée via LUKS sur un VPS. Évalué à 10. Dernière modification le 05 février 2020 à 10:37.
C'est surtout de ta faute : si tu n'indiques pas de clé ssh dans ton profil, il faut bien, que puisses te connecter sur ton VPS fraîchement installé. Tu veux qu'ils t'envoient ton mot de passe par télépathie ?
Ensuite, faut vraiment pas avoir de bol pour se faire pirater son VPS fraîchement installé, entre le moment où ils t'envoient le mail, et le moment où tu te connectes la première fois et que tu changes ton mot de passe ;-).
"mon compte > services > clés ssh"
Les dépôts sont ceux d'OVH, pour plusieurs raisons :
Mais :
Pour le reste, peut être que l'offre VPS n'est pas ce qu'il te faut pour ton besoin. Je ne sais plus pour les VPS, mais je sais qu'en prenant un serveur physique (j'en gère des dizaines), tu partitionnes comme tu veux avant l'installation de l'OS.
J'aimerais bien un retour d'expérience pour les VPS chez d'autres hébergeurs, voir si c'est aussi "compliqué" de partitionner et de chiffrer…
[^] # Re: Attention au stats
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal A propos de packaging et de LuaUnit. Évalué à 2.
L'augmentation des stats reste bon signe, c'est certain. Good job!
# Attention au stats
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal A propos de packaging et de LuaUnit. Évalué à 5.
Luanit est un framework de tests unitaires. Dans un projet, il est donc susceptible d'être lancé à chaque push sur le dépôt du projet, si il y a de l'intégration continue.
Normalement, dans un système d'intégration continue bien fait et bien configuré, les dépendances externes ne sont installés au moment du lancement des tests que quand leur version change ou qu'elles sont nouvelles. Dans gitlab-ci, il est ainsi possible de mettre par exemple un répertoire de dépendances comme node_modules (paquets npm), dans un cache. À chaque lancement de l'intégration continue, gitlab-ci, créé les répertoires de dépendances à partir de son cache. Cela évite au packageur (ici npm), de re-télécharger tous les paquets.
Mais ça c'est quand c'est bien fait.
Il y a des projets où c'est mal foutu : utilisation d'un outil d'intégration continue pas cool, ou mal configuré.
Du coup, à chaque push sur le dépôt d'un de ces projets, téléchargement systématique des dépendances. Sur un projet bien actif, cela peut en provoquer des dizaines par jour. (Pour SlimerJS, j'avais eu des soucis d'un serveur de je ne sais où qui téléchargeait toutes les 2-3 minutes le paquet : il me bouffait toute la bande passante de mon serveur d’hébergement !)
Du coup, les statistiques ne veulent pas dire grand chose. Cela ne correspond pas au nombre d'utilisateurs, donc à la popularité de l'outil.
Disons que c'est une popularité artificielle, qui peut avoir tout de même un bénéfice : avec des stats gonflées ainsi artificiellement, cela propulse le paquet dans les hauteurs des classements des "projets les plus utilisés", donc ça incite plus facilement à ceux qui doivent choisir, d'utiliser le projet en question. Ce qui fait encore plus gonfler les stats etc..
[^] # Re: D’accord sur Thunderbird
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 72. Évalué à 7.
Qu'est-ce que tu appelles "ne plus bouger" ?
Parce que j'utilise Thunderbird depuis sa toute première version, et à chaque mise à jour, il y a des évolutions, en particulier depuis ces 2-3 dernières années. Ok, au niveau fonctionnalités, il n'y a pas de révolution à chaque fois. Mais ça bouge. Beaucoup même ces derniers temps.
Et j'en sais quelque chose : je maintiens pour un client une appli mail qui repose sur thunderbird (c'est un thunderbird avec une tout autre interface, sans passer par une extension, donc il y a des patchs, des modules XUL additionnels etc), et à chaque upgrade, j'ai toujours eu des problèmes de compatibilité avec les api internes, et donc des adaptations à faire, parce que justement, ça bouge.
Et c'est de pire en pire depuis 2-3 ans, surtout en ce moment, car XUL/XBL/etc commence à disparaître de Gecko, donc de TB. Là, concrètement, pour faire le passage à TB 68, l'appli mail du client est toute cassée. Faut que je refasse plein de trucs.
Donc non. TB n'est pas immobile. Peut-être que tu trouves qu'au niveau fonctionnalité ça ne bouge pas trop, mais je t'assure qu'ils font beaucoup de boulot "qui ne se voit pas", pour tuer le code legacy et pouvoir, dans un future proche, bouger encore plus vite.
[^] # Re: Où est la diversité ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal KHTML c'est fini. Évalué à 10.
En théorie. Seulement en théorie. Un moteur de navigateur, c'est pas un hello world. C'est très complexe, très gros. Il faut avoir les moyens financiers d'une grosse boite pour forker un tel projet. Même Microsoft ne s'y est pas risqué.
ça ne peut pas être gênant. ça peut être TRÈS gênant. Voir cauchemardesque. Qu'une boite, commerciale, dicte le futur de standards ouverts, c'est toujours mauvais à long terme.
IP est un protocole, pas une implémentation. Fort heureusement, il y a plusieurs implémentations, qui ont permis à IP d'exister et de se répandre !
Trop facile de balancer la responsabilité du coté des utilisateurs. Comme si tout le monde pouvait, savait, modifier un navigateur.
[^] # Re: La fondation mozilla partage une lourde part de responsabilité dans le fait que blink
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Que penser du navigateur internet Brave ? (Et pourquoi je privilégie Firefox…). Évalué à 5.
Oui, mais non. Songbird n'était pas une application qui embarquait gecko, mais qui reposait sur gecko, ou plus exactement XulRunner. Comme la majeure partie d'application XUL de cette époque. Songbird était loin d'être la seule, il y a en a eu plein d'autres : Thunderbird, Nvu, Komodo Ide, Chatzilla et j'en passe.
Il y a une différence entre embarquer Gecko, le moteur de rendu et utiliser XulRunner comme runtime. Le second, c'est en gros Firefox sans son interface : on a donc Gecko, mais aussi tout un framework et des composants XUL ou techniques prêt à l'emploi.
Gecko, c'était vraiment que la partie moteur de rendu et XPCOM (système de composants binaire ou JS).
Il fut un temps où il y avait la possibilité d'embarquer Gecko, c'est à dire d'avoir un lib avec une API, permettant d'instancier un moteur de rendu, de le manipuler (charger une page etc).
Camino, mais aussi d'autres navigateurs de l'époque, utilisaient cette lib. (donc ce n'était pas des applis XUL).
XulRunner, plus simple à utiliser pour développer une application, avait pris le dessus, entre autre parce que Thunderbird l'utilisait et que donc Mozilla le maintenait, et Mozilla du coup mettait moins de moyen sur la partie "embeddable" de Gecko.
L'API embed fut donc de moins en moins maintenue. Et quand Mozilla decida d'abandonner XulRunner puis le XUL, c'était trop tard pour relancer le projet embed. Presque plus personne n'utilisait cette API (Camino était mort…).
Ensuite, il y avait peu de contributeurs sur cette api embed.
En clair, contrairement à ce qui s'est dit, ce n'est pas une vraie volonté de Mozilla de ne pas rendre Gecko embarquable, c'est juste que les moyens manquaient, et qu'il y avait d'autres priorités à l'époque.
Il y a bien eu quelques workshops (il y a de cela 10 ans) pour tenter de relancer le projet de cette API, (j'avais assisté à l'un d'entre eux), mais la mayonnaise n'a pas pris.
Depuis, ils se sont un peu rattrapés : Servo, le moteur 100% en rust de mozilla est fait depuis le début pour être embarqué. Et il y a une lib embarquant gecko pour les navigateurs pour Android, geckoView, qu'utilise Firefox pour Android (ou d'autres variantes, je n'ai pas trop suivi).
Je ne sais pas ce qu'il en est aujourd'hui de cette API embed de Gecko.
[^] # Re: Faute avouée, pas pardonnée
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Perquisition chez NGINX à Moscou, Igor Sysoev arrêté. Évalué à 9.
non, du moment que le travail demandé est fait dans les temps.
Bosser sur des projets perso, ça fait partie de la "veille" selon moi. D'ailleurs c'est pas pour rien que chez Google ou d'autres boites, les développeurs peuvent passer (ou pouvaient, je ne sais plus si c'est le cas chez Google) 20% de leur temps pour développer sur des projets libres de leur choix.
Une boite qui ne laisse pas faire de la veille à ses devs, c'est une boite à fuir. En tout cas de mon point de vue.
# Pastilles pas très objectives
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche VigiBati : un outil libre de cartographie et veille des permis de construire en France. Évalué à 4.
Il faudrait revoir je pense l'affichage des pastilles qui indiquent le nombre de permis. Leur position n'est pas très cohérente avec la réalité du terrain. Un exemple: à un certain niveau de zoom, je me suis retrouvé avec une grosse pastille affichant 152 en plein milieu de belle-île en mer, alors qu'en fait il y en a une vingtaine sur l'île.
Il faudrait donc les positionner géographiquement, par communes par exemple, plutôt qu'en grille (regrouper par "carré", ça n'a pas de sens selon moi).
[^] # Re: Base de données
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Sortie de Glewlwyd 2.0, serveur SSO. Évalué à 2. Dernière modification le 04 novembre 2019 à 14:38.
Au hasard, pour stocker les utilisateurs, et leurs données sous-jacentes (nom, mot de passe, email..).
J'ai du mal à imaginer ça dans un stockage non persistant…
Donc à chaque reboot, l'admin sys doit se taper le remplissage de sa base de donnée en RAM en y injectant les centaines d'utilisateurs potentiels ?
[^] # Re: Ni bonne, ni mauvaise
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Tristan Nitot devient directeur général de Qwant. Évalué à 5.
Oui, donc, Tristan Nitot faisait du libre AVANT de quitter Netscape, pas après, contrairement à ton commentaire précédent.
À moins que pour toi, faire du libre, c'est forcément une activité non payée ? Ou c'est forcément taper des lignes de code ?
Bien sûr qu'il a en quelque sorte créé son poste. mais quand on créé son poste dans ces conditions, à savoir du bénévolat sans salaire pendant plusieurs mois, c'est aussi et surtout par conviction, par envie de travailler sur le projet en question. Pas pour des raisons purement pécuniaire.
C'est quoi le rapport avec Tristan ? Une boite qui fait du libre n'a pas le droit de louer des locaux dans un bâtiment comme celui-ci ? (qui ne sont pas aussi cher que l'on pourrait croire, car monument historique, donc beaucoup de contraintes techniques, dont le fait par exemple de ne pas pouvoir accrocher des équipements réseaux aux murs etc..)
Au passage : Mozilla n'est plus dans ces locaux depuis quelques semaines…
Parce que le libre ne se résume pas à Linux !!
Aujourd'hui oui. Il y a 10 ans (l'époque dont on discute) non.
Franchement, faut apprendre à lire hein. Je n'ai absolument pas écris que je n'utilisais pas Linux. Je l'ai écrit et je le réécrit : Linux est mon OS principal depuis 18 ans, sur mes machines pro et perso !
Oui, tout à fait. Où ai-je écris le contraire ? Il ne voulait pas s’embêter avec ces problèmes de compatibilité de matériel. C'est ce que j'ai voulu expliqué.
C'est ton avis, mais avant d'avoir ce genre d'avis sur des gens, on essaye de le connaître..
Tu te caches derrière ton pseudo, donc je ne sais pas qui tu es ou ce que tu as fait pour le libre, mais il y a forte chances qu'il en a fait beaucoup plus que toi, qu'il soit désintéressé ou pas.
Pas par des lignes de codes, mais par avoir fait connaître Firefox, Mozilla et les logiciels libres en général. Par avoir, avec sa bonne humeur, ses convictions, donné l'envie à bon nombre de contributeurs francophone, de contribuer au projet (code, doc, localisation etc…) ou même sur d'autres projets, qui a leur tour en ont entraîné d'autres dans l'aventure etc..
[^] # Re: Ni bonne, ni mauvaise
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Tristan Nitot devient directeur général de Qwant. Évalué à 2.
Je voudrais rajouter aussi une raison de l'utilisation de MacOs plutôt que Linux, en particulier pour un utilisateur qui doit souvent se brancher sur un video-projecteur, pour des conférences ou des réunions.
Comme je le disais, j'utilise Linux depuis 18 ans. Ça fait beaucoup d'occasions de faire des conférences ou des réunions, et donc des occasions d'avoir à brancher un video-projecteur sur mon laptop linux.
Au début de chaque conf/réunion, ça a toujours été le stress de savoir si le branchement sur le vidéo-projecteur allait fonctionner. 1 fois sur 2 (et je suis gentils), ça ne fonctionnait pas du premier coup. Y avait toujours un truc à régler ici ou là, à trouver le pourquoi du non-fonctionnement, avec parfois obligation de rebooter avec la prise déjà branchée pour que le video-projecteur soit reconnu. Bref, Linux et la video-projection : c'était la galère. ça s'est amélioré ces dernières années, avec la généralisation du hdmi, et l'amélioration des interfaces utilisateurs pour les réglages. Mais franchement, c'était pas la joie.
Entre 2009 et 2011, j'ai utilisé un Mac au boulot. Chaque fois que je devais faire une présentation, quelque soit le vidéo projecteur (en vga ou hdmi) : je branchais, ça marchait. Toujours. Et j'ai rarement vu un conférencier galérer avec son Mac.
Donc franchement, quand on est un communiquant, surtout dans les années 2000-2010, je comprend tout à fait qu'on choisisse un Mac. Le job d'un communiquant, ce n'est pas faire de la ligne de commande pour débugger l'affichage d'un vidéo projecteur. C'est de communiquer.
[^] # Re: Ni bonne, ni mauvaise
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Tristan Nitot devient directeur général de Qwant. Évalué à 7.
Oui en tant que responsable marketing, son combat est le thème de son poste. Quoi de plus normal en effet.
Mais note qu'avec ses compétences et son CV, il aurait très bien pu, après Mozilla, aller chez Microsoft, ou tout autre grosse boite "du mauvais coté". Si il n'avait pas de convictions comme tu sembles le prétendre, ça se serait fait en un claquement de doigt, j'en suis certain (1).
Mais il ne l'a pas fait. Il a préféré une petite boite qui faisait du libre et qui défendait la vie privée (Cozy Cloud), puis une boite qui défend aussi la vie privée (Qwant).
Cela montre quand même qu'il a des convictions (libre, vie privée etc), et qu'il ne fait pas ça "juste pour le poste" comme tu dis plus haut.
(1) je l'ai côtoyé régulièrement pendant plus de 10 ans quand il était chez Netscape et Mozilla, je connais un peu le bonhomme.
[^] # Re: Ni bonne, ni mauvaise
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Tristan Nitot devient directeur général de Qwant. Évalué à 10.
C'est factuellement FAUX.
Il a passé ses dernières années à Netscape à faire la promotion des standards du web et la promotion des technologies du projet de navigateur libre, Mozilla.org (aka la suite Mozilla et vers la fin, Firefox).
Essayé ? Il est resté salarié 10 ans chez Mozilla. On n'essaye pas pendant 10 ans. Il a fait énormément de choses pour promouvoir Firefox en Europe notamment.
Visiblement, tu es passé à coté de la période où il a dirigé bénévolement l'association Mozilla Europe, avec aucun salaire pendant un an. On ne fait pas ça pour "un poste".
Visiblement, tu aurais dû contribué à Mozilla pour te rendre compte que ton avis est basé… sur rien.
Et ? Comme la majorité des devs Mozilla à l'époque. Ce n'est pas parce qu'on fait la promo d'un logiciel libre, qu'il faut absolument utiliser Linux.
J'utilise Linux comme OS principal pour faire du dev depuis 2001. Mais franchement, "Linux prêt pour le desktop de mr michu", avant les années 2010, c'était pas encore tout à fait ça, quoi que tu puisses en penser.