Julien a écrit 160 commentaires

La GPL n'oblige pas strictement de contribuer en retour. Des utilisateurs peuvent très bien ne pas publier les modifs qu'ils ont fait sur leur serveur qu'ils ont en production et qui serait super plus efficasse que le serveur officiel.
A priori, c'est le cas en GPLv2 et c'est une des grosses différences de la GPLv3.

J'avais cependant entendu dire que la principale raison qui faisait que ces systèmes de fichier n'étaient pas plus utilisés etait la présence d'un méchanisme matériel. Ce méchanisme traduit les adresses et permet d'éviter d'utiliser toujours le même bloc pour la même adresse. Le périphérique s'use donc plus uniformément et les mécanismes mis en places au dessus pour faire tourner les adresses utilisées sont rendus inopérents.

Qu'en est-il ? Ces mécanismes vont-ils être supprimés avec l'apparition de FS appropriés ? Ces FS se limitent ils aux cas particuliers de l'embarqué où ces mécanismes sont absents ? Est-ce que l'augmentation de l'espace de stockage rend la création matériele de tels mécanismes plus compliqués ?

Ainsi que nokia/trolltech

L'état actuel des choses est le suivant : webkit sera intégré dans Qt 4.4 (dont dépendra KDE4) mais le moteur utilisé par konqueror reste KHTML.
Il existe aussi du code (par exemple la version de TRUNK, futur 4.1 de plasma) qui dépend de webkit.

Cet état de fait est du à l'existance de deux camps chez les développeurs KDE (trois si on compte aussi le camps de ceux qui s'en foutent).

Ceux qui poussent pour l'utilisation de webkit.
Je pense notamment à un ex développeur de khtml embauché chez Trolltech qui a participé à l'intégration de webkit dans Qt. Son principal argument est qu'utiliser webkit permettra un comportement similaire bug pour bug à Safari et donc la compatibilité d'un plus grand nombre de pages.
C'est aussi le cas de Aaron Seigo, l'actuel président de KDE e.V. C'est lui qui a fait le choix d'utiliser webkit dans plasma. Sa position est plus pragmatique et son principal argument est que webkit fonctionne bien, qu'il est intégré à Qt et que KDE ne pourra jamais mettre autant de ressources dans le développement de KHTML que celles qui sont mises dans webkit.

Dans le camps des contre, ce sont surtout les développeurs actuels de KHTML.
Il faut noter qu'ils ont tout d'abord eu des relations très tendues lors des débuts de webkit. Apple n'a parlé de ce fork que bien après l'avoir lancé. Pendant tout ce temps, il n'ont pas collaboré avec les développeurs de KHTML. Ils ne fournissaient au début que le code source (comme légalement nécessaire avec la LGPL) mais pas les commits indépendemment les uns des autres ... Bref, ils ont été loin d'être coopératif.
Les arguments de ce camp concernent donc premièrement cet aspet politique, utiliser webkit au lieu de KHTML revient à laisser les choix concernant un composant important de KDE à des entités externes. Ils soulignent aussi que les release de webkit ne correspondront pas à celles de KDE. Ainsi, il ne sera plus possible de sortir une nouvelle version mineure de KDE en cas de bug dans le moteur HTML. Enfin, puisque KHTML et webkit se sont séparé il y a maintenant pas mal de temps, passer à webkit signifierait abandonner tout le travail fait entre temps sur KHTML et revenir en arrière sur certaines fonctionalités.

Bref, le débat est loin d'être tranché et déchaîne pas mal les passions au sein de KDE. On peut cependant se féliciter que ce débat reste relativement technique et qu'il se cantonnne à ceux qui ont effectivement un choix à faire sans dégénérer en un troll stérile entre les deux camps.

Oui, donc Qt est écrit dans un langage qui n'est pas du C++ puisqu'il doit être précompilé par le préprocesseur MOC pour étendre certaines macro ... Sinon, un compilateur C++ n'est pas capable de compiler un fichier source Qt.

Qt a fait ce choix lorsque les différents compilateurs n'offraient pas un support complet du langage et ne l'a pas revu depuis. Les signals/slots peuvent par exemple être implémentés dans le langage (Cf implementation boost http://www.boost.org/doc/html/signals.html ) Il faut cependant bien dire que la syntaxe est peut être moins agréable avec cette implémentation.

quid de "super utilisateur" ?

Le sujet est en effet suivi par un grand nombre d'instituts aussi bien industriels qu'académiques.
Une thèse[1] vient justement de débuter dans le projet XtreemOS sur l'intérêt des VMs (consolidation, sécurité, HA) pour les applications au niveau des grilles. Un premier rapport étudiant les caractéristiques majeures des VMs par rapport aux mécanismes fournis par les approches SSI est d'ores-et-déjà dispo [2] !

[1] http://www.irisa.fr/paris/web/Member-Home-Pages/view-94.html (la page web devrait être mise à jour sous peu)
[2] http://hal.inria.fr/inria-00196717/en/

Pour ce qui est d'intel, la dernière fois que j'avais regardé, les spec étaient bien disponibles ... mais sous NDA !
On est loin des spec vraiment disponibles comme les propose AMD/ATI.

Mais si un code est sous double licence, j'ai parfaitement le droit de n'en accepter qu'une (la GPL), de travailler sur le code résultant, puis d'en publier une version modifiée.
Est-ce que c'est sympa, c'est un autre débat, mais c'est légal, ça c'est sûr.

On délivre un pli, ok ... Mais délivrer un logiciel, ça me semble bizarre, on ne te l'amène pas dans les mains là, on le met à disposition ...

Oui, sauf que Phonon et GStreamer n'ont rien à voir.
GStreamer est effectivement une "belle lib bien complexe qui fait le travail", comme xine ou arts.
Par contre Phonon est une simple API qui ne fait aucun travail, mais qui est une couche d'abstraction du backend audio utilisé (xine, xmmm ou ... GStreamer).
Dans le monde des bases de données, ça revient à comparer postgreSQL et ODBC ... ça n'a pas de sens.

oui, sauf que j'ai pris le cas particulier d'une fonction de [[1,n]]² -> R ...

Ah non !
En classe, on apprend que pour A = B.C la valeur de A[i][j] est égale à la somme de B[i][k].C[k][j] pour k=1 à n.

Qui a parlé de boucle là ?
Soit, à la limite, on peu considérer que le "somme pour k de ... à ..." ressemble à une boucle, mais il n'y a pas de notion d'ordre contrairement à une boucle !

Par contre, les deux autres boucles, tu les as ajouté parce que c'est ta manière de penser en impératif.

----------

En fonctionnel, tu peux faire ca de la manière suivante (je prend pas la syntaxe CAML puisqu'elle fait peur)

soit les deux fonction B et C de [[1,n]]^2 dans R qui représentent les deux matrices du même nom (une fonction, une matrice, c'est la même chose finalement ...)

// calcule B[i][k].C[k][j] (on aurait pu en faire une fonction anonyme, mais ça fait peur ...
prod(B,C,i,j,k) := B(i,k)*C(k,j)

// la fonction A qui représente la matrice du même nom
// sum qui est classiquement fourni par une bibliothèque prend en paramètre deux entier (les bornes) et une fonction à un paramètre (prod dont on a fixé tous les paramètres sauf un)
A(i,j) := sum(1,n,prod(B,C,i,j))

Il faut savoir ce qu'on veut. Quand une entreprise refuse de publier un code sous prétexte qu'il n'est pas assez propre, combien ici trouvent qu'il s'agit d'un argument bidon ?

Quand une entreprise prend la peine de publier son code sous licence GPL, sans qu'à priori, elle n'ait rien à en retirer, les commentaires se plaignent du système d'install qui n'est pas bien foutu ...

Mais merde, si c'est un code de simulation, il devait être installé sur quelques machines à peine. Tout le monde n'a pas besoins de faire des simulations de méchanique des fluides sur son PC ... Alors oui, je pense que le système d'install est mal foutu, mais ça ne me choque vraiment pas.

C'est maintenant à la communauté de polir le système d'install et tout ce qui n'était pas utile chez EDF, mais qui le devient maintenant. Vous vous rappelez, "chacun implémente ce qui lui sert, et au final le logiciel n'en est que meilleur" ...

Merci beaucoup de cette réponse qui m'incite à tester l'upgrade au leiu de choisir la solution de facilité et la réinstallation, j'essaye ca dans la semaine prochaine.

Et quand on a des paquets installés depuis des dépots tiers (codecs ...) ?
Puisque ces codecs sont maintenant gérés par la distribution, j'imagine qu'il faut les desinstaller, virer les lignes du sources.list puis mettre a jour ...

Si c'est effectivement la marche a suivre, ma question est alors : comment supprimer tous les paquets d'un dépot donné, comment être sûr qu'on n'en laisse pas un qui va tout casser ?

Oui, mais adobe sort le porte monaie pour faire installer le lecteur flash sur les machines avant qu'elles arrivent chez l'acheteur. Qui dans le libre peut s'amuser a faire pareil ?

Aujourd'hui, flash, c'est un standard de fait, pas mal documenté. GNU a pris la bonne décision en choisissant d'en implémenter un lecteur. Pas la peine d'inventer un niemme standard !

http://mail.google.com/mail/help/paper/

http://www.google.com/tisp/

Que moins d'1 % des utilisateurs demandent cette fonctionnalité ?

Je dois vous annoncer en exclusivité que le prochain Gnome sera impossible à exécuter. En effet, une étude récente démontre que 87,3% des utilisateurs préféreraient ne pas utiliser d'ordinateur ...

Plus sérieusement, j'espère que ce n'est pas la philosophie de Gnome, et pour tout dire, je n'en ai pas l'impression.
Il suffit de voir l'emphase qui est faite sur l'accessibilité aux handicapé ou les produits pour les développeurs (99,418% des utilisateurs haïssent les développeurs ... ;p)

Je pense que comme dans de nombreux logiciels, c'est plus une question d'immobilisme de certains, ou simplement l'absence d'une personne intéressée pour intégrer ça ...

> La feature "je singe les interfaces graphiques des années 1990".

Gnome a préféré une interface dont, déjà dans les années 90, personne n'aurait voulu ...


pas taper, pas taper :)

En même temps, une enveloppe, c'est pas épais, et "pas épais" + "pas épais" = ... "pas épais" :)
Je suis pas sûr qu'après une heure à dire "a voté" tu sois suffisamment attentif pour remarquer quelqu'un qui l'aurait fait.
Par contre, ça se remarque si le nombre de votes est différent du nombre de votants et si c'était vraiment fait à grande échelle ça se saurait. C'est donc pas un moyen de fraude viable à mon sens, mieux vaut faire voter des morts ... ou pirater les machines à voter.

Ceci dit, je pense plutôt qu'il parlait de personnes qui mettent deux bulletins dans l'enveloppe par inadvertance, parce qu'ils étaient un peu collés et qui se retrouvent du coup avec un vote nul.

Certain sur ce site ont tendance à faire passer leurs opinions personnelles comme des faits avérés ou même à le sous-entendre pour faire passer l'idée de manière encore plus sournoisement.
Quand c'est dans un commentaire ... on y peut pas grand chose ...
Mais sur les news, je trouve ça quand même un peu pénible. Celle-ci en est l'exemple type.
Le pire est que pour attirer le chaland, on est prêt à annoncer tout et n'importe quoi, au milieu de ce foutoir de contre vérités, bien malin celui qui extraira les faits.

La technologie de stockage à haute densité est enfin entièrement disponible sous Linux.

Certes, on sait écrire sur les disques Blue Ray depuis Linux. dvd+rw-tools le propose depuis la version 7.0 [1]. Version dont je trouve des références qui remontent à ... octobre 2006 [2].
Je ne pense donc pas que ce soit là la nouveauté qui fait du bruit en ce moment.

Tout d'abord, le stockage à haute densité permettra aux utilisateurs de Linux de pouvoir envisager des sauvegardes performantes.

Idem.

Le deuxième intérêt est de pouvoir lire maintenant les DVD légalement acquis grâce aux logiciels FFMpeg et surtout MPlayer.

Là on rentre dans un autre sujet. Une équipe de hackers a récemment réussi à profiter d'une faille d'un logiciel Windows pour passer outre la protection des films en vente sur supports HD-DVD ou Blue Ray.
Ce logiciel est illégal selon le DMCA étasunien, sa diffusion ainsi que son utilisation sont illégales aussi bien aux États-Unis qu'en France.

Contrairement à ce qui est dit, on ne permet lire maintenant les DVD, mais les HD-DVDs ou les Blue Ray, enfin passons sur ce détail.

J'ai par contre beaucoup de mal à comprendre pourquoi le légalement acquis présent dans la news.
Est-ce qu'il est impossible de lire un HD-DVD volé ... non.
Est-ce qu'il est légal d'utiliser ce logiciel pour lire un HD-DVD légalement acquis ... non.
À part entretenir la confusion, quel est le but alors ?

De plus le grâce aux logiciels FFMpeg et surtout MPlayer sème à nouveau la confusion.
Bien sur, un logiciel est nécessaire pour déchiffre et décoder le flux, mais ce n'est pas tout, il faut aussi fournir la clef à ces logiciels. C'est là qu'intervient notre logiciel illégal qui va récupérer la clef contenue dans un autre logiciel ...
On est donc pas encore au stade où un logiciel linux est capable de lire un HD-DVD du commerce, et encore moins au stade où un logiciel linux est capable de lire légalement un tel média.

Ici, l'histoire se répète. Lors de l'apparition des DVD de première génération, il avait fallu attendre libdvdcss2 pour pouvoir les lire.

Oui, mais non. Comme expliqué précédemment, les logiciels cités ne sont pas capables de décrypter quoi que ce soit, contrairement à libdvdcss2.
Rien à voir donc.

Alors s'il vous plaît, stop à la désinformation.
Il serait au moins appréciable que lorsqu'une news de ce type est publiée, un modérateur puisse l'éditer pour signaler ces petites ambiguïtés.

Pourquoi ne pas proposer un lien spécial pour les signaler ?
Il pourrait aussi permettre de signaler les erreurs d'orthographe et autres tournures malheureuses. On éviterait ainsi les nombreux commentaires de ce type qui ont tendance à foisonner.


[1] http://fy.chalmers.se/~appro/linux/DVD+RW/Blu-ray/
[2] http://bugs.gentoo.org/show_bug.cgi?id=149831
[3] http://www.backuphddvd.net/

Maintenant que PyPy est sur la bonne voie, est-ce que l'équivalent va être écrit pour Caml ?

Le jour ou l'UE aura financé PyPy et CaCa, on peut dire que la boucle sera alors bouclée.

Uhm, ok ... --> []

Claude Allègre pour ne citer que lui ...

Mais oui, prend les pour des jambons...

Ou pour des jésus, c'est plus local.