Pas besoin de s'enregistrer chez Google. Sauf si tu veux leurs statistiques.
Tu peux aussi faire un compte google séparé pour ça.
Par exemple, si tu as un nom de domaine avec le site web, tu peux t'inscrire via un alias, et tu te connectes sur la console quand et si tu en as besoin, et basta.
En cas de perte du mot de passe, tu ne perds rien à part des vagues stats sur l'indexation. Comme y a rien d'important, tu n'as pas forcément besoin de mettre du 2FA, et comme le mail va être utilisé nulle part ailleurs, le login va être dur à deviner. Point bonus, tu peux faire bing search en plus.
Comme le compte sert uniquement à ça, le tracking est plus que minimal et lié à rien d'utile pour Google ou personne d'autre.
Mais en effet, ça n'aide pas des masses à l'indexation. Ça va te dire si il y a des problèmes (genre, erreur dans le code HTML, etc), mais c'est tout.
Dans Chromium il y a un outils (pour développeurs) qui va te
donner de nombreuses indications sur les performances et les
points à améliorer.
En même temps, n'importe ou dans l'industrie serait un souci.
Les boites veulent des gens avec de l'expérience, et ça implique d'avoir travailler ailleurs dans le même domaine. Sauf que ailleurs dans le même domaine, ça implique aussi de travailler dans une entreprise d'une certaine taille. Et si une entreprise a une certaine taille, elle a forcément des casseroles au cul, c'est plus ou moins statistique de part la taille.
Je pense qu'on aurait mis "Google", "Amazon", "Oracle", ou "Thales", "Renault", "Société Général", ça n'aurait rien changé à la critique. Et le fait que Mozilla embauche régulièrement des gens qui viennent de Microsoft, de Google ou ailleurs sans que personne ne fasse de journal montre que c'est sans doute aussi un non événement en soi (car bon, ou est ce qu'on trouve des gens avec de l'expérience pour faire un navigateur à part chez les concurrents ?).
Et je trouve que c'est un peu manipulatoire que d'utiliser ce genre de culpabilité par association, en plus d'être des méthodes assez proches des milieux complotistes (comme on a pu le voir depuis quelques années).
"oh, X a été a un poste de responsabilité dans l'industrie pharmaceutique, donc ne peux pas être Y au ministère de la santé", comme si on allait toujours trouver des gens avec des compétences spécifiques d'un domaine hors du domaine.
Je serais assez étonné qu'ils n'aient pas des gens qui
connaissent très bien les interpréteurs des navigateurs et
c'est le même qui est utilisé côté serveur.
Bah, y a du monde chez facebook, mais ça veut pas dire forcément qu'ils vont couvrir tout. Entre dédié des devs sur le support d'un langage, ou les mettre sur des produits qui rapportent des thunes, le choix est vite fait.
Parce que perdre de la RAM, ça peut aller côté client (dans une
certaine mesure, parce que ça veut dire quand même que
certaines personne ne pourront pas accéder au site), mais
perdre du CPU, ça veut dire que le temps d'affichage va
augmenter.
Je parle plus des perfs à l’échelle de Facebook. Si tu perds 100ko de ram par client coté client, c'est invisible pour le client. Si tu perds 100ko par client coté serveur, ça va se voir plus, vu que ça s'accumule.
Si chaque client prends 10% de CPU en plus coté client, ç'est pas super, mais suivant le niveau de base, ça peut aller, surtout que le terminal client, il fait pas que ça, ni en permanence.
Personne ne cherche vraiment à maximiser l'usage du temps CPU sur les clients, donc il y a grosso modo des trucs en trop. C'est bien d'optimiser bien sur.
Si toute ta flotte prends 10% de CPU en plus, alors ça a un impact, car toi, en tant que fournisseur (à l’échelle de FB), tu n'as pas forcément du temps CPU qui traîne, car le but est d'utiliser le matos au maximum.
Je sais que Google a (ou avait) un outil interne pour savoir si c'est intéressant d'optimiser ou pas un service, car l'optimisation a un coût (salaire, etc), mais la non optimisation aussi (temps CPU, etc).
Et à coté de ça, ça impacte aussi l’écosystème. Tu veux rajouter un langage coté serveur, il faut rajouter et maintenir des libs pour la stack en question (j'imagine que Facebook a des libs pour les APIs internes). Il faut des gens qui connaissent les soucis de sécurité de la stack coté serveur pour examiner le code, faut que tes SRE puissent le lire et l'écrire. Il faut aussi maintenir la stack, donc embaucher du monde, etc.
Intuitivement, on se doute bien que supporter tout ce qui existe n'est pas faisable. On peut discuter de savoir si la limite devrait être 10, 50 ou 4, mais je pense que si Facebook a fait le choix de 4, ils ont sans doute plus de chiffres que nous.
Je n'ai pas du être clair quand j'ai dit "compilo/interpreteur", je parle des équipes qui vont maintenir le dit compilo/interpréteur.
Coté client, si tu perds des ressources (que ça soit cpu ou ram), tu t'en fout, c'est pas toi qui paye. Coté serveur, si tu perds des ressources, tu payes vu que c'est tes serveurs, et à l'échelle de facebook, ça fait beaucoup.
De plus, si tu as un souci coté navigateur, tu n'a pas toujours le contrôle pour corriger. Coté serveur, tu n'as aucune excuse vu que tu as choisi la pile logiciel.
Je suppose que ça reflète plus la capacité de support par les salariés des équipes dédiés (eg, si y a un souci de perf sur le compilo/interpréteur), et donc les gens en place ainsi que l'historique de la base de code qu'autre chose.
C'est pour ça que ça me fait rire de voir ce genre de liste vu que ça ne va rien apporter de spécial pour la majorité des gens, à part des arguments d'autorité foireux comme "si une boite qui est assis sur une pompe à fric l'utilise, alors ça doit être adapté à ce que je veux faire".
qui ont leur BIOS, le truc le plus sensible en terme de sécurité
Je suis pas d'accord. Le BIOS n'est pas "le plus sensible en terme de sécurité".
Deja, c'est loin d'être le plus exposé des logiciels ni le plus exploité. Il ne traite pas des données complexes venant du réseau, ses seuls inputs vont être le hardware au démarrage.
Et il suffit de remplacer "BIOS" par "grub" (qui est le suivant dans la chaine) dans la phrase pour voir que c'est totalement creux comme discours sauf dans l'esprit enfiévré d'une partie de la communauté du libre qui pense que la NSA et le Mossad s'intéresse à eux.
De toute manière on est en grande pénurie d'admins. Les écoles
crachent des dev par milliers, des admins, non.
Ensuite, l'administration système n'est pas vu comme attractive.
Ça paye moins qu'un dev (de ce que j'ai vu en parlant salaire avec les collégues, et en regardant des chiffres , la profession donne l'image de râleurs qui vont dire "non" (voir directement de connards, et il faut dire la vérité, c'est parfois non usurpé), le business ne va pas te voir comme générateur de valeur mais comme un coût.
Les grandes boites du net (style Google, facebook) ont repris l'idée de l'administration systéme mais en rajoutant "fait par des devs" sous le terme "devops", comme si les adminsys n'avaient jamais rien codé avant.
Et on va associer l'adminsys avec le fait d'avoir des astreintes, donc des contraintes un peu naze.
Donc franchement, faut pas se plaindre des écoles. Si on voulait plus d'admin, on pourrait payer plus et former les gens sans dépendre de l'éducation national. Le fait est que ça n'est pas ce qui est fait, donc la pénurie doit pas être si problématique que ça.
Oui, quand j’étais sur ce genre de poste pendant 2 ans et demi, je l'ai déjà fait aussi parce que je sais le faire et que j'étais la. Contrairement à ce qu'on pourrais croire, les gens du support ne sont pas des monstres.
Ensuite, quand je n'étais pas la ou dans les bureaux sans service informatique sur place, ça passe par le fabriquant, ou les gens le font eux même.
Ensuite, on parle des Lenovos, qui sont facile à modifier (plus ou moins). Je pense que pour les macbooks, c'est direction le genius bar le plus proche (et ça doit être compris dans le support applecare, vu qu'une boite va payer pour ça).
En pratique, c'est pas l'admin qui va faire ça, mais le support du fabricant. Et en général, tu ne rajoutes pas du matos aprés l'achat, tu t'arranges pour que ça soit directement fait avant la livraison.
Les revendeurs qui servent d’intermédiaire à Dell/Lenovo/etc font ça sans souci (ou peut être que c'est directement chez le fabricant).
un poids suffisant auprès de Microsoft pour heu disons discuter
en cas de problème.
Le terme que tu cherches est sans doute "contrat de support".
Je pense qu'on se rends pas trop compte du gouffre qu'il y a entre les offres pas cher grand public (exemple, la téléphonie, l’accès internet) avec un support minimal et les offres pro plus cher, justement, parce que quelqu'un paye pour le support (et parce que le support, ça coûte de l'argent).
Je suppose qu'une bonne part a des admins pour gérer tout le parc. La, j'ai l'impression que les portables sont en gestion par les employés (cf le passage sur "on a besoin d'un screenshot pour prouver que vous avez un disque chiffré", ce qui n'aurait aucun sens si les portables étaient géré par des admins).
Du coup, ça change un peu la donne, et c'est pas tant interdire Windows qu'interdire Windows géré par les utilisateurs.
Dans une grande organisation, tu as en général un département informatique qui va filer des portables sous le contrôle du département, donc capable d'appliquer des GPO (politique de sécurité) avec un annuaire centralisé (eg active directory), etc.
Oui, mais en même temps, c'est le point globalement le plus consensuel en politique.
Ensuite bien sur, dans le détail, c'est plus compliqué. C'est dur à évaluer, les projets (surtout en informatique) foirent assez régulièrement pour des raisons structurelles, les entreprises du privé s'arrangent pour maximiser l'argent gagné ce qui va à l'encontre d'économiser de l'argent, tu te retrouves avec des soucis imprévus et des erreurs, et la moindre connerie peut devenir assez vite un cauchemar politique.
Et ce qui est triste, c'est que ça ne semble pas être unique à la france, ce qui veut dire que c'est pas une question de personnes, et qu'on est sans doute pas plus des tocards que la moyenne, mais qu'il y a un truc plus profond qui fait que c'est relativement difficile de réussir.
Ça me rappelle pas mal les changements dans une grande boite (genre changement d'intranet, etc). La portée est moindre, mais pareil, ça a l'air complexe, ça foire pas mal etc. Et pourtant, je sais que les équipes qui bossent dessus sont ni mauvais, ni débutants, ni même contraint par des règles juridiques complexes.
Et pourtant, ça ne se déroule jamais comme prévu. Donc peut etre que l'humain est juste incroyablement confiant dans sa capacité à comprendre et à prévoir alors que c'est faux.
Je sais pas pourquoi tout le monde va imaginer des cas de conspirations tirées d'un trip sous un mélange de cocaïne et térébenthine, au lieu de regarder le budget mais bon, faut toujours se dire que c'est ça.
Les forces de polices coûtent de l'argent, le reste aussi.
Les électeurs ne veulent pas en général payer plus d’impôts. Les gens sont parfois d'accord pour les augmenter, mais ceux des autres surtout (en général, les gens plus riches qu'eux, les gens à l'étranger, les entreprises), et le font savoir via le vote.
Peut être pas partout en Europe, mais c'est bien ce que je vois en France. Je sais pas si il y a des journaux qui expliquent comment payer moins d’impôts dans le reste du continent, mais ça revient assez souvent en France.
Du coup, maintenir un service égal, voir plus performant (cad qui traite plus de cas, ou des cas plus vite), ça passe par l'automatisation, ça passe par la simplification administrative (donc moins de vérif), ça passe par le fait de décharger des choses sur le privé.
Ou simplement, essayer de prévenir le crime au lieu d'attendre que ça soit fait, ça permet aussi de réduire les coûts.
Par exemple, la mise en commun des fichiers de police en 2011 (STIC et JUDEX), c'est de la réduction des coûts et de la simplification administrative. Sur le papier, ça évite de maintenir 2 bases pour rien, et ça aide les enquêteurs. En pratique, les fichiers sont sans doute mal remplis, il y a des fuites, etc.
On peut discuter sur le fait que la réduction soit effective ou pas (surtout dans un contexte ou le secteur privé va sans doute ajuster les offres par rapport à ce qui est déjà dépensé), on peut discuter sur les coûts cachés (maintenance), les dysfonctionnements des projets informatiques en général, etc.
Mais ça change rien que le but, c'est réduire et simplifier, car la complexité coûte, et que "il faut qu'on paye plus d’impôts pour maintenir les services" est une revendication que personne ne porte.
Par contre, faire plus ou autant avec autant ou moins d'argent, ç'est une constante.
Et maintenir les services, c'est aussi "ne pas avoir une série d'attentats" sur le territoire, en sachant que les groupes terroristes s'adaptent aussi (exemple, on est passé de groupe organisé des années 1970 comme la fraction armée rouge à des formes de terrorismes stochastiques avec des "loups solitaires").
L'infiltration des groupes et la surveillance comme dans les années 70 ne marchent sans doute pas pour les formes modernes, vu qu'il y a selon moins une évolution.
Ensuite, pour les histoires spécifiquement de pédocriminalités, c'est sans doute des associations de la société civile. Je ne connais pas ce qui se fait en Europe, mais aux USA, c'est des groupes comme NCOSE (parmi tant d'autres). Le livre The Digital Closet: How the Internet Became Straight détaille les dynamiques.
Le livre est en accès libre, je l'ai lu rapidement. J'ai trouvé le style un chouia inutilement provocateur et inflammatoire (et en général, je prends ça comme un signe qu'on tente de me manipuler, et je coupe rapidement), mais la thèse exposé dans le livre a le mérite de ne pas être trop farfelu, donc j'invite les gens à le lire tout en gardant un esprit critique (sauf si bien sur vous voulez des arguments pour chier sur Google et Facebook avec un peu de mauvaise foi, auquel cas le livre va plaire).
Donc je ne doute pas qu'une partie vient des fondamentalistes américains que j'ai cité, mais aussi des groupes conservateurs classiques basé en Europe (eg, le Vatican/Opus Dei, l'European Centre for Law & Justice, etc).
Je pense qu'il y a eu une réunion pour dire "la décision est final", quelqu'un a fuité l'info à la presse pour faire changer d'avis car l'idée semble désastreuse, et la personne en charge de la décision a du changé d'avis.
Tu as des suppressions de dépôts chez github aussi
bien sur, mais il y a une différence entre "l'admin efface les dépôts dans des conditions exceptionnels" et "la politique est d'effacer systématiquement des dépôts".
J'ai jamais eu un dépot qui a été effacer par github ou gitlab pour le moment. Par contre, si ce que je comprends est mis en place, j'aurais sans doute du code à moi qui va disparaître si je fait rien (et pourtant j'utilise ce code, et je pousse régulièrement sur gitlab.com).
C'est la porte ouverte à une attaque de type supply chain
attack. Parce qu'un attaquant peut récupérer le domaine mettre
en place une copie de l'existant sauf qu'il te donne son code
par exemple.
Oui, bien sur. Mais:
- un nom de domaine qui expire n'est normalement pas automatiquement disponible, donc tu va avoir un souci visible assez vite si tu as une CI, etc. Ensuite, je suppose que tout les registrars ne sont pas Gandi.
un certificat qui expire ne va pas automatiquement résulter en une compromission. Les MITM restent quand même assez rare en pratique. Je pense que ça requiert des moyens assez importants en général digne d'un état, tout en étant non utilisable pour ce qu'un état va avoir besoin (cad d'une cible précise avec un timing précis, et idéalement, ne pas se faire choper).
mais qu'avoir comme politique de fuir les projets qui sont sur
gitlab n'est pas une solution. Tous les projets qui sont
sensibles à ce genre de problème peut poser des problèmes
quelques soit là où il est hébergé.
Clairement, ça me parait contre productif, je suis d'accord.
Ensuite, il y a une échelle des risques, et la, gitlab risque de grimper d'un échelon. Le bon coté, c'est qu'il me parait facile de vérifier si une de tes dépendances va disparaître de gitlab via leur API.
Mais ce n'est pas parce que le code n'est pas modifié qu'il est peu supporté.
J'ai des roles ansibles triviaux que j'ai pas eu besoin de toucher et qui marchent encore. Ils sont sur ma propre forge, donc j'ai pas le souci, mais je me vois pas rajouter 1 commit tout les ans pour un truc dont le seul but est de faire un include de 3 roles.
Et bon, il faut aussi voir le timing de tout ça, tu dépends de code mort, tu préféres qu'on te le dise, et que tu géres à ton rythme, ou que tu découvres que la CI ne compile plus, même sur les versions stables, parce que la plateforme l'a retiré ?
Parce qu'on risque de se retrouver avec "left-pad II, le retour"
(j'avais proposé "left-pad de quartier", mais la productrice ne m'a pas suivi)
[^] # Re: Naturel... pourquoi pas
Posté par Misc (site web personnel) . En réponse au message annuaires, référencement gratuit, seo naturel. Évalué à 3.
Tu peux aussi faire un compte google séparé pour ça.
Par exemple, si tu as un nom de domaine avec le site web, tu peux t'inscrire via un alias, et tu te connectes sur la console quand et si tu en as besoin, et basta.
En cas de perte du mot de passe, tu ne perds rien à part des vagues stats sur l'indexation. Comme y a rien d'important, tu n'as pas forcément besoin de mettre du 2FA, et comme le mail va être utilisé nulle part ailleurs, le login va être dur à deviner. Point bonus, tu peux faire bing search en plus.
Comme le compte sert uniquement à ça, le tracking est plus que minimal et lié à rien d'utile pour Google ou personne d'autre.
Mais en effet, ça n'aide pas des masses à l'indexation. Ça va te dire si il y a des problèmes (genre, erreur dans le code HTML, etc), mais c'est tout.
Un site utile (aussi par Google) est https://pagespeed.web.dev/
Pas besoin de s'enregistrer, et ça donne des éléments utiles.
# gotosocial
Posté par Misc (site web personnel) . En réponse au message Mastodon, seul de mon côté. Évalué à 4.
Je pense qu'un serveur dont on parle pas assez, c'est gotosocial:
https://github.com/superseriousbusiness/gotosocial
C'est parfait pour des petits groupes, ça s'installe facilement (c'est du go) et ça tourne bien.
Mastodon avait l'air un peu plus lourd à mettre en place, et il y a sans doute plus d'infra à gérer.
[^] # Re: que du bon
Posté par Misc (site web personnel) . En réponse au lien Mozilla nomme Steve Teixeira comme nouveau chef de produit. Évalué à 10.
En même temps, n'importe ou dans l'industrie serait un souci.
Les boites veulent des gens avec de l'expérience, et ça implique d'avoir travailler ailleurs dans le même domaine. Sauf que ailleurs dans le même domaine, ça implique aussi de travailler dans une entreprise d'une certaine taille. Et si une entreprise a une certaine taille, elle a forcément des casseroles au cul, c'est plus ou moins statistique de part la taille.
Je pense qu'on aurait mis "Google", "Amazon", "Oracle", ou "Thales", "Renault", "Société Général", ça n'aurait rien changé à la critique. Et le fait que Mozilla embauche régulièrement des gens qui viennent de Microsoft, de Google ou ailleurs sans que personne ne fasse de journal montre que c'est sans doute aussi un non événement en soi (car bon, ou est ce qu'on trouve des gens avec de l'expérience pour faire un navigateur à part chez les concurrents ?).
Et je trouve que c'est un peu manipulatoire que d'utiliser ce genre de culpabilité par association, en plus d'être des méthodes assez proches des milieux complotistes (comme on a pu le voir depuis quelques années).
"oh, X a été a un poste de responsabilité dans l'industrie pharmaceutique, donc ne peux pas être Y au ministère de la santé", comme si on allait toujours trouver des gens avec des compétences spécifiques d'un domaine hors du domaine.
[^] # Re: Le paradis ?
Posté par Misc (site web personnel) . En réponse au lien Keet, un nouvelle appli de messagerie P2P... basée sur une blockchain ?. Évalué à 8.
Pas de code non plus
[^] # Re: pas de javascript donc
Posté par Misc (site web personnel) . En réponse au lien Pour le développement côté serveur, Meta recommande hack(php) c++ rust et python . Évalué à 4.
En fait, c'est dans le lien que j'ai donné. J'ai pas regardé la vidéo, mais dans les slides:
https://github.com/facebookincubator/cinder
Ce qui est intéressant, c'est qu'il y a sans doute plus de gens payé à temps plein sur le fork qu'upstream.
[^] # Re: pas de javascript donc
Posté par Misc (site web personnel) . En réponse au lien Pour le développement côté serveur, Meta recommande hack(php) c++ rust et python . Évalué à 5.
Instagram est en Python si je me souviens bien:
https://pyvideo.org/pycon-us-2021/python-performance-at-scale-making-python-faster-at-instagram.html
Je suppose que comme Google en son temps (le projet Unladen Swallow), Meta/Instagram a son propre fork de Python.
Donc ils ont les techos et le code historique. On noteras que c'est pareil pour php avec Hack et facebook d'après mes souvenirs
[^] # Re: pas de javascript donc
Posté par Misc (site web personnel) . En réponse au lien Pour le développement côté serveur, Meta recommande hack(php) c++ rust et python . Évalué à 5.
Bah, y a du monde chez facebook, mais ça veut pas dire forcément qu'ils vont couvrir tout. Entre dédié des devs sur le support d'un langage, ou les mettre sur des produits qui rapportent des thunes, le choix est vite fait.
Je parle plus des perfs à l’échelle de Facebook. Si tu perds 100ko de ram par client coté client, c'est invisible pour le client. Si tu perds 100ko par client coté serveur, ça va se voir plus, vu que ça s'accumule.
Si chaque client prends 10% de CPU en plus coté client, ç'est pas super, mais suivant le niveau de base, ça peut aller, surtout que le terminal client, il fait pas que ça, ni en permanence.
Personne ne cherche vraiment à maximiser l'usage du temps CPU sur les clients, donc il y a grosso modo des trucs en trop. C'est bien d'optimiser bien sur.
Si toute ta flotte prends 10% de CPU en plus, alors ça a un impact, car toi, en tant que fournisseur (à l’échelle de FB), tu n'as pas forcément du temps CPU qui traîne, car le but est d'utiliser le matos au maximum.
Je sais que Google a (ou avait) un outil interne pour savoir si c'est intéressant d'optimiser ou pas un service, car l'optimisation a un coût (salaire, etc), mais la non optimisation aussi (temps CPU, etc).
Et à coté de ça, ça impacte aussi l’écosystème. Tu veux rajouter un langage coté serveur, il faut rajouter et maintenir des libs pour la stack en question (j'imagine que Facebook a des libs pour les APIs internes). Il faut des gens qui connaissent les soucis de sécurité de la stack coté serveur pour examiner le code, faut que tes SRE puissent le lire et l'écrire. Il faut aussi maintenir la stack, donc embaucher du monde, etc.
Intuitivement, on se doute bien que supporter tout ce qui existe n'est pas faisable. On peut discuter de savoir si la limite devrait être 10, 50 ou 4, mais je pense que si Facebook a fait le choix de 4, ils ont sans doute plus de chiffres que nous.
[^] # Re: pas de javascript donc
Posté par Misc (site web personnel) . En réponse au lien Pour le développement côté serveur, Meta recommande hack(php) c++ rust et python . Évalué à 6.
Je n'ai pas du être clair quand j'ai dit "compilo/interpreteur", je parle des équipes qui vont maintenir le dit compilo/interpréteur.
Coté client, si tu perds des ressources (que ça soit cpu ou ram), tu t'en fout, c'est pas toi qui paye. Coté serveur, si tu perds des ressources, tu payes vu que c'est tes serveurs, et à l'échelle de facebook, ça fait beaucoup.
De plus, si tu as un souci coté navigateur, tu n'a pas toujours le contrôle pour corriger. Coté serveur, tu n'as aucune excuse vu que tu as choisi la pile logiciel.
[^] # Re: pas de javascript donc
Posté par Misc (site web personnel) . En réponse au lien Pour le développement côté serveur, Meta recommande hack(php) c++ rust et python . Évalué à 7.
Je suppose que ça reflète plus la capacité de support par les salariés des équipes dédiés (eg, si y a un souci de perf sur le compilo/interpréteur), et donc les gens en place ainsi que l'historique de la base de code qu'autre chose.
C'est pour ça que ça me fait rire de voir ce genre de liste vu que ça ne va rien apporter de spécial pour la majorité des gens, à part des arguments d'autorité foireux comme "si une boite qui est assis sur une pompe à fric l'utilise, alors ça doit être adapté à ce que je veux faire".
[^] # Re: Fauxpensource et libriste en carton ?
Posté par Misc (site web personnel) . En réponse au lien Windows prohibé chez Gitlab !!!. Évalué à -1.
Je suis pas d'accord. Le BIOS n'est pas "le plus sensible en terme de sécurité".
Deja, c'est loin d'être le plus exposé des logiciels ni le plus exploité. Il ne traite pas des données complexes venant du réseau, ses seuls inputs vont être le hardware au démarrage.
Et il suffit de remplacer "BIOS" par "grub" (qui est le suivant dans la chaine) dans la phrase pour voir que c'est totalement creux comme discours sauf dans l'esprit enfiévré d'une partie de la communauté du libre qui pense que la NSA et le Mossad s'intéresse à eux.
[^] # Re: De bonnes raisons ?
Posté par Misc (site web personnel) . En réponse au lien Windows prohibé chez Gitlab !!!. Évalué à 10.
Ensuite, l'administration système n'est pas vu comme attractive.
Ça paye moins qu'un dev (de ce que j'ai vu en parlant salaire avec les collégues, et en regardant des chiffres , la profession donne l'image de râleurs qui vont dire "non" (voir directement de connards, et il faut dire la vérité, c'est parfois non usurpé), le business ne va pas te voir comme générateur de valeur mais comme un coût.
Les grandes boites du net (style Google, facebook) ont repris l'idée de l'administration systéme mais en rajoutant "fait par des devs" sous le terme "devops", comme si les adminsys n'avaient jamais rien codé avant.
Et on va associer l'adminsys avec le fait d'avoir des astreintes, donc des contraintes un peu naze.
Donc franchement, faut pas se plaindre des écoles. Si on voulait plus d'admin, on pourrait payer plus et former les gens sans dépendre de l'éducation national. Le fait est que ça n'est pas ce qui est fait, donc la pénurie doit pas être si problématique que ça.
[^] # Re: De bonnes raisons ?
Posté par Misc (site web personnel) . En réponse au lien Windows prohibé chez Gitlab !!!. Évalué à 6.
Oui, quand j’étais sur ce genre de poste pendant 2 ans et demi, je l'ai déjà fait aussi parce que je sais le faire et que j'étais la. Contrairement à ce qu'on pourrais croire, les gens du support ne sont pas des monstres.
Ensuite, quand je n'étais pas la ou dans les bureaux sans service informatique sur place, ça passe par le fabriquant, ou les gens le font eux même.
Ensuite, on parle des Lenovos, qui sont facile à modifier (plus ou moins). Je pense que pour les macbooks, c'est direction le genius bar le plus proche (et ça doit être compris dans le support applecare, vu qu'une boite va payer pour ça).
[^] # Re: De bonnes raisons ?
Posté par Misc (site web personnel) . En réponse au lien Windows prohibé chez Gitlab !!!. Évalué à 3.
En pratique, c'est pas l'admin qui va faire ça, mais le support du fabricant. Et en général, tu ne rajoutes pas du matos aprés l'achat, tu t'arranges pour que ça soit directement fait avant la livraison.
Les revendeurs qui servent d’intermédiaire à Dell/Lenovo/etc font ça sans souci (ou peut être que c'est directement chez le fabricant).
[^] # Re: De bonnes raisons ?
Posté par Misc (site web personnel) . En réponse au lien Windows prohibé chez Gitlab !!!. Évalué à 4.
Le terme que tu cherches est sans doute "contrat de support".
Je pense qu'on se rends pas trop compte du gouffre qu'il y a entre les offres pas cher grand public (exemple, la téléphonie, l’accès internet) avec un support minimal et les offres pro plus cher, justement, parce que quelqu'un paye pour le support (et parce que le support, ça coûte de l'argent).
[^] # Re: De bonnes raisons ?
Posté par Misc (site web personnel) . En réponse au lien Windows prohibé chez Gitlab !!!. Évalué à 8. Dernière modification le 06 août 2022 à 11:33.
Je suppose qu'une bonne part a des admins pour gérer tout le parc. La, j'ai l'impression que les portables sont en gestion par les employés (cf le passage sur "on a besoin d'un screenshot pour prouver que vous avez un disque chiffré", ce qui n'aurait aucun sens si les portables étaient géré par des admins).
Du coup, ça change un peu la donne, et c'est pas tant interdire Windows qu'interdire Windows géré par les utilisateurs.
Dans une grande organisation, tu as en général un département informatique qui va filer des portables sous le contrôle du département, donc capable d'appliquer des GPO (politique de sécurité) avec un annuaire centralisé (eg active directory), etc.
C'est pas la direction que gitlab a pris.
[^] # Re: Qui a demandé ce projet ?
Posté par Misc (site web personnel) . En réponse au lien Les CNIL européennes se disent très inquiètes du projet antipédopornographie européen. Évalué à 4.
Oui, mais en même temps, c'est le point globalement le plus consensuel en politique.
Ensuite bien sur, dans le détail, c'est plus compliqué. C'est dur à évaluer, les projets (surtout en informatique) foirent assez régulièrement pour des raisons structurelles, les entreprises du privé s'arrangent pour maximiser l'argent gagné ce qui va à l'encontre d'économiser de l'argent, tu te retrouves avec des soucis imprévus et des erreurs, et la moindre connerie peut devenir assez vite un cauchemar politique.
Et ce qui est triste, c'est que ça ne semble pas être unique à la france, ce qui veut dire que c'est pas une question de personnes, et qu'on est sans doute pas plus des tocards que la moyenne, mais qu'il y a un truc plus profond qui fait que c'est relativement difficile de réussir.
Ça me rappelle pas mal les changements dans une grande boite (genre changement d'intranet, etc). La portée est moindre, mais pareil, ça a l'air complexe, ça foire pas mal etc. Et pourtant, je sais que les équipes qui bossent dessus sont ni mauvais, ni débutants, ni même contraint par des règles juridiques complexes.
Et pourtant, ça ne se déroule jamais comme prévu. Donc peut etre que l'humain est juste incroyablement confiant dans sa capacité à comprendre et à prévoir alors que c'est faux.
[^] # Re: Qui a demandé ce projet ?
Posté par Misc (site web personnel) . En réponse au lien Les CNIL européennes se disent très inquiètes du projet antipédopornographie européen. Évalué à 0.
Le premier truc, c'est la réduction des coûts.
Je sais pas pourquoi tout le monde va imaginer des cas de conspirations tirées d'un trip sous un mélange de cocaïne et térébenthine, au lieu de regarder le budget mais bon, faut toujours se dire que c'est ça.
Les forces de polices coûtent de l'argent, le reste aussi.
Les électeurs ne veulent pas en général payer plus d’impôts. Les gens sont parfois d'accord pour les augmenter, mais ceux des autres surtout (en général, les gens plus riches qu'eux, les gens à l'étranger, les entreprises), et le font savoir via le vote.
Peut être pas partout en Europe, mais c'est bien ce que je vois en France. Je sais pas si il y a des journaux qui expliquent comment payer moins d’impôts dans le reste du continent, mais ça revient assez souvent en France.
Du coup, maintenir un service égal, voir plus performant (cad qui traite plus de cas, ou des cas plus vite), ça passe par l'automatisation, ça passe par la simplification administrative (donc moins de vérif), ça passe par le fait de décharger des choses sur le privé.
Ou simplement, essayer de prévenir le crime au lieu d'attendre que ça soit fait, ça permet aussi de réduire les coûts.
Par exemple, la mise en commun des fichiers de police en 2011 (STIC et JUDEX), c'est de la réduction des coûts et de la simplification administrative. Sur le papier, ça évite de maintenir 2 bases pour rien, et ça aide les enquêteurs. En pratique, les fichiers sont sans doute mal remplis, il y a des fuites, etc.
On peut discuter sur le fait que la réduction soit effective ou pas (surtout dans un contexte ou le secteur privé va sans doute ajuster les offres par rapport à ce qui est déjà dépensé), on peut discuter sur les coûts cachés (maintenance), les dysfonctionnements des projets informatiques en général, etc.
Mais ça change rien que le but, c'est réduire et simplifier, car la complexité coûte, et que "il faut qu'on paye plus d’impôts pour maintenir les services" est une revendication que personne ne porte.
Par contre, faire plus ou autant avec autant ou moins d'argent, ç'est une constante.
Et maintenir les services, c'est aussi "ne pas avoir une série d'attentats" sur le territoire, en sachant que les groupes terroristes s'adaptent aussi (exemple, on est passé de groupe organisé des années 1970 comme la fraction armée rouge à des formes de terrorismes stochastiques avec des "loups solitaires").
L'infiltration des groupes et la surveillance comme dans les années 70 ne marchent sans doute pas pour les formes modernes, vu qu'il y a selon moins une évolution.
Ensuite, pour les histoires spécifiquement de pédocriminalités, c'est sans doute des associations de la société civile. Je ne connais pas ce qui se fait en Europe, mais aux USA, c'est des groupes comme NCOSE (parmi tant d'autres). Le livre The Digital Closet: How the Internet Became Straight détaille les dynamiques.
Le livre est en accès libre, je l'ai lu rapidement. J'ai trouvé le style un chouia inutilement provocateur et inflammatoire (et en général, je prends ça comme un signe qu'on tente de me manipuler, et je coupe rapidement), mais la thèse exposé dans le livre a le mérite de ne pas être trop farfelu, donc j'invite les gens à le lire tout en gardant un esprit critique (sauf si bien sur vous voulez des arguments pour chier sur Google et Facebook avec un peu de mauvaise foi, auquel cas le livre va plaire).
Donc je ne doute pas qu'une partie vient des fondamentalistes américains que j'ai cité, mais aussi des groupes conservateurs classiques basé en Europe (eg, le Vatican/Opus Dei, l'European Centre for Law & Justice, etc).
[^] # Re: Beaucoup de bruit...
Posté par Misc (site web personnel) . En réponse au lien GitLab plans to delete dormant projects in free accounts. Évalué à 4.
Je pense qu'il y a eu une réunion pour dire "la décision est final", quelqu'un a fuité l'info à la presse pour faire changer d'avis car l'idée semble désastreuse, et la personne en charge de la décision a du changé d'avis.
[^] # Re: Beaucoup de bruit...
Posté par Misc (site web personnel) . En réponse au lien GitLab plans to delete dormant projects in free accounts. Évalué à 6. Dernière modification le 05 août 2022 à 09:40.
J'invite aussi à lire l'article de "the register" sur le sujet: https://www.theregister.com/2022/08/05/gitlab_reverses_deletion_policy/
Il y a aussi des commentaires intéressants sur https://news.ycombinator.com/item?id=32350180
Par exemple, le code qui efface les projets explique l'idée
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/85689
une discussion sur "last_updated_at":
https://gitlab.com/gitlab-org/gitlab/-/issues/366467
[^] # Re: Beaucoup de bruit...
Posté par Misc (site web personnel) . En réponse au lien GitLab plans to delete dormant projects in free accounts. Évalué à 5.
Alors, justement, gitlab a fini par répondre:
https://twitter.com/gitlab/status/1555325376687226883
[^] # Re: Pire des options
Posté par Misc (site web personnel) . En réponse au lien GitLab plans to delete dormant projects in free accounts. Évalué à 3.
Oui, c'est pour ça que je les pointe et que je colle le passage.
Ensuite, combien de fois est ce que ça a été appliqué ?
Parce que si on va par la, Framasoft se réserve le droit de fermer le compte même plus jeune que 6 mois (sur la même page):
"Framasoft se réserve le droit, à tout moment de modifier ou d’interrompre, temporairement ou définitivement, le service avec ou sans préavis."
[^] # Re: Pire des options
Posté par Misc (site web personnel) . En réponse au lien GitLab plans to delete dormant projects in free accounts. Évalué à 3.
Pareil. Les conditions n'en parlent pas:
https://framagit.org/-/users/terms
Par contre, ce qui est dit, c'est que Framasoft se réserve le droit de le faire:
https://framasoft.org/fr/cgu
"Framasoft se réserve également le droit de résilier votre compte si vous ne vous connectez pas à votre compte pour une période supérieure à 6 mois."
Ça ne veut pas dire que ça va être fait systématiquement, ni même que c'est fait pour framagit.
[^] # Re: Pire des options
Posté par Misc (site web personnel) . En réponse au lien GitLab plans to delete dormant projects in free accounts. Évalué à 4.
bien sur, mais il y a une différence entre "l'admin efface les dépôts dans des conditions exceptionnels" et "la politique est d'effacer systématiquement des dépôts".
J'ai jamais eu un dépot qui a été effacer par github ou gitlab pour le moment. Par contre, si ce que je comprends est mis en place, j'aurais sans doute du code à moi qui va disparaître si je fait rien (et pourtant j'utilise ce code, et je pousse régulièrement sur gitlab.com).
D'ou l'idée d'échelle de risque.
[^] # Re: Pire des options
Posté par Misc (site web personnel) . En réponse au lien GitLab plans to delete dormant projects in free accounts. Évalué à 3.
non, mais c'est le critère annoncé par Gitlab.
Oui, bien sur. Mais:
- un nom de domaine qui expire n'est normalement pas automatiquement disponible, donc tu va avoir un souci visible assez vite si tu as une CI, etc. Ensuite, je suppose que tout les registrars ne sont pas Gandi.
Clairement, ça me parait contre productif, je suis d'accord.
Ensuite, il y a une échelle des risques, et la, gitlab risque de grimper d'un échelon. Le bon coté, c'est qu'il me parait facile de vérifier si une de tes dépendances va disparaître de gitlab via leur API.
[^] # Re: Pire des options
Posté par Misc (site web personnel) . En réponse au lien GitLab plans to delete dormant projects in free accounts. Évalué à 6.
Mais ce n'est pas parce que le code n'est pas modifié qu'il est peu supporté.
J'ai des roles ansibles triviaux que j'ai pas eu besoin de toucher et qui marchent encore. Ils sont sur ma propre forge, donc j'ai pas le souci, mais je me vois pas rajouter 1 commit tout les ans pour un truc dont le seul but est de faire un include de 3 roles.
Et bon, il faut aussi voir le timing de tout ça, tu dépends de code mort, tu préféres qu'on te le dise, et que tu géres à ton rythme, ou que tu découvres que la CI ne compile plus, même sur les versions stables, parce que la plateforme l'a retiré ?
Parce qu'on risque de se retrouver avec "left-pad II, le retour"
(j'avais proposé "left-pad de quartier", mais la productrice ne m'a pas suivi)