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 ?
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 ;-).
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.
> 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.
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).
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.
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:
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.
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.
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.
[^] # Re: Au lieu de te prendre la tête
Posté par Matthieu Moy (site web personnel) . En réponse au journal La mémoire ne se trouve pas dans les poubelles ... où rarement. Évalué à 3.
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.
[^] # Re: navigateur de fichier et gestion de l'ordonnancement des tranferts.
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Aperçu en français de GNOME 2.12. Évalué à 2.
[^] # Re: Pour faire simple...
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Aperçu en français de GNOME 2.12. Évalué à 3.
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 ;-).
[^] # Re: Compatibilité BSD ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche La GPL version 3 pourrait sortir en 2007. Évalué à 3.
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.
[^] # Re: Adoption
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche La GPL version 3 pourrait sortir en 2007. Évalué à 4.
[^] # Re: Compatibilité BSD ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche La GPL version 3 pourrait sortir en 2007. Évalué à 4.
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.
[^] # Re: Compatibilité BSD ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche La GPL version 3 pourrait sortir en 2007. Évalué à 3.
> 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.
# setgid
Posté par Matthieu Moy (site web personnel) . En réponse au message drwxrwsr-x 2 toto toto 4096 mai 9 11:08 CACHE/. Évalué à 4.
[^] # Re: Pour faire simple...
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Aperçu en français de GNOME 2.12. Évalué à 3.
En entreprise, si.
[^] # Re: Pour faire simple...
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Aperçu en français de GNOME 2.12. Évalué à 2.
[^] # Re: Coopération inter-distributions
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Lancement de Debian Common Core. Évalué à 3.
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).
[^] # Re: Fôte
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Lancement de Debian Common Core. Évalué à 3.
[^] # Re: Pour faire simple...
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Aperçu en français de GNOME 2.12. Évalué à 1.
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.
# meta-bug-tracker
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Derrière vos distributions et logiciels favoris... le retour.. Évalué à 6.
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/(...)
[^] # Re: Derrière vos logiciels favoris...
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Derrière vos distributions et logiciels favoris... le retour.. Évalué à 6.
Un peu à la manière d'un Wiki, oui, ça existe !
https://launchpad.net/rosetta(...)
[^] # Re: Pour faire simple...
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Aperçu en français de GNOME 2.12. Évalué à 4.
[^] # Re: linux mag
Posté par Matthieu Moy (site web personnel) . En réponse au journal Compiler pour un FPGA. Évalué à 1.
[^] # Re: \_o<
Posté par Matthieu Moy (site web personnel) . En réponse au message conversion de gif en eps. Évalué à 3.
puis \input toto.pdftex_t
(a adapter pour ta config)
[^] # Re: Euh...
Posté par Matthieu Moy (site web personnel) . En réponse au journal Sauvegarder sur DAT en activant la compression. Évalué à 4.
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.
# alternatives ...
Posté par Matthieu Moy (site web personnel) . En réponse au message [???] lynx et les accents. Évalué à 2.
[^] # Re: cvs import
Posté par Matthieu Moy (site web personnel) . En réponse au message CVS et sf.net. Évalué à 3.
Les admins sont en vacances jusqu'au 20 aout ;-).
# cvs import
Posté par Matthieu Moy (site web personnel) . En réponse au message CVS et sf.net. Évalué à 2.
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".
[^] # Re: Comprends pas....
Posté par Matthieu Moy (site web personnel) . En réponse au journal TPM et "matériel certifié". Évalué à 2.
[^] # Re: Heureusement mon article avance
Posté par Matthieu Moy (site web personnel) . En réponse au journal TPM et "matériel certifié". Évalué à 4.
[^] # Re: Heureusement mon article avance
Posté par Matthieu Moy (site web personnel) . En réponse au journal TPM et "matériel certifié". Évalué à 3.
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.