CB + code ? Mes parents me l'ont fait souvent dans ma jeunesse
sans difficulté ce coup là.
C'est quand même curieux que tu ne soit pas à l'aise de te trimballer avec 50€ mais que ça te paraisse normal de filer une carte capable de retirer beaucoup plus à un gamin qui ferait sans doute pas le malin face à un gamin plus grand que lui et mal intentionné. Une fois qu'il a la carte et le code, y a quand même pas grand chose qui va lui interdire de dépenser plus que le prix de ta baguette. (genre, si il est organisé, il pourrait juste prendre une crypto-monnaie quelconque).
Mais au delà de la surveillance, ça laisse quand même vachement trop de pouvoir à l'état.
Si demain au lieu d'utiliser l'état d'urgence pour interdire de séjour les gens sur des manifs, l'état bloque les dépenses de certaines personnes, ça va être vachement handicapant. Paypal a bloqué Wikileaks, par exemple: https://www.wired.com/2010/12/paypal-wikileaks/ (le même paypal fondé par un mec qui se réclame pour la liberté d'expression, mais qui finance des procès contre un site web (Gawker) qui a publié des trucs qu'il voulait garder secret (à savoir son orientation sexuel))
Si après demain, on se retrouve à avoir un gouvernement plus proche de Vichy qu'on voudrait, on serait pas non plus super jouasse de filer autant de pouvoir aux banques et aux organisations gouvernementales.
Pas vraiment, y a des boites qui se chargent de ça. Une fois que tu as trouvé un pays ou il faut juste faire un peu de papier pour faire une boite, tu as juste à faire un truc qui soit long à démêler et ou tu peux automatiser les transferts de fonds.
IE, dépenser du pognon et le faire passer partout, c'est automatisé et direct, car il y a une volontée de faire circuler l'argent (ce qui est la base d'une économie qui marche d'un point de vue théorique, si je me souviens bien, donc on cherche à réduire les frictions à ce niveau).
Auditer par contre, c'est souvent manuel et long, vu qu'il faut chaque fois obtenir l'info dans un format peut être différent, sans doute sur papier (surtout si tu veux ralentir l'analyse, tu fait le minimum), rentrer ça dans une machine (avec tout les risques de typo), examiner tout et recommencer à l'étape suivante quand tu as vu ou l'argent est parti.
Une fois que quelqu'un a monté ses 200 sociétés écrans et qu'elles s'appartiennent toute les unes aux autres, ce quelqu'un a juste à "louer" les sociétés pour masquer les flux. Si le coup d'entretien et de création est minuscule, ça se rentabilise assez vite.
C'est pas tant le fait d'être basé sur fuse que le fait d'être en réseau (et potentiellement distribué), vu que plein de petit fichier, ça implique plus de lookups de meta données qu'un gros fichier à taille équivalente.
Ceph souffre aussi du même souci, et c'est pas basé sur fuse dans mon souvenir.
C'est vrai mais la probabilité que GitHub change est faible
C'est amusant, parce que justement, Github a changé. Par exemple, ils ont changés les prix. J'ai entendu parlé de client avec pleins de repo publiques et quelques dépôts privés, et dont les tarifs passeraient de 50 par mois, vu que ça compte maintenant par personne au lieu de payer par dépot.
Github a aussi changé car ils étaient en train de s'endormir (avant d'avoir une lettre de gens pour dire "votre issue tracker est pourri", on peut pas dire que grand monde faisait des changements sur ce bout du logiciel)
Ensuite, pour le moment, les changements sont positifs (à mon sens) pour la majorité, mais je pense que c'est pas ce que tout le monde croit. Par exemple, il y a tout une frange des utilisateurs qui semble s'opposer aux positions actuelles de Github (http://dancerscode.com/blog/why-the-open-code-of-conduct-isnt-for-me/ et http://garrett.damore.org/2016/02/leaving-github.html pour 2 exemples). D'un coté, je me dit que c'est des opinions minoritaires, mais de l'autre, c'est souvent une source de discussions des plus chaudes et donc peut être que c'est moins minoritaires que je le crois.
Et je ne suis pas super confiant dans l'avenir de Github, car d'une part, le nombre de projet libre ne va faire qu'augmenter, donc les coûts de github aussi, mais je ne voit pas forcément le nombre de clients grimper aussi vite (ne serais ce que parce les startups semblent avoir moins de fond qu'avant, ce qui me rappelle la première bulle).
Je suppose que les changements de tarif sont aussi la pour ça, retirer un chouia plus de pognon des boites qui utilisent github maintenant qu'ils estiment être en position de force, afin d'absorber la crise qui vient.
Donc j'attendrais perso de voir ce que ça va donner d'ici 2 ans.
Tu ne parles pas non plus du principal souci, à savoir les divers facteurs humains, en estimant que c'est évident de décider qu'un projet est "over engineeré". Les gens sont rarement d'accord sur le sujet et y a plusieurs raisons pour ça.
Par exemple, les gens vont avoir tendance à sur estimer leur capacité (effet dunning kruger), et donc à voir de l'over enginering la ou il y a juste de leur part un manque de compréhension.
Ou voir du coté des choses qu'on a à peine commencé à explorer, comme l'effet Ikea (https://en.wikipedia.org/wiki/IKEA_effect), et comment les gens vont préférer ce qu'ils ont montés et dans lequel ils ont investis du temps.
De surcroit, tu ne parles pas du fait que tout le monde n'a pas forcément la même idée de ce qui doit être fait, en partie parce que les spécifications sont souvent flous, et changeantes, et que certaines personnes vont avoir le sentiment qu'on va vouloir faire d'autres choses plus tard et qu'il faut prendre ça en compte
Exemple, je déploie un site statique. Je fait un script de 5 lignes qui buildent tout. Parfait. Ensuite, on veut refaire ça. Du coup, mon script commence à avoir des paramétres, et je fait un role ansible pour déployer. Et puis, on commence à utiliser parfois des submodules, et parfois pas. Etc. Résultat, maintenant, mon script fait 243 lignes.
Pour le cas de base, il est clairement trop complexe. Pour tout les cas de bases des autres sites, il est pas encore suffisant, vu que les demandes ont évolués, et que je me retrouve à refactoriser les demandes dans 1 script.
Et pourtant, je pense pas que ça soit de l'over engineering, par rapport à l'alternative d'avoir 15 scripts presque semblables, voir pire, un logiciel pour produire les 15 scripts simples.
Et tu dit qu'un logiciel compliqué ne va pas avoir de contributions, mais c'est non évident. Au contraire, si le logiciel ne réponds pas aux besoins, il ne va pas attirer des gens pour s'en occuper.
Prends par exemple apache. Le système de module le rends plus complexe qu'un logiciel sans le même système. Mais pourtant, c'est ce qui permet d'avoir des contributions externes.
Donc non, l'over engineering, c'est comme la sécurité, c'est pas un état binaire, ça dépend des besoins qui doivent être précisés.
mais je ne vois pas en quoi du télétravail nécessite un bureau,
à part pour le confort donc autre chose que "clapier à lapin"
ça fait parti en général des recommandations des gens qui font du travail à la maison depuis longtemps (car je distingue "télétravail" de "travail à domicile"). Les raisons sont de se donner un rythme et un cadre (ie, j'arrete de bosser quand je suis en dehors du bureau), et de signaler à la famille qu'on est pas dispo ("non, maman travaille quand elle est dans la pièce avec le bureau, alors tu ne viens pas la déranger").
Et bien sur, les raisons classiques comme "avoir une vrai chaise de boulot", "poser un écran de taille suffisante", etc.
Mais en effet, si tu fait du travail à la maison de façon occasionnel et le reste chez des clients, au bureau, d'une bibliothèque, des conférences ou dans un bus, tu as pas forcément besoin d'investir dans tout ça. Et ça dépend aussi en effet du travail que tu as.
Mais aprés avoir vu des chambres en cité U de 9 m², je qualifierais pas non plus un 30 m² de clapier (bien que je trouverais ça sans doute un peu petit à mon gout)
15 ans, pas vraiment. j'ai du en faire y a moins de 10 ans.
Ensuite, que la transparence réseau de xorg soit 1) limité (pas de passage du son, pas de montage des périphériques) 2) insécure (kough clear text kough) et donc désactivé par défaut, c'est autre chose.
j'imagine que quand les gens parlent de "transparence réseau", ils parlent de ssh -X/-Y la plupart du temps, ce qui reste à des années lumières de ce que rdesktop (ou spice) peuvent faire (mais toujours mieux que vnc). Et qui est globalement pas toujours fonctionnel du au fait que pas mal de services ont besoin d'une session dbus, ce qui prouve bien qu'en effet, les gens utilisent pas vraiment, ou alors, dans des cas ultra spécifiques.
Bien que les performances passés n'augurent pas des performances futures, je pense que dans ton cas, tu es l'exception qui éprouve la règle.
j'ai comme un doute que wayland arrive par defaut sur RHEL
avant 2 ans.
Je ne vois pas un changement de taille comme wayland se faire dans une version stable, en effet (ça fait parti des promesses que fait RH sur la compatibilités).
Donc comme l'a fait remarquer Renault, ça va dépendre de la sortie de la prochaine RHEL, et ça va surtout dépendre des constructeurs (ie, si nvidia dit "pour les nouvelles cartes, on file que des pilotes compatible avec l'archi de wayland", alors les clients de RHEL Desktop (genre les studios qui font de la 3d, les bureaux scientifiques, etc) vont sans doute demander, et RH va s'adapter et proposer ça dans une version de RHEL.
La transparence reseau ca va etre fondamental si vous voulez
avoir wayland sur RHEL car vos clients c'est pas le desktop et
sans transparence reseau ca va etre sacrement difficile a
faire avaler la pillule.
Pour un mec incapable de faire une recherche et de lire une page de wiki pour savoir à qui tu parles, je te trouve bien péremptoire sur les demandes des clients des boites ou tu ne bosses pas et ou visiblement, tu n'as pas des masses d'info.
Alors non, je ne crois pas que Ubuntu en bantou veuille dire "ne sais pas configurer debian". C'est un élitisme à 2 balles qui vaut bien l'élitisme anti-mandrake a 2 francs d'il y a 15 ans.
Et sinon, oui, Mint est pourri niveau gestion de la sécurité.
J'ai ouvert un bug de secu en 2012 sur Mint, j'ai eu 0 réponse ou ack. Un collègue a fini par me dire "tiens, prends ce CVE" que j'ai rajouté, mais bon.
La gestion de l'attaque sur leur site web était aussi un peu risible. Le souci n'est pas de s'être fait attaquer, mais fait attaquer 2 fois de suite. Ça arrive de pas savoir, et je sais que sysadmin, c'est un métier qu'on peut improviser jusqu'à un certain point, mais ça commence à faire beaucoup.
Si on rajoute le fait que globalement, Mint ne fournit aucun support de sécurité sur ses paquets, on commence en effet à avoir un chouia de trucs qui font tiquer quand on regarde la sécurité.
Et ça, c'est juste les trucs qu'on voit. Y a aucune transparence sur le processus de build ou de release engineering, donc tu sais pas comment, c'est fait, comment la clé gpg est stocké, etc, etc.
Le même je-m-en-foutisme est à l'oeuvre pour la gestion de ce qui est distribuable ou pas (brevets, proprio, etc), ou juste de leur formulaire de donation (qui pendant longtemps à été la cible de spammers qui donne 1 euro pour avoir un lien comme donateur)
1) Est-ce que cette sécurité est bien fonctionnelle ?
Je n'ai pas testé, mais je suppose que oui (modulo les bugs). En fait, c'est pas un niveau de confiance à la qubes-os, c'est bien que l'appli n'a pas le droit.
En d'autres mots, qu'est-ce qui empêche une application
malveillante de reproduire fidèlement et de manière
indiscernable mon navigateur web de telle sort que je lui
fasse confiance pour introduire des informations à protéger ?
c'est pas vraiment dans le scope. Le changement apporté par Wayland, c'est pas de te protéger d'une appli qui te dit "entrer votre mot de passe", c'est de te protéger de celle qui ne te le dit pas mais qui espionne le clavier. Tu as l'air de confondre la sécurité que xdg-app/snap veut apporter avec celle que wayland vut apporter.
2) Est-ce que cela est suffisant ?
Vu que ta question 1 a l'air d'être sur une mauvaise prémisse, je suis pas sur de savoir répondre.
3) Pour reprendre votre paraphrase et afin de réexpliquer mon
précédent commentaire, n'est-ce pas vouloir boucher le trou
dans la coque d'un bateau qui coule ?
Non.
tw, qu'est-ce qui nous empêche aujourd'hui de lancer un
serveur X par application et d'y ajouter un arbitre pour les
interactions inter-applications (touches globales, copie
d'écran, drag&drop,etc) ?
Grosso modo les ressources. C'est le fonctionnement de qubes os, vu que tu lances 1 VM par appli, avec chacune son serveur X. Mais la question devient "pourquoi le monde entier n'utilise pas qubes os comme distro"
Oui, mais ça reste un chouia plus compliqué à mettre en oeuvre que juste envoyer un paquet snap d'un nounours sur l'Appstore Ubuntu.
ie, je suis sur que n'importe qui ici pourrait le faire avec un peu d'entrainement, alors que je suis sur que la majorité des gens ici ne sauraient même pas ou commencer pour exploiter un browser avec la tonne de protection qu'on trouve de nos jours.
L'idée, c'est pas de sandboxer le serveur graphique, mais de ne donner à chaque client graphique accés que à ce qu'il a besoin.
Si jamais quelque chose (au hsard, un attaquant) arrive à compromettre evince, j'ai pas envie que evince soit capable d'écouter ce qui passe dans X, comme le mot de passe de ma clé gpg.
Ensuite, il y a d'autres vecteurs, mais dire "y a d'autres trucs donc ce trou n'a pas besoin d'être fermé", c'est un bon moyen de ne jamais rien faire, sauf à tout faire d'un coup, ce qui n'arrive jamais. La sécurité s'améliore par petites touches, et c'est une touche.
Que les frappes au clavier lorsqu'on utilise X.org ne soient pas > hyper faciles à enregistrer.
Wayland devrait s'occuper de ça.
De pouvoir mettre un disque dur externe en veille lors de son
démontage (c'est légèrement important pour beaucoup de modèles,
histoire de pouvoir les utiliser sur une longue durée), sans
devoir lancer un script en tant que root (Windows fait ça depuis
16 ans en deux clics)
Je n'ai jamais pensé à ça, mais si un script peut le faire, alors ça peut se faire intégré sans trop de souci (ie sans revoir toute l'archi, contrairement au point 1 et 2 qui sont en gros qu'un seul changement d'architecture)
Je ne peux pas répondre pour les windows récent, mais de mon temps, écrire un sniffeur de clavier était trivial, vu que j'ai fait ça à la fac.
IE, tu avais une api pour avoir les événements clavier, et à partir, suffit d'écrire dans un fichier et basta.
Ensuite, on parle dans un contexte d'application non vérifié par la distribution que n'importe qui peut envoyer (ie, l'appstore de Ubuntu). En pratique, le problème se pose vachement moins avec les applications libres et les dépôts qu'on a maintenant.
Mais ça se poseras dans un futur plus décentralisé permis par xdg-app et/ou les snaps.
Non, les soucis de X, c'est aussi qu'il y a pas de séparation du tout entre les applis. IE, tout les trucs que tu tapes au clavier, ça peut arriver sur tout les clients. Pareil pour les mouvement de souris.
Le souci n'est pas de forker, mais de croire que parce qu'un truc est un fork, alors c'est meilleur, et de croire que tout les forks vont faire mieux que l'original.
Il y a tout un tas de facteurs à prendre en compte pour voir si c'est opportun ou pas, et si j'osais faire un début d’hypothèse, le facteur le plus important, c'est de voir ou les développeurs de longue date du projet vont. Dans le cas d'Openoffice et de Mandrake, les forks sont ceux qui ont globalement survécus. Dans le cadre de certains forks de gnome, kde ou debian, c'est globalement pas le cas (Ubuntu étant une des exceptions à mon hypothèse, tout comme Libressl).
En même temps, c'est dans la version gnu de rm depuis un bout de temps, je suppose que ça a fini par être vu comme une bonne chose avec le recul de l'activation de l'option.
Oui enfin, on peut aussi dire le contraire avec mate, ou le fork de gnome à l'époque de gnome 2, ou trinity, qui sont globalement comme apache openoffice, pas mort mais avec un niveau d'activité pas non plus énorme.
Et du coup, c'est quoi la motivation pour ne pas trouver un taf qui soit moins relou ?
Parce que bon, le taf, on y passe pas mal de temps, donc ça me parait important que le truc soit pas trop chiant. Est ce que ça paye tellement bien, le travail en lui même est intéressant, ou d'autres raisons ?
Les fondations comme Apache ne vont aller que dans des cas précis. Comme tu dis, il y a des règles, notamment d'avoir assez de contributeurs (de boites différentes aussi), ce qui rends ça impropre pour la majorité des projets (mais pas forcément pour la majorité des projets qui ont un impact).
Et oui, y a des alternatives, mais pour le moment, si les gens n'utilisent pas, ça ne va pas influer vraiment sur la décentralisation.
[^] # Re: FUD
Posté par Misc (site web personnel) . En réponse au journal La Suède abandonne les paiements en espèce — ne devrait-on pas s'en inquiéter?. Évalué à 7.
C'est quand même curieux que tu ne soit pas à l'aise de te trimballer avec 50€ mais que ça te paraisse normal de filer une carte capable de retirer beaucoup plus à un gamin qui ferait sans doute pas le malin face à un gamin plus grand que lui et mal intentionné. Une fois qu'il a la carte et le code, y a quand même pas grand chose qui va lui interdire de dépenser plus que le prix de ta baguette. (genre, si il est organisé, il pourrait juste prendre une crypto-monnaie quelconque).
Mais au delà de la surveillance, ça laisse quand même vachement trop de pouvoir à l'état.
Si demain au lieu d'utiliser l'état d'urgence pour interdire de séjour les gens sur des manifs, l'état bloque les dépenses de certaines personnes, ça va être vachement handicapant. Paypal a bloqué Wikileaks, par exemple: https://www.wired.com/2010/12/paypal-wikileaks/ (le même paypal fondé par un mec qui se réclame pour la liberté d'expression, mais qui finance des procès contre un site web (Gawker) qui a publié des trucs qu'il voulait garder secret (à savoir son orientation sexuel))
Si après demain, on se retrouve à avoir un gouvernement plus proche de Vichy qu'on voudrait, on serait pas non plus super jouasse de filer autant de pouvoir aux banques et aux organisations gouvernementales.
[^] # Re: Et les Panama Papers, alors ?!?
Posté par Misc (site web personnel) . En réponse au journal La Suède abandonne les paiements en espèce — ne devrait-on pas s'en inquiéter?. Évalué à 3.
Pas vraiment, y a des boites qui se chargent de ça. Une fois que tu as trouvé un pays ou il faut juste faire un peu de papier pour faire une boite, tu as juste à faire un truc qui soit long à démêler et ou tu peux automatiser les transferts de fonds.
IE, dépenser du pognon et le faire passer partout, c'est automatisé et direct, car il y a une volontée de faire circuler l'argent (ce qui est la base d'une économie qui marche d'un point de vue théorique, si je me souviens bien, donc on cherche à réduire les frictions à ce niveau).
Auditer par contre, c'est souvent manuel et long, vu qu'il faut chaque fois obtenir l'info dans un format peut être différent, sans doute sur papier (surtout si tu veux ralentir l'analyse, tu fait le minimum), rentrer ça dans une machine (avec tout les risques de typo), examiner tout et recommencer à l'étape suivante quand tu as vu ou l'argent est parti.
Une fois que quelqu'un a monté ses 200 sociétés écrans et qu'elles s'appartiennent toute les unes aux autres, ce quelqu'un a juste à "louer" les sociétés pour masquer les flux. Si le coup d'entretien et de création est minuscule, ça se rentabilise assez vite.
[^] # Re: Et les performances ?
Posté par Misc (site web personnel) . En réponse au journal Monter un cluster mémoire avec un raspberry pi. Évalué à 2.
C'est pas tant le fait d'être basé sur fuse que le fait d'être en réseau (et potentiellement distribué), vu que plein de petit fichier, ça implique plus de lookups de meta données qu'un gros fichier à taille équivalente.
Ceph souffre aussi du même souci, et c'est pas basé sur fuse dans mon souvenir.
[^] # Re: GitHub
Posté par Misc (site web personnel) . En réponse au journal Migration d'un projet de SourceForge vers TuxFamily. Évalué à 6.
C'est amusant, parce que justement, Github a changé. Par exemple, ils ont changés les prix. J'ai entendu parlé de client avec pleins de repo publiques et quelques dépôts privés, et dont les tarifs passeraient de 50
par mois, vu que ça compte maintenant par personne au lieu de payer par dépot.
Github a aussi changé car ils étaient en train de s'endormir (avant d'avoir une lettre de gens pour dire "votre issue tracker est pourri", on peut pas dire que grand monde faisait des changements sur ce bout du logiciel)
Ensuite, pour le moment, les changements sont positifs (à mon sens) pour la majorité, mais je pense que c'est pas ce que tout le monde croit. Par exemple, il y a tout une frange des utilisateurs qui semble s'opposer aux positions actuelles de Github (http://dancerscode.com/blog/why-the-open-code-of-conduct-isnt-for-me/ et http://garrett.damore.org/2016/02/leaving-github.html pour 2 exemples). D'un coté, je me dit que c'est des opinions minoritaires, mais de l'autre, c'est souvent une source de discussions des plus chaudes et donc peut être que c'est moins minoritaires que je le crois.
Et je ne suis pas super confiant dans l'avenir de Github, car d'une part, le nombre de projet libre ne va faire qu'augmenter, donc les coûts de github aussi, mais je ne voit pas forcément le nombre de clients grimper aussi vite (ne serais ce que parce les startups semblent avoir moins de fond qu'avant, ce qui me rappelle la première bulle).
Je suppose que les changements de tarif sont aussi la pour ça, retirer un chouia plus de pognon des boites qui utilisent github maintenant qu'ils estiment être en position de force, afin d'absorber la crise qui vient.
Donc j'attendrais perso de voir ce que ça va donner d'ici 2 ans.
# Un chouia simpliste ?
Posté par Misc (site web personnel) . En réponse au journal Lutter contre l'overengineering. Évalué à 10.
Tu ne parles pas non plus du principal souci, à savoir les divers facteurs humains, en estimant que c'est évident de décider qu'un projet est "over engineeré". Les gens sont rarement d'accord sur le sujet et y a plusieurs raisons pour ça.
Par exemple, les gens vont avoir tendance à sur estimer leur capacité (effet dunning kruger), et donc à voir de l'over enginering la ou il y a juste de leur part un manque de compréhension.
Ou voir du coté des choses qu'on a à peine commencé à explorer, comme l'effet Ikea (https://en.wikipedia.org/wiki/IKEA_effect), et comment les gens vont préférer ce qu'ils ont montés et dans lequel ils ont investis du temps.
De surcroit, tu ne parles pas du fait que tout le monde n'a pas forcément la même idée de ce qui doit être fait, en partie parce que les spécifications sont souvent flous, et changeantes, et que certaines personnes vont avoir le sentiment qu'on va vouloir faire d'autres choses plus tard et qu'il faut prendre ça en compte
Exemple, je déploie un site statique. Je fait un script de 5 lignes qui buildent tout. Parfait. Ensuite, on veut refaire ça. Du coup, mon script commence à avoir des paramétres, et je fait un role ansible pour déployer. Et puis, on commence à utiliser parfois des submodules, et parfois pas. Etc. Résultat, maintenant, mon script fait 243 lignes.
Pour le cas de base, il est clairement trop complexe. Pour tout les cas de bases des autres sites, il est pas encore suffisant, vu que les demandes ont évolués, et que je me retrouve à refactoriser les demandes dans 1 script.
Et pourtant, je pense pas que ça soit de l'over engineering, par rapport à l'alternative d'avoir 15 scripts presque semblables, voir pire, un logiciel pour produire les 15 scripts simples.
Et tu dit qu'un logiciel compliqué ne va pas avoir de contributions, mais c'est non évident. Au contraire, si le logiciel ne réponds pas aux besoins, il ne va pas attirer des gens pour s'en occuper.
Prends par exemple apache. Le système de module le rends plus complexe qu'un logiciel sans le même système. Mais pourtant, c'est ce qui permet d'avoir des contributions externes.
Donc non, l'over engineering, c'est comme la sécurité, c'est pas un état binaire, ça dépend des besoins qui doivent être précisés.
[^] # Re: HS folie des grandeurs
Posté par Misc (site web personnel) . En réponse au journal Quelqu'un intéressé par du coworking sur Paris, France?. Évalué à 4.
ça fait parti en général des recommandations des gens qui font du travail à la maison depuis longtemps (car je distingue "télétravail" de "travail à domicile"). Les raisons sont de se donner un rythme et un cadre (ie, j'arrete de bosser quand je suis en dehors du bureau), et de signaler à la famille qu'on est pas dispo ("non, maman travaille quand elle est dans la pièce avec le bureau, alors tu ne viens pas la déranger").
Et bien sur, les raisons classiques comme "avoir une vrai chaise de boulot", "poser un écran de taille suffisante", etc.
Mais en effet, si tu fait du travail à la maison de façon occasionnel et le reste chez des clients, au bureau, d'une bibliothèque, des conférences ou dans un bus, tu as pas forcément besoin d'investir dans tout ça. Et ça dépend aussi en effet du travail que tu as.
[^] # Re: Loyer
Posté par Misc (site web personnel) . En réponse au journal Quelqu'un intéressé par du coworking sur Paris, France?. Évalué à 5.
Je suppose à Londres, à SF et à Tokyo aussi.
Mais aprés avoir vu des chambres en cité U de 9 m², je qualifierais pas non plus un 30 m² de clapier (bien que je trouverais ça sans doute un peu petit à mon gout)
[^] # Re: Un peu incomplet
Posté par Misc (site web personnel) . En réponse au journal Brave - un nouveau navigateur web. Évalué à 10.
Tu veux parler du paradoxe que plus y a de gruyère , plus il y a de trous, mais plus il y a de trous, moins il y a de gruyère ?
[^] # Re: Support 5 ans vs variantes
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie d’Ubuntu 16.04 LTS Xenial Xerus. Évalué à 2.
Arrête, on sait tous que Debian est une dérivé d'Ubuntu.
[^] # Re: Mir et Wayland périmés
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie d’Ubuntu 16.04 LTS Xenial Xerus. Évalué à 5.
15 ans, pas vraiment. j'ai du en faire y a moins de 10 ans.
Ensuite, que la transparence réseau de xorg soit 1) limité (pas de passage du son, pas de montage des périphériques) 2) insécure (kough clear text kough) et donc désactivé par défaut, c'est autre chose.
j'imagine que quand les gens parlent de "transparence réseau", ils parlent de ssh -X/-Y la plupart du temps, ce qui reste à des années lumières de ce que rdesktop (ou spice) peuvent faire (mais toujours mieux que vnc). Et qui est globalement pas toujours fonctionnel du au fait que pas mal de services ont besoin d'une session dbus, ce qui prouve bien qu'en effet, les gens utilisent pas vraiment, ou alors, dans des cas ultra spécifiques.
[^] # Re: Mir et Wayland périmés
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie d’Ubuntu 16.04 LTS Xenial Xerus. Évalué à 6.
Je vois pas ce que nexvision vient faire dans la discussion (cf https://fedoraproject.org/wiki/User:Renault ).
Bien que les performances passés n'augurent pas des performances futures, je pense que dans ton cas, tu es l'exception qui éprouve la règle.
Je ne vois pas un changement de taille comme wayland se faire dans une version stable, en effet (ça fait parti des promesses que fait RH sur la compatibilités).
Donc comme l'a fait remarquer Renault, ça va dépendre de la sortie de la prochaine RHEL, et ça va surtout dépendre des constructeurs (ie, si nvidia dit "pour les nouvelles cartes, on file que des pilotes compatible avec l'archi de wayland", alors les clients de RHEL Desktop (genre les studios qui font de la 3d, les bureaux scientifiques, etc) vont sans doute demander, et RH va s'adapter et proposer ça dans une version de RHEL.
Pour un mec incapable de faire une recherche et de lire une page de wiki pour savoir à qui tu parles, je te trouve bien péremptoire sur les demandes des clients des boites ou tu ne bosses pas et ou visiblement, tu n'as pas des masses d'info.
[^] # Re: Support 5 ans vs variantes
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie d’Ubuntu 16.04 LTS Xenial Xerus. Évalué à 6.
Alors non, je ne crois pas que Ubuntu en bantou veuille dire "ne sais pas configurer debian". C'est un élitisme à 2 balles qui vaut bien l'élitisme anti-mandrake a 2 francs d'il y a 15 ans.
Et sinon, oui, Mint est pourri niveau gestion de la sécurité.
J'ai ouvert un bug de secu en 2012 sur Mint, j'ai eu 0 réponse ou ack. Un collègue a fini par me dire "tiens, prends ce CVE" que j'ai rajouté, mais bon.
La gestion de l'attaque sur leur site web était aussi un peu risible. Le souci n'est pas de s'être fait attaquer, mais fait attaquer 2 fois de suite. Ça arrive de pas savoir, et je sais que sysadmin, c'est un métier qu'on peut improviser jusqu'à un certain point, mais ça commence à faire beaucoup.
Si on rajoute le fait que globalement, Mint ne fournit aucun support de sécurité sur ses paquets, on commence en effet à avoir un chouia de trucs qui font tiquer quand on regarde la sécurité.
Et ça, c'est juste les trucs qu'on voit. Y a aucune transparence sur le processus de build ou de release engineering, donc tu sais pas comment, c'est fait, comment la clé gpg est stocké, etc, etc.
Le même je-m-en-foutisme est à l'oeuvre pour la gestion de ce qui est distribuable ou pas (brevets, proprio, etc), ou juste de leur formulaire de donation (qui pendant longtemps à été la cible de spammers qui donne 1 euro pour avoir un lien comme donateur)
[^] # Re: Mir et Wayland périmés
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie d’Ubuntu 16.04 LTS Xenial Xerus. Évalué à 3.
Je n'ai pas testé, mais je suppose que oui (modulo les bugs). En fait, c'est pas un niveau de confiance à la qubes-os, c'est bien que l'appli n'a pas le droit.
c'est pas vraiment dans le scope. Le changement apporté par Wayland, c'est pas de te protéger d'une appli qui te dit "entrer votre mot de passe", c'est de te protéger de celle qui ne te le dit pas mais qui espionne le clavier. Tu as l'air de confondre la sécurité que xdg-app/snap veut apporter avec celle que wayland vut apporter.
Vu que ta question 1 a l'air d'être sur une mauvaise prémisse, je suis pas sur de savoir répondre.
Non.
Grosso modo les ressources. C'est le fonctionnement de qubes os, vu que tu lances 1 VM par appli, avec chacune son serveur X. Mais la question devient "pourquoi le monde entier n'utilise pas qubes os comme distro"
[^] # Re: Mir et Wayland périmés
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie d’Ubuntu 16.04 LTS Xenial Xerus. Évalué à 4.
Non, c'est pas unity 7, c'est Mir.
[^] # Re: Mir et Wayland périmés
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie d’Ubuntu 16.04 LTS Xenial Xerus. Évalué à 2.
Oui, mais ça reste un chouia plus compliqué à mettre en oeuvre que juste envoyer un paquet snap d'un nounours sur l'Appstore Ubuntu.
ie, je suis sur que n'importe qui ici pourrait le faire avec un peu d'entrainement, alors que je suis sur que la majorité des gens ici ne sauraient même pas ou commencer pour exploiter un browser avec la tonne de protection qu'on trouve de nos jours.
[^] # Re: Mir et Wayland périmés
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie d’Ubuntu 16.04 LTS Xenial Xerus. Évalué à 6.
L'idée, c'est pas de sandboxer le serveur graphique, mais de ne donner à chaque client graphique accés que à ce qu'il a besoin.
Si jamais quelque chose (au hsard, un attaquant) arrive à compromettre evince, j'ai pas envie que evince soit capable d'écouter ce qui passe dans X, comme le mot de passe de ma clé gpg.
Ensuite, il y a d'autres vecteurs, mais dire "y a d'autres trucs donc ce trou n'a pas besoin d'être fermé", c'est un bon moyen de ne jamais rien faire, sauf à tout faire d'un coup, ce qui n'arrive jamais. La sécurité s'améliore par petites touches, et c'est une touche.
[^] # Re: Mir et Wayland périmés
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie d’Ubuntu 16.04 LTS Xenial Xerus. Évalué à 3.
Wayland devrait s'occuper de ça.
Je n'ai jamais pensé à ça, mais si un script peut le faire, alors ça peut se faire intégré sans trop de souci (ie sans revoir toute l'archi, contrairement au point 1 et 2 qui sont en gros qu'un seul changement d'architecture)
[^] # Re: Mir et Wayland périmés
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie d’Ubuntu 16.04 LTS Xenial Xerus. Évalué à 5.
Je ne peux pas répondre pour les windows récent, mais de mon temps, écrire un sniffeur de clavier était trivial, vu que j'ai fait ça à la fac.
IE, tu avais une api pour avoir les événements clavier, et à partir, suffit d'écrire dans un fichier et basta.
Ensuite, on parle dans un contexte d'application non vérifié par la distribution que n'importe qui peut envoyer (ie, l'appstore de Ubuntu). En pratique, le problème se pose vachement moins avec les applications libres et les dépôts qu'on a maintenant.
Mais ça se poseras dans un futur plus décentralisé permis par xdg-app et/ou les snaps.
[^] # Re: Mir et Wayland périmés
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie d’Ubuntu 16.04 LTS Xenial Xerus. Évalué à 8.
Non, les soucis de X, c'est aussi qu'il y a pas de séparation du tout entre les applis. IE, tout les trucs que tu tapes au clavier, ça peut arriver sur tout les clients. Pareil pour les mouvement de souris.
[^] # Re: Erreur Support Kubuntu
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie d’Ubuntu 16.04 LTS Xenial Xerus. Évalué à 4.
Oui enfin y a que les 90% supportés par ubuntu et dans main. C'est grosso modo 7300 sur 45 000 paquets, le reste étant non supportés.
Dans la plupart des cas, c'est en effet pas important, mais bon, c'est pas non plus pas assez mineur pour ne pas être mentionné.
[^] # Re: sécurisée et moderne
Posté par Misc (site web personnel) . En réponse à la dépêche LibreSSL 2.3.3. Évalué à 3.
Le souci n'est pas de forker, mais de croire que parce qu'un truc est un fork, alors c'est meilleur, et de croire que tout les forks vont faire mieux que l'original.
Il y a tout un tas de facteurs à prendre en compte pour voir si c'est opportun ou pas, et si j'osais faire un début d’hypothèse, le facteur le plus important, c'est de voir ou les développeurs de longue date du projet vont. Dans le cas d'Openoffice et de Mandrake, les forks sont ceux qui ont globalement survécus. Dans le cadre de certains forks de gnome, kde ou debian, c'est globalement pas le cas (Ubuntu étant une des exceptions à mon hypothèse, tout comme Libressl).
[^] # Re: Sérieusement ^^
Posté par Misc (site web personnel) . En réponse à la dépêche OpenBSD 5.9. Évalué à 2.
En même temps, c'est dans la version gnu de rm depuis un bout de temps, je suppose que ça a fini par être vu comme une bonne chose avec le recul de l'activation de l'option.
[^] # Re: sécurisée et moderne
Posté par Misc (site web personnel) . En réponse à la dépêche LibreSSL 2.3.3. Évalué à 2.
Oui enfin, on peut aussi dire le contraire avec mate, ou le fork de gnome à l'époque de gnome 2, ou trinity, qui sont globalement comme apache openoffice, pas mort mais avec un niveau d'activité pas non plus énorme.
[^] # Re: La sécurité ? Une contrainte pour la productivité
Posté par Misc (site web personnel) . En réponse au journal Avant c'est trop cher, après c'est trop tard. Évalué à 10.
Et du coup, c'est quoi la motivation pour ne pas trouver un taf qui soit moins relou ?
Parce que bon, le taf, on y passe pas mal de temps, donc ça me parait important que le truc soit pas trop chiant. Est ce que ça paye tellement bien, le travail en lui même est intéressant, ou d'autres raisons ?
[^] # Re: Backup
Posté par Misc (site web personnel) . En réponse au journal Comment Github a ressuscité mon logiciel libre. Évalué à 3.
Les fondations comme Apache ne vont aller que dans des cas précis. Comme tu dis, il y a des règles, notamment d'avoir assez de contributeurs (de boites différentes aussi), ce qui rends ça impropre pour la majorité des projets (mais pas forcément pour la majorité des projets qui ont un impact).
Et oui, y a des alternatives, mais pour le moment, si les gens n'utilisent pas, ça ne va pas influer vraiment sur la décentralisation.