D'après les mesures, les coûts sont assez bien répartis/équilibrés entre les différentes sources de consommation de ressources; il n'y a pas un centre de coût unique qui permettrait de faire des gains miraculeux
Dans les 8 entreprises étudiées, les coûts principaux ne se situent pas dans les salles machines, mais sur les salles utilisateurs. (En même temps, ils n'ont pas mesuré les coûts des prestations externes, parce que c'est plus difficile. Mais du coup on ne sait pas quelle serait la contribution énergétique de l'utilisation de services informatiques externalisés, par exemple.)
Pour l'émission de gaz à effet de serre, les coûts principaux sont la fabrication des équipements utilisateurs (mobiliers de bureau, machines, etc.), 32%, et les trajets des employés (19%). Le télétravail aurait donc un impact important ici.
Pour la consommation d'eau, les coûts principaux sont la fabrication des équipements utilisateurs, 26% et les impressions de papier, 24%. Le coût d'impression suggère qu'on pourrait économiser pas mal en recyclant mieux le papier, mais surtout en imprimant moins.
Le rapport insiste pas mal sur le réemploi des équipements. C'est une bonne idée, et ça suggère que pas mal de boîte ont aujourd'hui sans doute des pratiques où on gaspille pas mal—en jetant plein d'équipements quand une nouvelle version arrive, ordinateurs aux switch réseaux en passant par les chaises de bureau.
J'ai l'impression que le changement de style de la nouvelle "sélectionnée" a cassé une propriété du design précédent qui m'était personnellement très utile: le menu de gauche n'est plus visible sur la page d'accueil sans (pour mes tailles d'écran et de police par défaut) scroller un coup en bas.
Un cas d'usage courant pour moi est d'aller sur la page d'accueil pour voir s'il y a des nouveaux commentaires dans une discussion à laquelle je participe, en regardant si l'icône "bulle BD" s'affiche à côté de "Mon tableau de bord". La nouvelle feuille de style rend cela plus pénible, j'imagine de façon involontaire.
J'aurais une préférence pour une solution de "style différent" qui n'impacte pas le positionnement du menu de gauche sur cette page par rapport aux autres. (Ou alors on pourrait imaginer avoir l'information "vous avez des notifications" dans le menu du haut du site, pas seulement le menu de gauche.)
Tu fais référence à qui au juste ? À ma connaissance les gens qui ont fait ce bench ne les auteurs d'aucun langage en particulier, ça vient d'un workload qui a été observé en practice comme un pire-cas pour la latence du GC de GHC (Haskell)—donc le benchmark est un peu injuste avec GHC, dans le sens où on sait déjà qu'il devrait faire pire que les autres ici.
Euh, tous les éditeurs supportent l'indentation avec les espaces, mais pour les alignements avec des espaces tu as une source ? Parce que je connais assez peu d'éditeurs qui gèrent ça bien. (Emacs est passable avec l'édition rectangulaire.)
Euh tu nous dis plus haut que les fins de tabulations élastiques ne sont en pratique pas utilisables car aucun éditeur ne les supporte et maintenant tu dis qu'aligner des espaces est chiant si c'est pas supporté…
La différence c'est qu'un support dans l'éditeur des espaces pour l'alignement, ce sera toujours une macro, tu appuies sur un bouton et ça fait plein de trucs (rajoute et enlève des espaces aux lignes). Le support des tabs élastiques dans l'éditeur, ça ne change pas le buffer, c'est juste la bonne façon de le visualiser qui est utiliser. C'est beaucoup plus propre conceptuellement, et une solution plus robuste sur le long terme.
Je me demande un peu où va ton argument là… si on arrêtait d'indenter le code, on aurait plus de bugs à cause du fait qu'on ne comprend pas sa structure, pas moins.
Oui, d'ailleurs en fait un recalcul dynamique, en fonction de ce qui est montré dans la fenêtre d'affiche (en ne prenant pas en compte les zones hors-champ), me paraît pas mal du point de vue de l'utilisabilité, en tout cas tant que ton éditeur est assez proprement fait pour pouvoir changer les alignements avec une animation continue pour ne pas créer d'accrocs visuels.
… sauf qu'aligner avec des espaces est très chiant sans support spécifique de l'éditeur. Là l'idée c'est de donner une meilleure sémantique à un caractère qui existe, et donc d'avoir un espoir à terme d'un comportement standard, portable, et pas de devoir trouver la commande / le raccourci différent chez chacun.
Et il n'y a pas que l'éditeur de texte qui est concerné, il faudrait aussi adapter les tail, head et autres cat.
Tu veux dire adapter le terminal ? Parce que ces commandes ne dépendent pas de la sémantique d'affichage des tabs.
Un outil d'alignement comme post-processing comme clang-format n'est pas aussi pratique qu'un support natif dans les éditeurs et rendus de texte :
tu peux aligner les constructions du langage prévues par ton éditeur, mais pas les autres
(par exemple si tu veux aligner un tableau dans les commentaires, tu es cuit)
surtout, en traduisant vers des espaces, tu obtiens un truc qui marche bien tant que tu
codes avec une fonte monospace, mais qui ne marche pas avec une fonte proportionnelle;
au contraire, les fins de tabulation élastiques ne sont pas définies par rapport à un
nombre fixé d'espaces, juste par un alignement vertical, et n'imposent donc pas cette contrainte de proportionnalité
Pour des exemples de serveurs qui tournent sur la JVM (c'est ça l'important plutôt que Java en particulier), regarder par exemple la liste d'utilisateurs de Netty, ou bien de Akka. Netty est utilisé, par exemple, par Ebay pour construire des équilibreurs de charge (load balancers), et Akka par Intel pour faire du streaming de données en temps réel.
Il y a des domaines applicatifs dans lesquels le C++ est plus populaire, mais le runtime de la JVM est quand même méchamment bien optimisé pour des types de charge où le code tourne pendant très longtemps sur le serveur en traitant un grand nombre de données/requêtes de façon proche les unes des autres. Le JIT fait un excellent travail de spécialisation, et ça va vraiment très vite—j'imagine que dans les bons cas on peut même battre une application en C++ à niveau d'abstraction du code égale, grâce aux optimisations spéculatives. Il y a aussi beaucoup d'analyse des performances—ce qui montre aussi qu'il y a beaucoup de gens qui écrivent du code haute-performance, assez pour générer les besoins de peaufiner ces outils.
Le fait qu'Unity en interne soit du C++ ne change rien au fait que des milliers de développeurs créent des jeux en C# grâce à cette bibliothèque. Je le mentionnais dans mon message pour expliquer que le nombre de domaines applicatifs perçus comme "ne tolérant pas un GC" diminue, longtemps les jeux vidéos ont été cités en exemple, ce n'est plus pertinent aujourd'hui.
(Le fait qu'en interne des bouts de code critiques soient écrits dans un autre langage que le reste de l'application n'est pas nouveau. Tous les langages managés ou presque ont un runtime en C (plus rarement en C++), par exemple.)
Le problème des GC est qu'il rajoute des latences à peu n'importe où, et un peu n'importe quand.
C'est un peu simplificateur. On peut écrire du code à faible latences dans un langage à GC—mais il faut un GC raisonnablement prévu pour ça. En OCaml par exemple, les latences du GC sont courtes pour la plupart des types de charge de calcul (il y a des cas particuliers mauvais, comme sur tous les systèmes).
Golang dispose d'un gc avec des latences ajouté super courte (9ms de mémoire), mais au pris d'un usage du cpu plus gros.
Dans ce billet de blog, qui part d'un benchmark des latences (sur un workload spécifique) que j'ai contribué à écrire / alimenter, on voit que les latences du GC OCaml sont inférieures à celles de Go 1.7—OCaml a une implémentation plus simple car le GC n'est pas concurrent.
Oui, pour moi le comptage de références (reference counting) est une forme de GC, mais une différence importante entre C++ et les langages managés est que, en C++, les constructions du langage ne t'imposent pas l'usage de shared_ptr ou d'un autre schéma automatique pour tracer les allocations mémoires, donc c'est facile de s'en passer et il y a des pratiques reconnues pour écrire du code où tout est géré manuellement. On peut aussi écrire du code qui n'utilise pas le GC dans un langage managé, mais c'est souvent beaucoup moins bien compris et donc plus délicat, et ça peut mal interagir avec le reste de l'écosystème logiciel.
C'est utilisé par de grosses applications industrielles (robotique, CAO, etc.) qui exigent pourtant des performances élevées.
Oui enfin tout le monde "exige des performances élevées", ça ne veut pas dire qu'un GC n'aurait pas été un choix raisonnable aussi—on peut écrire des applications performantes dans des langages avec GC, et d'ailleurs pas mal de code à haute performance côté serveur est écrit en Java.
Parmi ces langages, en excluant ceux qui ne sont qu'interprétés et ceux qui utilisent un garbage collector, les seuls qui pourraient remplacer C++ à performances égales sont donc C, Rust et D.
C'est un peu raté, D est un langage à Garbage Collector (GC).
Je regrette la phobie des GC dans les discussions sur les choix des langages de programmation. Il y a certains types d'applications très spécifiques qu'on veut écrire sans GC, et certains GCs peuvent parfois causer des problèmes de performance et demander du tuning ou un comportement pour certains usages. Mais ça reste très rare; c'est bien d'avoir des langages sûrs comme Rust pour écrire ces parties d'un programme, mais ça ne concerne pas la plupart des applications et la plupart des programmeurs.
(On disait avant qu'on ne pouvait pas coder de jeux vidéos sérieux dans un langage à GC, maintenant il y a énormément de gens qui utilisent Unity depuis un code en C# et… ça marche. Certaines parties de Unity sont codées en C++ en dessous, mais ça n'affecte pas les utilisateurs.)
C++ est un langage qui part d'un principe intéressant et personne ne nie son droit à exister. Mais par contre ce n'est pas forcément très raisonnable de continuer utiliser des piles applicatives qui sont très majoritairement écrites en C et C++, comme la grande majorité de ce qui se trouve sur un environnement de bureau libre—de grosses codebases Gtk en C, Qt en C++, et des navigateurs globalement en C++ et Javascript.
Je me sentirais beaucoup mieux si mon userland était écrit dans un langage sûr par défaut, même un langage aussi verbeux et peu tentant que Java.
Tu vas un peu loin je pense, sur leur site web il y a lien vers une certification de sécurité validée par l'ANSSI, fait par une entreprise de certification qui semble avoir procédé à une revue sérieuse de la sécurité du produit (et indique y compris que la partie propriétaire du code source a été expertisée). Le rapport confirme bien l'existence d'un chiffrement pair-à-pair "respectant les bonnes pratiques du domaine".
Je n'ai pas de raison de penser que ce n'est pas effectivement une solution de vidéo-conférence sécurisée—je dirais qu'on sait faire cela correctement aujourd'hui—juste qu'elle ne mérite pas une dépêche publicitaire sur ce site.
Cette dépêche est une honte. (Et je ne dis pas ça à la légère; je suis conscient du travail de rédiger une dépêche, et c'est la première fois que je pense ça d'une dépêche sur ce site.)
Faire de la publicité pour du logiciel propriétaire sur LinuxFR devrait être réservé aux cas exceptionnels, où la disponibilité du logiciel peut avoir un impact important sur les écosystèmes libres, parce qu'il n'existe pas de vraie alternative libre ou à cause de l'importance de l'effet réseau venant des utilisateurs des autres systèmes.
Ce logiciel n'est pas notable (combien de personnes vont pouvoir migrer à un système libre parce que celui-ci est disponible dessus ?), a tous les problèmes évidents des logiciels propriétaires qui se prétendent sécurisés, peut être remplacé par des alternatives libres—Jitsi par exemple chiffre les conversations par défaut (la version WebRTC, Jitsi Meet, passe par un relai géré par Jitsi auquel il faut faire confiance).
Un peu moins de superbe ascii-art avec des pingouins et des verrous géants, un peu plus de contenu, s'il vous plaît.
Pas excitant peut-être, mais il reste des défis majeurs à surmonter :
On n'a pas de solution logicielle libre pour avoir un ordinateur personnel utilisable et sécurisé contre les acteurs étatiques (à conseiller à un journaliste dans un pays totalitaire, par exemple). Même contre la cyber-criminalité, la sécurité de l'écosystème des environnements de bureau au-dessus de Linux perd de l'avance et prend du retard sur les solutions verrouillées verticalement (Windows, OSX, les versions Google d'Android). La meilleure équipe de sécurité pour les logiciels libres en ce moment est celle de Google, et c'est un peu triste.
On n'a pas réussi à faire des progrès durables sur des propositions "libres" sérieuses dans les domaines artistiques et ludiques. Même chez les gens qui sont sensibilisés au logiciel libre, l'extrême majorité continue à écouter de la musique propriétaire, jouer à des jeux propriétaires, lire des livres diffusés en des termes très privateurs et généralement consommer et subventionner de l'art qui n'est pas libre.
Quelques idées de gestes qui avancent dans la bonne direction:
Pour le premier point, apprendre à utiliser des techniques de programmation plus sûres et s'en servir dans ses projets libres. Essayer des langages qui rendent moins facile les failles, des outils de vérification de programmes, des architectures logicielles mieux compartementalisées et mieux conçues pour la sécurité.
Pour le second point, essayer au moins de se renseigner sur l'offre qui existe aujourd'hui et leur apporter un peu de publicité. Jouer à Battle for Wesnoth ou Xonotic (par exemple), écouter Regis Gronoff (par exemple), ou acheter et lire les auteurs de la maison d'édition C&F éditions qui propose des livres intéressants (souvent sur des thèmes pertinents pour les libristes), sans DRMs et qui essaie de transposer des idées de licences ouvertes à l'édition en poussant la licence Édition Équitable.
Pas très convaincant comme commentaire, il y a plein de gens partout dans le monde qui donnent leur temps et leurs compétences pour faire avancer les logiciels libres ! Je ne sais pas sur quoi tu te bases pour dire que "les USA restent la source la plus importante"; Richard Stallman est américain mais il y a plein de communautés du libre dont nombre d'acteurs principaux sont européens. Dans une communauté donnée, on essaie plutôt de s'ouvrir à tous et de ne pas trop mentionner les positions géographiques, donc on ne va pas le dire en ces termes. Mais si on regarde du point de vue local, en Europe par exemple, il y a beaucoup d'acteurs majeurs de projets libres, et je n'ai pas connaissance d'études quantitatives qui permettraient de dire que les États-Unis sont "plus importants".
L'argument principal utilisé pour conseiller les conteneurs plutôt que les machines virtuelles (qui me semblent clairement plus sécurisées) est qu'avec les machines virtuelles c'est à l'utilisateur de maintenir son noyau à jour question sécurité, alors qu'avec les conteneurs il ne choisit pas le noyau et c'est le fournisseur de service qui le maintient, et le maintient sans doute mieux.
Cet argument me semble bancal. On pourrait utiliser exactement le même pour dire que les machines partagées sont plus sécurisées en moyenne que les machines où l'utilisateur contrôle tout, et pourtant l'auteur ne les conseille pas.
L'analyse repose sur l'idée que la maintenance du système est assurée soit par le fournisseur, bien, soit par l'utilisateur, mal. Même si on ne suppose pas que les utilisateurs compétents et dévoués sont majoritaires, on peut aussi remarquer qu'il existe des tierces parties qui peuvent se charger de maintenir des morceaux de la stack pour l'utilisateur. Le fournisseur peut le faire dans certains schémas, mais on peut aussi compter sur une distribution pour maintenir un kernel, ou sur un fournisseur de machines virtuelles (par exemple Red Hat fournit des conteneurs de base dans lequel on peut déployer ses applications, remplaçant une partie du rôle du fournisseur). On peut avoir des tiers à qui on fait aussi ou plus confiance qu'au fournisseur de machines pour la maintenance de sécurité.
Il me semble qu'il y a deux choses à dire :
Pour un utilisateur non-expert, le mieux est d'avoir le moins d'opérations de maintenance à faire possibles, en déléguant la plus grande partie de la pile applicative à des tiers de confiance. Mais pas forcément le fournisseur ! On peut tout à fait louer les services d'un fournisseur qui déploie des machines virtuelles (sur un hyperviseur, donc), et utiliser un fournisseur tiers de machines virtuelles en qui on a confiance pour configurer et maintenir le kernel. On peut aussi utiliser une distribution en qui on a confiance pour configurer et maintenir la grande majorité de la couche applicative—le plus possible.
Pour un fournisseur de machines qui ne veut pas fournir de machines dédiées (trop cher), l'interface la plus protégée du code des utilisateurs est un hyperviseur—tant qu'on en prend plus petit et plus simple que le kernel Linux, et plus attentif à la sécurité. Il peut bien sûr proposer une interface au-dessus à ses clients, par exemple "conteneurs" ou même "login sur une machine partagée" (ou déploiement clicodrome d'applications fixées à l'avance), mais il a intérêt à construire ça au-dessus de machines virtuelles séparées s'il veut limiter au maximum les risques d'attaques d'un utilisateur à l'autre. (Bien sûr, un gain en sécurité peut avoir un coût en performance.)
LWN.net (et, dans le monde francophone, Mediapart) vivent sur le modèle par abonnement, c'est quand même un modèle qui marche pour des gens qui ont une base d'utilisateurs fidélisés, même quand les concurrents font du gratuit façon vous-êtes-le-produit. Il faut plus d'ingénieurs pour faire un navigateur que de journalistes pour faire un magazine/journal, mais Mozilla a d'autres sources d'argent (la vente du champ de recherche par défaut) pour complémenter.
J'ai horreur de ces tentatives de Mozilla de rajouter de la publicité dans Firefox. Par contre, je serais prêt à donner une petite somme d'argent chaque mois (5€ ?) pour leur permettre de continuer à fonctionner.
Il y a déjà donate.mozilla.org, qui permet de donner de façon ponctuelle ou régulière, mais ce n'est pas la même chose que d'annoncer un modèle par abonnement et d'encourager largement les utilisateurs de Firefox de s'y mettre s'ils apprécient le service fourni—et en échange d'arrêter ces plans à la noix sur la publicité, qui agacent leur base d'utilisateurs fidèles et dont je ne suis pas convaincu qu'ils soient si rentables que cela.
C'est quand même un peu naïf de répondre ça. La possibilité de réduire le nombre d'identités virtuelle dépend énormément de ce qu'on fait dans la vie. Il y a des gens qui ont la chance d'avoir des besoins de représentation en ligne (et donc d'avoir une identité) qui sont facilement compatibles—j'en fais partie—et qui peuvent facilement assumer de tout regrouper sur une seule identité. Mais il y a aussi des gens pour qui ce serait difficile, pas possible ou dangereux.
Quelques exemples évidents:
Si tes préférences sexuelles ne sont pas compatibles avec le milieu familial ou professionnel dans lequel tu vis, tu peux te retrouver à maintenir une identité séparée au sein de communautés qui se regroupent autour de ça.
Tu peux avoir une action politique ou militante qui serait, pareil, susceptible de te nuire dans la vie de tous les jours. (Quand on voit qu'une bonne partie des développeurs/contributeurs Tor se fait régulièrement emmerder quand ils ou elles franchissent les frontières des États-Unis, on se rend compte que ça peut aussi toucher les milieux techniques.)
Il y a des gens qui n'ont aucun de ces besoins, parce qu'ils ne font que des choses qui sont bien reconnues et comprises par le grand public et leur propre milieu. Tant mieux pour eux ! Mais ce n'est pas une raison pour nier que cette difficulté existe pour d'autre, ou pour croire que c'est évident à gérer.
Posté par gasche .
En réponse au journal Copyleft is censorship.
Évalué à 4.
Dernière modification le 19 mars 2018 à 12:19.
Je ne suis pas le sujet d'assez près (il est assez subtil, et les détails du projet de loi évoluent sans cesse) pour savoir si le logiciel libre est mis en danger par cette loi. Il me semble clair par contre qu'en demandant la mise en place de procédure techniques compliquées (par opposition, par exemple, à une demande de traitement de bonne foi en cas de signalement non-abusif), il rend la création d'une plateforme d'hébergement de contenus nettement plus délicate : Github pourrait certainement se mettre en conformité assez facilement (en utilisant des techniques automatiques de détection de réutilisation de code, de formats précis de descriptions de licences (SPDX), etc.), Framagit va avoir beaucoup plus de mal.
Je pense que la protestation d'une partie du camp pirate repose plus sur des questions plus générales de culture libre, de droit de remix, d'usages non-marchands, etc. Les filtres de détection de violation de copyright aujourd'hui sont une plaie pour les Youtubeurs qui font des critiques de film ou musique en incluant des extraits de l'œuvre, ce qui est un exception du droit d'auteur autorisée, mais que les bots détectent pas ou mal, et après chaque utilisateur est soumis à l'arbitraire de la plateforme (tu as plein de vues, tu es puissant, Google t'écoute; tu es petit, tant pis pour toi). Tous ces problèmes se posent beaucopu moins dans le contexte du logique libre.
On est d'accord sur l'aspect excessif du tweet, mais il faut quand même signaler que c'est une personne importante au niveau européen—il a fait par exemple partie d'une délégation d'auteurs venue rencontrer les parlementaires sur cette loi, dirigée par Jean-Michel Jarre.
Par ailleurs il me semble que la distinction "œuvre ou outil" n'est pas aussi claire qu'on pourrait le penser. Autant du point de vue du droit que dans la réalité de la pratique de la programmation, un logiciel, c'est une œuvre de l'esprit. C'est en général plus proche d'une forme d'artisanat que d'une production artistique (même s'il y a quelques rares logiciels qui trouvent une forme d'art), mais c'est un artisanat très créatif donne des résultats uniques, personnels et difficilement reproductibles par autrui. Essayer de faire une distinction à ce niveau (plutôt que sur les cultures et les structures de production) n'est pas valide, à mon humble avis.
# C'est mieux avec le vrai document
Posté par gasche . En réponse au journal Pollution numérique. Évalué à 4.
En faisant le travail de remonter aux sources de ces citations, on trouve le rapport à l'origine de l'article à l'origine de cet article, autrement plus intéressant…
Quelques remarques rapides:
D'après les mesures, les coûts sont assez bien répartis/équilibrés entre les différentes sources de consommation de ressources; il n'y a pas un centre de coût unique qui permettrait de faire des gains miraculeux
Dans les 8 entreprises étudiées, les coûts principaux ne se situent pas dans les salles machines, mais sur les salles utilisateurs. (En même temps, ils n'ont pas mesuré les coûts des prestations externes, parce que c'est plus difficile. Mais du coup on ne sait pas quelle serait la contribution énergétique de l'utilisation de services informatiques externalisés, par exemple.)
Pour l'émission de gaz à effet de serre, les coûts principaux sont la fabrication des équipements utilisateurs (mobiliers de bureau, machines, etc.), 32%, et les trajets des employés (19%). Le télétravail aurait donc un impact important ici.
Pour la consommation d'eau, les coûts principaux sont la fabrication des équipements utilisateurs, 26% et les impressions de papier, 24%. Le coût d'impression suggère qu'on pourrait économiser pas mal en recyclant mieux le papier, mais surtout en imprimant moins.
Le rapport insiste pas mal sur le réemploi des équipements. C'est une bonne idée, et ça suggère que pas mal de boîte ont aujourd'hui sans doute des pratiques où on gaspille pas mal—en jetant plein d'équipements quand une nouvelle version arrive, ordinateurs aux switch réseaux en passant par les chaises de bureau.
[^] # Re: Menu de gauche plus difficile d'accès sur la page d'accueil > icône du tableau de bord
Posté par gasche . En réponse à la dépêche Quelques petits changements sur le site. Évalué à 3.
Merci ! Le retour en arrière a immédiatement amélioré mon expérience de navigation sur LinuxFR.
# Menu de gauche plus difficile d'accès sur la page d'accueil > icône du tableau de bord
Posté par gasche . En réponse à la dépêche Quelques petits changements sur le site. Évalué à 7.
J'ai l'impression que le changement de style de la nouvelle "sélectionnée" a cassé une propriété du design précédent qui m'était personnellement très utile: le menu de gauche n'est plus visible sur la page d'accueil sans (pour mes tailles d'écran et de police par défaut) scroller un coup en bas.
Un cas d'usage courant pour moi est d'aller sur la page d'accueil pour voir s'il y a des nouveaux commentaires dans une discussion à laquelle je participe, en regardant si l'icône "bulle BD" s'affiche à côté de "Mon tableau de bord". La nouvelle feuille de style rend cela plus pénible, j'imagine de façon involontaire.
J'aurais une préférence pour une solution de "style différent" qui n'impacte pas le positionnement du menu de gauche sur cette page par rapport aux autres. (Ou alors on pourrait imaginer avoir l'information "vous avez des notifications" dans le menu du haut du site, pas seulement le menu de gauche.)
[^] # Re: Phobie du GC
Posté par gasche . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 2.
Flûte, je me suis trompé de sous-fil, je pensais que tu parlais de cet autre billet sur les temps de latence de Go et d'autres langages, désolé.
[^] # Re: Phobie du GC
Posté par gasche . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 2.
Tu fais référence à qui au juste ? À ma connaissance les gens qui ont fait ce bench ne les auteurs d'aucun langage en particulier, ça vient d'un workload qui a été observé en practice comme un pire-cas pour la latence du GC de GHC (Haskell)—donc le benchmark est un peu injuste avec GHC, dans le sens où on sait déjà qu'il devrait faire pire que les autres ici.
[^] # Re: aligner tabuler
Posté par gasche . En réponse au journal Fins de tabulation élastiques: la bonne manière d'indenter et d'aligner le code. Évalué à 4.
Euh, tous les éditeurs supportent l'indentation avec les espaces, mais pour les alignements avec des espaces tu as une source ? Parce que je connais assez peu d'éditeurs qui gèrent ça bien. (Emacs est passable avec l'édition rectangulaire.)
La différence c'est qu'un support dans l'éditeur des espaces pour l'alignement, ce sera toujours une macro, tu appuies sur un bouton et ça fait plein de trucs (rajoute et enlève des espaces aux lignes). Le support des tabs élastiques dans l'éditeur, ça ne change pas le buffer, c'est juste la bonne façon de le visualiser qui est utiliser. C'est beaucoup plus propre conceptuellement, et une solution plus robuste sur le long terme.
[^] # Re: aligner tabuler
Posté par gasche . En réponse au journal Fins de tabulation élastiques: la bonne manière d'indenter et d'aligner le code. Évalué à 4.
Je me demande un peu où va ton argument là… si on arrêtait d'indenter le code, on aurait plus de bugs à cause du fait qu'on ne comprend pas sa structure, pas moins.
[^] # Re: Ce serait pas mal, oui
Posté par gasche . En réponse au journal Fins de tabulation élastiques: la bonne manière d'indenter et d'aligner le code. Évalué à 2.
Oui, d'ailleurs en fait un recalcul dynamique, en fonction de ce qui est montré dans la fenêtre d'affiche (en ne prenant pas en compte les zones hors-champ), me paraît pas mal du point de vue de l'utilisabilité, en tout cas tant que ton éditeur est assez proprement fait pour pouvoir changer les alignements avec une animation continue pour ne pas créer d'accrocs visuels.
[^] # Re: aligner tabuler
Posté par gasche . En réponse au journal Fins de tabulation élastiques: la bonne manière d'indenter et d'aligner le code. Évalué à 5.
… sauf qu'aligner avec des espaces est très chiant sans support spécifique de l'éditeur. Là l'idée c'est de donner une meilleure sémantique à un caractère qui existe, et donc d'avoir un espoir à terme d'un comportement standard, portable, et pas de devoir trouver la commande / le raccourci différent chez chacun.
Tu veux dire adapter le terminal ? Parce que ces commandes ne dépendent pas de la sémantique d'affichage des tabs.
[^] # Re: Automatiser l'indentation
Posté par gasche . En réponse au journal Fins de tabulation élastiques: la bonne manière d'indenter et d'aligner le code. Évalué à 6.
Un outil d'alignement comme post-processing comme clang-format n'est pas aussi pratique qu'un support natif dans les éditeurs et rendus de texte :
[^] # Re: Phobie du GC
Posté par gasche . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 10. Dernière modification le 28 juillet 2018 à 23:14.
Pour des exemples de serveurs qui tournent sur la JVM (c'est ça l'important plutôt que Java en particulier), regarder par exemple la liste d'utilisateurs de Netty, ou bien de Akka. Netty est utilisé, par exemple, par Ebay pour construire des équilibreurs de charge (load balancers), et Akka par Intel pour faire du streaming de données en temps réel.
Il y a des domaines applicatifs dans lesquels le C++ est plus populaire, mais le runtime de la JVM est quand même méchamment bien optimisé pour des types de charge où le code tourne pendant très longtemps sur le serveur en traitant un grand nombre de données/requêtes de façon proche les unes des autres. Le JIT fait un excellent travail de spécialisation, et ça va vraiment très vite—j'imagine que dans les bons cas on peut même battre une application en C++ à niveau d'abstraction du code égale, grâce aux optimisations spéculatives. Il y a aussi beaucoup d'analyse des performances—ce qui montre aussi qu'il y a beaucoup de gens qui écrivent du code haute-performance, assez pour générer les besoins de peaufiner ces outils.
[^] # Re: Phobie du GC
Posté par gasche . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 5.
Le fait qu'Unity en interne soit du C++ ne change rien au fait que des milliers de développeurs créent des jeux en C# grâce à cette bibliothèque. Je le mentionnais dans mon message pour expliquer que le nombre de domaines applicatifs perçus comme "ne tolérant pas un GC" diminue, longtemps les jeux vidéos ont été cités en exemple, ce n'est plus pertinent aujourd'hui.
(Le fait qu'en interne des bouts de code critiques soient écrits dans un autre langage que le reste de l'application n'est pas nouveau. Tous les langages managés ou presque ont un runtime en C (plus rarement en C++), par exemple.)
C'est un peu simplificateur. On peut écrire du code à faible latences dans un langage à GC—mais il faut un GC raisonnablement prévu pour ça. En OCaml par exemple, les latences du GC sont courtes pour la plupart des types de charge de calcul (il y a des cas particuliers mauvais, comme sur tous les systèmes).
Dans ce billet de blog, qui part d'un benchmark des latences (sur un workload spécifique) que j'ai contribué à écrire / alimenter, on voit que les latences du GC OCaml sont inférieures à celles de Go 1.7—OCaml a une implémentation plus simple car le GC n'est pas concurrent.
[^] # Re: Phobie du GC
Posté par gasche . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 10.
Oui, pour moi le comptage de références (reference counting) est une forme de GC, mais une différence importante entre C++ et les langages managés est que, en C++, les constructions du langage ne t'imposent pas l'usage de
shared_ptrou d'un autre schéma automatique pour tracer les allocations mémoires, donc c'est facile de s'en passer et il y a des pratiques reconnues pour écrire du code où tout est géré manuellement. On peut aussi écrire du code qui n'utilise pas le GC dans un langage managé, mais c'est souvent beaucoup moins bien compris et donc plus délicat, et ça peut mal interagir avec le reste de l'écosystème logiciel.Oui enfin tout le monde "exige des performances élevées", ça ne veut pas dire qu'un GC n'aurait pas été un choix raisonnable aussi—on peut écrire des applications performantes dans des langages avec GC, et d'ailleurs pas mal de code à haute performance côté serveur est écrit en Java.
# Phobie du GC
Posté par gasche . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 10.
C'est un peu raté, D est un langage à Garbage Collector (GC).
Je regrette la phobie des GC dans les discussions sur les choix des langages de programmation. Il y a certains types d'applications très spécifiques qu'on veut écrire sans GC, et certains GCs peuvent parfois causer des problèmes de performance et demander du tuning ou un comportement pour certains usages. Mais ça reste très rare; c'est bien d'avoir des langages sûrs comme Rust pour écrire ces parties d'un programme, mais ça ne concerne pas la plupart des applications et la plupart des programmeurs.
(On disait avant qu'on ne pouvait pas coder de jeux vidéos sérieux dans un langage à GC, maintenant il y a énormément de gens qui utilisent Unity depuis un code en C# et… ça marche. Certaines parties de Unity sont codées en C++ en dessous, mais ça n'affecte pas les utilisateurs.)
C++ est un langage qui part d'un principe intéressant et personne ne nie son droit à exister. Mais par contre ce n'est pas forcément très raisonnable de continuer utiliser des piles applicatives qui sont très majoritairement écrites en C et C++, comme la grande majorité de ce qui se trouve sur un environnement de bureau libre—de grosses codebases Gtk en C, Qt en C++, et des navigateurs globalement en C++ et Javascript.
Je me sentirais beaucoup mieux si mon userland était écrit dans un langage sûr par défaut, même un langage aussi verbeux et peu tentant que Java.
[^] # Re: Une honte
Posté par gasche . En réponse à la dépêche Tixeo, une solution propriétaire de visioconférence sécurisée sous GNU/Linux. Évalué à 8.
Tu vas un peu loin je pense, sur leur site web il y a lien vers une certification de sécurité validée par l'ANSSI, fait par une entreprise de certification qui semble avoir procédé à une revue sérieuse de la sécurité du produit (et indique y compris que la partie propriétaire du code source a été expertisée). Le rapport confirme bien l'existence d'un chiffrement pair-à-pair "respectant les bonnes pratiques du domaine".
Je n'ai pas de raison de penser que ce n'est pas effectivement une solution de vidéo-conférence sécurisée—je dirais qu'on sait faire cela correctement aujourd'hui—juste qu'elle ne mérite pas une dépêche publicitaire sur ce site.
# Une honte
Posté par gasche . En réponse à la dépêche Tixeo, une solution propriétaire de visioconférence sécurisée sous GNU/Linux. Évalué à 10.
Cette dépêche est une honte. (Et je ne dis pas ça à la légère; je suis conscient du travail de rédiger une dépêche, et c'est la première fois que je pense ça d'une dépêche sur ce site.)
Faire de la publicité pour du logiciel propriétaire sur LinuxFR devrait être réservé aux cas exceptionnels, où la disponibilité du logiciel peut avoir un impact important sur les écosystèmes libres, parce qu'il n'existe pas de vraie alternative libre ou à cause de l'importance de l'effet réseau venant des utilisateurs des autres systèmes.
Ce logiciel n'est pas notable (combien de personnes vont pouvoir migrer à un système libre parce que celui-ci est disponible dessus ?), a tous les problèmes évidents des logiciels propriétaires qui se prétendent sécurisés, peut être remplacé par des alternatives libres—Jitsi par exemple chiffre les conversations par défaut (la version WebRTC, Jitsi Meet, passe par un relai géré par Jitsi auquel il faut faire confiance).
Un peu moins de superbe ascii-art avec des pingouins et des verrous géants, un peu plus de contenu, s'il vous plaît.
[^] # Re: Excité !
Posté par gasche . En réponse au journal Un rachat, un summit et un BIOS qui s'ouvre de plus en plus grâce à linux . Évalué à 0. Dernière modification le 24 juin 2018 à 18:24.
Pas excitant peut-être, mais il reste des défis majeurs à surmonter :
On n'a pas de solution logicielle libre pour avoir un ordinateur personnel utilisable et sécurisé contre les acteurs étatiques (à conseiller à un journaliste dans un pays totalitaire, par exemple). Même contre la cyber-criminalité, la sécurité de l'écosystème des environnements de bureau au-dessus de Linux perd de l'avance et prend du retard sur les solutions verrouillées verticalement (Windows, OSX, les versions Google d'Android). La meilleure équipe de sécurité pour les logiciels libres en ce moment est celle de Google, et c'est un peu triste.
On n'a pas réussi à faire des progrès durables sur des propositions "libres" sérieuses dans les domaines artistiques et ludiques. Même chez les gens qui sont sensibilisés au logiciel libre, l'extrême majorité continue à écouter de la musique propriétaire, jouer à des jeux propriétaires, lire des livres diffusés en des termes très privateurs et généralement consommer et subventionner de l'art qui n'est pas libre.
Quelques idées de gestes qui avancent dans la bonne direction:
Pour le premier point, apprendre à utiliser des techniques de programmation plus sûres et s'en servir dans ses projets libres. Essayer des langages qui rendent moins facile les failles, des outils de vérification de programmes, des architectures logicielles mieux compartementalisées et mieux conçues pour la sécurité.
Pour le second point, essayer au moins de se renseigner sur l'offre qui existe aujourd'hui et leur apporter un peu de publicité. Jouer à Battle for Wesnoth ou Xonotic (par exemple), écouter Regis Gronoff (par exemple), ou acheter et lire les auteurs de la maison d'édition C&F éditions qui propose des livres intéressants (souvent sur des thèmes pertinents pour les libristes), sans DRMs et qui essaie de transposer des idées de licences ouvertes à l'édition en poussant la licence Édition Équitable.
[^] # Re: Félicitations
Posté par gasche . En réponse au journal Un rachat, un summit et un BIOS qui s'ouvre de plus en plus grâce à linux . Évalué à 5. Dernière modification le 24 juin 2018 à 18:05.
Pas très convaincant comme commentaire, il y a plein de gens partout dans le monde qui donnent leur temps et leurs compétences pour faire avancer les logiciels libres ! Je ne sais pas sur quoi tu te bases pour dire que "les USA restent la source la plus importante"; Richard Stallman est américain mais il y a plein de communautés du libre dont nombre d'acteurs principaux sont européens. Dans une communauté donnée, on essaie plutôt de s'ouvrir à tous et de ne pas trop mentionner les positions géographiques, donc on ne va pas le dire en ces termes. Mais si on regarde du point de vue local, en Europe par exemple, il y a beaucoup d'acteurs majeurs de projets libres, et je n'ai pas connaissance d'études quantitatives qui permettraient de dire que les États-Unis sont "plus importants".
# Pas convaincant
Posté par gasche . En réponse au journal Surface d'attaque des serveurs dans les nuages (cloud). Évalué à 6.
L'argument principal utilisé pour conseiller les conteneurs plutôt que les machines virtuelles (qui me semblent clairement plus sécurisées) est qu'avec les machines virtuelles c'est à l'utilisateur de maintenir son noyau à jour question sécurité, alors qu'avec les conteneurs il ne choisit pas le noyau et c'est le fournisseur de service qui le maintient, et le maintient sans doute mieux.
Cet argument me semble bancal. On pourrait utiliser exactement le même pour dire que les machines partagées sont plus sécurisées en moyenne que les machines où l'utilisateur contrôle tout, et pourtant l'auteur ne les conseille pas.
L'analyse repose sur l'idée que la maintenance du système est assurée soit par le fournisseur, bien, soit par l'utilisateur, mal. Même si on ne suppose pas que les utilisateurs compétents et dévoués sont majoritaires, on peut aussi remarquer qu'il existe des tierces parties qui peuvent se charger de maintenir des morceaux de la stack pour l'utilisateur. Le fournisseur peut le faire dans certains schémas, mais on peut aussi compter sur une distribution pour maintenir un kernel, ou sur un fournisseur de machines virtuelles (par exemple Red Hat fournit des conteneurs de base dans lequel on peut déployer ses applications, remplaçant une partie du rôle du fournisseur). On peut avoir des tiers à qui on fait aussi ou plus confiance qu'au fournisseur de machines pour la maintenance de sécurité.
Il me semble qu'il y a deux choses à dire :
Pour un utilisateur non-expert, le mieux est d'avoir le moins d'opérations de maintenance à faire possibles, en déléguant la plus grande partie de la pile applicative à des tiers de confiance. Mais pas forcément le fournisseur ! On peut tout à fait louer les services d'un fournisseur qui déploie des machines virtuelles (sur un hyperviseur, donc), et utiliser un fournisseur tiers de machines virtuelles en qui on a confiance pour configurer et maintenir le kernel. On peut aussi utiliser une distribution en qui on a confiance pour configurer et maintenir la grande majorité de la couche applicative—le plus possible.
Pour un fournisseur de machines qui ne veut pas fournir de machines dédiées (trop cher), l'interface la plus protégée du code des utilisateurs est un hyperviseur—tant qu'on en prend plus petit et plus simple que le kernel Linux, et plus attentif à la sécurité. Il peut bien sûr proposer une interface au-dessus à ses clients, par exemple "conteneurs" ou même "login sur une machine partagée" (ou déploiement clicodrome d'applications fixées à l'avance), mais il a intérêt à construire ça au-dessus de machines virtuelles séparées s'il veut limiter au maximum les risques d'attaques d'un utilisateur à l'autre. (Bien sûr, un gain en sécurité peut avoir un coût en performance.)
[^] # Re: Payer un abonnement
Posté par gasche . En réponse au journal De la publicité dans Firefox (sur un air de déjà vu). Évalué à 3. Dernière modification le 03 mai 2018 à 13:47.
LWN.net (et, dans le monde francophone, Mediapart) vivent sur le modèle par abonnement, c'est quand même un modèle qui marche pour des gens qui ont une base d'utilisateurs fidélisés, même quand les concurrents font du gratuit façon vous-êtes-le-produit. Il faut plus d'ingénieurs pour faire un navigateur que de journalistes pour faire un magazine/journal, mais Mozilla a d'autres sources d'argent (la vente du champ de recherche par défaut) pour complémenter.
# Payer un abonnement
Posté par gasche . En réponse au journal De la publicité dans Firefox (sur un air de déjà vu). Évalué à 5.
J'ai horreur de ces tentatives de Mozilla de rajouter de la publicité dans Firefox. Par contre, je serais prêt à donner une petite somme d'argent chaque mois (5€ ?) pour leur permettre de continuer à fonctionner.
Il y a déjà donate.mozilla.org, qui permet de donner de façon ponctuelle ou régulière, mais ce n'est pas la même chose que d'annoncer un modèle par abonnement et d'encourager largement les utilisateurs de Firefox de s'y mettre s'ils apprécient le service fourni—et en échange d'arrêter ces plans à la noix sur la publicité, qui agacent leur base d'utilisateurs fidèles et dont je ne suis pas convaincu qu'ils soient si rentables que cela.
[^] # Re: Solution évidente
Posté par gasche . En réponse au journal distinguer ses identités sur le net. Évalué à 10.
C'est quand même un peu naïf de répondre ça. La possibilité de réduire le nombre d'identités virtuelle dépend énormément de ce qu'on fait dans la vie. Il y a des gens qui ont la chance d'avoir des besoins de représentation en ligne (et donc d'avoir une identité) qui sont facilement compatibles—j'en fais partie—et qui peuvent facilement assumer de tout regrouper sur une seule identité. Mais il y a aussi des gens pour qui ce serait difficile, pas possible ou dangereux.
Quelques exemples évidents:
Si tes préférences sexuelles ne sont pas compatibles avec le milieu familial ou professionnel dans lequel tu vis, tu peux te retrouver à maintenir une identité séparée au sein de communautés qui se regroupent autour de ça.
Tu peux avoir une action politique ou militante qui serait, pareil, susceptible de te nuire dans la vie de tous les jours. (Quand on voit qu'une bonne partie des développeurs/contributeurs Tor se fait régulièrement emmerder quand ils ou elles franchissent les frontières des États-Unis, on se rend compte que ça peut aussi toucher les milieux techniques.)
Il y a des gens qui n'ont aucun de ces besoins, parce qu'ils ne font que des choses qui sont bien reconnues et comprises par le grand public et leur propre milieu. Tant mieux pour eux ! Mais ce n'est pas une raison pour nier que cette difficulté existe pour d'autre, ou pour croire que c'est évident à gérer.
[^] # Re: Expérience littéraire
Posté par gasche . En réponse au journal Copyleft is censorship. Évalué à 7.
L'affaire Pepper & Carrot pour ceux qui n'auraient pas suivi, sur Phylacterium.
[^] # Re: Analyse réaliste des menaces?
Posté par gasche . En réponse au journal Copyleft is censorship. Évalué à 4. Dernière modification le 19 mars 2018 à 12:19.
Je ne suis pas le sujet d'assez près (il est assez subtil, et les détails du projet de loi évoluent sans cesse) pour savoir si le logiciel libre est mis en danger par cette loi. Il me semble clair par contre qu'en demandant la mise en place de procédure techniques compliquées (par opposition, par exemple, à une demande de traitement de bonne foi en cas de signalement non-abusif), il rend la création d'une plateforme d'hébergement de contenus nettement plus délicate : Github pourrait certainement se mettre en conformité assez facilement (en utilisant des techniques automatiques de détection de réutilisation de code, de formats précis de descriptions de licences (SPDX), etc.), Framagit va avoir beaucoup plus de mal.
Je pense que la protestation d'une partie du camp pirate repose plus sur des questions plus générales de culture libre, de droit de remix, d'usages non-marchands, etc. Les filtres de détection de violation de copyright aujourd'hui sont une plaie pour les Youtubeurs qui font des critiques de film ou musique en incluant des extraits de l'œuvre, ce qui est un exception du droit d'auteur autorisée, mais que les bots détectent pas ou mal, et après chaque utilisateur est soumis à l'arbitraire de la plateforme (tu as plein de vues, tu es puissant, Google t'écoute; tu es petit, tant pis pour toi). Tous ces problèmes se posent beaucopu moins dans le contexte du logique libre.
On est d'accord sur l'aspect excessif du tweet, mais il faut quand même signaler que c'est une personne importante au niveau européen—il a fait par exemple partie d'une délégation d'auteurs venue rencontrer les parlementaires sur cette loi, dirigée par Jean-Michel Jarre.
[^] # Re: Expérience littéraire
Posté par gasche . En réponse au journal Copyleft is censorship. Évalué à 3.
Par ailleurs il me semble que la distinction "œuvre ou outil" n'est pas aussi claire qu'on pourrait le penser. Autant du point de vue du droit que dans la réalité de la pratique de la programmation, un logiciel, c'est une œuvre de l'esprit. C'est en général plus proche d'une forme d'artisanat que d'une production artistique (même s'il y a quelques rares logiciels qui trouvent une forme d'art), mais c'est un artisanat très créatif donne des résultats uniques, personnels et difficilement reproductibles par autrui. Essayer de faire une distinction à ce niveau (plutôt que sur les cultures et les structures de production) n'est pas valide, à mon humble avis.