Non, ce ne sont pas les navigateurs qui sont devenus très gourmands. Ce sont les sites web, où les développeurs ne se privent pas d'empiler les libs et frameworks JS dans tout les sens, avec de l'ajax et des images à tous les étages (sans parler du chargements de multiples fontes, vidéos et cie). Et puis charger une page web l'une après l'autre, c'est has been, alors on met tout le site dans une seule page, qui au final pèse plusieurs mégas.
coté calculatrice : j'ai aussi commencé avec une Ti57, puis Casio 8500G et HP48
J'ai découvert les ordinateurs au début des années 80 en utilisant un "Compaq portable" et le ZX81 d'un copain. J'ai ensuite tapé mes premières lignes de code (1986) sur un TO9 (que j'ai toujours).
Avec mes premiers PC (début des années 90), ce fut la découverte du langage C, mais aussi l'organisation de "lan party" entre potes, à partir de 1995, avec au départ du réseau en anneau en BNC (la gaaaallèèèère), puis du réseau en étoile avec du RJ45 et des hubs (le bonheur !) (pas de switch, ça coutaient beaucoup trop cher à l'époque). Et parmi les jeux auxquels on jouait en lan, les plus utilisés furent Doom, Starcraft, Warcraft, Quake, Diablo… Sans oublier Duke Nukem bien sûr !
Je n'ai commencé le jeu via internet qu'en 2001, majoritairement avec Counter Strike (en lan également). Le jeu par internet, c'est sympa, mais beaucoup moins fun et convivial que les lan.
Certains souhaitent rester sur CoffeeScript, car le coût pour passer à ES6 ou typescript est élevé et les bénéfices ne semblent pas valoir le coût
Vous n'êtes pas obligés de transformer tout le code CoffeeScript existant en ES6. Vous pouvez tout simplement utiliser ES6 pour les nouvelles libs ou applis, et faire la migration en douceur petit à petit. Utiliser une lib ES6 dans du code CoffeeScript ne pose à priori pas de problème. Et migrer petit à petit des briques que vous refondez par nécessité, vers ES6, est faisable sans trop de douleurs ni trop de coûts.
Le bénéfice est quand même flagrant : avec ES6, vous utilisez un langage pérenne, utilisé par bien plus de développeurs (donc recrutement et contributions facilités) que CoffeeScript, qui lui, comme tu le remarques toi même, tombe en désuétude. (sans parler de la non-necessité d'un transpiler :-))
C'est un projet intéressant. Je vais l'essayer. Si j'avais du temps, je contribuerai bien, mais là pour moi, déjà, CoffeeScript est un frein parce que je n'ai pas envie d'apprendre ce langage (alors que l'ES6, j'en fais tous les jours ou presque).
je me souviens même d'avoir envoyé des corrections par fax, internet n'existait pas encore.
Je pense que tu voulais dire "à l'époque, internet n'existait pas encore dans notre boite". Parce que techniquement dans les années 90, Internet existait. (oui je chipote)
Le premier réseau (celui de l'INRIA) raccordé à internet en france, c'est en 1988. Dans la foulée quelques centres de recherche, puis les universités vers 1993 grâce au réseau Renater (j'ai pu en profiter en 1994 quand je suis entré à l'IUT d'Orsay :-)). Ensuite les premiers FAI grand public vers 1994 (sans oublier French Data Network en 1992).
Bon, finalement, j'ai fini par envoyé un mail à la FSF pour leur demander leur avis.
Et la réponse est… qu'il n'y a pas de réponse simple.
Comme je le pensais, selon la personne qui m'a répondu, il peut être très compliqué de déterminer si le code enlevé ou encore, si du code refondu peut avoir encore des "traces" ou pas du code original. J'imagine qu'il entend par là que le code refondu, même si syntaxiquement il n'est plus le même, peut faire tout de même la même chose ou très inspiré du code original. (la logique globale, ou l'idée générale de l'algo peut rester la même). Et dans ce cas, le contributeur reste plus ou moins l'auteur du code refondu.
Il m'a indiqué aussi que dans certaines boites, quand ils veulent refondre quelque chose et en être l'unique détenteur du copyright, ils font appel à quelqu'un qui n'a jamais vu le code original. Ainsi il n'est pas tenté de s'en inspirer, et donc fait un travail totalement original.
J'en conclu donc, à moins de totalement virer le code du contributeur sans le remplacer, qu'il est préférable de garder les noms des contributeurs dans le copyright. Une autre solution possible est aussi de demander aux contributeurs concernés par la réécriture ou les changements sur leur code, si ils acceptent d'abandonner leur copyright sur le nouveau code. Mais pas simple à faire (surtout sur du vieux code).
Il est dit qu'il faut indiquer la mention de copyright avec la/les années de publications, et la liste de toutes les personnes qui ont contribué au code ex : Copyright 2006-2016 Toto, Titi, Tata. Et sur chaque fichier du programme.
Par contre, il n'est pas précisé si on doit garder ou si on peut enlever la mention de copyright conçernant une personne pour laquelle sa contribution n'est plus présente dans le code… Ça ne répond pas trop à ma question :-/
Dans le projet en question, ajouter les contributeurs dans l'entête de chaque fichier était une habitude qui avait été prise. Probablement (mes souvenirs sont vagues), parce que, au début du projet A (2001), d'une part, mise à part la compréhension des 4 libertés fondamentales du libre, on ne maitrisait peut être pas très bien l'aspect juridique de la LGPL (pas sûr de tout maîtriser encore aujourd'hui, d'où ma question :-) ), d'autres parts, on utilisait CVS à l'époque, et que bon, manipuler ce truc n'était particulièrement pas user friendly pour inspecter l'historique etc (par rapport aux outils d'aujourd'hui).. Et souvent on intégrait des patchs à la main, donc les commits n'étaient pas créés par les auteurs des patchs. Ça nous permettait donc de laisser au moins une trace de qui avait touché à quel fichier, et de le savoir sans avoir à utiliser CVS… (ce qui au final est encore utile aujourd'hui, étant donné que le dépôt CVS et subversion du projet A a disparu :-/ )
À l'ère d'outils comme Git, Github, Gitlab, il est clair que l'intérêt de faire perdurer cette pratique est moins pertinente.
Dans le cas d'un changement de licence, retirer le code des contributeurs qui ne se sont pas manifesté, ne veut pas dire modifier l'historique de git. Je ne pense pas que dans le cas de VLC, il s'agisse de modifier la licence des versions passées, mais celle des versions à venir. Cela veut donc juste dire que le code source, à la date D où sa licence change, il n'y a plus de lignes de code "litigieuses".
"Bonjour madame. Alors 54,50 € s'il vous plait. Ah. Attendez. Je n'ai plus de connexion internet. La caisse ne veux plus encaisser. Désolé. Pouvez-vous revenir plus tard ? (grmlmlml faut encore que je rappel "internet by Orange")
C'est con à dire, c'est facile à dire, mais je ne vois que cette solution.
Contribuer au code. Contribuer au code en résolvant les problèmes qui te semble les plus importants. Contribuer en faisant de la pub, du prosélitisme. Contribuer en faisant du triage de bug. Contribuer en informant des bugs sur bugzilla. Contribuer en votant pour des features sur bugzilla. Contribuer en utilisant simplement Firefox (pour faire monter les stats des utilisateurs). Contribuer en traduisant les sites, la doc, l'interface, le support etc. Contribuer en installant firefox sur les ordinateurs des gens, sur leurs téléphones. Contribuer en développant des extensions innovantes. Contribuer en notifiant les propriétaires de sites web que leur site est à la ramasse sur Firefox. Contribuer en lançant une campagne de pub en 4x3 dans le métro (pour ceux qui ont gagné au loto :-)).
La liste n'est pas exhaustive. Et d'ailleurs cette liste est valable pour n'importe quel logiciel libre : il faut contribuer d'une manière ou d'une autre. Pas besoin d'être un développeur.
J'utilise qwant depuis plus d'un an. J'ai quasi abandonné Google. Je n'y retourne que de très rare fois quand vraiment les réponses de qwant ne me satisfont pas (à vue de nez, 5% de mes recherches).
Bref, je trouve Qwant particulièrement bon. Si Google est meilleur (ou en tout cas te parait meilleur), c'est en parti parce qu'il t'a pisté comme un malade et qu'il sort des réponses en fonction de ton "profil". (qui ne sont pas forcément les plus pertinentes, puisque Google choisi pour toi ce qui est pertinent selon lui).
Personnellement, je n'ai pas besoin d'études en tout genre pour voir et pour dire que, oui, en informatique, ou plus précisément dans le développement logiciel (puisque c'est mon domaine), il y a beaucoup moins de filles que de garçons.
Depuis plus de 16 ans que je bosse, chez de multiples clients et sociétés, j'en ai vu des open-spaces rempli de développeurs/euses ou des équipes de développeurs/euses . J'ai aussi fait cours à des étudiants en info à la fac jusqu'à il y a 2 ans.
Le constat a toujours été le même : il y a une écrasante majorité de garçon. J'aurais même tendance à dire qu'il y a de moins en moins de filles (surtout si je compare à mes études il y a +20 ans en IUT info ou Miage).
Je dirais que le sysadmin n'a pas à vérifier les dépendances de chaque appli, ce n'est à mon avis pas son rôle. Parce que dans ce cas là, il vérifie aussi le code de toutes les applis que les devs de sa boite font, sans parler de tous les outils qu'il doit installer sans passer par apt (bah oui, il y a plein d'outils que l'on peut avoir besoin absolument mais qui ne sont pas les dépôts de la distro). Il n'a alors jamais fini.
Tout ce qui est problématique de sécurité dans le code, je dirais que ce serait plutôt à l'équipe QA de vérifier tout ça, quand ce n'est pas aux développeurs de le faire (encore faut-il avoir une politique de sécurité).
Le sysadmin par contre, son rôle, IMHO, est de limiter les dégâts en cas d'éventuels attaques via des trous de sécu. C'est à dire cloisonner les applis (container par ex), ne les laisser accéder que ce à quoi elles ont droit d'accéder (firewall &cie), et mettre en place du monitoring pour détecter les comportements inadéquates.
Et si il découvre qu'il y a effectivement des problèmes, voir qu'il découvre à ses heures perdues une faille dans un paquet d'une appli, il fait comme pour tout logiciel qu'il installe sur son infra : il fait passer l'info en upstream (à Debian si c'est un paquet debian, aux dev de sa boite si c'est une appli interne, etc..).
Enfin bon, c'est en tout cas la manière dont je vois les choses.
Ma réponse va sembler simpliste mais : tu code ton appli pour qu'elle tourne sur Debian 8 et c'est tout. N'utilise pas de dépendances externes ou en version trop récente. Cet enfer de dépendances est peut-être justement due au fait que tout le monde veut aller trop vite et considère que le problème vient des distributions ?
Sérieusement, il faut évoluer là. On n'est plus dans les années 90 où la plupart des softs étaient en C/C++ avec des dépendances binaires, donc des dépendances fortes avec les systèmes.
Alors peut-être que ton quotidien consiste à déployer majoritairement des applis C++, mais il n'y a pas que les applis à dépendances binaires dans la vie.
Un projet Node, PHP, python ou autre techno n'a pas de dépendances binaires, des trucs à compiler fortement liés aux systèmes. La seule dépendance qu'ils ont avec le système, c'est le paquet du runtime. Et encore.. un projet réalisé avec PHP 5.3 peut très bien fonctionner avec 5.6 par exemple.
Un programme en NodeJS ou PHP (avec Composer), a toutes ses dépendances avec lui (répertoire vendor/ pour PHP). Sérieusement, qu'est ce que ça peut te faire toi, que ce programme ait ses dépendances avec lui ? En quoi est-ce différent d'un programme dans lequel le développeur aurait développé ses propres libs plutôt que de réutiliser l'existant ? Dans ce cas là aussi, tu forcerais le développeur a mettre à la poubelle ses libs et le forcer à utiliser PEAR ?
De mon point de vue, ce n'est pourtant pas de ta responsabilité.
Je comprend ton point de vue pour ce qui est des projets développés en C/C++ non linkés statiquement, parce que oui, là, effectivement, il y a une forte dépendances avec le système, et que ça peut foutre la merde.
Mais pour du node, du php ou autre langage interprété, je ne comprend pas ta réaction. Je n'ai jamais eu à faire à un admin-sys avec de telles exigences, qui sont d'ailleurs pour moi totalement infondées. Quand je travaille avec un admins-sys en général, il m'impose une version de PHP, une version de base de donnée, une version de rabbit mq etc, bref, une version des outils qui gravitent autour de l'appli. Ce que je peux comprendre parce qu'il n'a pas envie d'avoir un parc hétéroclite et que tous ses serveurs sont en Debian 8 par ex. Va donc pour du PHP de telle version, et je fais avec.
Mais de là à m'imposer à ne pas utiliser des libs externes, non fournis en général par le système, mais par un système de package comme Composer ou Npm, alors là, j'hallucine, je ne comprend pas. Je fais comment alors ? je réécris tout from scratch ? Je ré-invente la roue tous les jours ? Bonjour les coûts et les temps de développements…
D'ailleurs, je comprend encore moins ta réaction puisque pour moi, moins de dépendances avec le système, c'est moins de souci. Tu peux faire cohabiter plusieurs applis ayant des dépendances avec des version différentes, sur un même serveur. Alors que faire cohabiter deux applis PHP qui reposent sur une version de PEAR différente (installée via le système), c'est mission quasi impossible. Et c'est d'ailleurs la raison pour laquelle PEAR n'a jamais vraiment percé, jamais été apprécié par les développeurs. On se retrouve avec des libs vieillottes, pas à jour, donc avec des fonctionnalités manquantes, et donc à devoir réinventer la roue sans cesse. Et si par malheur on voulait faire un upgrade des libs PEAR, il y a de fortes chances que ça casse les vieilles applis déjà en place. Pas cool pour un admin. Alors que depuis l’avènement de Composer, et donc la possibilité d'installer des libs à l’intérieur du projet même, sans conséquence pour le reste du système et des autres applis, c'est bien plus simple d'un point de vue administration (ou alors quelque chose m'échappe), et bien plus simple pour le développeur.
L'évolution de l'informatique converge vers la minimisation des dépendances : autonomie des applications, autonomie des services. Le succès de docker en est l'expression la plus forte. Mettre tout sur la même machine, sur le même système, c'est fini, terminé : c'est trop de contraintes pour tout le monde, trop compliqué pour faire évoluer les applications etc…
En tant qu'admin sys, tu devrais t'en réjouir… À moins que tu n'aimes pas les changements qui s'opèrent dans ton métier ? Il se transforme, il passe de la gestion pure et dure d'une machine et de son OS à la gestion d'un Cloud, de containers, de micro-services et j'en passe. Nouvelles méthodes, nouvelles façon de voir les choses. Tout ça pour permettre d'être plus réactif aux demandes des utilisateurs, de pouvoir chipper une nouvelle fonctionnalité rapidement, sans à se poser de question "est ce que ça ne va pas casser l'appli Y?", ou encore "comment je fais pour implémenter cette fonctionnalité parce que l'admin-sys veut pas que j'utilise telle lib, qui pourtant me permettrait de coder ça en 1 heure ?" .
Fournir et faire évoluer rapidement un service suite à des demandes utilisateurs, c'est le but de tous services informatiques non ? (c'est le seul truc qui n'a pas changé ça ;-)
[^] # Re: Poids Plume
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Sortie de Linux Mint 18 « Sarah ». Évalué à 10.
Non, ce ne sont pas les navigateurs qui sont devenus très gourmands. Ce sont les sites web, où les développeurs ne se privent pas d'empiler les libs et frameworks JS dans tout les sens, avec de l'ajax et des images à tous les étages (sans parler du chargements de multiples fontes, vidéos et cie). Et puis charger une page web l'une après l'autre, c'est has been, alors on met tout le site dans une seule page, qui au final pèse plusieurs mégas.
[^] # Re: Nostalgie ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Quake. Vingt ans déjà. Évalué à 3. Dernière modification le 23 juin 2016 à 15:42.
coté calculatrice : j'ai aussi commencé avec une Ti57, puis Casio 8500G et HP48
J'ai découvert les ordinateurs au début des années 80 en utilisant un "Compaq portable" et le ZX81 d'un copain. J'ai ensuite tapé mes premières lignes de code (1986) sur un TO9 (que j'ai toujours).
Avec mes premiers PC (début des années 90), ce fut la découverte du langage C, mais aussi l'organisation de "lan party" entre potes, à partir de 1995, avec au départ du réseau en anneau en BNC (la gaaaallèèèère), puis du réseau en étoile avec du RJ45 et des hubs (le bonheur !) (pas de switch, ça coutaient beaucoup trop cher à l'époque). Et parmi les jeux auxquels on jouait en lan, les plus utilisés furent Doom, Starcraft, Warcraft, Quake, Diablo… Sans oublier Duke Nukem bien sûr !
Je n'ai commencé le jeu via internet qu'en 2001, majoritairement avec Counter Strike (en lan également). Le jeu par internet, c'est sympa, mais beaucoup moins fun et convivial que les lan.
Ça ne nous rajeunit pas tout ça.
[^] # Re: Désinformation ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Le malaise.. Évalué à 6.
Ah ? Il y en a ?
[^] # Re: Nom de domaine dans quels TLD ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Cozy Cloud lève 4 millions d'euros (pour faire du libre). Évalué à 9.
Vous n'êtes pas obligés de transformer tout le code CoffeeScript existant en ES6. Vous pouvez tout simplement utiliser ES6 pour les nouvelles libs ou applis, et faire la migration en douceur petit à petit. Utiliser une lib ES6 dans du code CoffeeScript ne pose à priori pas de problème. Et migrer petit à petit des briques que vous refondez par nécessité, vers ES6, est faisable sans trop de douleurs ni trop de coûts.
Le bénéfice est quand même flagrant : avec ES6, vous utilisez un langage pérenne, utilisé par bien plus de développeurs (donc recrutement et contributions facilités) que CoffeeScript, qui lui, comme tu le remarques toi même, tombe en désuétude. (sans parler de la non-necessité d'un transpiler :-))
C'est un projet intéressant. Je vais l'essayer. Si j'avais du temps, je contribuerai bien, mais là pour moi, déjà, CoffeeScript est un frein parce que je n'ai pas envie d'apprendre ce langage (alors que l'ES6, j'en fais tous les jours ou presque).
[^] # Re: Au siècle dernier ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi une petite société a intérêt à contribuer et produire du libre... mais pas que. Évalué à 5.
Je pense que tu voulais dire "à l'époque, internet n'existait pas encore dans notre boite". Parce que techniquement dans les années 90, Internet existait. (oui je chipote)
Le premier réseau (celui de l'INRIA) raccordé à internet en france, c'est en 1988. Dans la foulée quelques centres de recherche, puis les universités vers 1993 grâce au réseau Renater (j'ai pu en profiter en 1994 quand je suis entré à l'IUT d'Orsay :-)). Ensuite les premiers FAI grand public vers 1994 (sans oublier French Data Network en 1992).
[^] # Re: Un début de réponse
Posté par Laurent J (site web personnel, Mastodon) . En réponse au message Copyright du code d'un fork refondu. Évalué à 2.
Pourquoi faudrait-il leur attribuer la paternité du code d'un fichier quand leurs contributions n'y sont plus ?
Pour l'historique, il y a les mentions de copyright dans les versions précédentes, le dépôt de code etc..
# Un début de réponse
Posté par Laurent J (site web personnel, Mastodon) . En réponse au message Copyright du code d'un fork refondu. Évalué à 4.
Bon, finalement, j'ai fini par envoyé un mail à la FSF pour leur demander leur avis.
Et la réponse est… qu'il n'y a pas de réponse simple.
Comme je le pensais, selon la personne qui m'a répondu, il peut être très compliqué de déterminer si le code enlevé ou encore, si du code refondu peut avoir encore des "traces" ou pas du code original. J'imagine qu'il entend par là que le code refondu, même si syntaxiquement il n'est plus le même, peut faire tout de même la même chose ou très inspiré du code original. (la logique globale, ou l'idée générale de l'algo peut rester la même). Et dans ce cas, le contributeur reste plus ou moins l'auteur du code refondu.
Il m'a indiqué aussi que dans certaines boites, quand ils veulent refondre quelque chose et en être l'unique détenteur du copyright, ils font appel à quelqu'un qui n'a jamais vu le code original. Ainsi il n'est pas tenté de s'en inspirer, et donc fait un travail totalement original.
J'en conclu donc, à moins de totalement virer le code du contributeur sans le remplacer, qu'il est préférable de garder les noms des contributeurs dans le copyright. Une autre solution possible est aussi de demander aux contributeurs concernés par la réécriture ou les changements sur leur code, si ils acceptent d'abandonner leur copyright sur le nouveau code. Mais pas simple à faire (surtout sur du vieux code).
[^] # Re: Copyleft
Posté par Laurent J (site web personnel, Mastodon) . En réponse au message Copyright du code d'un fork refondu. Évalué à 2. Dernière modification le 26 mai 2016 à 16:25.
J'ai fait quelques recherches et je suis tombé sur le "mode d'emploi" de la GPL/LGPL/AGPL.
Il est dit qu'il faut indiquer la mention de copyright avec la/les années de publications, et la liste de toutes les personnes qui ont contribué au code ex : Copyright 2006-2016 Toto, Titi, Tata. Et sur chaque fichier du programme.
Par contre, il n'est pas précisé si on doit garder ou si on peut enlever la mention de copyright conçernant une personne pour laquelle sa contribution n'est plus présente dans le code… Ça ne répond pas trop à ma question :-/
[^] # Re: Copyleft
Posté par Laurent J (site web personnel, Mastodon) . En réponse au message Copyright du code d'un fork refondu. Évalué à 2. Dernière modification le 26 mai 2016 à 16:01.
Dans le projet en question, ajouter les contributeurs dans l'entête de chaque fichier était une habitude qui avait été prise. Probablement (mes souvenirs sont vagues), parce que, au début du projet A (2001), d'une part, mise à part la compréhension des 4 libertés fondamentales du libre, on ne maitrisait peut être pas très bien l'aspect juridique de la LGPL (pas sûr de tout maîtriser encore aujourd'hui, d'où ma question :-) ), d'autres parts, on utilisait CVS à l'époque, et que bon, manipuler ce truc n'était particulièrement pas user friendly pour inspecter l'historique etc (par rapport aux outils d'aujourd'hui).. Et souvent on intégrait des patchs à la main, donc les commits n'étaient pas créés par les auteurs des patchs. Ça nous permettait donc de laisser au moins une trace de qui avait touché à quel fichier, et de le savoir sans avoir à utiliser CVS… (ce qui au final est encore utile aujourd'hui, étant donné que le dépôt CVS et subversion du projet A a disparu :-/ )
À l'ère d'outils comme Git, Github, Gitlab, il est clair que l'intérêt de faire perdurer cette pratique est moins pertinente.
[^] # Re: Cas VLC
Posté par Laurent J (site web personnel, Mastodon) . En réponse au message Copyright du code d'un fork refondu. Évalué à 5.
Dans le cas d'un changement de licence, retirer le code des contributeurs qui ne se sont pas manifesté, ne veut pas dire modifier l'historique de git. Je ne pense pas que dans le cas de VLC, il s'agisse de modifier la licence des versions passées, mais celle des versions à venir. Cela veut donc juste dire que le code source, à la date D où sa licence change, il n'y a plus de lignes de code "litigieuses".
[^] # Re: blockchain
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Point d'étape sur loi française de finances 2016 (article 88) et les logiciels libres de caisse. Évalué à 7.
"Bonjour madame. Alors 54,50 € s'il vous plait. Ah. Attendez. Je n'ai plus de connexion internet. La caisse ne veux plus encaisser. Désolé. Pouvez-vous revenir plus tard ? (grmlmlml faut encore que je rappel "internet by Orange")
[^] # Re: javascript ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Node.js passe la sixième vitesse. Évalué à 2.
Ça tombe bien, dans les derniers Chrome, Firefox et Nodejs, tu peux utiliser les classes sans faire du typescript ;-)
[^] # Re: Le javascript
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Node.js passe la sixième vitesse. Évalué à 3. Dernière modification le 13 mai 2016 à 17:16.
Ouai mais avec PHP, je n'ai pas besoin d'une ferme de 15 serveurs octocore pour servir une appli normale à 15 utilisateurs. #vendredi
[^] # Re: Autres OS
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Android: position dominante et navigateurs alternatifs. Évalué à 0.
Le gars qui se plaint d'un manque d'une fonctionnalité tout en affirmant qu'il n'a pas cherché si la fonctionnalité existait. Très fort.
Indice : FAQ.
[^] # Re: Non.
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Il faut sauver le soldat Firefox!. Évalué à 5.
En contribuant.
C'est con à dire, c'est facile à dire, mais je ne vois que cette solution.
Contribuer au code. Contribuer au code en résolvant les problèmes qui te semble les plus importants. Contribuer en faisant de la pub, du prosélitisme. Contribuer en faisant du triage de bug. Contribuer en informant des bugs sur bugzilla. Contribuer en votant pour des features sur bugzilla. Contribuer en utilisant simplement Firefox (pour faire monter les stats des utilisateurs). Contribuer en traduisant les sites, la doc, l'interface, le support etc. Contribuer en installant firefox sur les ordinateurs des gens, sur leurs téléphones. Contribuer en développant des extensions innovantes. Contribuer en notifiant les propriétaires de sites web que leur site est à la ramasse sur Firefox. Contribuer en lançant une campagne de pub en 4x3 dans le métro (pour ceux qui ont gagné au loto :-)).
La liste n'est pas exhaustive. Et d'ailleurs cette liste est valable pour n'importe quel logiciel libre : il faut contribuer d'une manière ou d'une autre. Pas besoin d'être un développeur.
[^] # Re: Autres OS
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Android: position dominante et navigateurs alternatifs. Évalué à 4.
Et ne pas oublier la version lite https://lite.qwant.com/ , pour ceux qui trouvent l'interface par défaut trop lourde ;-)
[^] # Re: Autres OS
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Android: position dominante et navigateurs alternatifs. Évalué à 3.
J'utilise qwant depuis plus d'un an. J'ai quasi abandonné Google. Je n'y retourne que de très rare fois quand vraiment les réponses de qwant ne me satisfont pas (à vue de nez, 5% de mes recherches).
Bref, je trouve Qwant particulièrement bon. Si Google est meilleur (ou en tout cas te parait meilleur), c'est en parti parce qu'il t'a pisté comme un malade et qu'il sort des réponses en fonction de ton "profil". (qui ne sont pas forcément les plus pertinentes, puisque Google choisi pour toi ce qui est pertinent selon lui).
[^] # Re: Linux for desktop !!!
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal des paquets Snaps dans Ubuntu. Évalué à 2.
Comme Mozilla pour Firefox.
C'est pour cela (entre autres raisons) que j'utilise le Firefox vanilla, et non pas celui de la distro
[^] # Re: Le logiciel libre, c’est repenser la société
Posté par Laurent J (site web personnel, Mastodon) . En réponse au sondage Pour ou contre le hors sujet sur LinuxFr.org ?. Évalué à 2.
Personnellement, je n'ai pas besoin d'études en tout genre pour voir et pour dire que, oui, en informatique, ou plus précisément dans le développement logiciel (puisque c'est mon domaine), il y a beaucoup moins de filles que de garçons.
Depuis plus de 16 ans que je bosse, chez de multiples clients et sociétés, j'en ai vu des open-spaces rempli de développeurs/euses ou des équipes de développeurs/euses . J'ai aussi fait cours à des étudiants en info à la fac jusqu'à il y a 2 ans.
Le constat a toujours été le même : il y a une écrasante majorité de garçon. J'aurais même tendance à dire qu'il y a de moins en moins de filles (surtout si je compare à mes études il y a +20 ans en IUT info ou Miage).
# developpement : idem
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Avant c'est trop cher, après c'est trop tard. Évalué à 10.
J'ai rencontré et eu connaissance de cas similaires pour des prestations de développement :
Et c'est une grande satisfaction quand tu apprend que le projet a eu du retard, que cela ne correspond pas à ce que voulait le client etc…
On en a que pour son argent.
# GNU/Windows
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Bash dans Windows. Évalué à 10.
lu sur twitter
:-)
[^] # Re: Trollons
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Comment 11 lignes de code ont provoqué un #npmgate. Évalué à 7.
Je dirais que le sysadmin n'a pas à vérifier les dépendances de chaque appli, ce n'est à mon avis pas son rôle. Parce que dans ce cas là, il vérifie aussi le code de toutes les applis que les devs de sa boite font, sans parler de tous les outils qu'il doit installer sans passer par apt (bah oui, il y a plein d'outils que l'on peut avoir besoin absolument mais qui ne sont pas les dépôts de la distro). Il n'a alors jamais fini.
Tout ce qui est problématique de sécurité dans le code, je dirais que ce serait plutôt à l'équipe QA de vérifier tout ça, quand ce n'est pas aux développeurs de le faire (encore faut-il avoir une politique de sécurité).
Le sysadmin par contre, son rôle, IMHO, est de limiter les dégâts en cas d'éventuels attaques via des trous de sécu. C'est à dire cloisonner les applis (container par ex), ne les laisser accéder que ce à quoi elles ont droit d'accéder (firewall &cie), et mettre en place du monitoring pour détecter les comportements inadéquates.
Et si il découvre qu'il y a effectivement des problèmes, voir qu'il découvre à ses heures perdues une faille dans un paquet d'une appli, il fait comme pour tout logiciel qu'il installe sur son infra : il fait passer l'info en upstream (à Debian si c'est un paquet debian, aux dev de sa boite si c'est une appli interne, etc..).
Enfin bon, c'est en tout cas la manière dont je vois les choses.
[^] # Re: Trollons
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Comment 11 lignes de code ont provoqué un #npmgate. Évalué à 10.
Sérieusement, il faut évoluer là. On n'est plus dans les années 90 où la plupart des softs étaient en C/C++ avec des dépendances binaires, donc des dépendances fortes avec les systèmes.
Alors peut-être que ton quotidien consiste à déployer majoritairement des applis C++, mais il n'y a pas que les applis à dépendances binaires dans la vie.
Un projet Node, PHP, python ou autre techno n'a pas de dépendances binaires, des trucs à compiler fortement liés aux systèmes. La seule dépendance qu'ils ont avec le système, c'est le paquet du runtime. Et encore.. un projet réalisé avec PHP 5.3 peut très bien fonctionner avec 5.6 par exemple.
Un programme en NodeJS ou PHP (avec Composer), a toutes ses dépendances avec lui (répertoire vendor/ pour PHP). Sérieusement, qu'est ce que ça peut te faire toi, que ce programme ait ses dépendances avec lui ? En quoi est-ce différent d'un programme dans lequel le développeur aurait développé ses propres libs plutôt que de réutiliser l'existant ? Dans ce cas là aussi, tu forcerais le développeur a mettre à la poubelle ses libs et le forcer à utiliser PEAR ?
De mon point de vue, ce n'est pourtant pas de ta responsabilité.
Je comprend ton point de vue pour ce qui est des projets développés en C/C++ non linkés statiquement, parce que oui, là, effectivement, il y a une forte dépendances avec le système, et que ça peut foutre la merde.
Mais pour du node, du php ou autre langage interprété, je ne comprend pas ta réaction. Je n'ai jamais eu à faire à un admin-sys avec de telles exigences, qui sont d'ailleurs pour moi totalement infondées. Quand je travaille avec un admins-sys en général, il m'impose une version de PHP, une version de base de donnée, une version de rabbit mq etc, bref, une version des outils qui gravitent autour de l'appli. Ce que je peux comprendre parce qu'il n'a pas envie d'avoir un parc hétéroclite et que tous ses serveurs sont en Debian 8 par ex. Va donc pour du PHP de telle version, et je fais avec.
Mais de là à m'imposer à ne pas utiliser des libs externes, non fournis en général par le système, mais par un système de package comme Composer ou Npm, alors là, j'hallucine, je ne comprend pas. Je fais comment alors ? je réécris tout from scratch ? Je ré-invente la roue tous les jours ? Bonjour les coûts et les temps de développements…
D'ailleurs, je comprend encore moins ta réaction puisque pour moi, moins de dépendances avec le système, c'est moins de souci. Tu peux faire cohabiter plusieurs applis ayant des dépendances avec des version différentes, sur un même serveur. Alors que faire cohabiter deux applis PHP qui reposent sur une version de PEAR différente (installée via le système), c'est mission quasi impossible. Et c'est d'ailleurs la raison pour laquelle PEAR n'a jamais vraiment percé, jamais été apprécié par les développeurs. On se retrouve avec des libs vieillottes, pas à jour, donc avec des fonctionnalités manquantes, et donc à devoir réinventer la roue sans cesse. Et si par malheur on voulait faire un upgrade des libs PEAR, il y a de fortes chances que ça casse les vieilles applis déjà en place. Pas cool pour un admin. Alors que depuis l’avènement de Composer, et donc la possibilité d'installer des libs à l’intérieur du projet même, sans conséquence pour le reste du système et des autres applis, c'est bien plus simple d'un point de vue administration (ou alors quelque chose m'échappe), et bien plus simple pour le développeur.
L'évolution de l'informatique converge vers la minimisation des dépendances : autonomie des applications, autonomie des services. Le succès de docker en est l'expression la plus forte. Mettre tout sur la même machine, sur le même système, c'est fini, terminé : c'est trop de contraintes pour tout le monde, trop compliqué pour faire évoluer les applications etc…
En tant qu'admin sys, tu devrais t'en réjouir… À moins que tu n'aimes pas les changements qui s'opèrent dans ton métier ? Il se transforme, il passe de la gestion pure et dure d'une machine et de son OS à la gestion d'un Cloud, de containers, de micro-services et j'en passe. Nouvelles méthodes, nouvelles façon de voir les choses. Tout ça pour permettre d'être plus réactif aux demandes des utilisateurs, de pouvoir chipper une nouvelle fonctionnalité rapidement, sans à se poser de question "est ce que ça ne va pas casser l'appli Y?", ou encore "comment je fais pour implémenter cette fonctionnalité parce que l'admin-sys veut pas que j'utilise telle lib, qui pourtant me permettrait de coder ça en 1 heure ?" .
Fournir et faire évoluer rapidement un service suite à des demandes utilisateurs, c'est le but de tous services informatiques non ? (c'est le seul truc qui n'a pas changé ça ;-)
[^] # Re: Autres exemples rigolos
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Comment 11 lignes de code ont provoqué un #npmgate. Évalué à 2.
Bah le pire, c'est que ça existe ce genre de lib, comme lodash… Et c'est pourtant une lib plutôt connue.
[^] # Re: Dépendances
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Comment 11 lignes de code ont provoqué un #npmgate. Évalué à 3.
Oui, ce genre de module montre la faiblesse d'une lib standard.
Si ça peut rassurer, String.padStart et String.padEnd arrivent dans ES7
https://github.com/tc39/proposal-string-pad-start-end
https://bugzilla.mozilla.org/show_bug.cgi?id=934776