J'ai remarqué que depuis quelques mois, mon ordi portable pro souffle de plus en plus d'air chaud, alors même que je n'ai pas changé mes habitudes sur cette machine, ni que htop me montre des efforts indécents du CPU. Je l'ai même ouvert pour vérifier que le radiateur et le ventilo ne sont pas encrassés. Vu que cet ordi tourne quasi tous les jours depuis 7 ans, cette histoire de pâte craquelée, vieillie, pourrait bien être la cause de cette chauffe.
Aujourd'hui j'ai testé 3 écrans, dont deux chainés. Ecran 2 <-> écran 1 <-> prise 1 de la CG, et écran 3 <-> prise 2 de la CG, tout ça en display port. J'ai eu du mal à obtenir une image sur le 2. Après avoir activé DiplayPort 1.2 dans la configuration des écrans, ça n'a pas fonctionné tout de suite. Après plusieurs manipulations (reboot, extinction/rallumage des écrans), ça a fini par fonctionner mais je ne sais pas trop comment au final :)
J'ai donc une image sur l'écran 2. Sous Linux, il s'agit de l'affichage cloné de l'écran 1. Dans les paramètres affichage de KDE, il n'y a cependant que 2 écrans représentés (1 et 3). À priori Xorg ne "voit" pas l'écran 2, car même quand je débranche le 2, il ne se passe rien au niveau de l'affichage, genre une reconfiguration, comme cela arrive si je débranche les écrans 1 ou 3.
J'ai tenté d'installer les drivers proprio d'AMD : pas d'amélioration.
Sous Windows par contre, j'ai bien 3 écrans représentés dans la configuration de l'affichage, non clonés, et je peux les déplacer, changer l'orientation etc..
Peut-être faut-il que je modifie à la main la conf xorg ? (mais je ne trouve pas le fichier xorg.conf, il n'est pas dans /etc/X11)…
Ou alors le chainage d'écran en display port n'est pas implémenté ?
Finalement, j'ai découvert qu'avec le DisplayPort 1.2, on peut chainer plusieurs écrans. Par exemple: brancher un écran sur un autre écran sur un autre écran sur la carte graphique. Apparemment mes écrans prennent en charge le DP 1.2 et ont les entrées/sorties qu'il faut. Je vais pouvoir donc brancher deux écrans sur une seule prise, et le troisième écran sur la deuxième prise. D'après la documentation de la carte graphique, je peux brancher six écrans au total. Pas besoin d'avoir une deuxième carte graphique.
Reste à savoir comment va se comporter Linux/Xorg/KDE avec tout ça. C'est la grande inconnue.
Il n'y a plus qu'à tester, ce que je pourrais faire la semaine prochaine :-)
J'ai effectivement un troisième port DVI, mais je pensais que je ne pouvais pas l'utiliser en même temps que les deux display port. Je viens de vérifier la documentation et à priori c'est possible. Je vais tester ça.
Vous pouvez dire lequel? Vou parle de coût, mais désolé je ne vois pas : mettre un fichier de licence, pusher sur le Git public plutôt que privé, écrire "posé la, faite ce que vous voulez mais ne m'emmerdez pas avec", bloquer les trackers sur GitHub, et basta, ça coûte tant que ça pour vous?
En fonction du projet, oui, libérer du code source, ça a un coût. Par exemple, pour libérer du code, on peut devoir :
supprimer ou remplacer du code qui est trop dépendant de son environnement initial (des chemins en dur par exemple…)
supprimer des infos confidentielles
extraire les parties de codes que l'on veut garder proprio car trop spécifique à l'activité de l'entreprise : cette extraction peut nécessiter de mettre en place "un fork", ou un système de plugins etc…
anonymiser les contributeurs dans l'historique pour des raisons de confidentialités. Bien qu'en général le copyright est celui de la boite, tous les contributeurs au projet n'ont peut-être pas envie de se retrouver sur github avec leur nom, prénom, email pro, surtout ceux qui ne font plus parti de la boite (encore moins ceux qui sont parti en mauvais terme ou qui veulent oublier cette expérience professionnelle).
Bref, ça peut être un boulot énorme. Et bien sûr, qui dit suppression de code ou autre info confidentielle, veut dire publier les sources sur un nouveau dépôt sans l'historique de la période "proprio". Cela peut avoir des répercussions sur l'intégration continue ou je ne sais quoi d'autres…
Je ne parle pas non plus des coûts liés à l'administratif dans les grosses boites, genre la demande "bonjour, je veux pouvoir poser ce tar.gz sur le serveur XY" qui doit passer par un mille-feuille administratif, ensuite passer par le service admin système pour ouvrir des accés, préparer l'hebergement etc…
Bref, des raisons de coûts, on peut en trouver plein, en fonction de la complexité du projet, de son historique, de la taille de la boite, de la volonté de faire bien les choses ou pas etc..
Et si tu n'es pas convaincu, je te propose de voir (ou revoir) Code Rush, le documentaire qui retrace la libération de Netscape 4, qui devint alors le projet Mozilla. Typique d'une libération d'un projet qui contient du code proprio que l'on ne veut pas libérer, qu'il faut pouvoir compiler avec des outils open-sources, avec en plus ici (un peu particulier certes), l'ouverture aux outils d'intégration continue, au bug tracker, sans compter l'ouverture d'un site dédié etc..
Il y a une "guerre" entre les GAFAM et autres grosses boites, pour avoir les meilleurs développeurs. Celui qui a les meilleurs développeurs (et manageur aussi), a de plus fortes chances de croitre. Tu n'as pas de bons produits sans bons développeurs. Or les très bons, voir bons développeurs, ne courent pas les rues.
Aussi, si tu as accès à une base de données contenant des milliers de profils de développeurs, (et surtout la possibilité d'interroger cette base de donnée plus finement que tu ne peux le faire au travers d'une interface web publique), tu as plus de chances de trouver les perles rares, donc de les débaucher.
Pourquoi ? pour des enjeux stratégiques. Si tu externalises tout, tu affaiblis ta capacité de résiliance et donc de survie. De mon point de vue, pour une boite qui fait du logiciel, des outils comme une forge logiciels, un système d'intégration continue et j'en passe, sont vitaux.
Et c'est pas comme si il fallait 3 semaines pour installer et configurer un gitlab. En une demi-journée c'est plié (ou en un apt-get install "pour voir").
Maintenant chacun met le curseur du compromis sécurité/confidentialité/coût de maintenance où il le sent.
Il est donc simple est facile de migrer ses dépôts d'une forge à une autre.
Il y a le souci quand même de l'export/import des tickets. Ça se fait, mais pas si facilement. Et les tickets, c'est tout aussi important que le code source, ça fait parti de l'historique du projet, mais aussi de la gestion du projet.
Les logiciels libres, ce n'est pas important quand on acquiert un Github, parce que même si ils vont ailleurs, leur code source restera dispo quelque part.
Par contre, une chose que personne n'a accès publiquement, ce sont les milliers de dépôt privés de sociétés petites ou grosses, dont certaines probablement des concurrents directs. Microsoft va avoir accès à des milliers de "secrets industriels".
Avant de râler sur linuxfr dans un journal bien senti à l'encontre des administrateurs pour dire ce que j'en pense, j'ai pris la peine dans le courant de la matinée, dans la seconde après avoir découvert cette insupportable situation d'insécurité, d'avertir les administrateurs par Twitter. (chose que personne à priori n'avait fait :-/ ).
Bien m'en a pris, puisque notre cher président m'a répondu et a pris le problème très au sérieux en "likant" mon tweet dans les minutes qui ont suivi, puis a répondu quelques dizaines de minutes après, le temps d'investiguer je suppose, qu'ils étaient sur le coup.
Environ deux heures après, dixit notre cher admin sys, le problème était résolu, en plus, d'une heureuse manière : ce bon vieux certificat acheté à prix d'or chez Gandi, a été remplacé par un certificat let's encrypt gratuit, qui sera renouvelé périodiquement automatiquement. Le problème ne devrait donc plus réapparaitre !
Du coup, je n'ai plus envie de râler dans un journal, mais plutôt faire un bisou à nos sauveurs, qui n'hésitent pas à mouiller la chemise même par un beau dimanche ensoleillé :-)
Je ne voudrais pas troller, mais je suis étonné qu'il n'y ait pas IRC dans ta liste.
En tant que membre d'une équipe utilisant du Team Chat, nos trois plus gros problèmes sont :
1. je ne sais pas
2. je ne trouve pas
3. y en a pas
IRC suffit largement à notre Team : client légers (mon dieu quel grosse bouse Slack en terme d'occupation mémoire !), multiplateforme, décentralisé, interfaces simples (pas de chichi et pas de conneries animées dans tous les sens), intégration dans le bureau (après ça dépend des clients), serveurs installables en local pour ceux qui veulent de la maxi privacy. Et ça fait des années qu'on fonctionne avec ça (j'utilise IRC perso depuis les années 1996).
Et tous les problèmes indiqués dans les commentaires existants au moment de l'écriture de ce commentaire : ils n'existent pas avec IRC ^_^
pouvoir chatter en 1-1 et par groupes.
Avec IRC, c'est possible. /query pour le 1-1, /join #nomquejeveux pour les groupes
que l'historique des conversations soit enregistré/si un membre du groupe n'est pas là il a accès à l'historique.
Installation du bot qui va bien. No problem. Au pire, envoi du log de son client local au membre qui était absent.
faire 1 et 2 de manière cross-plateform, sans que ce soit compliqué.
Il y a des clients IRC pour toutes plateformes
On ne peut pas "highlighter/mentioner" quelqu'un sans mettre son nom complet.
Là c'est pas une "feature" spécifique à un protocole, mais au client de chat. Mauvais client, changer client.
Dans un bon client IRC (genre irssi), on tape le début du nom puis <tab> et hop…
On ne peut pas communiquer avec les bots ; ils sont unidirectionnels.
Avec IRC, si, bien sûr ^_^.
Tous les emojis et smileys sont interprétés.
Pareil que pour les mentions. Mauvais client, changer client.
Pour les autres problèmes mentionnés, il s'agit plus d'organisation (et/ou de communication) que d'un problème d'outils, et on peut les retrouver avec n'importe quel outil de team chat.
Pertinentes pour des sujets généraux. Mais dès qu'on fait dans le technique (genre tout ce qui concerne le développement logiciel/web..), ce n'est pas pertinent du tout, voir réponses complètement à coté de la plaque, quand il ne répond pas "aucune réponse". C'est dur à dire, mais Google est beaucoup plus pertinent sur ces sujets.
À cela il faut ajouter des erreurs de type 500 (erreur serveurs) régulières (en tout cas avec Qwant lite, n'utilisant pas le Qwant normal à cause de son interface trop lourde à mon gout).
J'ai même trouvé ces derniers mois qu'il était de moins en moins pertinent, et de plus en plus en erreur : j'ai fini par jeter l'éponge il y a quelques semaines hélas :-( Je ne peux pas me permettre de perdre du temps à cause de ça pour le boulot (je fais des dizaines de recherches par jour)…
Mais j'essaye de l'utiliser de temps en temps quand même…
Mais tu n'as pas répondu pourquoi mon nom, adresse postale, numéro de téléphone et autres données personnelles doivent être diffusées, juste parce que je possède une entreprise et non pas un nom de domaine.
Parce que tout simplement c'est la loi qui l'y oblige. Personnellement je ne trouve pas ça normal à notre époque. C'était peut-être acceptable à l'époque où il n'y avait pas internet, parce que c'était contraignant pour obtenir ces informations et que donc ça limitait les problèmes. Manifestement, il y a selon moi une incompatibilité avec le RGPD (il faudrait montrer patte blanche pour accéder aux extrait kbis).
Pareil pour infogreffe, on est donc d'accord qu'infogreffe devrait cacher? Pareil pour Panama
oui on est d'accord.
tu as évité de répondre à une question précise, en brodant autour, du HS
bla bla bla. Tu as très bien compris mon propos. Ne te fait pas prendre pour moins intelligent que tu es.
qu'elle différence fais-tu entre whois et infogreffe?
Tu compares des choux et des carottes. Une entreprise par définition, c'est publique.
Un nom de domaine, est certes, publique, mais son propriétaire n'est pas forcément une personne morale. J'ai plusieurs noms de domaines que je possède à titre personnel, qui pointent vers des sites non commerciaux, et non, désolé, je n'ai pas envie que mon nom, adresse postale, numéro de téléphone et autres données personnelles soient diffusées à tout le monde. Je ne vois pas en quoi il faudrait que cela le soit.
C'est comme si il fallait obligatoirement qu'un livre contiennent la véritable identité de son auteur, ainsi que son adresse domicile, numéro de téléphone etc.
Il serait bon de vouloir arrêter d'imposer sa vision des choses à tous le monde. C'est pas parce qu'on place le curseur de sa vie privée à un certain niveau (genre diffusion à tous le monde de ses coordonnées domicile), qu'il faut imposer ce curseur à tous le monde. J'estime avoir le droit d'avoir un minimum de vie privée.
pour voir les différents liens entre les gens et les sites.
Non, je n'ai pas envie que n'importe qui voit les liens entre moi et des sites, en particulier les coordonnées de mon Domicile. Et j'emmerde ceux qui ne sont pas content.
Et si ils veulent voir pour des raisons légales (genre enquête de police ou autre), bah, ils ont à priori les moyens légaux d'aller interroger le registrar.
Les licences libres ne donnent pas de droits aux auteurs, mais aux utilisateurs.
Alors d'abord ça dépend des licences libres, il n'y a pas que la GPL dans la vie et encore, je doute qu'elle ne donne pas de droits aux auteurs. D'autres parts, si elles ne donnent pas de droits aux auteurs, cela veut dire qu'un contributeur peut par exemple s'attribuer la paternité de mes contributions sans que je puisse dire quelque chose ?? je ne crois pas..
J'imagine aussi que c'est impossible de retirer des informations personnelles tant qu'on utilise un service qui en a besoin.
C'est ce que j'ai écris. Le RGPD impose toutefois de signaler à l'utilisateur ce qu'il fait de ses données personnelles.
Non, mais le problème, c'est que ces informations sont publiques. À ma connaissance, l'URSAFF ne publie pas les informations personnelles.
Je ne comprends pas, ces données, elles sont publiques ou pas ? ;-)
Quoiqu'il en soit, l'URSAFF échange ces données (une partie au moins) avec d'autres services de l'état il me semble.
Le cas de l'URSAFF et d'autres similaires, c'est que là, les données ne sont pas seulement nécessaire au fonctionnement du service, mais est aussi imposée par des lois (qui t'obligent à donner certaines données personnelles à l'URSAF).
Bref, les obligations imposées par des lois doivent probablement faire parti des exceptions dans le RGPD.
ypiquement, les infos personnelles disponibles par whois sont indispensables pour l'identification du propriétaire d'un nom de domaine
Le WHOIS est encore un cas intéressant, et fait d'ailleurs débat actuellement. Que l'on puisse t'identifier, oui, mais la question est, qui peut t'identifier. Que le registrar auprès duquel tu as réservé ton nom de domaine, stocke dans le WHOIS tes informations personnels, cela peut se comprendre. Mais que ces informations puissent être diffusées à n'importe qui dans le monde, c'est franchement discutable. Heureusement certains registrar comme Gandi permettent d'obfusquer ces informations (je crois que concrètement, les données restent dans leur base, et dans le WHOIS, elles n'y apparaissent pas)..
Dans git, l'identifiant est le résultat du hashage de ces informations. Si tu les modifies, cela veut dire que l'id ne correspond plus. C'est la manière utilisée dans git pour certifier l'authenticité des informations.
Changer la manière dont c'est fait ou stocké, revient à créer un nouveau format de stockage de Git. Je te laisse en discuter alors avec les mainteneurs de git ;-)
une modification d'un article, ça ressemble à un commit
Oui, mais chez wikipedia, à priori, l'identifiant d'un "commit" n'est pas lié à son parent. Le modifier n'impacte en rien le système. Et puis j'imagine que l'utilisateur est identifié dans une autre table dédié aux utilisateurs, et qu'il n'y a dans le "commit" qu'une référence vers cet utilisateur. Il "suffit" dans ce cas, à priori, juste de modifier un enregistrement dans la base de donnée pour changer le nom en "anonymous1234".
Dans Git, c'est différent, car l'identifiant d'un commit est calculé en fonction de son contenu, c'est à dire en fonction du nom et email de l'auteur, de l'identifiant des commits parents etc.. Changer une information dans le commit, et ça change les identifiants de tous les commits descendants.
Comme je le dis plus bas, en théorie, c'est possible. Mais en pratique, c'est un cauchemar pour les autres utilisateurs, puisque tous les identifiants de commits changent : ça fout la merde chez les développeurs, dans les systèmes d'intégration continue, dans les bugs trackers etc. Et plus le projet est gros, plus tu t'approches de l'enfer. Donc en pratique, c'est juste pas possible.
j'ai du mal à voir comment ce changement peut être légal dans le cadre de la RGPD/GPRD
Dans le cadre d'une participation à un projet open-source, quel qu'il soit, depuis la nuit des temps, implicitement tu acceptes que ton nom et ton email soient publiques. Je ne vois pas comment cela peut être autrement. Il faut bien, à un moment ou à un autre, qu'on puisse t'identifier, ne serait-ce que pour appliquer les droits que t'autorise la licence libre utilisée.
Cette identification peut être réèlle (ton vrai nom, et une adresse mail contenant ton nom), ou peut être anonymisée (un pseudo, et une adresse basée sur un pseudo).
Quoi qu'il en soit, en contribuant, tu as donné ton accord pour que l'identité que tu as donné soit publique.
On peut maintenant s'interroger sur la retractation, puisque le RGPD te permet en théorie de supprimer tes données personnelles. Mais dans le cadre d'un dépot git (open-source ou pas), ça devient particulièrement complexe. Certes, en théorie, il serait possible de réécrire tous les commits où ton nom/email apparait. Mais cela revient à créer un nouveau dépôt puisque tous les identifiants des commits créés depuis ta première participation sont changés. Et si il y a besoin de faire ça régulièrement, dans la pratique, cela devient un cauchemar pour les développeurs, puisqu'il faudrait "rebaser" son travail en cours sur un dépôt totalement nouveau, sans parler de tous les outils qui référencent des commits (integration continue, bug tracker…). Bref, en pratique, ce n'est pas possible.
Et fort heureusement, je crois que le RGPD prévoit les cas où tes informations personnelles sont absolument nécessaires au fonctionnement d'un service ou d'une entreprise (vous imaginez ? "bonjour l'urssaf, supprimez toutes mes données personnelles siouplait").
Bref, la suppression de tes données personnelles dans les dépots git étant impossible, et ce cas d'impossibilité de suppression étant prévu par le RGPD, Gitlab respecte de mon point de vue le RGPD. Donc soit tu acceptes que ton nom/email soit utilisé et tu ne pourras pas faire machine arrière, soit tu n'utilises pas le service.
Sur des clefs usb ou autre "petit" stockages externes, je me suis toujours interrogé sur la pertinence d'utiliser ext3 ou ext4. Alors si en plus il est préférable de désactiver le journal comme conseillé ici, pourquoi ne pas proposer tout simplement de formater en ext2 ? Parce qu'à priori, sur une clé USB, ses caractéristiques suffisent (sauf si on a des gros gros fichiers).
# Merci pour le tuyau
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Tectonique de la pâte thermique (Linux Pratique). Évalué à 5.
J'ai remarqué que depuis quelques mois, mon ordi portable pro souffle de plus en plus d'air chaud, alors même que je n'ai pas changé mes habitudes sur cette machine, ni que htop me montre des efforts indécents du CPU. Je l'ai même ouvert pour vérifier que le radiateur et le ventilo ne sont pas encrassés. Vu que cet ordi tourne quasi tous les jours depuis 7 ans, cette histoire de pâte craquelée, vieillie, pourrait bien être la cause de cette chauffe.
Je vais vérifier ça ! Merci :-)
[^] # Re: Chainer plusieurs écrans
Posté par Laurent J (site web personnel, Mastodon) . En réponse au message Brancher plus de 2 écrans. Évalué à 2.
Aujourd'hui j'ai testé 3 écrans, dont deux chainés. Ecran 2 <-> écran 1 <-> prise 1 de la CG, et écran 3 <-> prise 2 de la CG, tout ça en display port. J'ai eu du mal à obtenir une image sur le 2. Après avoir activé DiplayPort 1.2 dans la configuration des écrans, ça n'a pas fonctionné tout de suite. Après plusieurs manipulations (reboot, extinction/rallumage des écrans), ça a fini par fonctionner mais je ne sais pas trop comment au final :)
J'ai donc une image sur l'écran 2. Sous Linux, il s'agit de l'affichage cloné de l'écran 1. Dans les paramètres affichage de KDE, il n'y a cependant que 2 écrans représentés (1 et 3). À priori Xorg ne "voit" pas l'écran 2, car même quand je débranche le 2, il ne se passe rien au niveau de l'affichage, genre une reconfiguration, comme cela arrive si je débranche les écrans 1 ou 3.
J'ai tenté d'installer les drivers proprio d'AMD : pas d'amélioration.
Sous Windows par contre, j'ai bien 3 écrans représentés dans la configuration de l'affichage, non clonés, et je peux les déplacer, changer l'orientation etc..
Peut-être faut-il que je modifie à la main la conf xorg ? (mais je ne trouve pas le fichier xorg.conf, il n'est pas dans /etc/X11)…
Ou alors le chainage d'écran en display port n'est pas implémenté ?
# Chainer plusieurs écrans
Posté par Laurent J (site web personnel, Mastodon) . En réponse au message Brancher plus de 2 écrans. Évalué à 4. Dernière modification le 28 juin 2018 à 21:28.
Finalement, j'ai découvert qu'avec le DisplayPort 1.2, on peut chainer plusieurs écrans. Par exemple: brancher un écran sur un autre écran sur un autre écran sur la carte graphique. Apparemment mes écrans prennent en charge le DP 1.2 et ont les entrées/sorties qu'il faut. Je vais pouvoir donc brancher deux écrans sur une seule prise, et le troisième écran sur la deuxième prise. D'après la documentation de la carte graphique, je peux brancher six écrans au total. Pas besoin d'avoir une deuxième carte graphique.
Reste à savoir comment va se comporter Linux/Xorg/KDE avec tout ça. C'est la grande inconnue.
Il n'y a plus qu'à tester, ce que je pourrais faire la semaine prochaine :-)
[^] # Re: re
Posté par Laurent J (site web personnel, Mastodon) . En réponse au message Brancher plus de 2 écrans. Évalué à 3.
J'ai effectivement un troisième port DVI, mais je pensais que je ne pouvais pas l'utiliser en même temps que les deux display port. Je viens de vérifier la documentation et à priori c'est possible. Je vais tester ça.
Merci de m'avoir rappelé que j'avais du DVI :-)
[^] # Re: Mettre à dispo du code coûte cher
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 7. Dernière modification le 14 juin 2018 à 14:18.
En fonction du projet, oui, libérer du code source, ça a un coût. Par exemple, pour libérer du code, on peut devoir :
Bref, ça peut être un boulot énorme. Et bien sûr, qui dit suppression de code ou autre info confidentielle, veut dire publier les sources sur un nouveau dépôt sans l'historique de la période "proprio". Cela peut avoir des répercussions sur l'intégration continue ou je ne sais quoi d'autres…
Je ne parle pas non plus des coûts liés à l'administratif dans les grosses boites, genre la demande "bonjour, je veux pouvoir poser ce tar.gz sur le serveur XY" qui doit passer par un mille-feuille administratif, ensuite passer par le service admin système pour ouvrir des accés, préparer l'hebergement etc…
Bref, des raisons de coûts, on peut en trouver plein, en fonction de la complexité du projet, de son historique, de la taille de la boite, de la volonté de faire bien les choses ou pas etc..
Et si tu n'es pas convaincu, je te propose de voir (ou revoir) Code Rush, le documentaire qui retrace la libération de Netscape 4, qui devint alors le projet Mozilla. Typique d'une libération d'un projet qui contient du code proprio que l'on ne veut pas libérer, qu'il faut pouvoir compiler avec des outils open-sources, avec en plus ici (un peu particulier certes), l'ouverture aux outils d'intégration continue, au bug tracker, sans compter l'ouverture d'un site dédié etc..
[^] # Re: Pourquoi s’en inquiéter ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Microsoft rachète Github. Évalué à 3.
Dans le message auquel je répondais, ça parlait du rachat de LinkedIn, pas de github ;-)
[^] # Re: Pourquoi s’en inquiéter ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Microsoft rachète Github. Évalué à 8.
Il y a une "guerre" entre les GAFAM et autres grosses boites, pour avoir les meilleurs développeurs. Celui qui a les meilleurs développeurs (et manageur aussi), a de plus fortes chances de croitre. Tu n'as pas de bons produits sans bons développeurs. Or les très bons, voir bons développeurs, ne courent pas les rues.
Aussi, si tu as accès à une base de données contenant des milliers de profils de développeurs, (et surtout la possibilité d'interroger cette base de donnée plus finement que tu ne peux le faire au travers d'une interface web publique), tu as plus de chances de trouver les perles rares, donc de les débaucher.
[^] # Re: Pourquoi le feraient-ils ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Microsoft rachète Github. Évalué à 6.
Pourquoi ? pour des enjeux stratégiques. Si tu externalises tout, tu affaiblis ta capacité de résiliance et donc de survie. De mon point de vue, pour une boite qui fait du logiciel, des outils comme une forge logiciels, un système d'intégration continue et j'en passe, sont vitaux.
Et c'est pas comme si il fallait 3 semaines pour installer et configurer un gitlab. En une demi-journée c'est plié (ou en un apt-get install "pour voir").
Maintenant chacun met le curseur du compromis sécurité/confidentialité/coût de maintenance où il le sent.
[^] # Re: Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Microsoft rachète Github. Évalué à 4.
Tu devrais aller faire un tour sur le compte Github de Microsoft…
[^] # Re: Oui et ....
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Microsoft rachète Github. Évalué à 4.
Il y a le souci quand même de l'export/import des tickets. Ça se fait, mais pas si facilement. Et les tickets, c'est tout aussi important que le code source, ça fait parti de l'historique du projet, mais aussi de la gestion du projet.
[^] # Re: Pourquoi le feraient-ils ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Microsoft rachète Github. Évalué à 10.
Il ne faut pas aller s'héberger chez Gitlab, mais installer Gitlab chez soi ! (en tout cas quand on est une entreprise).
Qui vous dit que Gitlab ne va pas se faire racheter par un Gafa dans quelques mois, en riposte à ce rachat Github ?
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Microsoft rachète Github. Évalué à 10.
Les logiciels libres, ce n'est pas important quand on acquiert un Github, parce que même si ils vont ailleurs, leur code source restera dispo quelque part.
Par contre, une chose que personne n'a accès publiquement, ce sont les milliers de dépôt privés de sociétés petites ou grosses, dont certaines probablement des concurrents directs. Microsoft va avoir accès à des milliers de "secrets industriels".
C'est ça qui vaut des milliards.
[^] # Re: Bon et bience lundi 4 juin : rebelotte !!
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal DLFP hacké. Évalué à 5.
Ce n'est pas plutôt ton cache navigateur qui te joue des misères ?
# Début du compte rendu
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal DLFP hacké. Évalué à 10. Dernière modification le 03 juin 2018 à 11:59.
Avant de râler sur linuxfr dans un journal bien senti à l'encontre des administrateurs pour dire ce que j'en pense, j'ai pris la peine dans le courant de la matinée, dans la seconde après avoir découvert cette insupportable situation d'insécurité, d'avertir les administrateurs par Twitter. (chose que personne à priori n'avait fait :-/ ).
Bien m'en a pris, puisque notre cher président m'a répondu et a pris le problème très au sérieux en "likant" mon tweet dans les minutes qui ont suivi, puis a répondu quelques dizaines de minutes après, le temps d'investiguer je suppose, qu'ils étaient sur le coup.
Environ deux heures après, dixit notre cher admin sys, le problème était résolu, en plus, d'une heureuse manière : ce bon vieux certificat acheté à prix d'or chez Gandi, a été remplacé par un certificat let's encrypt gratuit, qui sera renouvelé périodiquement automatiquement. Le problème ne devrait donc plus réapparaitre !
Du coup, je n'ai plus envie de râler dans un journal, mais plutôt faire un bisou à nos sauveurs, qui n'hésitent pas à mouiller la chemise même par un beau dimanche ensoleillé :-)
# Et IRC ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Points de douleur du Team Chat ?. Évalué à 5.
Je ne voudrais pas troller, mais je suis étonné qu'il n'y ait pas IRC dans ta liste.
En tant que membre d'une équipe utilisant du Team Chat, nos trois plus gros problèmes sont :
1. je ne sais pas
2. je ne trouve pas
3. y en a pas
IRC suffit largement à notre Team : client légers (mon dieu quel grosse bouse Slack en terme d'occupation mémoire !), multiplateforme, décentralisé, interfaces simples (pas de chichi et pas de conneries animées dans tous les sens), intégration dans le bureau (après ça dépend des clients), serveurs installables en local pour ceux qui veulent de la maxi privacy. Et ça fait des années qu'on fonctionne avec ça (j'utilise IRC perso depuis les années 1996).
Et tous les problèmes indiqués dans les commentaires existants au moment de l'écriture de ce commentaire : ils n'existent pas avec IRC
^_^Avec IRC, c'est possible.
/querypour le 1-1,/join #nomquejeveuxpour les groupesInstallation du bot qui va bien. No problem. Au pire, envoi du log de son client local au membre qui était absent.
Il y a des clients IRC pour toutes plateformes
Là c'est pas une "feature" spécifique à un protocole, mais au client de chat. Mauvais client, changer client.
Dans un bon client IRC (genre irssi), on tape le début du nom puis
<tab>et hop…Avec IRC, si, bien sûr
^_^.Pareil que pour les mentions. Mauvais client, changer client.
Pour les autres problèmes mentionnés, il s'agit plus d'organisation (et/ou de communication) que d'un problème d'outils, et on peut les retrouver avec n'importe quel outil de team chat.
[^] # Re: Qwant lite
Posté par Laurent J (site web personnel, Mastodon) . En réponse au sondage Quel (méta)moteur de recherche/annuaire du web respectueux de la vie privée utilisez-vous ?. Évalué à 2. Dernière modification le 29 mai 2018 à 18:23.
Pertinentes pour des sujets généraux. Mais dès qu'on fait dans le technique (genre tout ce qui concerne le développement logiciel/web..), ce n'est pas pertinent du tout, voir réponses complètement à coté de la plaque, quand il ne répond pas "aucune réponse". C'est dur à dire, mais Google est beaucoup plus pertinent sur ces sujets.
À cela il faut ajouter des erreurs de type 500 (erreur serveurs) régulières (en tout cas avec Qwant lite, n'utilisant pas le Qwant normal à cause de son interface trop lourde à mon gout).
J'ai même trouvé ces derniers mois qu'il était de moins en moins pertinent, et de plus en plus en erreur : j'ai fini par jeter l'éponge il y a quelques semaines hélas :-( Je ne peux pas me permettre de perdre du temps à cause de ça pour le boulot (je fais des dizaines de recherches par jour)…
Mais j'essaye de l'utiliser de temps en temps quand même…
[^] # Re: Pour les projets open-source
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 2. Dernière modification le 25 mai 2018 à 15:40.
Parce que tout simplement c'est la loi qui l'y oblige. Personnellement je ne trouve pas ça normal à notre époque. C'était peut-être acceptable à l'époque où il n'y avait pas internet, parce que c'était contraignant pour obtenir ces informations et que donc ça limitait les problèmes. Manifestement, il y a selon moi une incompatibilité avec le RGPD (il faudrait montrer patte blanche pour accéder aux extrait kbis).
oui on est d'accord.
bla bla bla. Tu as très bien compris mon propos. Ne te fait pas prendre pour moins intelligent que tu es.
[^] # Re: Pour les projets open-source
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 6.
Tu compares des choux et des carottes. Une entreprise par définition, c'est publique.
Un nom de domaine, est certes, publique, mais son propriétaire n'est pas forcément une personne morale. J'ai plusieurs noms de domaines que je possède à titre personnel, qui pointent vers des sites non commerciaux, et non, désolé, je n'ai pas envie que mon nom, adresse postale, numéro de téléphone et autres données personnelles soient diffusées à tout le monde. Je ne vois pas en quoi il faudrait que cela le soit.
C'est comme si il fallait obligatoirement qu'un livre contiennent la véritable identité de son auteur, ainsi que son adresse domicile, numéro de téléphone etc.
Il serait bon de vouloir arrêter d'imposer sa vision des choses à tous le monde. C'est pas parce qu'on place le curseur de sa vie privée à un certain niveau (genre diffusion à tous le monde de ses coordonnées domicile), qu'il faut imposer ce curseur à tous le monde. J'estime avoir le droit d'avoir un minimum de vie privée.
Non, je n'ai pas envie que n'importe qui voit les liens entre moi et des sites, en particulier les coordonnées de mon Domicile. Et j'emmerde ceux qui ne sont pas content.
Et si ils veulent voir pour des raisons légales (genre enquête de police ou autre), bah, ils ont à priori les moyens légaux d'aller interroger le registrar.
[^] # Re: Pour les projets open-source
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 2.
Je ne sais pas trop là. Tout dépend avec quel type de CLA on compare.
[^] # Re: Pour les projets open-source
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 2.
Alors d'abord ça dépend des licences libres, il n'y a pas que la GPL dans la vie et encore, je doute qu'elle ne donne pas de droits aux auteurs. D'autres parts, si elles ne donnent pas de droits aux auteurs, cela veut dire qu'un contributeur peut par exemple s'attribuer la paternité de mes contributions sans que je puisse dire quelque chose ?? je ne crois pas..
C'est ce que j'ai écris. Le RGPD impose toutefois de signaler à l'utilisateur ce qu'il fait de ses données personnelles.
Je ne comprends pas, ces données, elles sont publiques ou pas ? ;-)
Quoiqu'il en soit, l'URSAFF échange ces données (une partie au moins) avec d'autres services de l'état il me semble.
Le cas de l'URSAFF et d'autres similaires, c'est que là, les données ne sont pas seulement nécessaire au fonctionnement du service, mais est aussi imposée par des lois (qui t'obligent à donner certaines données personnelles à l'URSAF).
Bref, les obligations imposées par des lois doivent probablement faire parti des exceptions dans le RGPD.
Le WHOIS est encore un cas intéressant, et fait d'ailleurs débat actuellement. Que l'on puisse t'identifier, oui, mais la question est, qui peut t'identifier. Que le registrar auprès duquel tu as réservé ton nom de domaine, stocke dans le WHOIS tes informations personnels, cela peut se comprendre. Mais que ces informations puissent être diffusées à n'importe qui dans le monde, c'est franchement discutable. Heureusement certains registrar comme Gandi permettent d'obfusquer ces informations (je crois que concrètement, les données restent dans leur base, et dans le WHOIS, elles n'y apparaissent pas)..
[^] # Re: Git
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 6.
Dans git, l'identifiant est le résultat du hashage de ces informations. Si tu les modifies, cela veut dire que l'id ne correspond plus. C'est la manière utilisée dans git pour certifier l'authenticité des informations.
Changer la manière dont c'est fait ou stocké, revient à créer un nouveau format de stockage de Git. Je te laisse en discuter alors avec les mainteneurs de git ;-)
[^] # Re: Git
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 9.
Oui, mais chez wikipedia, à priori, l'identifiant d'un "commit" n'est pas lié à son parent. Le modifier n'impacte en rien le système. Et puis j'imagine que l'utilisateur est identifié dans une autre table dédié aux utilisateurs, et qu'il n'y a dans le "commit" qu'une référence vers cet utilisateur. Il "suffit" dans ce cas, à priori, juste de modifier un enregistrement dans la base de donnée pour changer le nom en "anonymous1234".
Dans Git, c'est différent, car l'identifiant d'un commit est calculé en fonction de son contenu, c'est à dire en fonction du nom et email de l'auteur, de l'identifiant des commits parents etc.. Changer une information dans le commit, et ça change les identifiants de tous les commits descendants.
[^] # Re: Git
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 10.
Comme je le dis plus bas, en théorie, c'est possible. Mais en pratique, c'est un cauchemar pour les autres utilisateurs, puisque tous les identifiants de commits changent : ça fout la merde chez les développeurs, dans les systèmes d'intégration continue, dans les bugs trackers etc. Et plus le projet est gros, plus tu t'approches de l'enfer. Donc en pratique, c'est juste pas possible.
# Pour les projets open-source
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 10.
Dans le cadre d'une participation à un projet open-source, quel qu'il soit, depuis la nuit des temps, implicitement tu acceptes que ton nom et ton email soient publiques. Je ne vois pas comment cela peut être autrement. Il faut bien, à un moment ou à un autre, qu'on puisse t'identifier, ne serait-ce que pour appliquer les droits que t'autorise la licence libre utilisée.
Cette identification peut être réèlle (ton vrai nom, et une adresse mail contenant ton nom), ou peut être anonymisée (un pseudo, et une adresse basée sur un pseudo).
Quoi qu'il en soit, en contribuant, tu as donné ton accord pour que l'identité que tu as donné soit publique.
On peut maintenant s'interroger sur la retractation, puisque le RGPD te permet en théorie de supprimer tes données personnelles. Mais dans le cadre d'un dépot git (open-source ou pas), ça devient particulièrement complexe. Certes, en théorie, il serait possible de réécrire tous les commits où ton nom/email apparait. Mais cela revient à créer un nouveau dépôt puisque tous les identifiants des commits créés depuis ta première participation sont changés. Et si il y a besoin de faire ça régulièrement, dans la pratique, cela devient un cauchemar pour les développeurs, puisqu'il faudrait "rebaser" son travail en cours sur un dépôt totalement nouveau, sans parler de tous les outils qui référencent des commits (integration continue, bug tracker…). Bref, en pratique, ce n'est pas possible.
Et fort heureusement, je crois que le RGPD prévoit les cas où tes informations personnelles sont absolument nécessaires au fonctionnement d'un service ou d'une entreprise (vous imaginez ? "bonjour l'urssaf, supprimez toutes mes données personnelles siouplait").
Bref, la suppression de tes données personnelles dans les dépots git étant impossible, et ce cas d'impossibilité de suppression étant prévu par le RGPD, Gitlab respecte de mon point de vue le RGPD. Donc soit tu acceptes que ton nom/email soit utilisé et tu ne pourras pas faire machine arrière, soit tu n'utilises pas le service.
# Pourquoi pas ext2 ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Partitions ext4 : ne gaspillez plus l’espace disque !. Évalué à 7.
Sur des clefs usb ou autre "petit" stockages externes, je me suis toujours interrogé sur la pertinence d'utiliser ext3 ou ext4. Alors si en plus il est préférable de désactiver le journal comme conseillé ici, pourquoi ne pas proposer tout simplement de formater en ext2 ? Parce qu'à priori, sur une clé USB, ses caractéristiques suffisent (sauf si on a des gros gros fichiers).