rakoo a écrit 925 commentaires

Note : Je tiens a m'excuser de tous les anglicismes, ils concernent la manière de travailler sur un projet a plusieurs et j’espère qu'ils seront facilement compris par tout le monde.

• Fais des tests. Le mieux serait de couvrir 100% du code, et de tester tous les cas bizarres. Quand je dis "faire des tests" ça veut dire tests unitaires, fonctionnels, tout ce qui est testable automatiquement par une machine.
• Lorsque tu as finis tes tests, remonte les upstream. Puisque ce sont des tests, ils devraient passer avec la version actuelle
• Une fois (et une fois seulement) que c'est fait, commence a faire tes modifications dans ta branche
• Lorsque tu as une fonctionnalité "traduite", propose la upstream. Le plus souvent possible.
• Une fois mergée, rebase ta branche sur l'originale, de manière a avoir le moins de changements qui n'existent que dans ton coin.
• Et tu recommences.

En fait, je pense que la philosophie agile ("Release early, release often") est une approche intéressante qui te permettra de ne pas te retrouver avec un fork trop loin de l'original. Le problème est l'acceptation de tous tes patchs upstream; c'est pour ça que les tests sont vitaux, pour être sur que tu ne casses rien (et pour montrer ta bonne volonté aux développeurs originaux)

Je ne l'ai jamais fait, mais c'est comme ça que je ferais.

Ward Cunningham, l'inventeur du concept du wiki, a lance un projet appelé "Smallest Federated Wiki". Le principe est simple : le wiki, tel que connu et implémenté aujourd'hui, est trop centralisé, comme tu l'as vu toi-même. En gros, il y a un wiki de référence pour un projet, et tout le monde doit donner sa version et attendre qu'elle soit acceptée pour être publiée, ou alors la plate-forme accepte tout aveuglement. Si quelqu'un n'est pas d'accord, il peut "forker", mais il n'y aura pas de lien concret entre l'original et le nouveau; uniquement un lien logique, connu des utilisateurs seuls et pas de la machine. C'est aux utilisateurs de faire le pont entre l'original et les forks.

A l'inverse, Smallest Federated Wiki se veut être une sorte d'organisation de la conscience collective. Chacun aurait un pair chez lui, diffusant des informations en son propre nom, et chacun pourrait construire son propre pair a partir des informations du voisin. Lorsque celui-ci modifie sa version, la modification est facilement suivie et peut être importée chez soi.

L’intérêt que je vois a cette approche est qu'il n'y a pas un point de connaissance (même si ça a a l’énorme avantage d’être simple a retenir) mais bien une myriade de bouts de connaissance qui peuvent s’agréger dynamiquement, ou en tout cas beaucoup plus dynamiquement qu'avec un système de wiki actuel.

Bon, je t'avoue ne pas avoir teste la chose profondément, j'ai surtout vu les vidéos qui sont pas mal. C'est peut-être une piste intéressante pour toi qui cherche justement a bien montrer qu'un document est l’œuvre d'un auteur, et pas la vérité vraie; je pense que SFW pourrait aider a lier une réflexion a une multitude de ressources de manière plutôt intéressante.

En tout cas, je tiens a te féliciter pour l'initiative !

D'accord sur le fond, avec une précision :

Une solution serait peut être d'interdire strictement la vente et autre mise à disposition de l'alcool, du tabac et du cannabis aux adolescents.

Qu'appelle-tu adolescents ? En France, la vente d'alcool et de tabac est interdite aux mineurs, et Wikipédia dit que le contrôle pour le premier est, en pratique, laxiste.

D'ailleurs, quand j'ai besoin d'un truc tard le soir ou de manger à une heure indue, je sais que les commerces des "bons Français" seront fermés, alors que ceux de ces "salauds d'étrangers" seront ouverts et pourront me servir.

Il a du confondre la mailing-list avec Reddit.

j'ai toujours pensé que sous GNU/Linux on serait libre de choisir les briques qu'on veut

Justement, ce qu'il te dit, c'est que GNOME dépend d'un bout d'API et pas d'un logiciel en particulier. Aujourd'hui, cette API en question n'a qu'une seule implémentation, systemd, mais qui en plus de faire ce que GNOME veut fait plusieurs autres choses. Si quelqu'un est pas content et veut séparer les choses (ce qui est une bonne idée), il n'a qu'à implémenter juste ce dont GNOME a besoin.

YAKAFOKON, au final, même si en pratique je n'ai aucune idée de la difficulté d'implémentation.

il n'y a pas de différence fondamentale, ou alors il faudra que tu m'expliques.

Tu l'as dis toi-même. Dans le cas des listes noires de malware :

on peut outrepasser le blocage si on sait comment ça marche

Et ça ça change tout. Pour voir son site sous Flash dans la "Windows UI", il faudra demander l'autorisation à Microsoft. Sinon, il faudra dire à l'utilisateur de passer à la version Bureau de IE. Faut quand même avouer que la simplicité d'utilisation en prend un coup.

C'est comme si le site disait "Pour voir ma vidéo, tu dois copier l'URL et la coller dans VLC qui va la lire". Un mode d'utilisation qui plairait aux plus barbus d'entre nous, mais qui ne vaut pas la simplicité d'utilisation du simple clic dans le navigateur.

Je peux aussi te donner une autre raison. Dans le cas de la liste noire, il s'agit de protéger l'utilisateur contre une menace réelle pour son ordinateur, sa vie privée ou son portefeuille. Dans le cas de la liste blanche, il s'agit de protéger l'expérience utilisateur et s'assurer qu'elle suit bien les règles instaurées par Microsoft et les possibilités offertes nativement par ce dernier. Autrement dit, dans le premier cas, c'est l'utilisateur qui est mis en avant; dans le second, c'est Microsoft.

Bref, hormis Gmail, y a des solutions pour les grosses boites emails jamais nettoyées ?

Je trouve ça aberrant que les MUA "lourds" ne gèrent pas correctement un grand nombre de mails et que l'utilisateur doive s'adapter au logiciel, et non l'inverse. Après toutes ces années, on aurait pu penser que c’était optimise…

Je peux te conseiller heliotrope, qui est en fait un serveur de stockage de mail, associe a un moteur de recherche et adressable en REST. Le problème est que les modifications faites dans cette base de données y restent… hormis si tu utilises mon fork(dans la branche imap) qui ajoute une compatibilité IMAP (ou plus précisément une partie d'IMAP seulement : celle qu'il faut a OfflineIMAP pour fonctionner) pour une migration tout de même un peu plus simple.

Tu peux également essayer notmuch qui a l'air d’être pas mal apprécié par pas mal de personnes et est stable, au moins. Par contre les mails sont stockes en maildir uniquement.

Le problème est que l'OS considère foo.c et foo.h comme deux fichiers différents, alors que l'utilisateur ne voit que deux fois le fichier foo; il a donc deux fichiers qu'il sait être différents, mais il est incapable de les différencier. Il y a donc clairement un problème a l'utilisation.

Imagine que tu aies affiche les extensions, mais que tu puisses quand même stocker deux fichiers foo.c parce qu'une autre variable fait qu'ils sont différents (un contenu différent, par exemple). Comment peux-tu les différencier sans aller les lire ? La situation est la même ici : Une variable, invisible a l'utilisateur (dans une installation par défaut, hein), différencie deux fichiers, mais l'utilisateur doit inspecter chacun séparément pour savoir lequel est le bon.

Je t’écris en ce moment même depuis un ordinateur qui a les caractéristiques suivantes :

Intel(R) Core(TM)
i7-2600 CPU @ 3.40GHz
3.39 GHz, 3.49 GB of RAM
Physical Address Extension

Il me dit que je n'ai que 3.5 Go de RAM, mais j'en ai 8; malheureusement pour moi ma boite ne veut pas payer pour du 64 bits, donc je ne peux pas en profiter. C'est pas pratique d'avoir moins de 4 Go quand on fait du Java.

Offres évaluées en région parisienne

T'as essayé de quitter la grisaille et de venir en province ? =]

Les encodages sont une vraie plaie. Le mieux que je puisse te proposer et de passer tous tes inputs dans iconv en spécifiant à ce dernier de te sortir de l'UTF-8, et de passer tes regex par dessus.

Normalement, iconv est capable de détecter automatiquement l'encodage en entrée, du moins dans mes quelques tests. Ça marchait en tout cas pour ISO-8859-1 et pour CP1252.

En attendant que tout le monde se mette à utiliser Unicode et plus particulièrement UTF-8, je te souhaite bonne chance !

C'est une bonne nouvelle pour un système qui a plein d'atout, mais :

il arrive pourtant bon dernier en terme de part de marché […] Pourquoi ?

Je pense apporter une voie de réponse en disant que ce n'est pas son but. Le but de txt2tags est d’écrire un message totalement indépendant de quel logiciel le lit, dans un format qui soit transformable en une myriade d'autres formats. Ainsi il sert a créer un document, là ou Markdown et consorts servent a mettre en forme du texte qui va être inclus dans une page, et non pas exister en lui même.

Je pense par exemple aux 3 premières lignes, nécessaires dans txt2tags, mais souvent inutiles dans les endroits ou les autres formats sont utilisés. Lorsque j’écris ce commentaire, je n'ai aucune envie d'en spécifier les éléments suivants :

line1: document title
line2: author name, email
line3: date, version

si ce n'est éventuellement le titre, mais je peux déjà le rentrer d'une autre manière.

Dans le même sens, je suis persuadé que générer un document HTML complet n'a pas de sens si on veut l'utiliser de la même manière que Markdown; puisque ces textes vont être inclus ailleurs, les en-têtes seront générés par l'application qui sert les pages, non par le texte que l'utilisateur tape.

Au final, la version php est utile pour la syntaxe est les pre/post process, mais la partie 2tags du titre est trompeuse; il faudrait peut-être appeler ça plutôt txt2html ?

Il a fallu attendre 10 mois pour avoir l'IPv6 promis (pendant cette période, c'était soit téléphone soit IPv6, à cause de leur modem)

Ah mais c'est à cause du modem/routeur ça, pas à cause d'OVH. D'ailleurs, sur l'offre no!Tv avant changement (donc l'ancienne box qui a également changé), on a une box qui ne permet pas de faire IPv6 et routeur en même temps. Dommage, je viens de voir qu'ils proposent un /56, c'est quand même sexy :(

Y'a des dizaines de clients pour Ubuntu One, qui doivent rendre la compréhension du protocole relativement simple pour qui s'y intéresse.

Et bien justement la doc pour la partie serveur existe déjà, et elle s'appelle U1DB.

Oh mais que vois-je ? Une implémentation de référence, libre, directement synchronisable avec Ubuntu One ?

Oui bien sur, d'ailleurs photorec et testdisk m'ont aide plus d'une fois dans la récupération de fichiers. Je me demande juste si, vu le ton de l'article, la différence entre écraser la table de partitions et effectivement écrire des 0 partout est claire pour le journaliste.

Et s'il s'agissait d'une Ubuntu, ou, si mes souvenirs sont exacts, il y a une option "Utiliser le disque entier" ?

En tout cas, vu l'article originel, on comprend mieux que ça n'avait rien d'accidentel, donc la question ne se pose même pas.

Au passage, vu que tu archives tes données dans un zip/tgz/autre, tu peux en profiter pour le chiffrer en GPG.

… et utiliser duplicity, ou directement deja-dup, le frontend graphique très bien fichu !

Attention !

Lorsque tu montes un ftp en local, le dossier est vu comme un dossier local. Et voila ce que fait rsync lorsqu'il traite deux dossiers locaux, extrait du man:

-W, --whole-file
Avec cette option, l'algorithme rsync incrémental n'est pas utilisé ; au lieu de cela, le fichier entier est envoyé tel quel. Le transfert peut être plus rapide grâce à cette option lorsque la bande passante entre les machines source et cible est plus grande que la bande passante vers le disque (en particulier lorsque le «disque» est en fait un système de fichiers sur réseau NFS). Cette option est utilisée par défaut lorsque la source et la cible sont sur la même machine.

Du coup, tu peux utiliser --no-whole-file, mais rsync va telecharger le fichier a distance, le comparer avec le local et n'envoyer que les differences. Pas glop.

XMPP c'est mieux, mais c'est pas ce qu'il y a de meilleur d’après les types de psyc:

• il est très verbeux (beaucoup de "presence stanzas" en double, du XML…)
• il ne sait pas faire de smart unicast (même SMTP sait le faire…) même si dans le monde parfait ou chacun possède son serveur, ça ne changera rien
• globalement, il ne fait pas de multicast, ce qui est un énorme problème lorsqu'on a des millions d'amis et qu'on héberge son serveur chez soi.

Bref, PSYC est sympathique, mais XMPP possède l'avantage d’être déjà implémenté et connu par pas mal de monde.

Bien vu, mais justement Apple distribue le rendu, pas la base de donnés sous-jacente, donc tout va bien.

Justement, d'après le wiki, il semble que la nouvelle licence soit "à l'avantage" d'Apple :

Avec la nouvelle licence, la carte [construite avec au moins des donnés sous ODbl] peut hériter de n'importe quelle licence, selon le souhait de son auteur, dès lors qu'il met à disposition toutes les améliorations apportées aux données OSM lors de la fabrication de sa carte.

Il y a 2 cas possibles:

1. C'est le site qui te fait payer, auquel cas je me demande comment il peut dire à ta banque de lui donner de l'argent.
2. C'est ton FAI qui te fait payer, et peut le faire parce que tu lui as donné libre accès à ton compte en banque.

On est dans le deuxième cas non ?

-Est-ce que FDN protège de ce problème ?

Si on rentre dans le premier cas, FDN ne te protègerait de rien. FDN n'est pas une nounou; FDN transporte les paquets de ta machine à l'autre machine et vice-versa sans s'occuper de leur contenu. Si le paquet contient le message "Vider mon compte" et que tu ne le sais pas, tant pis; FDN acheminera quand même ce paquet.

Si on tombe dans le deuxième cas, je doute fortement que FDN s'adonne à ce genre de pratiques.

Note: je ne connais pas exactement les pratiques de FDN, mais vu les interventions du chef et la philosophie de l'association, je ne pense pas me tromper sur eux.

Ah, effectivement, merci. Je retire ma complainte.

On est sûrs qu'Apple utilise les cartes OpenStreetMaps ? Je n'en vois aucune mention nulle part, alors qu'elle devrait y être.

(Je viens de me rendre compte que c'est vieux, mais je viens de l'apprendre et ça me choque.)