On trouve encore des articles poussiéreux sur le Net sur combien XUL allait révolutionner le monde, mais ça n'a jamais eu une très grande popularité
Tout dépend ce qu'on appelle popularité. Les possibilités du XUL sont à l'origine du succès des extensions dans Firefox (et donc en partie du succès de Firefox). Et il y a eu nombre de projets d'applications desktop en XUL.
C'est Mozilla lui-même qui a tué le XUL (pour les applications tierces j'entends) en ne faisant pas de XulRunner (le lanceur d'applications XUL), un vrai produit, c'est à dire, avec un beau packaging, du marketing etc..
et le code a été déplacé dans une extension (non livrée par défaut).
Le code de quoi ? Si tu parles de XUL, c'est toujours présent : c'est le langage utilisé pour l'interface de Firefox (et de Thunderbird…). Charge par exemple la page chrome://browser/content dans Firefox et regarde le code source ;-).
Je pense que tu confonds avec l'extension Xul Remote Manager, qui permet d’exécuter des applis web réalisée en XUL, cette possibilité ayant été désactivée par défaut il y a quelques années, à cause de trop nombreuses corrections de sécurité (le XUL, par nature, offrant une plus grande surface d'attaque).
Peut etre qu'on n'a pas la meme definition de econome en fait. Pour 4 tab ouvert, j'ai 240Mo qui disparaisse…
Ça veut rien dire. Les sites de nos jours sont gourmands.
Je suis pret a parier que Firefox OS est au dessus en conso ou au mieux au même niveau.
Je trouve bizarre de parier sur quelque chose dont tu ne connais rien : le matos qui sera utilisé, la pile graphique utilisée, le fonctionnement du moteur de rendu etc..
c'est qu'il deporte la resolution du souci plus haut dans la stack. Il faut utiliser un toolkit JavaScript qui soit malin..
Je ne comprend pas de quoi tu parles là… Le rendu graphique n'est pas en JS. De plus y a du JIT dans le moteur JS de Firefox…
J'ai l'impression que tu compares des choux et des carottes.
En théorie, tu prend un des téléphones supportés, tu flash la rom. Et voilà :-) Bon, ok, j'oublie la phase compilation et tout le bordel (quoique doit y avoir builds sur le ftp). Bref, pour les geeks barbus (ça changera probablement quand il y aura une release stable).
Les modèles low cost utilisés en interne chez Mozilla (nom de code Unagi et Otoro) pour le développement sont des téléphones "no-name", sans marque. J'en ai eu un entre les mains, c'est vraiment du no-name, y a aucun nom nulle part et le design est vraiment très basique.
Maintenant, si tu deviens contributeur super actif sur Firefox OS, tu pourras tenter ta chance auprès de Mozilla pour obtenir un de ces téléphones low cost en prêt ;-)
PS: je ne sais pas si, quand Telephonica sortira son téléphone, on pourra en acheter en France, mais je ne pense pas.
BeOS à son époque était très en avance sur son temps concernant le multimédia. Tu pouvais lancer plusieurs video/musique/anim3D en même temps sans que le système ne bronche. Et pourtant, je parle d'une époque où les processeurs tournaient à 133 Mhz. Bon, ok, la machine BeBox avait un double processeur mais quand même.
Donc si aujourd'hui on n'arrive pas à faire la même chose avec une distro linux et du matos 10 fois plus puissant…
oui pareil, je trouve bizarre qu'une "grosse" boite comme Canonical n'ait pas de partenariats avec des fabricants ou des opérateurs téléphoniques (à moins que ça soit encore secret pour des raisons marketing qu'on ignore ?).
Car si on veut s'assurer d'une bonne entrée sur le marché, vu la forte concurrence, il faudrait quand même pouvoir au moins présenter et fournir un modèle avec le système pré-installé. Sinon ça va rester un marché de geek.
Passer l'étape du "proof of concept", Mozilla avait très rapidement engagé des démarches pour avoir des partenariats avec des opérateurs, pour Firefox OS. Telephonica va ainsi proposer à ses clients brésiliens dans les semaines à venir des téléphones Firefox OS.
Rassures-moi, la dernière fois que tu as utilisé Firefox, c'était la version 3.6 non ?
Bon en tout cas, tu aurais pu éviter de troller, on n'est pas vendredi. Les dernières versions de Firefox sont particulièrement économes en mémoire et rapides.
Firefox OS, c'est un noyau linux, un gecko au dessus, et un bureau en HTML5/JS. Et c'est fait pour des téléphones lowcost. Et je peux t'assurer que ça reste véloce sur les prototypes bas de gamme que j'ai eu entre les mains.
C'est lent
Pas sur Firefox OS
mal integre
Pas sur Firefox OS. Il y a des API pour communiquer entre applis (qui sont chacunes dans leur sandbox), comme les webactivities, un truc similaire à ce qui existe sous android.
et toutes tes données finissent par transiter sur un serveur.
Je ne sais pas de quelles données tu parles (j'ai pas encore vu d'applis HTML qui envoi tout ton $HOME quelques part sur le web, le modèle de sécurité des applis web ne le permettant pas).
Conçernant les données de l'appli en elle-même, ou certaines données comme le carnet d'adresse, je dirais que c'est finalement comme n'importe quel appli de téléphone (ios, android etc). Faut juste pas accepter d'installer n'importe quoi, et pas autoriser l'appli à accéder à tes données personnelles.
Oui, mais tu violes les conditions générales d'utilisation. C'est mal
je suis d'accord avec toi
Bref, je n'aime pas confier mes données à une entreprise,
Certes, mais avoir son propre forge sur son propre serveur, et lisible par tous (puisque tu voudrais qu'on puisse consulter sans devoir se logguer), c'est publier son contenu à tous.
Donc rien n'empêche une entreprise de cloner ton dépôt, récupérer le contenu du wiki, des issues etc, et au final, de trouver des références à ton nom (dans les commits…). Et voilà, tu es fiché. Même si ils ne possèdent qu'un pseudo, tu es fiché. À moins d'avoir une "hygiène web" supère strict, on trouve toujours des infos sur le web permettant de faire un rapprochement entre un pseudo et un nom. Et un mail. Voire plus.
Par exemple, là, tu publie sous un pseudo, SKy. Mais tu as aussi indiqué ton site web dans ton profil. Et sur ton site web, on y apprend plein de chose, ton nom, ton prénom, ton adresse postale etc… Bref, même si linuxfr détruit bien ton profil, des crawlers (moteur de recherches, annuaires…), eux, auront déjà fait depuis longtemps le rapprochement entre le pseudo "SKy" et ton identité.
À partir du moment où tu publie quelque chose sur internet, tu ne peux plus contrôler ces données. Tu auras beau éteindre ton serveur, l'atomiser, tes données publiques auront été dupliquées quelques parts. Forcément. Il faut se mettre cela dans le crâne. Il n'y a pas besoin de publier des données sur le site d'un "méchant" pour que celui-ci en sache plus que tu en veux sur toi.
Que ton nom ou ton pseudo soit publié sur github ou sur ta forge perso, ça ne change rien du tout. Il est publié. point.
je ne vois pas ce que tu entends par données personnelles. Si tu parles du code/issues/wiki, dans ce cas c'est contradictoire avec le fait que tu veuille rendre public tes données dans gitlab. Si tu parles du profil utilisateur, je ne vois pas vraiment ce qu'il y a comme données personnelles. Dans Github, je n'ai pas de données personnelles dans mon profil, à part mon mail et mon nom/prénom. Mais tu peux très bien fournir un pseudo et une adresse mail anonymisée…
j'aimerais juste pouvoir l'installer sur mon serveur
comme je l'ai dit, à cause de leur infrastructure, il est fort possible que l'architecture de leur application ne soit pas évident à installer ça sur son petit serveur chez soi.
Par contre, si tu veux un Github like chez toi, regarde du coté de Gitlab. C'est une copie quasi conforme.
mais que j'aime avoir mes données chez moi
même avec github, tes données sont chez toi. Ton dépôt git est sur ta machine. Tu peux aussi avoir le depot git du wiki sur ta machine. Et tu peux rapatrier les issues via des api..
Le modèle propriétaire : le code du service n'est pas fourni, il est très difficile voire impossible d'exporter les données.
Le modèle libre : le code du service est fourni, il est souvent possible d'exporter ses données facilement.
Ce qui est totalement faux. La possibilité de récupérer ses données dépends seulement des fonctionnalités du service, pas du fait que le code du site soit ouvert ou fermé.
La boite qui offre un service reposant à 100% sur du libre ne va pas pour autant ouvrir ses bases de données ou son système de fichier à tout vent. L'export de tes données va donc dépendre des API qu'elle propose, qu'elle ouvre.
Imagine que demain j'ouvre une plateforme wiki basé sur Dokuwiki, je peux très bien ne pas vouloir ouvrir l'API XMLRPC de dokuwiki pour diverses raisons : sécurité, "emprisonner" l'utilisateur, ou encore faire payer l’accès à cet API.
Qu'est ce que cela va changer pour l'utilisateur, par rapport à un service dont le code source est proprio ? Rien. Absolument rien.
Ça fait plusieurs fois que je lis sur linuxfr cet argument "contre" pour les services reposant sur des logiciels proprio. ARRETEZ DE L'UTILISER, c'est totalement bidon, du coup, ça décrédibilise le reste de votre argumentaire.
Les fournisseurs de service misent sur la qualité de service
Oui, mais ça a un coût. Il faut donc payer quelque part (infrastructure, réseau…). Que le soft soit ouvert ou fermé ne change pas grand chose au final. Si on veut de la qualité de service, il faut payer, et c'est tout à fait normal. Maintenant, à qualité égale, on peut effectivement choisir de mettre ses sous dans la boite qui utilise des logiciels libres.
les clients qui n'ont pas la compétence en interne pour installer ce service
Ou pas envie et/ou pas le temps de gérer un service "interne".
Les parties les moins importantes de leur service sont libres, par exemple Gollum leur moteur de wiki utilisant un dépôt git. Mais le cœur de l'application est entièrement propriétaire.
En même temps, ça ferait une belle jambe à tout ceux qui utilisent github, d'avoir le coeur de l'application.
Un paramètre semble être oublié dans l'argumentaire : github héberge des centaines de milliers (millions?) de projets. Donc le coeur de l'appli est architecturé pour une infrastructure spécifique, à forte charge. Ça doit être certainement la plaie à installer et à configurer, parce que très spécifique. Très franchement, j'en voudrais pas pour l'installer sur un intranet en entreprise par exemple, ce serait prendre un marteau pour écraser une mouche.
Si on veut un outil similaire, autant prendre un des outils que tu as cité, ça sera certainement plus simple à installer, et certainement plus adapté à des petites structures. puisque si on veut du github chez soit, en entreprise, c'est qu'à priori, on a une petite infrastructure réservée au développement par rapport à chez github. Je doute qu'il existe une boite qui ait des centaines de milliers de projets à gérer comme sur Github.
Conclusion : tout le monde s'en fout que le coeur de Github soit proprio. sauf les aigris, les intégristes et les empêcheurs de tourner en rond.
Merci sinon pour ta liste d'alternatives. Mais sans troll, ça aurait été mieux.
Le nouveau "plugin" en question est entièrement en Javascript, et repose sur HTML5 (balise video pour les videos par exemple, et probablement canvas pour le reste).
Il n'utilise donc pas les mêmes technos que les autres (C/C++), il y a beaucoup moins de chance que ça crash (null pointer etc, ça n'existe pas en JS :-).
Coté perf, c'est à voir. Ils doivent certainement faire usage des Arrays spécialisés sur les entiers/flottants etc pour les manipulations de matrices ou de bytecode (ce qui est TRÈS performant par rapport à un Array normal).
ah non pour moi, une machine à voter, c'est une belle boite noire qui fait des choses que je (ou n'importe quel quidam) ne comprends pas. Elle a beau me sortir un ticket machin chose, au final, pour être sûr qu'elle a bien compté, il faudrait recompter "à la main".
Résultat : une machine à voter ne sert à rien, sauf à remplir les poches des vendeurs de machines à voter.
C'est pas comme ci Firefox OS avait un environnement très spécifique, des API exotiques, son propre langage, son propre environnement graphique ou que sais-je encore. Non. Firefox OS, c'est un OS reposant sur des standards (ou en passe de l'être).
Une appli pour Firefox OS, c'est du HTML/JS/CSS, avec des API étendues qui sont TOUTES en train d'être spécifiés et standardisés (donc en train d'être adoptées par les autres navigateurs).
Que Firefox OS n'arrivera pas au niveau de IOS et Android en terme de part de marché, c'est probable, on verra bien, et d'ailleurs, ce n'est pas le but de Mozilla que "d'écraser" la concurrence. Mais de là à dire que c'est un futur système agonisant, je n'y crois pas une seconde, surtout avec les contrats déjà passés avec des opérateurs télécoms, ou les contributions d'autres fabricants/opérateurs…
En tant qu'arrivant, personne me connait, je fourni un patch qui n'est pas dans les regles de l'art, il est rejeté comme un mal propre, et résultat je me casse.
Parce que tu t'y prend mal.
On n'arrive pas sur un projet avec ses gros sabots "tiendez, vla mon patch". C'est comme si tu étais un nouveau commis en cuisine dans un restaurant, que le chef te demande de faire le "gateau au chocolat" star du resto, et que tu en fasses un sans demander la recette (et qu'il y a donc de forte chance que ce ne soit pas le gateau attendu, parce que tu n'aura pas mis la crème qu'il faut, pas utiliser le bon chocolat etc).
Bref, quand on arrive sur un projet, on essaye de se renseigner :
chercher le bon canal de communication pour les contributeurs : forum / IRC / mailing list etc…
se présenter : "bonjour, j'ai vu tel bug, je voudrais contribuer", suivi d'un "quel est la procédure à suivre s'il vous plait"
Et là, il y a de forte chance qu'on te réponde, "va lire la doc ici" (quand elle existe :-) ), ou "faut faire comme-ci comme ça"..
Ensuite tu peux commencer ton patch et le proposer en suivant la procédure, le coding style etc…
Pour toi :
- tu ne refais pas 15 fois ton patch pour que ça soit accepté
- ta contribution est plus vite intégrée : ça flattera ton ego
- tu seras mieux vu et plus vite accepté
- les autres contributions n'en seront que plus facile
N'oublie pas que ce sont des êtres humains. Il ne faut donc pas oublier les rêgles sociales traditionnelles :-)
Si j'ai bien compris, c'est pas l'envie de contribuer qui te manque.
Ne cherche pas à te dire tout seul "qu'est ce que je pourrais bien faire sur ce projet". Tu ne trouveras pas.
Par contre, va voir les développeurs, et demande leur. Commence par leur demander des trucs qui sont faciles à faire. Cela a plusieurs avantages :
cela te fait découvrir l'intérieur du code source
cela fait avancer ENORMEMENT le projet. En effet, les trucs trop simple à corriger, il y en a des tonnes, parce que justement, c'est trop simple et que les développeurs déjà en place sont trop occupés à développer les trucs les plus compliqués.
cela rend le logiciel mieux fini, donc plus agréable pour l'utilisateur.
Par exemple, corriger une faute d'orthographe dans un menu :
- tu apprends où est le code des menus (ou alors comment et où sont stockées les chaînes de traduction)
- tu libères 5 minutes de temps pour les développeurs (et 5 min + 5 min + 5 min +… ça leur en fait du temps de gagner pour dev les trucs les plus durs)
- tu rends le logiciel moins agaçant pour les utilisateurs pour qui cette faute les choquent.
Tu commences donc par ces trucs anodins, et au fur et à mesure des patchs, tu passes à des bug fix ou des fonctionnalités plus compliquées. Et au bout de quelques mois ou année, tu finis par devenir un core-developper, code reviewer etc :-)
Une chose est sûre : tu ne pourras jamais arriver dans un projet et pouvoir proposer une grosse évolution tout de suite. C'est comme tout, il faut apprendre comment il fonctionne, de l'interieur et de l'exterieur. Bref, de la motivation, du courage, et de l'huile de coude.
Pour prendre l'exemple de Mozilla, dans la liste des choses à faire, il y a les bugs marqués "good first bug". Facile à faire en principe pour un nouveau venu. Pioche ! ;-) (tu peux aussi affiner la recherche en fonction des composants ou applis qui correspondraient plus à tes compétences/envies, le projet Mozilla ne se résume pas à Firefox ;-) )
en ce qui me concerne, non, ce n'est pas une question de génération (put** je vais sur mes 40 balais). J'ai vu plusieurs fois des épisodes de la 7ième compagnie (mais ça fait très longtemps), et j'adore la série kaamelott. Comme quoi, on peut aimer les vieux trucs et les trucs récents à la fois :) Et dans les deux oeuvres, il est excellent :-) (faut reconnaitre aussi que les dialogues de kamelott sont écrits aux petits oignons, en particulier donc avec son rôle de césar)
bon par contre, "cordier juge et flic", jamais pu accroché.
[^] # Re: Faillite du desktop ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Le laptop le plus vendu par Amazon en décembre tourne sous Google/Linux. Évalué à 4.
Tout dépend ce qu'on appelle popularité. Les possibilités du XUL sont à l'origine du succès des extensions dans Firefox (et donc en partie du succès de Firefox). Et il y a eu nombre de projets d'applications desktop en XUL.
C'est Mozilla lui-même qui a tué le XUL (pour les applications tierces j'entends) en ne faisant pas de XulRunner (le lanceur d'applications XUL), un vrai produit, c'est à dire, avec un beau packaging, du marketing etc..
Le code de quoi ? Si tu parles de XUL, c'est toujours présent : c'est le langage utilisé pour l'interface de Firefox (et de Thunderbird…). Charge par exemple la page chrome://browser/content dans Firefox et regarde le code source ;-).
Je pense que tu confonds avec l'extension Xul Remote Manager, qui permet d’exécuter des applis web réalisée en XUL, cette possibilité ayant été désactivée par défaut il y a quelques années, à cause de trop nombreuses corrections de sécurité (le XUL, par nature, offrant une plus grande surface d'attaque).
[^] # Re: sans intérêt
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Ubuntu phone OS. Évalué à 1.
j'ai beau relire, je ne vois pas de quoi tu parles. C'est quoi un toolkit JS pour toi ??
[^] # Re: sans intérêt
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Ubuntu phone OS. Évalué à 1.
Ça veut rien dire. Les sites de nos jours sont gourmands.
Je trouve bizarre de parier sur quelque chose dont tu ne connais rien : le matos qui sera utilisé, la pile graphique utilisée, le fonctionnement du moteur de rendu etc..
Je ne comprend pas de quoi tu parles là… Le rendu graphique n'est pas en JS. De plus y a du JIT dans le moteur JS de Firefox…
J'ai l'impression que tu compares des choux et des carottes.
[^] # Re: .
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Ubuntu phone OS. Évalué à 1. Dernière modification le 05 janvier 2013 à 16:15.
Préinstallé, non, va falloir attendre.
En théorie, tu prend un des téléphones supportés, tu flash la rom. Et voilà :-) Bon, ok, j'oublie la phase compilation et tout le bordel (quoique doit y avoir builds sur le ftp). Bref, pour les geeks barbus (ça changera probablement quand il y aura une release stable).
Dans la réalité, actuellement, si tu n'es pas un employé Mozilla, le choix du mobile est restreint : Nexus S, voir Galaxy S2 pour les aventuriers. https://developer.mozilla.org/en-US/docs/Mozilla/Boot_to_Gecko/Firefox_OS_build_prerequisites
Les modèles low cost utilisés en interne chez Mozilla (nom de code Unagi et Otoro) pour le développement sont des téléphones "no-name", sans marque. J'en ai eu un entre les mains, c'est vraiment du no-name, y a aucun nom nulle part et le design est vraiment très basique.
Maintenant, si tu deviens contributeur super actif sur Firefox OS, tu pourras tenter ta chance auprès de Mozilla pour obtenir un de ces téléphones low cost en prêt ;-)
PS: je ne sais pas si, quand Telephonica sortira son téléphone, on pourra en acheter en France, mais je ne pense pas.
# Ce n'est pas nouveau
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Le SDK d'android n'est plus libre !. Évalué à 10.
Arrêtez de propager cette news. Il n'y a rien de nouveau.
La licence de 2009 avait déjà ces conditions.
http://yro.slashdot.org/comments.pl?sid=3358333&cid=42475067
Je viens de comparer, il n'y a vraiment pas grand chose de changé.
à l'ouest, rien de nouveau donc.
[^] # Re: Je cherche à comprendre (no troll spotted)
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche ZevenOS 5, une distribution au goût de BeOS. Évalué à 5.
BeOS à son époque était très en avance sur son temps concernant le multimédia. Tu pouvais lancer plusieurs video/musique/anim3D en même temps sans que le système ne bronche. Et pourtant, je parle d'une époque où les processeurs tournaient à 133 Mhz. Bon, ok, la machine BeBox avait un double processeur mais quand même.
Donc si aujourd'hui on n'arrive pas à faire la même chose avec une distro linux et du matos 10 fois plus puissant…
[^] # Re: .
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Ubuntu phone OS. Évalué à 1.
Comme dans Firefox d'ailleurs, avec ses XPCom :-)
[^] # Re: .
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Ubuntu phone OS. Évalué à 1.
oui pareil, je trouve bizarre qu'une "grosse" boite comme Canonical n'ait pas de partenariats avec des fabricants ou des opérateurs téléphoniques (à moins que ça soit encore secret pour des raisons marketing qu'on ignore ?).
Car si on veut s'assurer d'une bonne entrée sur le marché, vu la forte concurrence, il faudrait quand même pouvoir au moins présenter et fournir un modèle avec le système pré-installé. Sinon ça va rester un marché de geek.
Passer l'étape du "proof of concept", Mozilla avait très rapidement engagé des démarches pour avoir des partenariats avec des opérateurs, pour Firefox OS. Telephonica va ainsi proposer à ses clients brésiliens dans les semaines à venir des téléphones Firefox OS.
[^] # Re: sans intérêt
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Ubuntu phone OS. Évalué à 5.
Rassures-moi, la dernière fois que tu as utilisé Firefox, c'était la version 3.6 non ?
Bon en tout cas, tu aurais pu éviter de troller, on n'est pas vendredi. Les dernières versions de Firefox sont particulièrement économes en mémoire et rapides.
Firefox OS, c'est un noyau linux, un gecko au dessus, et un bureau en HTML5/JS. Et c'est fait pour des téléphones lowcost. Et je peux t'assurer que ça reste véloce sur les prototypes bas de gamme que j'ai eu entre les mains.
Pas sur Firefox OS
Pas sur Firefox OS. Il y a des API pour communiquer entre applis (qui sont chacunes dans leur sandbox), comme les webactivities, un truc similaire à ce qui existe sous android.
Je ne sais pas de quelles données tu parles (j'ai pas encore vu d'applis HTML qui envoi tout ton $HOME quelques part sur le web, le modèle de sécurité des applis web ne le permettant pas).
Conçernant les données de l'appli en elle-même, ou certaines données comme le carnet d'adresse, je dirais que c'est finalement comme n'importe quel appli de téléphone (ios, android etc). Faut juste pas accepter d'installer n'importe quoi, et pas autoriser l'appli à accéder à tes données personnelles.
[^] # Re: Troll de compet
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi GitHub saimal, quelques alternatives. Évalué à 2.
je suis d'accord avec toi
Certes, mais avoir son propre forge sur son propre serveur, et lisible par tous (puisque tu voudrais qu'on puisse consulter sans devoir se logguer), c'est publier son contenu à tous.
Donc rien n'empêche une entreprise de cloner ton dépôt, récupérer le contenu du wiki, des issues etc, et au final, de trouver des références à ton nom (dans les commits…). Et voilà, tu es fiché. Même si ils ne possèdent qu'un pseudo, tu es fiché. À moins d'avoir une "hygiène web" supère strict, on trouve toujours des infos sur le web permettant de faire un rapprochement entre un pseudo et un nom. Et un mail. Voire plus.
Par exemple, là, tu publie sous un pseudo, SKy. Mais tu as aussi indiqué ton site web dans ton profil. Et sur ton site web, on y apprend plein de chose, ton nom, ton prénom, ton adresse postale etc… Bref, même si linuxfr détruit bien ton profil, des crawlers (moteur de recherches, annuaires…), eux, auront déjà fait depuis longtemps le rapprochement entre le pseudo "SKy" et ton identité.
À partir du moment où tu publie quelque chose sur internet, tu ne peux plus contrôler ces données. Tu auras beau éteindre ton serveur, l'atomiser, tes données publiques auront été dupliquées quelques parts. Forcément. Il faut se mettre cela dans le crâne. Il n'y a pas besoin de publier des données sur le site d'un "méchant" pour que celui-ci en sache plus que tu en veux sur toi.
Que ton nom ou ton pseudo soit publié sur github ou sur ta forge perso, ça ne change rien du tout. Il est publié. point.
[^] # Re: Troll de compet
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi GitHub saimal, quelques alternatives. Évalué à 2.
je ne vois pas ce que tu entends par données personnelles. Si tu parles du code/issues/wiki, dans ce cas c'est contradictoire avec le fait que tu veuille rendre public tes données dans gitlab. Si tu parles du profil utilisateur, je ne vois pas vraiment ce qu'il y a comme données personnelles. Dans Github, je n'ai pas de données personnelles dans mon profil, à part mon mail et mon nom/prénom. Mais tu peux très bien fournir un pseudo et une adresse mail anonymisée…
[^] # Re: Troll de compet
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi GitHub saimal, quelques alternatives. Évalué à 4.
comme je l'ai dit, à cause de leur infrastructure, il est fort possible que l'architecture de leur application ne soit pas évident à installer ça sur son petit serveur chez soi.
Par contre, si tu veux un Github like chez toi, regarde du coté de Gitlab. C'est une copie quasi conforme.
même avec github, tes données sont chez toi. Ton dépôt git est sur ta machine. Tu peux aussi avoir le depot git du wiki sur ta machine. Et tu peux rapatrier les issues via des api..
# Troll de compet
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi GitHub saimal, quelques alternatives. Évalué à 10.
Ce qui est totalement faux. La possibilité de récupérer ses données dépends seulement des fonctionnalités du service, pas du fait que le code du site soit ouvert ou fermé.
La boite qui offre un service reposant à 100% sur du libre ne va pas pour autant ouvrir ses bases de données ou son système de fichier à tout vent. L'export de tes données va donc dépendre des API qu'elle propose, qu'elle ouvre.
Imagine que demain j'ouvre une plateforme wiki basé sur Dokuwiki, je peux très bien ne pas vouloir ouvrir l'API XMLRPC de dokuwiki pour diverses raisons : sécurité, "emprisonner" l'utilisateur, ou encore faire payer l’accès à cet API.
Qu'est ce que cela va changer pour l'utilisateur, par rapport à un service dont le code source est proprio ? Rien. Absolument rien.
Ça fait plusieurs fois que je lis sur linuxfr cet argument "contre" pour les services reposant sur des logiciels proprio. ARRETEZ DE L'UTILISER, c'est totalement bidon, du coup, ça décrédibilise le reste de votre argumentaire.
Oui, mais ça a un coût. Il faut donc payer quelque part (infrastructure, réseau…). Que le soft soit ouvert ou fermé ne change pas grand chose au final. Si on veut de la qualité de service, il faut payer, et c'est tout à fait normal. Maintenant, à qualité égale, on peut effectivement choisir de mettre ses sous dans la boite qui utilise des logiciels libres.
Ou pas envie et/ou pas le temps de gérer un service "interne".
En même temps, ça ferait une belle jambe à tout ceux qui utilisent github, d'avoir le coeur de l'application.
Un paramètre semble être oublié dans l'argumentaire : github héberge des centaines de milliers (millions?) de projets. Donc le coeur de l'appli est architecturé pour une infrastructure spécifique, à forte charge. Ça doit être certainement la plaie à installer et à configurer, parce que très spécifique. Très franchement, j'en voudrais pas pour l'installer sur un intranet en entreprise par exemple, ce serait prendre un marteau pour écraser une mouche.
Si on veut un outil similaire, autant prendre un des outils que tu as cité, ça sera certainement plus simple à installer, et certainement plus adapté à des petites structures. puisque si on veut du github chez soit, en entreprise, c'est qu'à priori, on a une petite infrastructure réservée au développement par rapport à chez github. Je doute qu'il existe une boite qui ait des centaines de milliers de projets à gérer comme sur Github.
Conclusion : tout le monde s'en fout que le coeur de Github soit proprio. sauf les aigris, les intégristes et les empêcheurs de tourner en rond.
Merci sinon pour ta liste d'alternatives. Mais sans troll, ça aurait été mieux.
# Ce n'est pas arrété finalement
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal C'est pas sorcier a besoin de vous. Évalué à 2.
D'après cette info, l’émission n'est pas arrêtée, en tout cas pas en 2013. Par contre France 3 demande à ce qu'elle coute moins cher.
[^] # Re: C'est pas grave surtout si
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Nouveau rootkit – Ils l'avaient prédit : "la fin du monde arrive" !. Évalué à 2.
Ouai enfin, ce n'est pas qu'une "best practice" pour les moteurs de recherche. C'est surtout pour n'importe qui le contenu !
Parce que bon, être interrompu dans sa lecture tout les 4 mots par des URLS dans un texte, c'est plutôt pénible.
[^] # Re: Y a pas q'un pb d'interface chaise / clavier
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La France attaquée par les chinois du F.B.I. Évalué à 2.
je confirme que certaines applications (de la défense tout du moins), même des cms etc, ont ce genre de clé d’accès. Mais peut-être pas toutes..
[^] # Re: Dispersion
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Un nouveau lecteur Flash libre : Shumway. Évalué à 5.
Le nouveau "plugin" en question est entièrement en Javascript, et repose sur HTML5 (balise video pour les videos par exemple, et probablement canvas pour le reste).
Il n'utilise donc pas les mêmes technos que les autres (C/C++), il y a beaucoup moins de chance que ça crash (null pointer etc, ça n'existe pas en JS :-).
Coté perf, c'est à voir. Ils doivent certainement faire usage des Arrays spécialisés sur les entiers/flottants etc pour les manipulations de matrices ou de bytecode (ce qui est TRÈS performant par rapport à un Array normal).
[^] # Re: Les machines de votes c'est le mal
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La France a toujours un train de retard. Évalué à 3.
ah non pour moi, une machine à voter, c'est une belle boite noire qui fait des choses que je (ou n'importe quel quidam) ne comprends pas. Elle a beau me sortir un ticket machin chose, au final, pour être sûr qu'elle a bien compté, il faudrait recompter "à la main".
Résultat : une machine à voter ne sert à rien, sauf à remplir les poches des vendeurs de machines à voter.
[^] # Re: Pourquoi pas
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal SDK pour Ubuntu : faut-il déjà préparer le goudron et les plumes ?. Évalué à 2.
comment ça pour Firefox OS ??
C'est pas comme ci Firefox OS avait un environnement très spécifique, des API exotiques, son propre langage, son propre environnement graphique ou que sais-je encore. Non. Firefox OS, c'est un OS reposant sur des standards (ou en passe de l'être).
Une appli pour Firefox OS, c'est du HTML/JS/CSS, avec des API étendues qui sont TOUTES en train d'être spécifiés et standardisés (donc en train d'être adoptées par les autres navigateurs).
Que Firefox OS n'arrivera pas au niveau de IOS et Android en terme de part de marché, c'est probable, on verra bien, et d'ailleurs, ce n'est pas le but de Mozilla que "d'écraser" la concurrence. Mais de là à dire que c'est un futur système agonisant, je n'y crois pas une seconde, surtout avec les contrats déjà passés avec des opérateurs télécoms, ou les contributions d'autres fabricants/opérateurs…
[^] # Re: temps de pénétration
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi je n’arrive pas à contribuer au logiciel libre.. Évalué à 7.
Parce que tu t'y prend mal.
On n'arrive pas sur un projet avec ses gros sabots "tiendez, vla mon patch". C'est comme si tu étais un nouveau commis en cuisine dans un restaurant, que le chef te demande de faire le "gateau au chocolat" star du resto, et que tu en fasses un sans demander la recette (et qu'il y a donc de forte chance que ce ne soit pas le gateau attendu, parce que tu n'aura pas mis la crème qu'il faut, pas utiliser le bon chocolat etc).
Bref, quand on arrive sur un projet, on essaye de se renseigner :
Et là, il y a de forte chance qu'on te réponde, "va lire la doc ici" (quand elle existe :-) ), ou "faut faire comme-ci comme ça"..
Ensuite tu peux commencer ton patch et le proposer en suivant la procédure, le coding style etc…
Pour toi :
- tu ne refais pas 15 fois ton patch pour que ça soit accepté
- ta contribution est plus vite intégrée : ça flattera ton ego
- tu seras mieux vu et plus vite accepté
- les autres contributions n'en seront que plus facile
N'oublie pas que ce sont des êtres humains. Il ne faut donc pas oublier les rêgles sociales traditionnelles :-)
[^] # Re: (R)évolutions?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal OSEF. Évalué à 8.
sans oublier :
# Exemple avec Mozilla
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi je n’arrive pas à contribuer au logiciel libre.. Évalué à 7.
Si j'ai bien compris, c'est pas l'envie de contribuer qui te manque.
Ne cherche pas à te dire tout seul "qu'est ce que je pourrais bien faire sur ce projet". Tu ne trouveras pas.
Par contre, va voir les développeurs, et demande leur. Commence par leur demander des trucs qui sont faciles à faire. Cela a plusieurs avantages :
Par exemple, corriger une faute d'orthographe dans un menu :
- tu apprends où est le code des menus (ou alors comment et où sont stockées les chaînes de traduction)
- tu libères 5 minutes de temps pour les développeurs (et 5 min + 5 min + 5 min +… ça leur en fait du temps de gagner pour dev les trucs les plus durs)
- tu rends le logiciel moins agaçant pour les utilisateurs pour qui cette faute les choquent.
Tu commences donc par ces trucs anodins, et au fur et à mesure des patchs, tu passes à des bug fix ou des fonctionnalités plus compliquées. Et au bout de quelques mois ou année, tu finis par devenir un core-developper, code reviewer etc :-)
Une chose est sûre : tu ne pourras jamais arriver dans un projet et pouvoir proposer une grosse évolution tout de suite. C'est comme tout, il faut apprendre comment il fonctionne, de l'interieur et de l'exterieur. Bref, de la motivation, du courage, et de l'huile de coude.
Pour prendre l'exemple de Mozilla, dans la liste des choses à faire, il y a les bugs marqués "good first bug". Facile à faire en principe pour un nouveau venu. Pioche ! ;-) (tu peux aussi affiner la recherche en fonction des composants ou applis qui correspondraient plus à tes compétences/envies, le projet Mozilla ne se résume pas à Firefox ;-) )
[^] # Re: Pas un simple logiciel de lecture
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Lisez en liberté avec TeaBook Open Reader !. Évalué à 5.
Je te recommande d'aller lire la spec de epub3 par exemple, pour te rendre combien cette spec est complexe et contenant de nombreux trucs mal foutu, voir le blog de Daniel Glazman à ce sujet.
[^] # Re: BronsoNisé...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal PierreMondy Bronsorisé. Évalué à 1.
en ce qui me concerne, non, ce n'est pas une question de génération (put** je vais sur mes 40 balais). J'ai vu plusieurs fois des épisodes de la 7ième compagnie (mais ça fait très longtemps), et j'adore la série kaamelott. Comme quoi, on peut aimer les vieux trucs et les trucs récents à la fois :) Et dans les deux oeuvres, il est excellent :-) (faut reconnaitre aussi que les dialogues de kamelott sont écrits aux petits oignons, en particulier donc avec son rôle de césar)
bon par contre, "cordier juge et flic", jamais pu accroché.
# linuxfr sur typematrix
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Tester un clavier Typematrix 2030 USB Dvorak gratuitement. Évalué à 2.
Je viens de me balader sur le site de typematrix. Et que vois-je, dans la section "Dans les nouvelles" d'une page ? Un lien vers un article de ploum sur linuxfr :-)