Matthieu Moy a écrit 3251 commentaires

Au passage, question stupide: Comment ça s'est passé pour le passage v1 -> v2 ?

> Sous license BSD, Linux serait peut-être mort depuis longtemps.

Il me semble qu'il existe quelques exemples de noyaux sous license BSD qui ne sont toujours pas morts.

Note qu'on peut aussi la faire dans l'autre sens:

« Sous license GPL, la GNU libc serait peut-être morte depuis longtemps »

Par ailleurs, il y a quand même un monde entre la GPL et la BSD. Je comprend bien que des développeurs veuille empécher leur code de devenir propriétaire, mais franchement, moi, je me fiche pas mal de la licence des autres bouts de code qui utilisent le mien. Si un soft propriétaire veut utiliser mon code libre, je préfère ça plutôt qu'il utilise du code propriétaire à la place, tant que mon code reste libre.

> 1/ Rien ne l'empêche de développer un module d'interfacage en LGPL, ou de
> s'arranger pour que son code ne soit pas lié à du code GPL.

Si, il y a un truc qui t'en empêche : La GPL. Si ton programme, globalement, contient du code GPL, alors la totalité doit être GPL. Le fait que ton programme, incompatible GPL, passe par une interface LGPL pour y accéder, n'y change rien.

C'est le bit "setgid", qui veut dire que ce que tu met dans le répertoire appartiendra automatiquement à ce groupe.

> Un débutant n'aura jamais une telle configuration (home sur NFS ou RHEL) ...

En entreprise, si.

Attention, ne te méprends pas sur ce que je dis. Je ne dis pas « GNOME est mieux, la preuve, les grosses boites l'ont choisi », mais « GNOME devrait être mieux vu le nombre de gens qui investissent dedans ». Ce n'est pas moi qui dirait qui est mieux en pratique, puisque tout le monde sait que c'est ion3 le seul WM valable ;-).

> Avec les futurs systèmes de gestion de version distribués

Avec bazaar ( http://bazaar.canonical.com/(...) ), on peut parler au présent en fait. (aussi développé par canonical, justement, en attendant que bazaar-ng soit assez mûr).

sed, perl, vi, et sans doute d'autres.

KDE marche sur solaris, c'est une chose, mais à ma connaissance, SUN ne supporte pas KDE officiellement, et n'investi pas dans son développement.

Mais c'est vrai que le paradoxe, c'est que KDE est quand même très populaire, sans doute plus que GNOME sur les machines SUN.

Dans la série des bug trackers, il faut aussi citer malone, développé par canonical.

L'idée est de tracker les bugs du produit dans différentes distributions, en distinguant éventuellement les bugs de la version packagée et ceux du la version "upstream". C'est encore en développement, mais à terme, si j'ai bien compris, il sera capable d'aller chercher dans les bugzillas des autres distributions par exemple.

C'est par là que ça se passe:

https://launchpad.net/malone/(...)

> Existe-il des projets permettant des éditions de fichiers locales en ligne ?

Un peu à la manière d'un Wiki, oui, ça existe !

https://launchpad.net/rosetta(...)

Ce qui est marrant, c'est que pourtant, la majorité des entreprises qui investissent dans un bureau investissent dans GNOME en non KDE (RedHat, Novel, SUN, ...).

Celui d'avril 2005 est pire qu'une introduction, il est plein d'énormités (de mémoire, par exemple, on nous explique que le RTL, c'est has been, que maintenant, on code en VHDL synthétisable -- sachant que RTL, c'est le niveau d'abstraction, et VHDL un language à ce niveau d'abstraction). L'autre, j'ai pas lu.

Moi, j'ai mes fichiers *.fig dans un répertoire fig/ et chaque fichier X.fig est accompagné d'un X.scale qui donne l'échelle (pour agrandir ou réduire). Mon Makefile contient:

FIG2PDFTEX=fig2dev -L pdftex_t -m `cat $(srcdir)/$(FIGDIR)/$*.scale` -p $(FIGDIR)/$*.pdf $< $@
FIG2PDF=fig2dev -L pstex -m `cat $(srcdir)/$(FIGDIR)/$*.scale` $< $(FIGDIR)/$*.pstex; \
epstopdf $(FIGDIR)/$*.pstex -o $(FIGDIR)/$*.pdf

$(FIGDIR)/%.pdftex_t: $(srcdir)/$(FIGDIR)/%.fig $(srcdir)/$(FIGDIR)/%.scale
$(FIG2PDFTEX)
$(FIG2PDF)

$(srcdir)/$(FIGDIR)/%.scale ::
echo 0.7 > $@

puis \input toto.pdftex_t

(a adapter pour ta config)

1) se méfier des options -z et -j de tar, dispo seulement sur GNU tar. Pour des scripts de backup, la probabilité de devoir faire tourner le script sur une machine non GNU est non nulle...

2) Pour extraire un fichier d'un .tar.gz, il faut décompresser l'ensemble (pour obtenir le .tar -- même si on ne l'écrit pas forcément sur le disque), et ensuite extraire le fichier. Sur un backup de plusieurs giga, c'est pas pratique.

Question stupide, mais pourquoi lynx, sachant qu'il y a aussi w3m et links en mode texte, et avec pleins de fonctionalités en plus ?

> J'ai fait une demande chez gna déjà, j'ai pas encore de réponse, j'attends.

Les admins sont en vacances jusqu'au 20 aout ;-).

1) Es-tu sur d'avoir besoin de CVS comme gestionnaire de versions? C'est à peu de chose près le pire des gestionnaires de versions aujourd'hui. Si tu commences un projet, je te suggère assez fortement de regarder au moins bazaar ( http://bazaar.canonical.com/(...) ) et/ou subversion ( http://subversion.tigris.org/(...) ). Pour l'hébergement, tout ça existe chez http://gna.org(...) .

2) Si tu veux faire du CVS (ou même autre chose), entraines-toi déjà avec un repository local, sur ta machine. Si tu fais des conneries sur le serveur de sf.net, c'est difficile a annuler.

3) la commande que tu cherches est "cvs import".

Merci pour les précisions (je devrais peut être plutôt dire « correction » ;-).

A ce moment là, il n'y a plus tellement de logiciel. C'est le matériel qui doit tout gérér (y compris les codecs pour de l'audiovisuel). Adieu l'évolutivité : Le jour ou un meilleur algo de compression sort, il faut ajouter un composant matériel à ta machine.

Un logiciel « DRM aware » doit forcément manipuler les données en clair en interne. Si tu autorise des modifications du logiciel en question, il est toujours possible d'ajouter une fonctionalité « enregistrer en clair » sans limitation.

Donc, à partir du moment ou ton logiciel gère les DRM de manière efficace, il doit avoir un moyen d'empécher sa propre modification. Si c'est un logiciel « libre », au mieux, tu auras un logiciel qui devient incapable d'accéder au contenu si tu le modifie.

Trop tôt pour dire comment Apple va s'y prendre exactement, mais si ils veulent vraiment faire un truc sécurisé, ils le peuvent: En ne livrant qu'une version cryptée de MacOS (ou d'une partie vitale du système), dont la clé de décryptage se trouve dans la puce. La puce n'accepterait de décrypter ce morceau que si tu montre patte blanche. Ton étape 2 deviendrait « On décrypte le bout dont on a besoin sans la clé privée et on grave l'image binaire » ...

Maintenant, Apple peut aussi très bien faire un truc pas sécurisé juste pour dissuader les gens, mais ils prennent le risque que monsieur tout le monde puisse installer un MacOS piraté sur son PC (illégalement).

Légal ou pas en France, l'auteur a eu un certain nombre d'ennuis avec la justice, et a du faire du reverse-engineering, sans quoi on ne pourrait pas lire un DVD protégé sous Linux. L'EUDC devrait d'ailleurs rendre ça illégal un jour ou l'autre.

Je ne vais pas accueillir les DRM à bras ouverts sous prétexte que la France n'est pas le pire des pays de ce point de vue là.

De toutes façons, un patch n'est intégré au noyau qu'après avoir été testé un certain temps (je crois qu'un séjour dans la branche -mm est obligatoire). Donc, même si la fonctionalité était prête un jour avant la "deadline", elle ne serait pas intégrée pour autant. Les 15 jours ne correspondent pas au temps pour développer une nouvelle fonctionalité, mais au temps pour convaincre Linus d'appliquer le patch.

> Rien n'empêchera donc a priori d'installer autre chose que MAC OS sur ces plates-formes.

C'est dit clairement par Apple, en effet. Le verrouillage proposé n'est clairement pas le plus embetant, mais à mon gout, c'est un pas dans la mauvaise direction.

Avant, on pouvait dire « Oui, mais ça sera désactivé par défaut, et puis toutes les machines ne l'auront pas ». Aujourd'hui, on peut dire que tous les futurs Macs auront une puce TPM activée. De la à supposer qu'Apple l'utilisera pour iTunes par exemple, il n'y a qu'un pas.

> Concernant les DRM pour la musique protégée, bah oui, les majors cherchent à limiter le piratage, et ce n'est pas nouveau.

Un problème des DRM pour de la musique, c'est que ça ne gène que les gens honètes. Le pirate pourra toujours récupérer un enregistrement (au pire, analogique de bonne qualité) sur le net. Le mec honete qui veut acheter des MP3 sur le net légalement et sous Linux, lui, il est bien emerdé.

Un autre problème, c'est que la notion même de DRM est incompatible avec le logiciel libre si elle veut être efficace: Si tu fais un logiciel libre avec gestion des DRM, il y aura toujours possibilité de faire un fork ou la gestion des DRM est désactivée (cf. la gestion des protections implémentée mais désactivée par défaut dans kpdf par exemple.). Résultat, pour lire du contenu protégé, il faut passer par un logiciel propriétaire. Pour lire du contenu protégé sous un OS alternatif, il faut attendre que ces gentils messieurs aient porté leur soft sous ton OS (tu as déjà essayé de lire un DVD crypté sous Linux, je suppose).

> J'aimerais bien entendre la réponse de la "hotline" de ce major qui répondra
> à Luce et Henri qu'ils devront racheter tous leurs titres qu'ils avaient
> sauvegardé sur disque, uniquement parce que leur ancien portable a cramé.

Des fois, la réalité dépasse la fiction. J'ai un copain qui a du réencoder tous ses titres parce que le soft de compression qu'il utilisait avait gentilment protégé les morceaux encodés (sans lui dire), et qu'il a perdu la clé privée suite a une réinstallation. Faut croire que ça a pas dérangé l'auteur du soft en question que ça fonctionne comme ça.

> Une fois de plus, c'est le choix de la personne/major qui publie son titre :
> charge à elle de se mettre les clients sur le dos...

Oui, mais la personne qui publie son titre est rarement celle qui décide de l'application des DRM ou non. Entre les deux, il y a la maison de disque.

Bref, perso, j'ai pas envie de me retrouver dans un monde ou tous les contenu multimédia sont protégés par DRM, et j'ai pas l'impression qu'on aille dans la bonne direction.

> si les DRM permettent de limiter l'aspect du piratage des softs dits
> propriétaires, je ne peux qu'applaudir des 2 mains, et attendre que
> les gens se tournent vers de vraies alternatives ...

100% d'accord, sachant que pour du soft, en général, la boite qui décide d'appliquer le DRM est aussi celle qui a développé le soft (pas de majors comme intermédiaire).