Ben, OOo sous windows dispose des polices que tu as installées sous Windows. Vu que tu te plaignait de problèmes de polices, ça résoudra une partie des problèmes.
> Et quels sont les types de changement rencontrés et leur incidence ?
Impossibilité de linker des binaires compilés avec des versions incompatibles.
> Et comment ce fait-il que jusqu'à une version 3
GCC est avant tout destiné à compiler des logiciels libres. Au niveau source, les changements d'ABI ne posent pas de problèmes. Donc, pour les devs de GCC, ça n'était pas un gros problème. Par contre, pour les gens qui utilisent des bibliothèques non-libres, c'est très chiant, et heureusement qu'ils ont réussi à stabiliser la chose, en effet.
> d'un compilateur
GCC n'est pas "un compilateur", mais une collection de compilateurs. Là, on ne parle que du compilateur C++. Le C++ n'existe pas depuis si longtemps que ça, et la norme a un peu évolué depuis le début du langage. Pour le compilateur C, tu te doutes qu'en effet, l'ABI n'a pas changé depuis des lustres.
> une ABI, ça n'a à priori pas besoin d'évoluer très souvent ??
Tu peux regarder comment est foutue l'ABI C++ de GCC si tu as une semaine à perdre. C'est un truc archi-compliqué (le C++ avec de l'héritage multiple, de la covariance, des templates & cie, c'est une horreur à implémenter), et aujourd'hui vraiment bien optimisé. Bref, ça aurait été bien qu'ils fassent le truc parfait du premier coup, mais on peut comprendre que ça ne soit pas si évident :-/
> > Au moins, le debugger du visual, il est capable d'afficher toutes les informations que je lui demande.
> Ne serait-ce pas pour la simple et bonne raison que tu sais t'en servir, et pas de ddd ?
Là, c'est un des rares points sur lesquels son journal est pertinent : gdb est affreusement buggé. (et par conséquents, tous les front-ends qui l'utilisent souffrent de ses bugs.) Celà dit, les développeurs bossent pas mal sur la question, et le simple fait de passer sur la dernière version de gdb résous une partie des problèmes.
Attention quand même : Ca ne sert à rien d'aller poser pleins de questions aux vendeurs si vous n'avez pas réellement l'intention d'acheter. Si les vendeurs sont harcelés de questions sur Linux, qu'ils finissent par avoir une machine Linux préinstallée en rayon, et que personne ne l'achète, ils en concluront que Linux = que du vent.
Tu as pensé à installer les polices qui manquent, par exemple ? Nan, pasque sinon, il peut pas les inventer, hein.
> Impossible d'acceder à la machine linux depuis les autres machines du réseau.
Ouais, c'est sans doute la faute de Linux si windows réinvente des protocoles proprio là ou des outils standards existent sous UNIX depuis des années. Bon, enfin, si tu veux que tes windows soient un peu moins autistes et arrivent à communiquer avec les autres systèmes, installes SFU.
Tu peux essayer une expérience intéressante : Tu fais un bon gros réseau avec des Linux, des FreeBDS, des Solaris, ou tout le monde communique sans problème, et tu met un windows au milieu.
> Je me renseigne un peu sur le projet samba, et j'apprends qu'ils ne travaillent que par
> reverse engeenering sur les protocoles, et qu'ils sont extrèmements en retards.
Si tu te renseignes un peu plus, tu découvrira que dans bien des réseaux windows, les serveurs de fichiers sont des machines UNIX faisant tourner samba, parce que les admins trouvent que ça marche mieux qu'un windows.
> il s'avère que gcc change d'ABI quasiment à chaque version,
Plus depuis la 3.2 justement.
> Pas de support des headers précompilés (sauf dans une hypothétique future version,
Ton module IP Over Time est réglé à l'envers. GCC 3.4 est sorti le 20 avril dernier.
> Je suis spécialiste depuis 10 ans en programmation C++ de haut niveau.
> "Mes drivers sont pour 2.6.7 et je suis en 2.6.4 !! Argh !!"
Tu ne crois pas si bien dire : Les utilisateurs du driver eagle pour les modems sagem ont déjà eu : "Mes drivers sont pour 2.6.4 et je suis en 2.6.5 !! Argh !!" Parce que les API de l'usb avaient changé dans le noyau.
> Comme le code est proprio, le fait de ne pas en parler permet à "l'adversaire"
> de ne pas savoir comment est fait la fonction.
Justement, le principe du brevet, c'est que ce qui est breveté est forcément publié. Tu dis comment ça marche et en échange, tu interdit aux autres de faire pareil sans ton autorisation.
Le front-end peut être, mais le préprocesseur, surement pas.
Pour rappel, le préprocesseur, c'est le truc qui s'occupe des lignes qui commencent par '#' et la substitution des macros. Le front-end, c'est le truc qui parse le source avant la génération de code.
Les pubs IBM, c'est surtout pour les serveurs. Un truc pour les pros, quoi, et pour les particuliers, ça leur apprends qu'on peut faire du "e-business" avec Linux, mais pas qu'on peut faire du traitement de texte.
Oui, et c'est indispensable pour avoir quelque chose d'utilisable par un néophyte.
Le mec, il met la disquette dans le grille pain. si tu lui dit d'aller chercher dans /mnt/floppy, il comprends pas pourquoi. Si tu lui met bien en évidence un truc ou il voit son CD, son DVD, et sa disquette bien clairement, il est content.
Et d'ailleurs, ce système est source de pleins de confusion, parce que pour beaucoup de gens, une "licence", c'est un jetton sur le serveur, alors quand tu leur parle de "licence" au sens premier du terme, ils ne comprennent plus rien !
> Apres y a surrement quelques subtilités à regler, mais j'imagine que l'essentiel est fait très tot.
Ouais, quelques subtilités, comme tu dis ;-)
Pour des applications fesant du calcul pur, effectivement, la question est relativement facile à régler au niveau de l'OS. C'est au niveau applicatif qu'il faut paralléliser les algos.
Maintenant, si tu prends une application comme un gros SGBD, ou quelque chose qui utilise beaucoup d'appels systèmes, tu passes facilement 20% du temps dans les couches noyau. Maintenant, tu imagines bien que si deux processeurs executent en parallèle deux bouts de code qui touchent au mêmes données, ou au même périphérique, tu as 99% de chances d'avoir un truc déconnant. Il faut donc placer des verrou pour assurer l'exclusion mutuelle de certaines portions de code dans le noyau. L'approche la plus simple (c'est en gros comme ça que ça se passait dans les premiers Linux SMP), c'est de mettre un gros verrou sur l'ensemble du noyau, ce qui fait que deux processeurs ne peuvent pas executer du code en mode noyau en même temps. Ca marche assez bien sur 2 processeurs, parce que pendant qu'un processeur execute du code dans le noyau, l'autre processeur a en général un processus à executer. Mais évidement, si tu passes 20% du temps dans le noyau, et que tu as plus de 5 processeurs, alors tu as toujours plusieurs processeurs qui n'ont rien à faire. C'est (entre autres) pour ça qu'un Linux 2.2 a du mal sur une machine quadri-proc, et n'arrive vraiment pas à utiliser correctement 8 procs.
Pour utiliser correctement un grand nombre de processeurs, il faut donc que les verroux d'exclusion mutuelle dans le noyau soient le plus fins possibles. Qu'un processeur puisse écrire sur un disque dur pendant qu'un autre écrit sur un autre disque par exemple. Il y a déjà eu beaucoup de progrès dans ce domaine depuis Linux 2.2, mais avant d'exploiter correctement 1024 processeurs, il y a encore du boulot !
Ce n'est bien sur pas le seul problème. Par exemple, quand le noyau doit choisir entre 5 ou 10 processus éligibles (ce qui correspond déjà à une machine très chargée pour un mono ou bi-processeur), tu t'en fout pas mal que l'algo de scheduling soit en O(n), O(log(n)) ou en O(1). Sur une machine 1024 procs, tu as au moins 1024 taches éligibles à chaque instant quand ta machine est chargée, et la, la finesse des algos fait la différence.
Bref, avoir un systeme qui tourne sur 1024 procs, c'est assez facile, mais avoir un des perfs acceptables sur un tel système (avoir un système qui n'est pas trop loin d'être 1024 fois plus rapide qu'un système mono-processeur), c'est une autre paire de manches !
Apache 2, je sais pas, mais si mes souvenirs sont bons, le 1 gère un "pool" de processus : Partant du principe que le fork() est une opération couteuse, il en fait quelques uns d'avance, mais les processus créés sont suspendus jusqu'à une réception de requête HTTP. D'ou les multiples httpd, même quand le serveur ne fait rien.
> Les patchs du noyau sont des corrections de bugs [...]
Le patch dont je parlais est un patch qui ajoute une fonctionalité au noyau. Surement pas un bugfix. Il y a une multitude de patchs disponibles pour le kernel qui ne sont pas des corrections de bugs. Pour l'exemple dont je parlais, c'est un bug de LG, mais le mec qui vient de flinguer son lecteur est content de l'apprendre. Et ce n'est pas Mandrake qui a découvert le bug, ce sont ses utilisateurs. Je ne critique pas Mandrake, mais quand on dit que toutes les distribs se valent, c'est faux. Le boulot des distribs, c'est plus que de l'emballage, et dans le cas particulier du noyau, le choix des patchs est important. (Dans le cas que j'ai cité, ce n'était pas en l'avantage de Mandrake, mais il y a d'autres spécificités Mandrake qui sont très intéressantes)
Encore une fois, je ne dis pas qui est mieux dans l'absolu, je dis que les distribs sont différentes.
On est bien d'accord, mais relis le message auquel je répondais qui dit que toutes les distribs se valent. C'est tout simplement faux ! (Je n'ai pas dit qui était mieux dans l'absolu)
> - l'installation se fera avec quasiment la même facilité sur les deux distribs.
Si tu essayes une Debian stable et une Mandrake stable sur ce point, il y a un gouffre ... (Et la Mandrake qui est sortie en même temps que la dernière Debian était déjà très en avance du point de vue _facilité_ d'installation)
Il faut ajouter:
- la liste des patchs spécifiques à la distribution pour certains logiciels dont le noyau ne sera pas la même.
(Exemple (qui ne joue pas en la faveur de Mdk): Le patch du noyau qui flinguait les lecteurs de CD LG ou bien le gcc 2.96 de RedHat, ...)
- La qualité du support sera sans doutes très différente. La durée du support sera également très différente.
Bref, si toutes les distribs étaient les mêmes, ça se saurait !
Bien sur qu'en cherchant un peu, tu peux trouver les specs. Mais
1) Ca fait chier. C'est qu'il n'y a pas assez de main d'oeuvre chez MS pour faire un pdf ou quoi ?? (nb: J'y crois pas trop ;-)
2) Le site microsoft.com est rempli de petits détails comme ça : Des fichiers .doc, des .exe là ou un pdf aurait fait l'affaire, ... Ce sont autant de petits messages subliminaux pour l'utilisateur: "De toutes façons, tout le monde a un windows sous la main, le .doc et le .exe, saibonmangezen".
Bref, c'est un détail, ça empêche pas la terre de tourner, mais ca fait ch***.
> - Le mode spatial est utilisé par Gnome 2.6 alors que ça semblait ne pas décoller
Ahem ...
Je l'utilisais il y a plus de 10 ans sous Mac OS (Je ne me souviens plus de la date d'achat de la bête, mais pour donner une idée, c'était un Macintosh Classique, proc à 8Mhz, 4Mo de RAM, 40Mo de DD, ... bien avant windows 95 en tous cas.), mais à part ça, c'est un truc vachement inovant, hein ;-)
>Y a-t-il une licence libre qui serait l'équivalent de la GPL, mais qui imposerait pour quelqu'un qui veut
> modifier le logiciel L1 et le diffuser, d'indiquer quelque part qu'il s'agit d'une version modifiée?
La GPL impose déjà ça, il me semble ...
Sinon, le truc classique, c'est d'avoir une marque déposée non-libre, et un logiciel libre. (Exemple: RedHat)
> s'il faut que la combinaison soit explicitement GPL
Ben, je vais te traduire le passage que j'ai cité :
La GPL permet une telle combinaison [de code GPL et GPL-compatible] à condition qu'elle [la combinaison] soit distribué sous GPL.
C'est plus claire ? Tiens, d'ailleurs, la traduction est en ligne :
La GPL autorise une telle combinaison, à condition qu'elle soit distribuée sous GNU GPL. L'autre licence est compatible avec la GPL si elle permet cela aussi.
Si tu penses qu'il y a incohérence entre la GPL et la FAQ, signales-le à la FSF ...
[^] # Re: t'exagère un peu là !
Posté par Matthieu Moy (site web personnel) . En réponse au journal Linux : la plus vaste blague de l'informatique. Évalué à 1.
[^] # Re: Allez, on va en faire quelques uns ;-)
Posté par Matthieu Moy (site web personnel) . En réponse au journal Linux : la plus vaste blague de l'informatique. Évalué à 7.
Oui.
> Et quels sont les types de changement rencontrés et leur incidence ?
Impossibilité de linker des binaires compilés avec des versions incompatibles.
> Et comment ce fait-il que jusqu'à une version 3
GCC est avant tout destiné à compiler des logiciels libres. Au niveau source, les changements d'ABI ne posent pas de problèmes. Donc, pour les devs de GCC, ça n'était pas un gros problème. Par contre, pour les gens qui utilisent des bibliothèques non-libres, c'est très chiant, et heureusement qu'ils ont réussi à stabiliser la chose, en effet.
> d'un compilateur
GCC n'est pas "un compilateur", mais une collection de compilateurs. Là, on ne parle que du compilateur C++. Le C++ n'existe pas depuis si longtemps que ça, et la norme a un peu évolué depuis le début du langage. Pour le compilateur C, tu te doutes qu'en effet, l'ABI n'a pas changé depuis des lustres.
> une ABI, ça n'a à priori pas besoin d'évoluer très souvent ??
Tu peux regarder comment est foutue l'ABI C++ de GCC si tu as une semaine à perdre. C'est un truc archi-compliqué (le C++ avec de l'héritage multiple, de la covariance, des templates & cie, c'est une horreur à implémenter), et aujourd'hui vraiment bien optimisé. Bref, ça aurait été bien qu'ils fassent le truc parfait du premier coup, mais on peut comprendre que ça ne soit pas si évident :-/
[^] # Re: Trois choses :
Posté par Matthieu Moy (site web personnel) . En réponse au journal Linux : la plus vaste blague de l'informatique. Évalué à 3.
> Ne serait-ce pas pour la simple et bonne raison que tu sais t'en servir, et pas de ddd ?
Là, c'est un des rares points sur lesquels son journal est pertinent : gdb est affreusement buggé. (et par conséquents, tous les front-ends qui l'utilisent souffrent de ses bugs.) Celà dit, les développeurs bossent pas mal sur la question, et le simple fait de passer sur la dernière version de gdb résous une partie des problèmes.
[^] # Re: Lobbying auprès des grandes surfaces.
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Carrefour propose un PC équipé de MandrakeLinux sur son site Internet. Évalué à 4.
# Allez, on va en faire quelques uns ;-)
Posté par Matthieu Moy (site web personnel) . En réponse au journal Linux : la plus vaste blague de l'informatique. Évalué à 10.
Tu as pensé à installer les polices qui manquent, par exemple ? Nan, pasque sinon, il peut pas les inventer, hein.
> Impossible d'acceder à la machine linux depuis les autres machines du réseau.
Ouais, c'est sans doute la faute de Linux si windows réinvente des protocoles proprio là ou des outils standards existent sous UNIX depuis des années. Bon, enfin, si tu veux que tes windows soient un peu moins autistes et arrivent à communiquer avec les autres systèmes, installes SFU.
Tu peux essayer une expérience intéressante : Tu fais un bon gros réseau avec des Linux, des FreeBDS, des Solaris, ou tout le monde communique sans problème, et tu met un windows au milieu.
> Je me renseigne un peu sur le projet samba, et j'apprends qu'ils ne travaillent que par
> reverse engeenering sur les protocoles, et qu'ils sont extrèmements en retards.
Si tu te renseignes un peu plus, tu découvrira que dans bien des réseaux windows, les serveurs de fichiers sont des machines UNIX faisant tourner samba, parce que les admins trouvent que ça marche mieux qu'un windows.
> il s'avère que gcc change d'ABI quasiment à chaque version,
Plus depuis la 3.2 justement.
> Pas de support des headers précompilés (sauf dans une hypothétique future version,
Ton module IP Over Time est réglé à l'envers. GCC 3.4 est sorti le 20 avril dernier.
> Je suis spécialiste depuis 10 ans en programmation C++ de haut niveau.
Nan, rien ;-)
[^] # Re: Question ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Nouveau modèle de développement pour Linux. Évalué à 9.
Tu ne crois pas si bien dire : Les utilisateurs du driver eagle pour les modems sagem ont déjà eu : "Mes drivers sont pour 2.6.4 et je suis en 2.6.5 !! Argh !!" Parce que les API de l'usb avaient changé dans le noyau.
[^] # Re: Peut-etre
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Nouvelle forme d'arnaque : l'usurpation d'identité de site web via XUL. Évalué à 2.
Si c'est du XUL, ça s'adapte à ton thème, donc, ton idée ne marche pas.
[^] # Re: dégouté
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche John Carmack victime des brevets logiciels. Évalué à 5.
> de ne pas savoir comment est fait la fonction.
Justement, le principe du brevet, c'est que ce qui est breveté est forcément publié. Tu dis comment ça marche et en échange, tu interdit aux autres de faire pareil sans ton autorisation.
[^] # Re: Autre bonne nouvelle
Posté par Matthieu Moy (site web personnel) . En réponse au journal Recherche de statistiques d'utilisation de Linux côté serveur et bureau. Évalué à 2.
10%, c'est une prévision, pas un chiffre au présent ...
# Ahem ;-)
Posté par Matthieu Moy (site web personnel) . En réponse au journal J'adore Linus. Évalué à 3.
5. Types
NULL is unused. Testing for validity should use 0 instead of NULL. !foo is also often used.
Nan rien, c'est juste pour relancer le troll ;-)
[^] # Re: Petites precisions
Posté par Matthieu Moy (site web personnel) . En réponse au journal J'adore Linus. Évalué à 2.
Le front-end peut être, mais le préprocesseur, surement pas.
Pour rappel, le préprocesseur, c'est le truc qui s'occupe des lignes qui commencent par '#' et la substitution des macros. Le front-end, c'est le truc qui parse le source avant la génération de code.
[^] # Re: Pas credible !
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Une offre inhabituelle : un PC sans Windows mais avec un CD MandrakeLinux. Évalué à 4.
[^] # Re: Reels Problemes ?
Posté par Matthieu Moy (site web personnel) . En réponse au journal Gnome forke ?. Évalué à 3.
Le mec, il met la disquette dans le grille pain. si tu lui dit d'aller chercher dans /mnt/floppy, il comprends pas pourquoi. Si tu lui met bien en évidence un truc ou il voit son CD, son DVD, et sa disquette bien clairement, il est content.
[^] # Re: juste pour rappel
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Une solution d'installation soumise au W3C. Évalué à 3.
[^] # Re: ça m'intéresse...
Posté par Matthieu Moy (site web personnel) . En réponse au journal "Nouveau" site pour directfb. Évalué à 2.
[^] # Re: ça m'intéresse...
Posté par Matthieu Moy (site web personnel) . En réponse au journal "Nouveau" site pour directfb. Évalué à 2.
Si non, c'est peut-être pour ça ...
[^] # Re: Petite question
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Linux devient massivement multiprocesseurs. Évalué à 10.
Ouais, quelques subtilités, comme tu dis ;-)
Pour des applications fesant du calcul pur, effectivement, la question est relativement facile à régler au niveau de l'OS. C'est au niveau applicatif qu'il faut paralléliser les algos.
Maintenant, si tu prends une application comme un gros SGBD, ou quelque chose qui utilise beaucoup d'appels systèmes, tu passes facilement 20% du temps dans les couches noyau. Maintenant, tu imagines bien que si deux processeurs executent en parallèle deux bouts de code qui touchent au mêmes données, ou au même périphérique, tu as 99% de chances d'avoir un truc déconnant. Il faut donc placer des verrou pour assurer l'exclusion mutuelle de certaines portions de code dans le noyau. L'approche la plus simple (c'est en gros comme ça que ça se passait dans les premiers Linux SMP), c'est de mettre un gros verrou sur l'ensemble du noyau, ce qui fait que deux processeurs ne peuvent pas executer du code en mode noyau en même temps. Ca marche assez bien sur 2 processeurs, parce que pendant qu'un processeur execute du code dans le noyau, l'autre processeur a en général un processus à executer. Mais évidement, si tu passes 20% du temps dans le noyau, et que tu as plus de 5 processeurs, alors tu as toujours plusieurs processeurs qui n'ont rien à faire. C'est (entre autres) pour ça qu'un Linux 2.2 a du mal sur une machine quadri-proc, et n'arrive vraiment pas à utiliser correctement 8 procs.
Pour utiliser correctement un grand nombre de processeurs, il faut donc que les verroux d'exclusion mutuelle dans le noyau soient le plus fins possibles. Qu'un processeur puisse écrire sur un disque dur pendant qu'un autre écrit sur un autre disque par exemple. Il y a déjà eu beaucoup de progrès dans ce domaine depuis Linux 2.2, mais avant d'exploiter correctement 1024 processeurs, il y a encore du boulot !
Ce n'est bien sur pas le seul problème. Par exemple, quand le noyau doit choisir entre 5 ou 10 processus éligibles (ce qui correspond déjà à une machine très chargée pour un mono ou bi-processeur), tu t'en fout pas mal que l'algo de scheduling soit en O(n), O(log(n)) ou en O(1). Sur une machine 1024 procs, tu as au moins 1024 taches éligibles à chaque instant quand ta machine est chargée, et la, la finesse des algos fait la différence.
Bref, avoir un systeme qui tourne sur 1024 procs, c'est assez facile, mais avoir un des perfs acceptables sur un tel système (avoir un système qui n'est pas trop loin d'être 1024 fois plus rapide qu'un système mono-processeur), c'est une autre paire de manches !
[^] # Re: Scheduling domains
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Linux devient massivement multiprocesseurs. Évalué à 5.
[^] # Re: Décision objective ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Le ministère de l'équipement choisit Mandrakesoft. Évalué à 3.
Le patch dont je parlais est un patch qui ajoute une fonctionalité au noyau. Surement pas un bugfix. Il y a une multitude de patchs disponibles pour le kernel qui ne sont pas des corrections de bugs. Pour l'exemple dont je parlais, c'est un bug de LG, mais le mec qui vient de flinguer son lecteur est content de l'apprendre. Et ce n'est pas Mandrake qui a découvert le bug, ce sont ses utilisateurs. Je ne critique pas Mandrake, mais quand on dit que toutes les distribs se valent, c'est faux. Le boulot des distribs, c'est plus que de l'emballage, et dans le cas particulier du noyau, le choix des patchs est important. (Dans le cas que j'ai cité, ce n'était pas en l'avantage de Mandrake, mais il y a d'autres spécificités Mandrake qui sont très intéressantes)
Encore une fois, je ne dis pas qui est mieux dans l'absolu, je dis que les distribs sont différentes.
[^] # Re: Décision objective ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Le ministère de l'équipement choisit Mandrakesoft. Évalué à 1.
[^] # Re: Décision objective ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Le ministère de l'équipement choisit Mandrakesoft. Évalué à -2.
Si tu essayes une Debian stable et une Mandrake stable sur ce point, il y a un gouffre ... (Et la Mandrake qui est sortie en même temps que la dernière Debian était déjà très en avance du point de vue _facilité_ d'installation)
Il faut ajouter:
- la liste des patchs spécifiques à la distribution pour certains logiciels dont le noyau ne sera pas la même.
(Exemple (qui ne joue pas en la faveur de Mdk): Le patch du noyau qui flinguait les lecteurs de CD LG ou bien le gcc 2.96 de RedHat, ...)
- La qualité du support sera sans doutes très différente. La durée du support sera également très différente.
Bref, si toutes les distribs étaient les mêmes, ça se saurait !
[^] # Re: aller un petite réponse.
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Les dirigeants de Microsoft enfoncent le clou sur Linuxfrench. Évalué à 3.
1) Ca fait chier. C'est qu'il n'y a pas assez de main d'oeuvre chez MS pour faire un pdf ou quoi ?? (nb: J'y crois pas trop ;-)
2) Le site microsoft.com est rempli de petits détails comme ça : Des fichiers .doc, des .exe là ou un pdf aurait fait l'affaire, ... Ce sont autant de petits messages subliminaux pour l'utilisateur: "De toutes façons, tout le monde a un windows sous la main, le .doc et le .exe, saibonmangezen".
Bref, c'est un détail, ça empêche pas la terre de tourner, mais ca fait ch***.
[^] # Re: aller un petite réponse.
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Les dirigeants de Microsoft enfoncent le clou sur Linuxfrench. Évalué à 2.
Ahem ...
Je l'utilisais il y a plus de 10 ans sous Mac OS (Je ne me souviens plus de la date d'achat de la bête, mais pour donner une idée, c'était un Macintosh Classique, proc à 8Mhz, 4Mo de RAM, 40Mo de DD, ... bien avant windows 95 en tous cas.), mais à part ça, c'est un truc vachement inovant, hein ;-)
[^] # Re: Je ne suis pas convaincu
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Une nouvelle licence de logiciel libre : CeCILL. Évalué à 3.
> modifier le logiciel L1 et le diffuser, d'indiquer quelque part qu'il s'agit d'une version modifiée?
La GPL impose déjà ça, il me semble ...
Sinon, le truc classique, c'est d'avoir une marque déposée non-libre, et un logiciel libre. (Exemple: RedHat)
[^] # Re: une double licence
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Une nouvelle licence de logiciel libre : CeCILL. Évalué à 3.
Ben, je vais te traduire le passage que j'ai cité :
La GPL permet une telle combinaison [de code GPL et GPL-compatible] à condition qu'elle [la combinaison] soit distribué sous GPL.
C'est plus claire ? Tiens, d'ailleurs, la traduction est en ligne :
La GPL autorise une telle combinaison, à condition qu'elle soit distribuée sous GNU GPL. L'autre licence est compatible avec la GPL si elle permet cela aussi.
Si tu penses qu'il y a incohérence entre la GPL et la FAQ, signales-le à la FSF ...