Sur un chromebook, c'est comme un android ? As-t-on l'honneur d'avoir toutes les applis google qu'on ne peut pas désinstaller sans "rooter" la machine ?
Parce qu'avant d'installer puppet, il faut faire un minimum de chose pour qu'il puisse fonctionner, comme par exemple la configuration réseau pour atteindre le puppet master, ou encore sécuriser un minimum la machine quand elle est à poil sur internet.
J'ai donc des scripts ansible pour "bootstrapper" les nouvelles machines. Ces scripts configurent le minimum vital pour que puppet puisse fonctionner et qu'on puisse se connecter en toute sécurité sur la machine (et tout les trucs bas niveau qui sont trop chiant à faire en puppet) : lancent apt-update/upgrade,, installent les paquets de "survie" (comme vim :), configure les interfaces réseaux (en particulier tout ce qui est lan pour le vrack chez ovh etc), le /etc/hosts, resolv.conf, config du serveur ssh, et au final configurent l'agent puppet.
Les scripts puppet se chargent du reste.
On va me demander pourquoi ne pas faire tout en ansible (surtout que je ne suis pas super fan de puppet) : pour des raisons historique, c'est puppet qui avait été choisi au départ (par rapport à chief et quelques autres) et à l'époque ansible n'existait pas (ou alors n'était pas encore très stable/très connu/très fonctionnel). Et puis un jour j'en ai eu marre de préparer les nouvelles machines à la main pour pouvoir les "puppetiser". Et j'ai donc utilisé ansible puisqu'il a le bon gout de ne pas avoir une archi agent-serveur (idéal donc pour bootstraper une machine vierge), et très simple à utiliser dans sa philosophie (il serait encore plus simple si il utilisait autre chose que cette connerie de syntaxe Yaml).
J'aurais pu tout mettre au final en ansible, mais il y a des obstacles à ça :
ansible est lent
trop de modules puppet à migrer, pas le temps de le faire
le système d'agent de puppet, couplé avec un puppet-dashboard, permet de savoir en permanence que tes machines sont toujours configurée comme prévu, et que tu sais quand il y a des trucs qui sont modifiés à ton insu (ce qui peut arriver si il y a une appli qui fait de la merde). Alors qu'avec Ansible, c'est plus compliqué, même si des solutions existent.
Bref, le couple Ansible (pour le bootstrapping) + puppet me va très bien.
PS: ce que j'aime bien dans ansible, c'est la facilité de créé des plugins. On peut en faire aussi dans puppet, mais j'ai horreur de ruby et ça semble plus complexe.
Je ne suis pas sûr qu'on puisse parler de Servo comme d'une «réalisation concrète»,
De mon point de vue, c'est une réalisation concrête pour Rust. Je veux dire par là, c'est une application qui existe, qui fonctionne, avec laquelle d'ailleurs il a pu être montré les avantages de Rust.
Certes, ça n'en fait pas un bon navigateur dans le sens où il manque encore beaucoup de choses pour qu'il puisse remplacer un navigateur existant, dans la vraie vie. Mais ce n'est pas non plus un hello world amélioré. Il y a du concret. son developpement est suffisement avancé pour dire, "regardez, on peut faire un navigateur en Rust". C'est d'ailleurs bien pour cela que certains de ses composants vont être intégré dans Firefox.
Je ne sais pas si les serveurs distants dont tu parles sont des serveurs de clients (et donc peut être n'as tu pas accès au manager) ou les tiens, mais on peut accéder en ssh aux hébergements mutualisés OVH.
Firefox n'incarne plus vraiment ni la légèreté, ni l'innovation
Vendredi (et donc les trolls), c'était hier.
Je suis d'accord pour l'innovation, mais pour la légèreté, faut pas exagérer. Chromium est quand même au moins aussi gourmand que Firefox en terme de mémoire (en comparant avec les mêmes sites ouverts et sans extensions).
Et sinon, même si il est vrai que ces dernières années, Mozilla s'est un peu égaré sur divers projets et est devenu trop "corporate", il faut tout de même noter les grandes améliorations des perfs sur Gecko grâce aux besoins requis par Firefox OS pour fonctionner correctement sur des ordiphone bas de gamme (Firefox OS avait profité dés le jour 0 des developpements faits pour le projet Electrolysis : chaque app web était dans son propre processus).
Ensuite il y a le projet Servo, le moteur web expérimental de Mozilla, réécrit from scratch et conçu pour profiter au maximum du multi processing à tous les étages, c'est à dire paralléliser tout ce qui peut l'être (dans le moteur de rendu, dans les parseurs CSS, HTML, le style engine, etc..), ce que ne font ni Gecko, ni Webkit/Blink à l'heure actuelle. Les premiers benchs sont impressionnants, laissant loin derrière Gecko, Webkit et Blink (voir par exemple cette vidéo).
Et Gecko va commencer à profiter de ces innovations, via l'intégration de certains composants de Servo. Ils avaient commencé par un truc "simple", le parseur mpeg4 (en Rust donc), intégré dans Firefox 48. Dans les nightlies de Firefox, il y a le parser d'URL de Servo. Et dans quelques mois on va pouvoir profiter du style engine de Servo, qui apportera des gains de perfs au niveau du parsing/calculs des CSS. Cela fait parti du projet Quantum.
Bref, technologiquement parlant, Firefox ne sera à priori pas à la ramasse en 2017.
En cas de dégroupage, je pensais que la prise téléphone ne pouvait plus communiquer sur le protocole RTC mais seulement en ADSL?!
Qu'on me reprenne si je me trompe, mais chez Orange, il n'y a pas de notion de dégroupage pour l'abonné, puisque le réseau appartient à Orange. Le fil téléphonique qui relie ton chez toi au centre téléphonique appartient et est utilisé à 100% par Orange. En clair : il n'y a pas de raison que la voix ne puisse plus passer en RTC quand on est chez Orange. C'est juste une configuration au niveau central téléphonique.
Le dégroupage concerne les autres fournisseurs, qui loue la ligne téléphonique à Orange (entre chez toi et le central téléphonique) pour y faire passer les données IP. Et ce dégroupage est partiel ou total, suivant si tu continue à avoir un abonnement RTC chez Orange ou pas.
mais je me souviens du guide pour créer des paquets de debian, avec cette remarque (diapo 42) :
Et ? Comme je dis, tu n'es pas obligé de suivre le guide en totalité. Tu n'es pas obligé de contribuer à Debian. L'intégration dans Debian n'est pas une obligation. Donc ton 3) n'a pas lieu d'être.
Sur mon infra, je fais des paquets debian pour installer des softs internes. Les paquets sont loin de respecter toutes les guidelines de Debian. Je fais juste le minimum pour que ça s'installe correctement sur mes serveurs. ça reste relativement simple à faire, tout en me facilitant la vie pour tout ce qui est intégration continue, déploiement automatique etc..
Après quelques recherches je suis tombé sur plusieurs options possibles : livrer le code source
Si il s'agit d'un logiciel libre, livrer le code source n'est pas une option. C'est le minimal à faire ! Donc quoi que tu fasses, livre au moins un tar.gz des sources.
Il me semble que cela demande un travail énorme pour rentrer officiellement dans les dépôts des distributions (en tout cas pour Debian)
Certes, mais dans un premier temps, ton objectif pourrait être de livrer un paquet simple, et pas de l'inclure dans les dépots officiels. Tu pourrais très bien livrer par exemple un deb qui ne respecte pas tous les prérequis de Debian. Et du coup c'est tout de suite plus simple à faire un paquet deb (même si la doc est pas évidente pour un nouveau venu). L'utilisateur aurait à télécharger manuellement le deb, et faire un dpkg -i.
L'avantage est que cela évite à l'utilisateur de compiler, mais cela peut aussi attirer les contributeurs qui voudraient améliorer le deb.
Tuer les extensions, c'est exagéré. Ils tuent les extensions XUL, mais proposent un autre moyen de faire des extensions avec l'API WebExtensions. C'est certes moins puissant, mais plus safe d'un autre coté, que ce soit au niveau sécurité qu'au niveau compatibilité avec les versions ulterieures (ce qui n'était jamais garanti avec les extensions XUL). Et surtout, les WebExtensions seront compatibles (en théorie) avec Servo par exemple, car l'API est indépendante du moteur.
comme le dit un commentaire plus bas, nuance de taille : tu ne confie pas tes données à l'entreprise cozy. Elle développe juste un logiciel qui permet justement de ne pas confier tes données à un tiers. Donc, non, tu n'as pas à connaitre la tambouille interne de l'entreprise. Comme tout entreprise, ceux qui ont le droit de savoir : les actionnaires. Et les salariés dans une moindre mesure.
La "communauté" n'a pas non plus à savoir ce qui se passe dans la boite. La communauté n'est concernée uniquement par le logiciel libéré par l'entreprise. Et je dirais, peu importe la direction (imposée par l'entreprise) que prend le projet : si la communauté n'est pas satisfaite, libre à elle de forker : c'est la magie du libre. Ou à ses membres de s’intéresser à d'autres projets.
en tant qu’utilisateur, ça m’intéresse de savoir quel type de décision à conduit à ces désaccords,
Désolé de te dire que non, cela ne te concerne pas. La "vie privée" de l'entreprise (puisque l'origine de cette séparation est bien interne, entre deux personnes, selon le communiqué) ne te concerne pas. Au même titre que les décisions stratégiques de l'entreprise : ce ne sont pas tes affaires. Tout comme ta vie privée ne nous concerne pas, ce ne sont pas nos affaires.
C'est quand même "amusant" que des partisans de la vie privée veulent connaître à ce point celle des autres.
Certes, les orientations de la boite peuvent être intéressantes (ou pas), mais ta série de question me semble bien plus intrusive. Fait comme tout le monde : tu attends les communiqués, c'est à dire ce que veut bien rendre publique la boite. Si tu es vraiment impatient, très curieux de l'avenir de la boîte, deux solutions : devenir actionnaire ou salarié.
"tuile" n'est pas adapté, car les tuiles d'un toit se chevauchent, alors que ce n'est pas le cas des dalles, qui sont jointives.
Certes.
Mais pour avoir un rendu correcte des "dalles", en tenant compte des arrondis de calculs et tous le toutim, et afin de limiter les artefacts au niveau des jonctions des dalles, en particulier lors des transitions pendant les zooms, il faut générer des dalles légèrement plus grandes que la taille théorique affichée afin que les jonctions soient visuellement correctes. Ce sont donc bien, en théorie, dans un moteur de rendu à "dalles/tuiles" bien foutu, des tuiles.
Le problème d'avoir la carte en local (quel que soit le mode de téléchargement), c'est que tu as vite une carte obsolète, parce qu'une carte, c'est vivant (les routes changent, des nouvelles routes apparaissent, sans parler de l'apport des contributions pour OSM).
Avoir la carte en local, c'est surtout pertinent quand tu veux visualiser la carte en étant déconnecté.
Bref, cela veut dire du téléchargement régulier. Autant donc utiliser un service de tuile, qui fourni toujours des cartes à jour (en tout cas, dans le cas d'OSM).
Bittorent, comme tout protocol P2P, c'est bien si il y a suffisamment d'utilisateurs. Et via bittorent, pas sûr non plus que tu ais la carte à jour.
Et tu as prévu de t'intéresser à ce dont tu parles un jour histoire d'éviter de tirer des conclusions à partir de rien ?
Oui, je m'y suis déjà intéressè. Il paraitrait même que je fais du développement web depuis 1994 et que j'ai grouillé dans le code des navigateurs, voir même contribué.
Le single page, c'est une page plutôt légère qui va dynamiquement charger le contenu dont tu as besoin et ça remplace le changement de page par de l'ajax.
Ou pas. Tout dépend comment c'est foutu. Certaines ne remplacent rien, ils ajoutent (et cachent ce qu'il y avait avant). Certains pour des raisons de "perf" : éviter des appels réseaux, pouvoir garder des données ou je ne sais quoi d'autres. Bref. Ouvre le profiler et l'inspecteur réseaux de ton navigateur et navigue sur des beaux sites kikoulol single page utilisant le dernier super framework à la mode. Tu seras surpris des résultats.
Et je ne parle pas des sites single page (ou pas single d'ailleurs) qui chargent le contenu au fur et à mesure que l'on scrolle (et donc ne supprime pas ce qui est au dessus, logique). Un exemple ultra connu : Twitter. Arrivé en bas de la page (façon de parler, disons plutôt, quand on arrête de scroller au bout de trente secondes), le poid total de la page est monstrueux.
Si tout avait été chargé dés le départ, ça aurait pas mal ralentit "l’expérience utilisateur" (c'est pour ça qu'on ne faisait pas de la single page ou du chargement progressif il y a quelques années). Mais au final, dans les deux cas, lazy loading ou pas, le navigateur et l'os en prenne un coup dans la tronche. Encore une fois, suffit de regarder les métriques données par les outils de dev des navigateurs.
Cher un fonctionnement qui peut être lourd ou léger selon comment c'est fait
Voilà, on y est. Ce que je viens d'expliquer quoi.
et ce que tu utilise comme navigateur
Non. Il y aura quelques différences (pas forcément importantes au final) entre navigateurs, mais une page qui charge 1Mo de ressources, ça reste 1Mo de ressources à charger quelque soit le navigateur. Et donc ça fait 1Mo de ressources à traiter, qui sont multipliée par X fois puisque les images sont décompressées, le html est transformé en arbre DOM et en arbre de rendu avec tout ce que cela implique au niveau du layout, du compositing etc etc…
Et de nos jours, en prenant l'exemple de 1Mo, je suis super gentil. Je viens de regarder avec twitter, une application que bon nombre d'internaute utilise, tu en conviendra. Après un scrolling de quelques pages (138 messages twitters chargés et affichés, et non je ne les ai pas compté, le DOM s'en est chargé pour moi ;)), j'en suis à 23 Mo de ressources chargées d'après l'inspecteur réseau, et cela occupe au final 86 Mo après traitement (arbre DOM, JS et tout le toutim) d'après about:memory. À la fin de la journée, au fur et à mesure des messages reçus (plusieurs dizaines ou centaines?), je n'ose imaginer la quantité de mémoire que prend twitter. Et après on accuse les navigateurs d'être lourd, lent etc…
(Possible qu'après un certain nombre de messages, (200 ? 300 ? 1000 ?) il efface les plus anciens, mais je n'ai pas vérifié. En tout cas il n'a pas fait le ménage pendant ce test)
mais il ne s'agit pas de charger tout au début pour ne plus dépendre du réseau ensuite.
Bah si justement. Il y a même des applications qui sont développées spécifiquement comme ça, car elles ont besoin de fonctionner offline ou d'éviter trop de requêtes ou de temps de latence dans l'utilisation à cause des requêtes (avec la pile de lib js qu'on entasse de nos jours dans les sites/apps web, pas étonnant). Les services workers ont d'ailleurs été créés pour ce genre de besoin et résoudre les problèmes des technos appcache &cie.
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).
[^] # Re: ChromeOS & Android
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 2017 : l'année où Linux atteindra les 5% de parts de marché. Évalué à 4.
Sur un chromebook, c'est comme un android ? As-t-on l'honneur d'avoir toutes les applis google qu'on ne peut pas désinstaller sans "rooter" la machine ?
[^] # Re: Agentless, danger
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Déploiement et automatisation avec Ansible - partie 1. Évalué à 6.
C'est mon cas :-)
Parce qu'avant d'installer puppet, il faut faire un minimum de chose pour qu'il puisse fonctionner, comme par exemple la configuration réseau pour atteindre le puppet master, ou encore sécuriser un minimum la machine quand elle est à poil sur internet.
J'ai donc des scripts ansible pour "bootstrapper" les nouvelles machines. Ces scripts configurent le minimum vital pour que puppet puisse fonctionner et qu'on puisse se connecter en toute sécurité sur la machine (et tout les trucs bas niveau qui sont trop chiant à faire en puppet) : lancent apt-update/upgrade,, installent les paquets de "survie" (comme vim :), configure les interfaces réseaux (en particulier tout ce qui est lan pour le vrack chez ovh etc), le /etc/hosts, resolv.conf, config du serveur ssh, et au final configurent l'agent puppet.
Les scripts puppet se chargent du reste.
On va me demander pourquoi ne pas faire tout en ansible (surtout que je ne suis pas super fan de puppet) : pour des raisons historique, c'est puppet qui avait été choisi au départ (par rapport à chief et quelques autres) et à l'époque ansible n'existait pas (ou alors n'était pas encore très stable/très connu/très fonctionnel). Et puis un jour j'en ai eu marre de préparer les nouvelles machines à la main pour pouvoir les "puppetiser". Et j'ai donc utilisé ansible puisqu'il a le bon gout de ne pas avoir une archi agent-serveur (idéal donc pour bootstraper une machine vierge), et très simple à utiliser dans sa philosophie (il serait encore plus simple si il utilisait autre chose que cette connerie de syntaxe Yaml).
J'aurais pu tout mettre au final en ansible, mais il y a des obstacles à ça :
Bref, le couple Ansible (pour le bootstrapping) + puppet me va très bien.
PS: ce que j'aime bien dans ansible, c'est la facilité de créé des plugins. On peut en faire aussi dans puppet, mais j'ai horreur de ruby et ça semble plus complexe.
[^] # Re: Bourne
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Librsvg utilise maintenant le langage Rust. Évalué à 6. Dernière modification le 08 janvier 2017 à 16:12.
De mon point de vue, c'est une réalisation concrête pour Rust. Je veux dire par là, c'est une application qui existe, qui fonctionne, avec laquelle d'ailleurs il a pu être montré les avantages de Rust.
Certes, ça n'en fait pas un bon navigateur dans le sens où il manque encore beaucoup de choses pour qu'il puisse remplacer un navigateur existant, dans la vraie vie. Mais ce n'est pas non plus un hello world amélioré. Il y a du concret. son developpement est suffisement avancé pour dire, "regardez, on peut faire un navigateur en Rust". C'est d'ailleurs bien pour cela que certains de ses composants vont être intégré dans Firefox.
[^] # Re: pavé numérique ? FTP ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal revue elementary OS Loki. Évalué à 2.
Je ne sais pas si les serveurs distants dont tu parles sont des serveurs de clients (et donc peut être n'as tu pas accès au manager) ou les tiens, mais on peut accéder en ssh aux hébergements mutualisés OVH.
[^] # Re: installation pas *user-friendly*
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 50 Cent. Évalué à -2.
Tu es vraiment sérieux là ? o_O
[^] # Re: Flexibilité du développement
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 50 Cent. Évalué à 2.
s/étendables/extensibles
# Gecko, Servo et cie
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Mozilla: l'enjeu de 2017 est-il au niveau du navigateur web ?. Évalué à 10.
Vendredi (et donc les trolls), c'était hier.
Je suis d'accord pour l'innovation, mais pour la légèreté, faut pas exagérer. Chromium est quand même au moins aussi gourmand que Firefox en terme de mémoire (en comparant avec les mêmes sites ouverts et sans extensions).
Et sinon, même si il est vrai que ces dernières années, Mozilla s'est un peu égaré sur divers projets et est devenu trop "corporate", il faut tout de même noter les grandes améliorations des perfs sur Gecko grâce aux besoins requis par Firefox OS pour fonctionner correctement sur des ordiphone bas de gamme (Firefox OS avait profité dés le jour 0 des developpements faits pour le projet Electrolysis : chaque app web était dans son propre processus).
Ensuite il y a le projet Servo, le moteur web expérimental de Mozilla, réécrit from scratch et conçu pour profiter au maximum du multi processing à tous les étages, c'est à dire paralléliser tout ce qui peut l'être (dans le moteur de rendu, dans les parseurs CSS, HTML, le style engine, etc..), ce que ne font ni Gecko, ni Webkit/Blink à l'heure actuelle. Les premiers benchs sont impressionnants, laissant loin derrière Gecko, Webkit et Blink (voir par exemple cette vidéo).
Et Gecko va commencer à profiter de ces innovations, via l'intégration de certains composants de Servo. Ils avaient commencé par un truc "simple", le parseur mpeg4 (en Rust donc), intégré dans Firefox 48. Dans les nightlies de Firefox, il y a le parser d'URL de Servo. Et dans quelques mois on va pouvoir profiter du style engine de Servo, qui apportera des gains de perfs au niveau du parsing/calculs des CSS. Cela fait parti du projet Quantum.
Bref, technologiquement parlant, Firefox ne sera à priori pas à la ramasse en 2017.
# Internet Archive Archive
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La fin des liens morts sur Wikipedia ?. Évalué à 6.
C'est bien beau tout ça, mais est-ce que Internet Archive est archivé par quelqu'un d'autre ?
[^] # Re: Tél
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les routeurs Turris Omnia sont livrés. Évalué à 4.
Qu'on me reprenne si je me trompe, mais chez Orange, il n'y a pas de notion de dégroupage pour l'abonné, puisque le réseau appartient à Orange. Le fil téléphonique qui relie ton chez toi au centre téléphonique appartient et est utilisé à 100% par Orange. En clair : il n'y a pas de raison que la voix ne puisse plus passer en RTC quand on est chez Orange. C'est juste une configuration au niveau central téléphonique.
Le dégroupage concerne les autres fournisseurs, qui loue la ligne téléphonique à Orange (entre chez toi et le central téléphonique) pour y faire passer les données IP. Et ce dégroupage est partiel ou total, suivant si tu continue à avoir un abonnement RTC chez Orange ou pas.
https://fr.wikipedia.org/wiki/Dégroupage
[^] # Re: Remarques
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Comment distribuer un logiciel pour GNU/Linux ?. Évalué à 2.
Et ? Comme je dis, tu n'es pas obligé de suivre le guide en totalité. Tu n'es pas obligé de contribuer à Debian. L'intégration dans Debian n'est pas une obligation. Donc ton 3) n'a pas lieu d'être.
Sur mon infra, je fais des paquets debian pour installer des softs internes. Les paquets sont loin de respecter toutes les guidelines de Debian. Je fais juste le minimum pour que ça s'installe correctement sur mes serveurs. ça reste relativement simple à faire, tout en me facilitant la vie pour tout ce qui est intégration continue, déploiement automatique etc..
# Remarques
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Comment distribuer un logiciel pour GNU/Linux ?. Évalué à 3.
Si il s'agit d'un logiciel libre, livrer le code source n'est pas une option. C'est le minimal à faire ! Donc quoi que tu fasses, livre au moins un tar.gz des sources.
Certes, mais dans un premier temps, ton objectif pourrait être de livrer un paquet simple, et pas de l'inclure dans les dépots officiels. Tu pourrais très bien livrer par exemple un deb qui ne respecte pas tous les prérequis de Debian. Et du coup c'est tout de suite plus simple à faire un paquet deb (même si la doc est pas évidente pour un nouveau venu). L'utilisateur aurait à télécharger manuellement le deb, et faire un dpkg -i.
L'avantage est que cela évite à l'utilisateur de compiler, mais cela peut aussi attirer les contributeurs qui voudraient améliorer le deb.
[^] # Re: La fonctionnalité de visioconférence Hello [...] va être supprimée de Firefox
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 49 en chansons. Évalué à 6.
Tuer les extensions, c'est exagéré. Ils tuent les extensions XUL, mais proposent un autre moyen de faire des extensions avec l'API WebExtensions. C'est certes moins puissant, mais plus safe d'un autre coté, que ce soit au niveau sécurité qu'au niveau compatibilité avec les versions ulterieures (ce qui n'était jamais garanti avec les extensions XUL). Et surtout, les WebExtensions seront compatibles (en théorie) avec Servo par exemple, car l'API est indépendante du moteur.
[^] # Re: plusieurs truc
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Appel à idées pour prof(s) de lycée. Évalué à 7.
Parce que foutre de l'électronique partout, c'est du développement durable ?
[^] # Re: ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Trouver un développeur. Évalué à 10.
Voilà, c'est ça qu'il faut ajouter dans l'annonce :
[^] # Re: La version officielle
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Cozy cloud, maif et licenciement du CTO???. Évalué à 1.
comme le dit un commentaire plus bas, nuance de taille : tu ne confie pas tes données à l'entreprise cozy. Elle développe juste un logiciel qui permet justement de ne pas confier tes données à un tiers. Donc, non, tu n'as pas à connaitre la tambouille interne de l'entreprise. Comme tout entreprise, ceux qui ont le droit de savoir : les actionnaires. Et les salariés dans une moindre mesure.
La "communauté" n'a pas non plus à savoir ce qui se passe dans la boite. La communauté n'est concernée uniquement par le logiciel libéré par l'entreprise. Et je dirais, peu importe la direction (imposée par l'entreprise) que prend le projet : si la communauté n'est pas satisfaite, libre à elle de forker : c'est la magie du libre. Ou à ses membres de s’intéresser à d'autres projets.
[^] # Re: La version officielle
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Cozy cloud, maif et licenciement du CTO???. Évalué à 1.
Désolé de te dire que non, cela ne te concerne pas. La "vie privée" de l'entreprise (puisque l'origine de cette séparation est bien interne, entre deux personnes, selon le communiqué) ne te concerne pas. Au même titre que les décisions stratégiques de l'entreprise : ce ne sont pas tes affaires. Tout comme ta vie privée ne nous concerne pas, ce ne sont pas nos affaires.
C'est quand même "amusant" que des partisans de la vie privée veulent connaître à ce point celle des autres.
Certes, les orientations de la boite peuvent être intéressantes (ou pas), mais ta série de question me semble bien plus intrusive. Fait comme tout le monde : tu attends les communiqués, c'est à dire ce que veut bien rendre publique la boite. Si tu es vraiment impatient, très curieux de l'avenir de la boîte, deux solutions : devenir actionnaire ou salarié.
[^] # Re: La version officielle
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Cozy cloud, maif et licenciement du CTO???. Évalué à 9. Dernière modification le 19 juillet 2016 à 17:33.
C'est pénible ces gens qui veulent tout savoir sur tout, comme si tout leur était dû, alors que ce ne sont pas leurs affaires.
[^] # Re: Demande d'explication
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Une grosse tuile pour GNOME Maps. Évalué à 7. Dernière modification le 18 juillet 2016 à 11:49.
Certes.
Mais pour avoir un rendu correcte des "dalles", en tenant compte des arrondis de calculs et tous le toutim, et afin de limiter les artefacts au niveau des jonctions des dalles, en particulier lors des transitions pendant les zooms, il faut générer des dalles légèrement plus grandes que la taille théorique affichée afin que les jonctions soient visuellement correctes. Ce sont donc bien, en théorie, dans un moteur de rendu à "dalles/tuiles" bien foutu, des tuiles.
[^] # Re: osm map via BitTorrent
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Une grosse tuile pour GNOME Maps. Évalué à 4.
Le problème d'avoir la carte en local (quel que soit le mode de téléchargement), c'est que tu as vite une carte obsolète, parce qu'une carte, c'est vivant (les routes changent, des nouvelles routes apparaissent, sans parler de l'apport des contributions pour OSM).
Avoir la carte en local, c'est surtout pertinent quand tu veux visualiser la carte en étant déconnecté.
Bref, cela veut dire du téléchargement régulier. Autant donc utiliser un service de tuile, qui fourni toujours des cartes à jour (en tout cas, dans le cas d'OSM).
Bittorent, comme tout protocol P2P, c'est bien si il y a suffisamment d'utilisateurs. Et via bittorent, pas sûr non plus que tu ais la carte à jour.
[^] # Re: Poids Plume
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Sortie de Linux Mint 18 « Sarah ». Évalué à 3.
Oui, je m'y suis déjà intéressè. Il paraitrait même que je fais du développement web depuis 1994 et que j'ai grouillé dans le code des navigateurs, voir même contribué.
Ou pas. Tout dépend comment c'est foutu. Certaines ne remplacent rien, ils ajoutent (et cachent ce qu'il y avait avant). Certains pour des raisons de "perf" : éviter des appels réseaux, pouvoir garder des données ou je ne sais quoi d'autres. Bref. Ouvre le profiler et l'inspecteur réseaux de ton navigateur et navigue sur des beaux sites kikoulol single page utilisant le dernier super framework à la mode. Tu seras surpris des résultats.
Et je ne parle pas des sites single page (ou pas single d'ailleurs) qui chargent le contenu au fur et à mesure que l'on scrolle (et donc ne supprime pas ce qui est au dessus, logique). Un exemple ultra connu : Twitter. Arrivé en bas de la page (façon de parler, disons plutôt, quand on arrête de scroller au bout de trente secondes), le poid total de la page est monstrueux.
Si tout avait été chargé dés le départ, ça aurait pas mal ralentit "l’expérience utilisateur" (c'est pour ça qu'on ne faisait pas de la single page ou du chargement progressif il y a quelques années). Mais au final, dans les deux cas, lazy loading ou pas, le navigateur et l'os en prenne un coup dans la tronche. Encore une fois, suffit de regarder les métriques données par les outils de dev des navigateurs.
Voilà, on y est. Ce que je viens d'expliquer quoi.
Non. Il y aura quelques différences (pas forcément importantes au final) entre navigateurs, mais une page qui charge 1Mo de ressources, ça reste 1Mo de ressources à charger quelque soit le navigateur. Et donc ça fait 1Mo de ressources à traiter, qui sont multipliée par X fois puisque les images sont décompressées, le html est transformé en arbre DOM et en arbre de rendu avec tout ce que cela implique au niveau du layout, du compositing etc etc…
Et de nos jours, en prenant l'exemple de 1Mo, je suis super gentil. Je viens de regarder avec twitter, une application que bon nombre d'internaute utilise, tu en conviendra. Après un scrolling de quelques pages (138 messages twitters chargés et affichés, et non je ne les ai pas compté, le DOM s'en est chargé pour moi ;)), j'en suis à 23 Mo de ressources chargées d'après l'inspecteur réseau, et cela occupe au final 86 Mo après traitement (arbre DOM, JS et tout le toutim) d'après about:memory. À la fin de la journée, au fur et à mesure des messages reçus (plusieurs dizaines ou centaines?), je n'ose imaginer la quantité de mémoire que prend twitter. Et après on accuse les navigateurs d'être lourd, lent etc…
(Possible qu'après un certain nombre de messages, (200 ? 300 ? 1000 ?) il efface les plus anciens, mais je n'ai pas vérifié. En tout cas il n'a pas fait le ménage pendant ce test)
Bah si justement. Il y a même des applications qui sont développées spécifiquement comme ça, car elles ont besoin de fonctionner offline ou d'éviter trop de requêtes ou de temps de latence dans l'utilisation à cause des requêtes (avec la pile de lib js qu'on entasse de nos jours dans les sites/apps web, pas étonnant). Les services workers ont d'ailleurs été créés pour ce genre de besoin et résoudre les problèmes des technos appcache &cie.
[^] # 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).