Matthieu Moy a écrit 3257 commentaires

Pour vraiment bien faire, il faudrait gérer aussi le multi-utilisateur, parce que quand j'ai un fichier à copier pas urgent et qu'un autre utilisateur est en train de faire une copie (depuis un TX de la salle d'à coté), ça pourrait être intéressant d'attendre qu'il ai fini. Il faudrait aussi gérér la proximité sur le disque, parce que si j'ai deux fichiers A et B dans la file, qu'ils sont fragmentés, et qu'il y a des bouts de A à coté des bouts de B, ça peut être intéressant de les prendre au passage.

C'est fou ce que ça commence à ressembler à un bout du kernel, tout ça.

(par ailleurs, le scheduler d'IO de Linux n'est peut être pas parfait, mais c'est là qu'il faut travailler si on veut améliorer les accès concurrent, pas trop dans le gestionnaire de fichier).

> ça prendra globalement le même temps si il ne fait rien à côté,

Ça, ça dépends de ta config. Sur une machine avec plusieurs disques et/ou des disques réseau, ça n'est plus vrai du tout.

Et puis, si j'ai une grosse copie de fichier en tâche de fond, que je copie un petit fichier en même temps, j'ai pas envie qu'il me dise "Attends, je finie de recopier Debian-dvd.iso et je m'occupe de ton toto.txt juste après".

Bref, y'a des cas ou ça serait pas mal, mais il y a AMA plus de cas ou ça serait génant.

Tu as quand même pleins de cas ou tu as le choix dans l'implémentation d'une structure de donnée entre optimiser en mémoire ou optimiser en temps.

Il y a 15 ans, en général, il valait mieux optimiser en mémoire, mais aujourd'hui, il vaut mieux optimiser en temps.

Typiquement, pleins de programmes actuels gardent un cache en mémoire du résultat de certaines opérations pour éviter d'avoir à les refaire. Ca bouffe de la mémoire, mais c'est une optimisation quand même.

Tout ceci étant dit, il y a quand même beaucoup de gaspillage de RAM aujourd'hui et c'est dommage.

Je comprends pas trop l'intérêt. Justement, ton OS gère très bien les accès concurrent (on n'est plus sous DOS ;-) ), donc pourquoi ne pas le laisser faire ?

Si tu veux démarrer un nouveau projet, OK.

Pour contribuer à de l'existant, la majorité des programmes GNOME sont en C à ma connaissance. Un nouveau dans une équipe de dev qui inclue du code Java et C++ dans un projet en C, ça peut être une bonne source de troll, mais ça n'ira pas très loin ;-).

Ça n'est pas si clair.

Si tu as distribué le programme sous GPL, alors, tu t'es toi même engagé à filler les sources, t'es mal.

Sinon, on peut dire après coup : « Ah, bah, t'avais pas le droit de faire ça ». L'auteur du code GPL peut s'estimer laisé et demander le reste du code sous GPL en dédomagement, mais ce n'est pas dit qu'il l'obtienne.

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 » ;-).