Franck V a écrit 47 commentaires

Si c'est vrai, qu'est ce qui empêcherai google de reprendre les headers de la glibc (donc sous LGPL) dans leur propre code ?

Apparemment c'est aussi l'opinion de la FSF:
http://lkml.indiana.edu/hypermail/linux/kernel/0301.1/0362.html

OK, mais dans ce cas là, ça veut dire que la version compilée de la glibc qui est intégrée dans nos distribution se retrouve au final sous GPL puisqu'elle comporte un mix de codes sources GPL et LGPL.
Du coup je ne pige plus l’intérêt de la LGPL dans ce cas particulier...
La FAQ de la GPL semble indiquer qu'une librairie GPL implique forcement la GPL-isation du code l'utilisant (au contraire de la LGPL).

Non, compatible GPL veut dire que du code LGPL peut être intégré dans du code GPL pas l'inverse.

Apparemment c'est du code du noyau lui même qu'ils auraient repris, rien à voir avec la glibc.
Quelqu'un sait si la glibc utilise aussi des headers du noyau ?

En aucun cas la GPL ne se propage aux programmes utilisateurs. Il y a même un passage là dessus dans la GPL : l'utilisateur des outils de dev de la plateforme, y compris le noyau, n'impose pas les conditions de diffusion de la GPL.

A priori la glibc est sous LGPL pour éviter justement que le userland ne le devienne aussi.
Tu as un lien vers le passage de la GPL qui autorise ça ?

A moins d'utiliser Emacs, les outils de dev ça prend de la ressource

Trop gros passera pas

Tous les utilisateurs de logiciels de formatages de textes (LaTex, Groff, et visiblement aussi MarkDown) savent que le retour à la ligne n'est pas significatif. La ligne vide est par contre significative.

C'est arbitraire et ça n'a rien d'évident à priori (et encore moins d'intuitifs).

Que le retour à la ligne ne soit pas significatif me semble pratique lorsque l'on écrit un long texte dans son éditeur avant de le poster (une dépêche par exemple). Dans ce cas là, on est souvent heureux de ne pas avoir des lignes de trois kilomètres, sous prétexte qu'elles constituent un unique paragraphe.

Mauvais éditeur, changer d'éditeur. C'est à lui de se débrouiller pour présenter le texte correctement en fonction des préférences de l'utilisateur (d'ailleurs tous les bon éditeurs possèdent une option permettant d'afficher le texte soit sur une seule ligne, soit sur plusieurs).

Pour ou contre le respect de la syntaxe Markdown pour les retours à la ligne ?

C'est quoi les arguments pour la syntaxe actuelle ? Je pense que 99% des gens s'attendent à avoir un retour à la ligne quand ils tapent un retour à la ligne.

Idem, peu importe la capacité de plussage, ce qui compte de de contribuer chacun à son niveau.

En parlant de logo, c'est moi où le "GNU" a sauté pendant la migration ?

Oui mais il a beaucoup souffert...

Pendant un moment j'ai cru que le site avait migré vers la nouvelle version en RoR et qu'il n'avait pas résisté au premier pic de charge...

A ma connaissance, les différents composants de Django (système de templates, ORM, ...) sont faiblement couplés entre eux. Il est donc (en théorie) relativement aisé de remplacer l'un d'entre eux par un composant plus générique.
Le problème c'est que tu ne peux plus alors utiliser certains composants tout faits comme l'interface d'admin ou les vues génériques.

Cela dis, je regrette comme toi que les développeurs de Django passent leur temps à réinventer la roue plutôt que de réutiliser des composants plus avancés et éprouvés (comme SQLAlchemy). C'est sûrement lié à des raisons historiques (trop tard pour revenir en arrière) et probablement aussi une certaine volonté de garder le contrôle des évolutions.

En général on n'utilise pas la classe person qui sert de base à toutes les classes de type personne mais n'est pas destinée à être instancié directement.
Dans OpenLDAP la classe qui est le plus souvent utilisée pour représenter les utilisateurs est inetOrgPerson qui dérive de person et de organizationalPerson . Celle-ci contient bien l'attribut mail.

En effet, d'après le site du projet [3] :

The one significant exception is that RE2 drops support for backreferences and generalized zero-width assertions, because they cannot be implemented efficiently

Pour la synchronisation tu as le projet opensync (http://www.opensync.org/) qui permet de synchroniser ton téléphone et ton PC via le protocole standard SyncML.
Par contre c'est un petit peu complexe à configurer et la prochaine version stable (0.4) se fait un peu attendre.

J'anticipe une rupture de stock très prochaine de ce numéro...

As tu essayé d'installer le paquet cyrus-sasl-plugins ?

Source: http://permalink.gmane.org/gmane.network.jabber.devel/31961

Il veut plutôt parler de 'call it a day' qui signifie 's'arrêter pour aujourd'hui'.

Le problème c'est que tu ne peux installer des logiciels sur ton i[pod|phone] QUE depuis l'AppStore.
Tu es obligé de cracker ton propre matos si tu veux installer des logiciels depuis une autre source.
Franchement, un éditeur qui ne te permet même pas d'installer les applications que tu veux sur du matériel que tu as acheté légalement (et cher) ne mérite pas beaucoup de considération...

A une époque openDNS redirigeaient les requêtes google vers leurs propres serveurs (cf. http://blog.opendns.com/2007/05/22/google-turns-the-page).
Il me semble qu'ils ont arrêté mais j'aurai du mal à recommander un service avec ce genre de pratiques (même si c'est soit disant pour le bien des utilisateurs...)

J'en ai quelque unes aussi, envoyez moi un message privé.

Apparemment Chome OS aura un mode de fonctionnement offline via Google Gears.
De plus il sera aussi capable d'accéder à des médias stockés sur ses disques locaux (films, musique, ...).

Personnellement ce n'est pas les bugs qui me dérangent le plus mais la lourdeur de l'interface. Dès qu'une conversation dépasse la dizaine de participants (cas des waves publiques), ça se met à pédaler méchamment.
J'ai essayé avec Chrom(e|ium) pour voir si ça faisait une différence mais sans succès.

Ils ont intéret à optimiser leur bousin ou rajouter un paquet de serveurs avant la sortie publique sinon ils vont droit dans le mur...