Sytoka Modon a écrit 4546 commentaires

Il est vrai qu'en ce moment, gauche d'auteur fait un peu penser à la gauche politique. C'est surtout du, à mon avis, au fait que la droite gouverne en France et en Europe et que sur la question des brevets logiciels, on ne peux pas dire que la position du gouvernement ni de la commision ne soit très claire. Mais cette tendance, gauche d'auteur - gauche politique, est je pense passagère...

Et puis, même si on perds le jeu de mot originel, on peux en trouver d'autres dans les traductions et je te propose notament celle-ci : Droit d'auteur, droit -> rectiligne, carré... Gauche d'auteur, gauche -> tordu, bircornu... On voit donc sous-jacent le livre d'Eric Raymond : "La cathédrale et le bazar". Deux modes de développement, l'un plus associé historiquement aux logiciels propriétaires et l'autre plus lié à un développement communautaire libre, l'un qui utilise le copyright et l'autre le copyleft.

Comme quoi, une traduction peut aussi, à mon avis, enrichir un sens...

Ah bon, je croyais qu'en France, c'était 50 ans sauf si on est "mort pour la France" dans quel cas cela double (cf St Exupéry).

Sur l'autre point, a mon avis, on doit aussi expliquer à un débutant ce qu'est une licence virale... Alors mettre gauche d'auteur ou virale, je préfère le premier ;-) Au moins, on fait une action civique et il pourra utiliser la gauche d'auteur dans un autre contexte (notament publication de livres).

Un livre édité sous gauche d'auteur met en valeur une volonté claire de l'auteur. Allez dire que vous publiez vos bouquins sous une licence virale !

Bref, les vers, c'est plutôt du coté de bricosoft qu'il faudrait allez les chercher ;-)

Et pourquoi pas "gauche d'auteur" ? C'est sous ce terme que pas mal de copain désigne le copyleft et la "viralité" de la GPL. Au moins, l'appelation a une connotation positive car quasiment tout le monde accepte le bien fondé de droits d'auteur (raisonable ... pas 60 ans après la mort du créateur comme Disney l'a imposé aux USA).

Tu as de bonnes secretaires alors. La plupart des secretaires que j'ai vu ne maîtrise absolument pas Word (ni excel). Elles sont par exemple incapables de faire la moindre macro ni de se construire (voire d'utiliser) une feuille de style...

A leur décharge, elles font tout un tas de truc en parallèle (dont pas mal de compta) et n'ont pas vraiment le temps de s'investir dans leur suite Office.

Bon OK, je n'ai jamais dis que Darwin était un noyau nul. Mais n'est-il pas plus intéressant de reprogrammer les fioritures de Darwin dans FreeBSD par exemple que de développer Darwin lui-même.

Par ailleurs, je n'ai jamais trop vu l'intérêt du micro noyau Mach avec un OS monolithique par dessus. Autant Hurd est passionant, autant là, je suis plus dubitatif. En plus Hurd a laché Mach pour L4 pour des raisons techniques...

Ca n'a rien a voir... Darwin est un fork BSD dédié principalement à OSX. Sans OSX, il perds de son intérêt.

Apache et Caudium sont deux serveurs web mais très différents en interne. Idem pour ton autre exemple.

J'ai juste dis qu'il y avait déjà pas mal de BSD différents et donc un fork suplémentaire, Darwin, n'avait à mon sens aucun intérêt.

Quel intérêt ? Il y a déjà tous les autres BSD, Linux et Hurd ! Il y a bien mieux à faire ailleurs. Darwin a surtout un intérêt avec OSX par dessus.

Bon facile le troll... mais merci les licences de type BSD ;-)

Oui, mais cela ne marche pas avec les applications gnome et les bonnes vielles applications. Bilan, gnome développe sa propre couche et donc on a tout en double et les bonnes vielles applications sont mises petits à petits de coté alors qu'elles marchent super bien et sont super utiles dans les scripts.

Bref, ta vision est une vision un peu égoiste des choses. Et comme je l'ai dis plus haut, on peut très bien monter un système de fichier nfs en asynchrone.

Moi ce que je vois, c'est qu'une partie des personnes de kde et de gnome ont pour objectif d'enfermer les utilisateurs dans leur environnement. Moi, cela ne me gène pas d'utiliser une application kde avec une application gnome au coté d'un bon vieux gv qui a une interface pas du tout gnome ou kde mais qui est, à mon sens, pas égalé pour lire des fichiers postscripts.

Rien n'empêche de concevoir un système au niveau du noyau qui gère les systèmes lents... Intermezzo ou Codafs ont par exemple des options pour marcher même si la connection est déconnecté.

Ensuite sur la latence, NFS marchait très bien sur des hub a 10Mb il y a 10 ans. Donc pas besoin d'avoir un réseau gigabit (même si c'est mieux). Toujours avec NFS, il y a une option async pour être en asynchrone et une option intr pour que la connection ne soit pas bloquante. On peux certes mieux faire et c'est justement là ou c'est dommage, car la plupart des développeurs de gnome-vfs et de kio ont, j'en suis sur, des compétences pointus en informatique pour faire ce genre de chose.

Il y a aussi plan9 qui a l'air de faire tout un tas de chose sympathique...

Bref, les API systèmes ne demandent qu'a être améliorer si on arrive effectivement avec quelque chose de cohérent.

Ce qui est vrai pour Corba/bonobo, DCOP -> DBUS ne l'est pas forcément sur les systèmes de fichiers.

D'un coté, on a un bus orienté bureau avec un savoir faire pas énorme à l'époque. De l'autre, on a affaire a des systèmes de fichiers distribués. NFS, Samba... ce ne sont pas des trucs qui n'existaient pas en 2000 ! Ca marchait déjà très bien.

Au niveau des automounteurs, il y avait déjà autofs et amd qui marchaient aussi + ou - bien. Mais enfin, ils sont utilisés en production depuis des années.

Tout ca pour dire qu'il y a une base de personnes très compétentes en systèmes de fichiers qui auraient pu se pencher la dessus plutôt que de construire des trucs très liés au environnement de bureau.

Fuse est du kernel space comme tu le dis pour une partie. En pratique, a pars le noyau fuse, tout est renvoyé en mode utilisateur ! C'est pour cela que tu as des modules fuse en python par exemple. Il y a aussi des modules d'autoversionning...

La partie kernel space est donc juste une interface. Le plus gros problème est donc le passage d'un mode à l'autre qui grève les performances. C'est pour cela qu'il y a un nouveau système de fichier dans les derniers noyaux (je ne me souviens plus de son nom) pour améliorer tout cela.

Franchement très bien ton terminal pour gnuplot. Il va être intégré dans gnuplot ?

Question bête : avec les changements dans gcc, est-il possible de compiler la version 3.0 et la version 3.5 avec le même compilateur ?

En effet, gcc ayant pas mal évolué, on a été obliger de modifier le code source pour tenir compte de cette évolution. Il n'est donc effectivement pas sur que si l'API n'ait pas changé, le code soit en pratique compatible.

Heureusement, le C++ est un peu plus stable aujourd'hui.

> donc l'os ne pouvait pas founir ce service à l'époque de l'intégration
> systèmatique de gnome-vfs et kioslave

Sauf qu'on pouvait à l'époque mettre toute l'énergie disponible à construire une API propre (en gros Fuse) plutôt que de développer deux solutions transitoires.

Personnellement, j'utilise Linux depuis 10 ans tous les jours et je ne me suis quasiment jamais servis ni de l'un ni de l'autre. Ne pas les avoir n'aurait en aucune façon modifier mon utilisation de Linux.

Si tu veux un système qui marche pour tous, il n'y a pas le choix, seulement deux solutions :

- une gestion par le noyau

- une gestion par bibliothèque

La gestion en mode noyau peut être faite le mieux possible, c'est à dire mettre le plus de code possible en mode utilisateur. C'est justement le cas de Fuse.

La gestion par bibliothèque a peu de chance d'être générique. Si on souhaite que cela marche quasiment partout, il faut l'intégrer au coeur de la libc. En effet, la libc est linké avec 99% des executables (au pif). Aucune autre bibliothèque n'a cette possibilité.

Mais il y a aussi d'autre problème, les fichiers de type fish:/..., cela est-il conforme à la norme POSIX ? On a critiqué pendant longtemps les C:, D: ... de Microsoft, les UNIX préférant le système de fichier unifié où tout est sous /.

Personnellement, je trouve cela génial de pouvoir intégrer un serveur ftp distant dans mon arborescence / et que l'accès au serveur ftp soit transparent, un peu comme NFS qu'on oublie facilement en tant qu'utilisateur.

Il faut effectivement améliorer la facilité pour un utilisateur de monter un système de fichier distant, améliorer la robustesse de l'ensemble mais cela me parait bien plus positif que de travailler sur les VFS de gnome ou de kde.

Après, on va me dire que, ragnagna, Fuse ne marche pas sur tous les UNIX propriétaire, ne marche pas sous Windows... Et bien tant pis pour eux ! Ils n'ont qu'a faire le portage. Le code source est accessible à la lecture pour tous ;-)

Non, j'ai l'impression d'être cohérent dans l'ensemble ;-)

le VFS de gnome et celui de kde ne sont pas compatibles et ne sont pas utilsables par des applications tierces. Ce n'est au "framework" utilisateur de faire ce genre de chose. Par exemple, "vi" sais-t-il utiliser les url kde du type fish:// ? Bref, ces VFS sont des doublons qui enferment les utilsateurs dans l'un ou l'autre des environnements. Fuse au contraire, malgré des défauts, à l'avantage de s'ouvrir à tous et d'enfermer personne. Bref, je pense que les développeurs des VFS de gnome et de kde devraient mieux travailler sur une couche de plus bas niveau qui puisse servir a TOUS les programmes de manière transparente (je ne veux pas de gconfd, oaf, kdeinit... lorsque je lance vi ou latex !).

Pour la partie son, je ne suis pas sur qu'esd soit beaucoup mieux qu'arts. J'ai l'impression que jackd est de plus en plus utilisé ! Tout cela n'est en rien lié au serveur X. Pourtant, il est logique que le son suive par défaut la même route que X.

Bref, je ne critique pas le fait d'unifié les systèmes, je critique le fait que gnome et kde ont par le passé unifié leur système respectif mais par la même un peu exclu le reste. Compte le nombre de fois ou sur dlfp des personnes ont réclamés un version équivalente gnome d'un logiciel kde et réciproquement. Personnellement, je me fiche pas mal de l'aspect bureau unifié pour le look des applications que j'utilise mais j'en ai un peu marre, il est vrai, que gnome et kde cherchent à m'enfermer sur leur bureau.

Je suis d'accord. Le couche VFS dans gnome et kde est une très mauvaise chose. Les développeurs feraient mieux de travailler sur fuse sous linux et quelque chose d'équivalent sous les BSD...

Idem pour le serveur de son... Chaque aplication doit avoir son backend (oss, alsa, arts, esd...) alors qu'en tant que simple utilisateur, on demande juste à pouvoir entendre le son ! C'est tellement le bordel que ce n'est pas intégré dans ssh. Je ne sais pas pour vous, mais l'unification du protocole X est vraiment une merveille pour tous les UNIX depuis DES ANNEES. Il suffit de faire un ssh -X pour ne plus pouvoir s'en passer. Ecouter du son sur une machine distante est bien plus complexe, tellement complexe que bien peu l'utilise.

Heureusement, freedestop essaye de mettre pas mal de chose à plat. Cependant, cela prend pas mal de temps à se mettre en place. Le son serait plus compliqué que l'affichage graphique ? Je trouve dommage cette dépense d'énergie dans les deux environnements gnome et kde qui pourrait être bien plus bénéfique pour tous si elle était faite de manière communautaire comme X-Windows.

A ma décharge, je n'y connais pas grand chose en multi-média. Je suis un utilisateur plus que lambda. Mes propos sont peut être un amas de bétises.

Avec le premier ssh, tu lances un netcat (ou un socat) sur la machine distante et hop, tu as un acces sur la machine distance avec redirection de terminal...

Bref, d'après ce que j'ai compris de ton truc, j'irais voir de ce coté là.

Pour moi, rien n'empêche de modifier la licence BSD d'une bibliothèque pour la mettre en GPL. L'inverse n'est par contre pas possible.

Donc, cela n'empêche pas /a priori/ l'utilisation de bibliothèque sous licence BSD avec l'IDE EiffelStudio.

Je pense qu'il en ai de même avec les licences de type MIT ?

Depuis la séparation avec Sylpheed, version original, est-il prévu à terme de changer de nom ? Je trouve que cela pénalise les deux projets.

Pourquoi pas Sylclaws !

J'avoue que je suis personnellement en 2.6.15 et que qemu+kqemu marche vraiment très bien. WindowsXP est d'une réactivité surprenante dans la machine virtuelle Linux ;-)

Il existe aussi le YAML pour les fichiers de configuration. Cela résoud les problèmes de parseur, c'est léger et simple à modifier dans vi.

Pour les grosses structures, les scientifiques ont aussi des solutions qui marchent depuis des années, binaire et multiplateforme : HDF par exemple.

Je ne dis pas que HDF résoud tous les problèmes, simplement qu'il faut arréter de nous mettre du XML partout.

Faut pas exagérer non plus. Ca fait pas mal d'année que les modules Perl utilise le YAML pour spécifier leur fonctionalité.

Bref, le YAML est un truc qui tourne et n'est pas près de s'arréter. Cela m'étonnerais fort que les développeurs Perl remplacent les fichiers YAML par du XML !

Pour ma part, tous mes fichiers de configuration sont en YAML (ou sont un simple systeme clef=valeur). Il est hors de question d'utiliser du XML ou du gconf.

Mais tu as déjà tout cela dans Perl dés aujourd'hui et dans toute distribution linux (et en plus généralement installé par défaut).

Tu ne fais pas de la ligne de commande pour te prendre un objet illisible en retour. Il y a donc bien de la place entre le shell et le langage de script. Le problème de Microsoft est que son shell est minable et que son langage de script n'est pas beaucoup mieux...