Mildred a écrit 2249 commentaires

Franchement, je ne comprends pas le problème que les gens ont avec l'hébergement mail. J'ai toujours trouvé ça facile et j'ai que rarement eu des problèmes. Jusqu'à présent j'utilisais une solution exim + dovecot maison avec un record SPF -all. J'ai jamais remarqué des problèmes sauf a un certain moment où le bon coin envoyait des e-mails avec un expéditeur d'envelope qui correspondait a ton mail perso, qui bloquait sur la politique SPF. Mais plus maintenant.

J'ai jamais remarqué de blacklist ou autre…

Maintenant, j'utilise Mailu qui me donne entière satisfaction et qui me permet d'avoir DKIM en bonus. J'avoue l'avoir un peu customisé. Ma boîte mail perso est un wildcard sur le domaine. Et je suis la seule personne sur ce serveur mail. C'est peut être pour ça que je n'ai pas trop de soucis.

Pour donner l'argument inverse, il me semble que Daniel Glazman, créateur de Nvu et BlueGriffon, éditeur HTML WYSIWYG sorti de la suite Mozilla, et depuis longtemps dans le groupe de travail CSS du W3C, vantait au contraire l'avantage du W3C face au WHATWG qu change tous les quatre matins le texte normatif HTML5… Et du coup, pour implémenter la spec, cétait un peu plus compliqué.

C'est dans une de ses dernières vidéos: The third browser war is over and it's a bloodshed - WEB2DAY 2016 (31m 24s)

Je suis dans le même cas, j'apprécie de pouvoir facilement prendre mon livre n'importe où, mais je n'ai pas trop non plus dépendre de la technologie. C'est vrai qu'un livre électronique permet de faire des recherches textuelles, mais dans un livre papier, tu peux mettre de vrais marques pages, bien plus parlants que les pseudo parques pages d'une liseuse. Si il y a des figures et tableaux a aller voir, c'est beaucoup plus pratique avec un livre papier.

En fait, l'idéal est d'avoir les deux en même temps :)

Une connexion tcp ou websockets qui n'a pas de traffic, ne consomme rien en terme de ressources. C'est juste une entrée dans une table de connections ouvertes sur le serveur et sur le client, c'est tout.

Après, si les implems derrière font n'importe quoi, c'est un autre problème.

J'utilise, mais ce qui me manque le plus c'est de pouvoir ouvrir deux vidéos en même temps, pas juste la playlist.

En pratique je ne connais pas beaucoup de logiciels qui maintiennent en même temps plusieurs version en parallèle. Il faut des ressources pour se permettre de développer à la fois les nouvelles fonctionnalités de la version 2 et maintenir la version 1.

Ce qui est important effectivement c'est l'adaptation de la graine au lieu. Par sélection génétique sur des décénies, la graine est parfaitement adaptée a son jardin.

Vouloir comparer est normal, ils arrivent après, XMPP existe, et les gens ont besoin de comprendre pourquoi ils doivent investir dans une nouvelle techno alors qu'il y avait XMPP qui ne demandait qu'a évoluer.

C'est un peu comme Mir vs Wayland (d'ailleurs la FAQ de Mir sur Wayland était bien pourrie).

Pour moi, Matrix voulait refaire de la messagerie, avec un style très orienté IRC. Ils voulaient aller vite. XMPP leur donnait l'impression de stagner donc ils ont voulu s'en abstraire pour aller plus vite et par raisons marketing De toute façon, ça n'avait plus la cote… et ils ont fait un protocole fait au plus rapide avec une couche HTTP+JSON parce qu'il y a plein de libs qui marchent bien pour ça, c'est tout.

Il doit également y avoir des raisons techniques. Je pense que l'implémentation des utilisateurs et des salons de discussion est différente de XMPP et c'est souhaité. Si ils avaient dû reprendre XMPP, ils n'auraient peut être pas pu reprendre les mêmes groupchat et auraient fait leur truc séparé sans doute.

Disclaimer : on était ensemble sur framatalk. Somme toute, c'était un des meilleurs outils qu'on ait testé. Ça nous arrivait d'avoir des problèmes d'echo avec l'autre coté de l'atlantique, mais sinon, ça marchait bien. Surtout pour quelque chose qui tourne dans un navigateur uniquement. Donc n'hésitez pas a tester également.

D'un point de vue purement théorique sur la manière dont fonctionne terraform, il a un gros avantage par rapport a Ansible, Chef ou Puppet : il stocke son état courant.

En pratique ça veut dire que lorsqu'on enlève une ressource du fichier terraform, au prochain lancement, il va se souvenir que la ressource existait, quelle n'existe plus, et il tentera de la supprimer. Dans les faits, ça lui permet d'être toujours au plus proche de son état.

Des outils de gestion de conf classique, en cas de suppression d'une ressource dans les sources, ne vont pas la supprimer. Elle restera là sur les serveurs. Ce qui je trouve peut poser problème. Imagine que ce soit un serveur avec une faille de sécurité… En pratique, la solution est d'indiquer la ressource mais avec une booléen pour dire qu'elle doit être absente. Pas très propre je trouve.

En constatant cela, j'ai immédiatement pensé a comment faire pour utiliser terraform a la place de puppet, chef ou ansible. En pratique, c'est pas faisable … dans terraform on ne gère pas des fichiers, des services ou d'autres objets existant sur la machine où on exécute terraform. Ce que fait terraform c'est gérer des ressources distantes par API Web.

Mais en pratique, terraform permet l'écriture de plugins. En théorie rien n'empêche donc d'écrire un plugin qui au lieu de discuter avec une API Web, discutera avec une API d'appel systèmes pour provisionner une machine réelle et pas dans le cloud.

Après, en pratique, je n'ai pas tenté cette voie parce que terraform n'est vraiment pas fait pour ça, et rien ne dit que ça marchera pour tout faire. Et il n'y aura aucune volonté de merger du code sur ces fonctionnalités upstream. Ce serait un gros hack en quelque sorte. mais si vous avez du temps a faire, ça peut être un truc cool :)

Sachant qu'il existe un outil : mgmt (déjà discuté plus haut), tout neuf, écrit par un gars de Red Hat qui pourrait remplir ce rôle parfaitement.

https://wikileaks.org/ciav7p1/cms/page_9535850.html

BaldEagle

Local user-to-root privilege escalation exploit within the Hardware Abstraction Layer (HAL) daemon. Exploit is available on Linux and PC-BSD platforms with the hald process running.

Les macs de 2007 (Core2Duo MacBook2,1) ont un EFI (c'était pas encore UEFI a cette époque) 32 bits alors que ton OS est souvent 64bits. Du coup, si tu présentes une clé avec une code de boot 64bits, ça ne marche pas.

Solution: faire tout en 32bits, ou avoir une distro qui te file un EFI 32bits et un kernel 64bits. Et ça, pas grand monde le fait.

J'ai comme l'impression que chromium cache la page complètement sur disque. Avec un ordinateur pas très puissant, et pas beaucoup de RAM, chromium est nettement plus réactif que Firefox. Il faut dire que j'ai une sale habitude : avoir minimum 40 onglets ouverts, si ce n'est 120.

Sans doute que Firefox devra se mettre a faire ça, si ils décident d'activer un process par onglet (au lieu d'un process pour tous les onglets comme maintenant)

J'ai du mal a voir comment une extension binaire est capable de protéger du contenu. A mon sens, c'est complètement vulnérable a une attaque de type replay attack. Et je ne suis pas seule a le penser, il semble : EME undermines its stated purpose

It's stated in the abstract that the EME purpose it's for "providing APIs to control playback of protected content" but a standard (open) API undermines all content protection schemes using it thereby defeating its reason for existing.

There are a couple ways this can manifest:

• If the protected content, CDM, license requests/responses are all written to disk by the browser then they can be packaged into a single file for later playback.
• The CDM is architecture and OS agnostic, so it cannot make direct rendering calls. As a result, any possible output from the CDM can be recorded to disk as an unprotected media format.

En gros, il dit qu'il y a deux manières pour récupérer le contenu quand même :

• en interceptant les accès au serveur de DRM, et en contrôlant l'état du module DRM, il est possible de rejouer les requêtes réseau afin de redéchiffrer le contenu.
• en interceptant les frames déchiffrées, on peut reconstituer le flux vidéo non chiffré

En gros, cela revient, l'un comme l'autre a exécuter le module DRM dans une machine virtuelle, ou toutes les entrées sont connues, et si on peut faire ça, plus rien ne tient.

Dans le cas contraire, le module DRM est très lié au matériel et ne peut s'exécuter dans une machine virtuelle, on va rester dans le problème classique ou ces modules vont être sous une forte pression de reverse engineering pour réussir a accéder a une interopérabilité.

Ça n'a rien a voir, l'injection SQL permet a un attaquant d'attaquer une application via sa base de donnée.

Ici le cas de figure est un abonné free qui attaque directement la base de donnée pour avoir un accès privilégié sur les serveurs de free et donc faire plein de choses qu'il n'aurait pas pu faire sinon.

Autant sur le reste des critiques, je ne les partage pas, mais effectivement, le RaspberryPI me semble fort limité pour quelque chose comme Cozy. On a pas besoin de port HDMI !

Par contre, on a effectivement besoin d'IO descentes, de gigabit ethernet et de SATA (voire multiple SATA pour faire du RAID).

D'une manière générale, je regrette que tout se fasse a base de Raspberry. Il manque une alternative orientées stockage de données (pour Cozy par exemple) et une autre alternative orientée réseau pour faire son routeur maison (gigabit ethernet, switch ethernet intégré, pas besoin de SATA ni HDMI).

Vous connaissez des alternatives spécialisées dans ce genre ressemblant dans l'esprit au Raspberry ?

C'est vrai que par choix, je choisirais plutôt de l'écrire en Go, de par sa simplicité de déploiement (compilé en statique) et de par la facilité de la cross compilation. Mais le C n'est pas si mal non plus.

L'esprit de la LGPL veut que tu puisse modifier le code LGPL, et exécuter le même soft avec ton nouveau code. Pour cela, tu as besoin d'un link dynamique. Donc de l'extérieur, tu as bel et bien besoin d'avoir une lib séparée.

Ou alors la distribution peut refuser un paquet qui fait trop de link statique comme Chromium avec Fedora

En pratique, les deux sont aussi dangereux si tu ne fait pas confiance au mec qui écrit le script derrière (shell ou post install). Par contre, le paquet de la distrib a l'avantage de ne pas pourrir complètement ta distribution. Tu peux le désinstaller. Rien que ça, c'est un énorme avantage.

Surtout avec fpm

Il semble du moins assez clair que le logiciel libre porte des valeurs politiques, même si vous n'êtes pas d'accord sur lesquelles.

La politique au sens large n'est pas spécifique a un pays. La politique c'est aussi discuter du fonctionnement de la société au sens large. C'est pas juste un bulletin dans une urne. C'est très réducteur comme approche.

Et le fonctionnement de la société est un sujet qui est loin d'être spécifique a un pays en particulier.

Sans compter que le logiciel libre au sens de la FSF est un sujet hautement politique en lui même.

Pourquoi ne pas réhabiliter les journaux de seconde page ?

http://linuxfr.org/suivi/journaux-de-seconde-page-dans-la-colonne-de-gauche

A savoir que je pense qu'un journal peut très bien être dans la seconde page mais être très pertinent, alors qu'il peut y avoir des journaux de première page moins pertinents. C'est a mon avis une problématique orthogonale.

La première page contiendrait les journaux dans le thème, la seconde page, les journaux bookmark ou HS. La première page a une prévisualisation extensive, alors que la seconde page ne prévisualise que ~5 lignes dans la colonne de gauche (25 mots max).

C'est effectivement une remarque très juste. Si je ne me trompe pas, on a actuellement plusieurs implémentations des interfaces wayland : weston, enlightnment, gnome-shell, kwin. Rien ne garantit qu'ils fonctionnent de manière identique ou qu'ils implémentent exactement les mêmes protocoles.