Florent Fourcot a écrit 405 commentaires

Si si, pour monter à distance un système de fichier chiffré par exemple.

Dropbear permet de faire ça notamment : on charge le réseau minimal et on ouvre un serveur ssh, ce qui permet de taper la phrase de passe du système de fichier à monter avant la suite du démarrage.

En fait la réponse est dans la dépêche :

Pour autant, ils tentent de garder contact avec les développeurs officiels d'Ampache (certes avec une méthode "à prendre ou à laisser"). On peut notamment trouver ce bug ouvert, avec l'ensemble des modifications, et des questions sur l'avenir (sans réponse des développeurs).

Les développeurs ne répondent plus à rien, il semble difficile dans ces conditions de continuer.

Je me trompe ou AudioStreamer manque fortement de fonctionnalités ? (ce qui le rend probablement léger, certes).

Je pense notamment au minimum à une API pour se passer de navigateur, et le réencodage à la volée en qualité/format différent. Je ne parle même pas de pouvoir créer des listes de lecture.

Edit : ah pour le réencodage ça semble en parler dans le forum. C'est bien caché.

• éviter quelques problèmes potentiels de spoofing liés aux mechanismes du RA.

Hum ? Il dit qu'il ne voit pas le rapport. En DHCPv6, il y a toujours les RA (indispensables pour trouver la route par défaut). Et si c'est pour parler de spoofer les adresses des clients, je ne vois pas en quoi c'est plus difficile à faire avec un DHCP qu'avec de la génération sans état.

• éviter les problèmes de trash-cache quand des clients sont configurés comme des pingres et spam des messages RD toutes les 500 ms.

Et ça marche vraiment ? Cf juste au dessus, pour DHCPv6, on envoie juste des RA avec le drapeau Managed (qui désactive les adresses EUI-64, et demande au gentil client de faire une requête DHCP, mais si le client est bugué ça coincera toujours).

TCP Fast Open qui avait été ajouté dans Linux 3.7 est maintenant compilé par défaut ;

C'est plus que compilé par défaut, c'est activé par défaut. À ma connaissance, cela a toujours été compilé. La différence désormais c'est qu'il faut explicitement changer la variable sysctl pour refuser d'utiliser TCP Fast Open.

Une annonce sur quelques listes de diffusion.

À noter le numéro de version 0.099. L'annonce précise bien qu'ils se réservent le droit de modifier la grammaire ou d'autres choses pour la 0.1. Ça fait plaisir de le voir enfin dans le noyau, si ça prend ça peut révolutionner les pare-feux sous Linux.

J'aime ce commentaire qui à la fois signale une évolution du comportement (la suppression d'image "pornos". J'ai jamais vu d'images pornos depuis que je suis dans le projet) pour ensuite dire « ne pas te remettre en cause ».

En gros, on a tort : la preuve on change des trucs. Mais on est obtus car on ne change rien ?

Je pense que tu as confondu à qui tu répondais. Alors que le message de défense essayait justement de clarifier un peu qui était qui :-) (lui, c'est pas moi, l'auteur du journal).

Bref. Cette phrase me fait tout de même réagir :

Perso, j'ai hésité à contribuer à un moment ; et je me suis dit que si je contribuais et qu'on me retrouvait "lié" à ce projet ce n'est pas ce que je souhaitais en terme d'image de marque - simplement je n'adhère pas à cet "humour"

Tout dépend évidemment toujours de pourquoi tu contribues. Si tu contribues pour que le logiciel s'améliore (tu as un besoin ou un bug), il est probable qu'il sera plus simple et plus pertinent pour toi de contribuer tout de même, même si tu dois pour cela demander à être anonyme. Maintenir une branche externe peut être chiant.

Si tu contribues car tu trouves que le projet est utile, et tu le vois comme une sorte de remerciement, contribuer en anonyme serait probablement aussi une solution.

Si tu contribues au moins en partie pour pouvoir rajouter des lignes sur github/ohloh/outil que vous voulez, c'est effectivement plus gênant si tu ne souhaites pas être associé à cet "humour". Rien de péjoratif pour moi là-dedans, je tiens à le préciser. La reconnaissance fait parti des moteurs du logiciel libre. C'est juste à préciser pour nuancer le « je ne peux pas contribuer à cause du nom ».

Je ne parle pas de discuter avec des développeurs, je parle de retour utiles pour les développeurs. Pour juger qu'une interface est pourrie et détecter de la documentation manquante, donner des idées de fonctionnalités, il est rarement nécessaire d'être développeurs. Aucun élitisme là-dedans.

Je ne pense pas parler d'être pris au sérieux.

Autrement je ne crois pas (plus) à l'utilité du changement de nom. Les discussions à ce sujet ne reprendraient que de plus belle pour très longtemps.

Le mot technique est en fait assez mal choisi. J'entendais par là l'ensemble des sujets permettant de faire avancer le projet (idées de nouvelles fonctionnalités, empaquetage sur les distributions, retour sur les interfaces, etc).

Je ne suis pas dans la peau des autres rédacteurs de dépêches pour savoir s'ils ressentent une évolution dans la pertinence des retours.

Je pensais qu'on avait atteint le fond sur la discussion, mais apparemment non.

En fait, il faut l'avouer, ce nom est une méthode pour éviter de devenir les maîtres du monde.

Il est évident qu'avec un concept aussi révolutionnaire, nous devrions crouler sous les contributions, nous devrions avoir une interface en HTML5, et un portage sur tous les OS. Tout ça je le sais est dans les cartons de contributeurs externes non déclarés.

Pour éviter d'en arriver là, c'est une sorte d'auto-limitation. Et heureusement, sinon il faudrait recruter un second release manager.

P.S : pour tout un tas de bonnes raisons (n'ayant jamais eu à ma connaissance un lien avec le nom), il y a des contributeurs anonymes à Weboob. Si ça peut t'aider à éviter de maintenir une branche locale…

Cher fravashyo,

tu as réagi sur ce sujet sur la dépêche 0.g.

Tu as réagi sur ce sujet sur la dépêche 0.f.

Je n'ai pas le courage d'aller chercher plus loin, mais je pense que c'est bon, on a compris ce que tu pensais.

Note : pour 300k€, je te conseille de payer quelqu'un capable de faire un sed.

Ah oui. Je vais mettre le site à jour à ce sujet, merci de le signaler.

Soit je n'ai pas compris la question, soit tu n'as pas lu la dépêche qui précise « Autre nouveauté de cette version, un installateur Windows officiellement distribué ».

J'aime bien le principe d'ownCloud, mais j'ai à chaque mise à jour j'ai l'impression de servir de beta-testeur. Sur les versions mineures, ça bloque une fois sur deux. Sur la version 6, j'étais certain d'avoir au moins un problème. Ça n'a pas manqué. On commence par ça. Ça semble toucher pas mal de monde.

Après on tombe sur les bugs plus spécifiques. J'ai le malheur d'utiliser postgresql, qui est officiellement supportée par owncloud. Mais en fait, pas vraiment. Vous noterez que ça touche la RC2, mais n'a pas empêché la sortie de la version finale, même si ce n'est pas corrigé (ne pas faire attention au "closed" en bas du bug, les mainteneurs ont la notion de doublons/fusion un peu étrange).

Je pense que leurs processus de tests, notamment les mises à jour, sont complètement déficients. Je doute même de leur existence à vrai dire. Et sortir des versions alors qu'on sait qu'il reste des bugs critiques sur les mises à jour, ce n'est pas très malin.

Autrement, c'est un bon produit :) Je n'ai pas encore découvert de bugs après la mise à jour (habituellement des permissions sautent sur les groupes, sur le partage de calendrier, etc), ce qui est presque une victoire.

Pour les images le problème n'est pas le format, mais la récupération interne. Pour les gens souhaitant les images, ça marche plutôt bien avec Weboob actuellement en export RSS/Atom, car il suffit de laisser le lien. Le lecteur RSS fait le reste. Là il va falloir télécharger les fichiers, et faire attention à la taille. Rien de dramatique, mais ça change le comportement.

Le epub gère très bien les gros volumes. Il est tout à fait possible de faire un epub par site avec un document xhtml par article ou par groupe d'articles.

J'ignorais. Ça marche bien sur les différentes liseuses ?

Quand j'analyse le besoin que j'ai en tant que lecteur sur liseuse, je pense au projet weboob car il s'agit d'utiliser le web pour un usage hors navigateur. Il serait peut être intéressant de créer une nouvelle application, du genre "contentoob" avec tous types de backends, comme des blogs ou des sites de news. Avec la bonne ligne de commande, le contenu de ces sites serait transformé à la demande en EPUB. Avec les bons outils, udev, cron, il serait possible de remplir sa liseuse sans trop de manipulations.

C'est une chose qui est sur ma liste des priorités depuis bien longtemps, il y a peut-être même un ticket qui traîne à ce sujet là. Le premier problème c'est gérer le format epub, ce qui n'est probablement pas insurmontable mais demande de s'investir un peu là-dedans.

Le second, c'est que je ne suis pas certain de la bonne approche. Faut-il faire un fichier epub par article de journal ? Comment gérer les sites comme linuxfr avec des commentaires, et dont le contenu évolue donc rapidement ? Comment filtrer le contenu que l'on souhaite ? (un problème relié est la classification des articles de journaux récupérés par Weboob en catégorie, c'est prévu également). Dernier soucis, comment bien gérer les images ?

J'ai bien quelques idées vu les limitations de ma liseuse (un fichier par article, cela serait très vite insupportable), mais le coktails de ces questions saupoudré d'un manque de temps explique que ça n'est pas fait…

l'info est sur le site de crucial

Non pas sur le site, sur leur forum, même pas épinglé en haut de la rubrique !

Ce journal est clairement de la diffamation !

Je me suis probablement fourvoyé alors dans la façon de présenter les choses. Et si un modérateur pense que le mot obsolescence programmée dépasse le degré d'humour autorisé, qu'il hésite pas à corriger. Mais sur le contenu du journal :
- Le disque tombe-t-il en panne après 5184 heures ?
- L'information est-elle présente sur la page du support du fabricant pour le produit ?

Je ne vois pas ce qui est diffamant là-dedans.

Et j'ignorais pour LDLC, ce qui enlève effectivement une bonne part de mes critiques. Il semblerait que par mon circuit de distribution, il y a eu de la perte de paquets.

Les vrais gens enregistrent leur produit auprès du constructeur

Et beh, on connaît pas les mêmes vrais gens.

tu voudrais quoi ?

Que crucial l'écrive sur son site de support du produit, c'est trop demander ?

Mon smartctl -a /dev/sda ne donnait rien. J'ai peut-être loupé un morceau… Ou alors il y a d'autres options à utiliser ?

Après c'est vrai que les utilisateurs normaux consultent souvent smart quand leurs ordinateurs plantent. J'ai l'impression de vivre sur une autre planète quand je lis cette réponse.

Des bugs stupides arrivent quotidiennement oui. Mais habituellement, les constructeurs que je juge fréquentables mettent en avant sur leurs sites les correctifs. J'aurais attendu un message explicite sur le site de support de Crucial : « attention, votre SSD de modèle X est victime de ce bug, voici le correctif ».

Le correctif est en effet ancien, mais le bug va continuer de toucher des utilisateurs pendant des mois, voir années. Un autre utilisateur ayant commandé le même modèle le même jour que moi a encore 2000 heures devant lui avant d'atteindre le bug, il y a pour moi un devoir de communication à ce sujet sur la durée. S'ils ne le font pas, ils transforment le bug en une mise à la poubelle.

Vous avez peut-être loupé la partie « On peut y voir de l'incompétence, mais comme on est vendredi […] ».

C'est pour moi une vraie question pour un jour pareil. Sur la notion de bug, on a que la parole du constructeur. La présence d'un correctif ne prouve rien, vu que je doute de la proportion d'utilisateurs qui vont vraiment en bénéficier.

En tout cas, un constructeur capable de mettre en panne en disque en faisant un +1 sur un compteur, j'ai du mal à lui faire confiance pour mes données…

A priori non, je fais régulièrement des TRIM, et mon disque remarche parfaitement après la mise à jour du fabricant.

Et tant bien même sans TRIM. Ça pourrait provoquer une mort lente de certaines parties du disque, pas une déconnexion brutale de la liaison disque <-> OS.