L'important c'est peut être de faire assez de bruit pour que l'equipe d'Ooo developpe en visant gij ou kaffe plutôt que les environements Sun.
Personellement je suis très surpris qu'ils n'aient pas au moins testé leur code sur un environement java libre : il ne s'agit pas de webdesigners du dimanche (à qui on peut passer l'utilisation de features "ie-only"), mais de developpeurs expérimentés. Et dont je croyai qu'ils connaissaient les préocupations et problèmes des utilisateurs de LL.
Si nous passions ça sous licence, il est à peut près certain qu'aucun effort n'aurait été fait pour conserver la compatibilité gcj, si durement acquise, dans les versions ultérieures.
Et au passage le fait que ça marchouille avec le gcj de FC4 (et combien de patches ?) n'est pas satisfaisant: ça necessite nottament de disposer de la chaine gcj de gcc 4.0 (béta), du classpath récent (béta) etc.
Par contre il peut grandement améliorer la productivité des codeurs (syntaxe, gestion mémoire, portabilité, libs, etc.)
Mais justement, c'est la portabilité qui pose problème avec java! (enfin, entre autres problèmes).
Je m'abstiendrai de faire une blague pour ce qui concerne la "gestion de la mémoire" ;)
Je pense effectivement que c'est ce genre de comportement qui pourrait faire changer les choses
Bien sûr, mais il ne suffit pas de ne plus acheter le matériel: il faut le faire savoir au constructeur ! Utilisateurs de logiciels libres, ne restez pas passifs !
Il faut le faire savoir à son entourage, et faire du bruit sur internet, suffisament de contre-publicité pour que le constructeur s'inquiète. L'expérience des divers actions activistes menées par TdR l'a prouvé.
Cette fois, nous avons une gros bras de fer avec Adaptec mené en public sur les mailing-lists de FreeBSD et OpenBSD, des articles sur osnews, slashdot, linuxfr ... les utilisateures d'OpenBSD qui sont aussi actionnaires d'Adaptec (où dont l'employeur l'est) commencent à s'organiser pour utiliser leur droit de regard et proposition, la certification ISO 9001 affichée sur les boites Adaptec (illégale parceque la doc n'est pas fournie) va servir à faire pression, TdR a enlevé le support aac(4) du kernel de la nouvelle version d'OpenBSD (qui sort bientôt) et a donné un ultimatum à Adaptec ... Le lobbying tout azimut, en prenant les constructeurs un par un, aujourd'hui Adpatres, hier Qlogic et Ralink, ...
Bref on peut être efficace (je suis convaincu que cette affaire se terminera bien pour tout le monde). Mais il ne faut pas se laisser faire, mettre toutes les chances de son coté.... agir ! il en va des constructeurs de matériel comme des brevets logiciels en Europe, comme de l'utilisation de standards ouverts pour les publications administratives ...
- Sur la documentation des cartes RAID:
L'implémentation (libre ou pas) par le constructeur n'est pas suffisante ; elle ne doit pas se substituer à la diffusion libre (sans NDA) des spécifications: la maintenance peut être abandonnée à tout moment (par exemple si le constructeur veut vous encourager à upgrader le matériel), fragilise et ralenti la correction d'éventuels bugs ou failles (par ex. quand le développeur de la société concernée est en vacance ou s'il est licencié...), est difficile à maintenir synchrone avec les cycles de développement du noyau (utilisateurs de produits nvidia et radeon, vous connaissez cette chanson), dans certains cas n'est pas librement distribuable (utilisateurs de Fedora, Debian etc...).
- Sur les chipsets Wifi:
Depuis environ deux ans, la plupart des gros fabricants de chipsets wifi ont décidé de faire des économies d'échelle en n'incluant plus l'EPROM qui servait auparavant à stocker le firmware dans la carte (économie modique, au passage).
Ce firmware doit alors être chargé par le driver à l'initialisation de la carte. Par conséquent, il doit être accessible au driver (donc présent dans votre distribution).
Or la plupart de ces constructeurs n'autorisent pas la libre distribution du firmware. Certains exigent la signature d'une EULA en ligne sur leur site. Ceci est incompatible avec les besoins des distributions « communautaires » (comme Fedora, Debian, Gentoo etc.) et des *BSD, dont le contenu doit être librement redistribuable. Deux distributions plus « commerciales » (Suse et MandrakeLinux) ont signé des accords avec Intel pour être autorisées à distribuer les firmwares Intel Centrino.
Ce problème concerne la quasi totalité des chipsets wifi présents sur le marché aujourd'hui (les prism 2/2.5/3 ou Lucent devenant très rares).
La campagne lancée il y a quelques mois par TdR a permis de faire céder plusieurs constructeurs, qui ont finalement accepté d'autoriser la libre distribution du firmware (faute de l'ouverture des sources).
Le principe de ces campagnes est simple: si vous êtes utilisateur d'un OS libre, si vous étés propriétaire d'un tel matériel, ou tout simplement si vous vous sentez concerné, faites le savoir aux constructeurs (les mails et/ou numéros de téléphones des contacts sont indiqués par TdR). N'hésitez pas, c'est vraiment efficace :)
C'est un remplaçant entièrement en C pour autotools, libtool et pkg-config. C'est très éléguant, très rapide, très simple à utiliser, et ça diminue encore les dépendances et les problèmes liés au shell script (par rapport à autotools, ou python pour scons etc.).
On peut supposer qu'il pourrai facilement être porté sur des plateforme win32 (plus que les shells scripts auto* pour sûr ;) même si ce n'est pas un objectif immediat.
Je serai ravi que plus de developpeurs l'utilisent, en raison de l'objectif principal du projet: être irreprochable sur la sécurité pour l'utilisateur. Ça fonctionne sur la base de fichiers de description (parsés et 'éxecutés' par l'outil en C) avec bien entendu un nombre d'actions et de possibiltés prédéfinies et limités, bien étudiées. Il est censé ne pas permettre de faire des choses dangeureuses.
En effet il ne faut pas oublier qu'un script configure est toujours susceptible de vous installer une rootkit en loucedé (ou jouer avec votre courriel ou ....). Les scripts configure (et libtool) sont très gros et complexes, en pratique très penibles à auditer ; comme c'est du shell script, tout leur est permis. Pensez-y quand vous installez à la main un nouveau logiciel ...
C'est faisable (et d'ailleur, c'est souvent ce que fait le framework OpenEmbedded dans ce genre de cas). Mais :
1- ça exige généralement d'énormes patches sur les Makefiles (pas faciles à maintenir).
2- ça peut produire un résultat non fonctionnel: ces outils qui s'éxecutent en cours de route servent notamment à invoquer les bonnes options (CFLAGS/CXXFLAGS adéquats, paths, -L../-l../-I.. etc.) pour le reste de la compil. Et il n'est pas rare que ces options diffèrent entre l'hôte et la cible :(
3- ça peut rendre la compilation difficile à automatiser.
4- il est parfois difficile d'avoir sur l'hote source une config logicielle équivalente à celle de la cible. Surtout si la cible est un appareil embarqué, avec, typiquement, utilisation d'un framebuffer spécial, ou de nanox (vs outils linkés sur X windows sur l'hote), ou toute autre différence matérielle ; ce qui agrave les problèmes listés en "2-" (c'est du vécu ;).
Par contre je ne compte plus le nombre d'entreprises qui ont encore de nombreux serveurs NT4 et postes 95-98...
C'est rendu possible parceque ms fournis du support et des maj sur les anciennes versions de windows (enfin, les "relativement anciennes", pour nt4/win98 je ne sait pas).
Quand les anciennes versions sont maintenues longtemps (au moins en ce qui concerne les mises à jours de sécu, et c'est le cas pour certaines distribs, comme red hat, pour netbsd, pour solaris etc.) l'ensemble des utilisateurs n'est pas pénalisé par les quelques déploiment tellements bordéliques qu'ils sont inupgradables. (nb: amha si l'upgrade est un vrai probleme, les admins concernés devraient se poser des questions, ou les devs si le frein est l'upgrade des compilos/interpreteurs: cf. les questions de portabilité).
Sans desavouer les points forts de debian, il faut reconnaitre qu'ils pourraient faire mieux sur ce point (les mises à jour de la distrib). Et les problèmes de déploiment sont une mauvaise excuse.
Les admins de serveurs mails sous debian seraient contents d'avoir des antispams et antivirus à jour.
Les admins d'applis web, d'avoir les versions récentes (enfin pas celles d'il y a 5 ans) des interpréteteurs php/python/perl/java (et que les developpeurs leur demandent de remplacer à la main)...
Les admins de serveurs de fichiers en entreprise ne seraient pas contre le fait de pouvoir causer aux windows sortis il y a moins de 5 ans ...
etc.
Si les admins n'utilisent pas sarge ou sid, c'est parcequ'elles sont instables et trop mouvantes, pas parcequ'ils n'ont pas besoin de paquetages modernes.
Et d'autres distributions GNU/Linux comme d'autres systèmes d'exploitation (Solaris, *BSD notamment) ont prouvés qu'il nétait pas nécessaire d'avoir de vieux logiciels pour être stable. Le problème de délais chez debian est -amha- un pb d'organisation sociale plus qu'autre chose.
La proposition indique que les architectures non séléctionnées ne seront plus "releasées" ; mais elles pourront rester dans sid (avec des snapshots de temps en temps).
Donc ces archis ne sont pas vraiment abandonnées.
NetBSD, comme tous les BSD, ne propose que le kernel et les outils userland. tout le reste se trouve dans les ports ( cad 90% des softs non ?) qui ne sont pas maintenus par le team NetBSD (pas de correctifs de sécu et autres)
DTÉ ! (désinformation trollistique éhontée ;)
Le userland est copieusement fournis et souvent suffisant. Les sources du système de base (kernel + userland) sont relues et auditées en permanence par les mainteneurs (ce qui n'est le cas des sources d'aucune distrib linux à ma connaissance).
Et bien sûr, les ports & packages sont maintenus (et les correctifs sont distribués).
Les compilations croisées qui posent problème (et qui méritent véritablement qu'on les qualifie de "croisées") sont celles qui compilent pour une architecture donnée depuis une autre.
À vrai dire, ces compilations croisées ne posent pas forcément trop de problèmes. En particulier les logiciels basés sur autoconf/automake se cross-compilent comme des lettres à la poste. Idem pour le kernel linux. Ou le système de base de NetBSD et d'OpenBSD.
Ça se corse quand une phase de la compilation necessite l'execution (sur la plateforme source) de binaires (ABI cible) produits dans une phase précédente de la compilation.
Par exemple lors du 'make' de python, on compile d'abord un interpreteur minimal qui est ensuite executé pour compiler les extensions binaires. Ça n'est pas possible si l'interpreteur binaire produit n'est pas executable sur la plateforme où l'on compile.
Même genre de problématiques pour les logiciels utilisant gtk-config, qmake, swig etc.
Bref il est complétement inenvisageable de cross compiler la debian pour les architectures rares.
D'autant que ça fait à néro maintenant un bel alibi au regard de la communauté open source, qui se satisfait -dirait-on- de tout ce qui brille.
Ils n'ont pas à se vanter de ce port : les bugs de leurs softs n'ont pas a être corrigé (parceque close source et "pas de support linux"). Pas de version pour les architectures minoritaires (eg linux/ppc, linux/mips ...), pas de version pour les plateformes *BSD etc.
On se retrouve donc avec exactement le même problème que java (les sources de java sont certes disponibles mais on ne peut distribuer les modifs, pas de sdk sun pour linux/sparc, ou *BSD): la communauté s'habitue à ces soutils, parcequ'elle prend le monde "Lintel" (linux/intel) pour le tout. La consequence c'est que les archis et plateformes minoritaires sont toujours plus isolées par les "Linteliens" cedant leur liberté et celle des autres par inconscience ...
> s'envoyer une version du programme tous les X temps et garder l'enveloppe fermée (cachet de la poste faisant foi)
Et s'envoyer une enveloppe ouverte, la remplir et la fermer au besoin (après coup)?
non, le coup de l'enveloppe comme preuve légale, c'est une légende.
From: Linus Torvalds <torvalds () osdl ! org>
"[...]I think we should drop the
original even/odd suggestion for now, and see if this would make more
sense.."
[^] # Re: Sun a toujours le mauvais rôle
Posté par herodiade . En réponse à la dépêche OpenOffice.org version 2.0 et Java. Évalué à 3.
Personellement je suis très surpris qu'ils n'aient pas au moins testé leur code sur un environement java libre : il ne s'agit pas de webdesigners du dimanche (à qui on peut passer l'utilisation de features "ie-only"), mais de developpeurs expérimentés. Et dont je croyai qu'ils connaissaient les préocupations et problèmes des utilisateurs de LL.
Si nous passions ça sous licence, il est à peut près certain qu'aucun effort n'aurait été fait pour conserver la compatibilité gcj, si durement acquise, dans les versions ultérieures.
Et au passage le fait que ça marchouille avec le gcj de FC4 (et combien de patches ?) n'est pas satisfaisant: ça necessite nottament de disposer de la chaine gcj de gcc 4.0 (béta), du classpath récent (béta) etc.
En somme, la réaction des utilisateurs de LL est cohérente avec ce que recommande Stalman:
http://www.gnu.org/philosophy/java-trap.html(...)
[^] # Re: Sun a toujours le mauvais rôle
Posté par herodiade . En réponse à la dépêche OpenOffice.org version 2.0 et Java. Évalué à 3.
Mais justement, c'est la portabilité qui pose problème avec java! (enfin, entre autres problèmes).
Je m'abstiendrai de faire une blague pour ce qui concerne la "gestion de la mémoire" ;)
[^] # Re: en attendant
Posté par herodiade . En réponse à la dépêche Spécifications matérielles: Théo de Raadt appelle de nouveau au lobbying. Évalué à 6.
Bien sûr, mais il ne suffit pas de ne plus acheter le matériel: il faut le faire savoir au constructeur ! Utilisateurs de logiciels libres, ne restez pas passifs !
Il faut le faire savoir à son entourage, et faire du bruit sur internet, suffisament de contre-publicité pour que le constructeur s'inquiète. L'expérience des divers actions activistes menées par TdR l'a prouvé.
Cette fois, nous avons une gros bras de fer avec Adaptec mené en public sur les mailing-lists de FreeBSD et OpenBSD, des articles sur osnews, slashdot, linuxfr ... les utilisateures d'OpenBSD qui sont aussi actionnaires d'Adaptec (où dont l'employeur l'est) commencent à s'organiser pour utiliser leur droit de regard et proposition, la certification ISO 9001 affichée sur les boites Adaptec (illégale parceque la doc n'est pas fournie) va servir à faire pression, TdR a enlevé le support aac(4) du kernel de la nouvelle version d'OpenBSD (qui sort bientôt) et a donné un ultimatum à Adaptec ... Le lobbying tout azimut, en prenant les constructeurs un par un, aujourd'hui Adpatres, hier Qlogic et Ralink, ...
Bref on peut être efficace (je suis convaincu que cette affaire se terminera bien pour tout le monde). Mais il ne faut pas se laisser faire, mettre toutes les chances de son coté.... agir ! il en va des constructeurs de matériel comme des brevets logiciels en Europe, comme de l'utilisation de standards ouverts pour les publications administratives ...
[^] # Re: Quelques compléments d'information
Posté par herodiade . En réponse à la dépêche Spécifications matérielles: Théo de Raadt appelle de nouveau au lobbying. Évalué à 7.
http://kerneltrap.org/node/4118(...)
# Quelques compléments d'information
Posté par herodiade . En réponse à la dépêche Spécifications matérielles: Théo de Raadt appelle de nouveau au lobbying. Évalué à 10.
L'implémentation (libre ou pas) par le constructeur n'est pas suffisante ; elle ne doit pas se substituer à la diffusion libre (sans NDA) des spécifications: la maintenance peut être abandonnée à tout moment (par exemple si le constructeur veut vous encourager à upgrader le matériel), fragilise et ralenti la correction d'éventuels bugs ou failles (par ex. quand le développeur de la société concernée est en vacance ou s'il est licencié...), est difficile à maintenir synchrone avec les cycles de développement du noyau (utilisateurs de produits nvidia et radeon, vous connaissez cette chanson), dans certains cas n'est pas librement distribuable (utilisateurs de Fedora, Debian etc...).
- Sur les chipsets Wifi:
Depuis environ deux ans, la plupart des gros fabricants de chipsets wifi ont décidé de faire des économies d'échelle en n'incluant plus l'EPROM qui servait auparavant à stocker le firmware dans la carte (économie modique, au passage).
Ce firmware doit alors être chargé par le driver à l'initialisation de la carte. Par conséquent, il doit être accessible au driver (donc présent dans votre distribution).
Or la plupart de ces constructeurs n'autorisent pas la libre distribution du firmware. Certains exigent la signature d'une EULA en ligne sur leur site. Ceci est incompatible avec les besoins des distributions « communautaires » (comme Fedora, Debian, Gentoo etc.) et des *BSD, dont le contenu doit être librement redistribuable. Deux distributions plus « commerciales » (Suse et MandrakeLinux) ont signé des accords avec Intel pour être autorisées à distribuer les firmwares Intel Centrino.
Ce problème concerne la quasi totalité des chipsets wifi présents sur le marché aujourd'hui (les prism 2/2.5/3 ou Lucent devenant très rares).
La campagne lancée il y a quelques mois par TdR a permis de faire céder plusieurs constructeurs, qui ont finalement accepté d'autoriser la libre distribution du firmware (faute de l'ouverture des sources).
Le principe de ces campagnes est simple: si vous êtes utilisateur d'un OS libre, si vous étés propriétaire d'un tel matériel, ou tout simplement si vous vous sentez concerné, faites le savoir aux constructeurs (les mails et/ou numéros de téléphones des contacts sont indiqués par TdR). N'hésitez pas, c'est vraiment efficace :)
[^] # Re: pourquoi virer autotools ?
Posté par herodiade . En réponse à la dépêche KDE 3.4 officiellement sorti. Évalué à 2.
C'est un remplaçant entièrement en C pour autotools, libtool et pkg-config. C'est très éléguant, très rapide, très simple à utiliser, et ça diminue encore les dépendances et les problèmes liés au shell script (par rapport à autotools, ou python pour scons etc.).
On peut supposer qu'il pourrai facilement être porté sur des plateforme win32 (plus que les shells scripts auto* pour sûr ;) même si ce n'est pas un objectif immediat.
Je serai ravi que plus de developpeurs l'utilisent, en raison de l'objectif principal du projet: être irreprochable sur la sécurité pour l'utilisateur. Ça fonctionne sur la base de fichiers de description (parsés et 'éxecutés' par l'outil en C) avec bien entendu un nombre d'actions et de possibiltés prédéfinies et limités, bien étudiées. Il est censé ne pas permettre de faire des choses dangeureuses.
En effet il ne faut pas oublier qu'un script configure est toujours susceptible de vous installer une rootkit en loucedé (ou jouer avec votre courriel ou ....). Les scripts configure (et libtool) sont très gros et complexes, en pratique très penibles à auditer ; comme c'est du shell script, tout leur est permis. Pensez-y quand vous installez à la main un nouveau logiciel ...
# ssh-agent
Posté par herodiade . En réponse au message [Admin] Darcs et shfs. Évalué à 2.
[^] # Re: Pas grave ...
Posté par herodiade . En réponse à la dépêche Debian envisage un support partiel des architectures les moins utilisées. Évalué à 3.
1- ça exige généralement d'énormes patches sur les Makefiles (pas faciles à maintenir).
2- ça peut produire un résultat non fonctionnel: ces outils qui s'éxecutent en cours de route servent notamment à invoquer les bonnes options (CFLAGS/CXXFLAGS adéquats, paths, -L../-l../-I.. etc.) pour le reste de la compil. Et il n'est pas rare que ces options diffèrent entre l'hôte et la cible :(
3- ça peut rendre la compilation difficile à automatiser.
4- il est parfois difficile d'avoir sur l'hote source une config logicielle équivalente à celle de la cible. Surtout si la cible est un appareil embarqué, avec, typiquement, utilisation d'un framebuffer spécial, ou de nanox (vs outils linkés sur X windows sur l'hote), ou toute autre différence matérielle ; ce qui agrave les problèmes listés en "2-" (c'est du vécu ;).
[^] # Re: NetBSD
Posté par herodiade . En réponse à la dépêche Debian envisage un support partiel des architectures les moins utilisées. Évalué à 2.
[^] # Re: On prend les mêmes et on recommence .....
Posté par herodiade . En réponse à la dépêche Debian envisage un support partiel des architectures les moins utilisées. Évalué à 2.
C'est rendu possible parceque ms fournis du support et des maj sur les anciennes versions de windows (enfin, les "relativement anciennes", pour nt4/win98 je ne sait pas).
Quand les anciennes versions sont maintenues longtemps (au moins en ce qui concerne les mises à jours de sécu, et c'est le cas pour certaines distribs, comme red hat, pour netbsd, pour solaris etc.) l'ensemble des utilisateurs n'est pas pénalisé par les quelques déploiment tellements bordéliques qu'ils sont inupgradables. (nb: amha si l'upgrade est un vrai probleme, les admins concernés devraient se poser des questions, ou les devs si le frein est l'upgrade des compilos/interpreteurs: cf. les questions de portabilité).
Sans desavouer les points forts de debian, il faut reconnaitre qu'ils pourraient faire mieux sur ce point (les mises à jour de la distrib). Et les problèmes de déploiment sont une mauvaise excuse.
[^] # Re: On prend les mêmes et on recommence .....
Posté par herodiade . En réponse à la dépêche Debian envisage un support partiel des architectures les moins utilisées. Évalué à 10.
Les admins d'applis web, d'avoir les versions récentes (enfin pas celles d'il y a 5 ans) des interpréteteurs php/python/perl/java (et que les developpeurs leur demandent de remplacer à la main)...
Les admins de serveurs de fichiers en entreprise ne seraient pas contre le fait de pouvoir causer aux windows sortis il y a moins de 5 ans ...
etc.
Si les admins n'utilisent pas sarge ou sid, c'est parcequ'elles sont instables et trop mouvantes, pas parcequ'ils n'ont pas besoin de paquetages modernes.
Et d'autres distributions GNU/Linux comme d'autres systèmes d'exploitation (Solaris, *BSD notamment) ont prouvés qu'il nétait pas nécessaire d'avoir de vieux logiciels pour être stable. Le problème de délais chez debian est -amha- un pb d'organisation sociale plus qu'autre chose.
[^] # Re: Oui mais non ...
Posté par herodiade . En réponse à la dépêche Debian envisage un support partiel des architectures les moins utilisées. Évalué à 3.
Donc ces archis ne sont pas vraiment abandonnées.
[^] # Re: NetBSD
Posté par herodiade . En réponse à la dépêche Debian envisage un support partiel des architectures les moins utilisées. Évalué à 5.
DTÉ ! (désinformation trollistique éhontée ;)
Le userland est copieusement fournis et souvent suffisant. Les sources du système de base (kernel + userland) sont relues et auditées en permanence par les mainteneurs (ce qui n'est le cas des sources d'aucune distrib linux à ma connaissance).
Et bien sûr, les ports & packages sont maintenus (et les correctifs sont distribués).
Et ce sur les 3 *BSD bien entendu.
[^] # Re: Pas grave ...
Posté par herodiade . En réponse à la dépêche Debian envisage un support partiel des architectures les moins utilisées. Évalué à 6.
À vrai dire, ces compilations croisées ne posent pas forcément trop de problèmes. En particulier les logiciels basés sur autoconf/automake se cross-compilent comme des lettres à la poste. Idem pour le kernel linux. Ou le système de base de NetBSD et d'OpenBSD.
Ça se corse quand une phase de la compilation necessite l'execution (sur la plateforme source) de binaires (ABI cible) produits dans une phase précédente de la compilation.
Par exemple lors du 'make' de python, on compile d'abord un interpreteur minimal qui est ensuite executé pour compiler les extensions binaires. Ça n'est pas possible si l'interpreteur binaire produit n'est pas executable sur la plateforme où l'on compile.
Même genre de problématiques pour les logiciels utilisant gtk-config, qmake, swig etc.
Bref il est complétement inenvisageable de cross compiler la debian pour les architectures rares.
[^] # Re: Bonne nouvelle
Posté par herodiade . En réponse à la dépêche NeroLINUX : Un nouveau logiciel de gravure de CD et DVD. Évalué à 8.
Ils n'ont pas à se vanter de ce port : les bugs de leurs softs n'ont pas a être corrigé (parceque close source et "pas de support linux"). Pas de version pour les architectures minoritaires (eg linux/ppc, linux/mips ...), pas de version pour les plateformes *BSD etc.
On se retrouve donc avec exactement le même problème que java (les sources de java sont certes disponibles mais on ne peut distribuer les modifs, pas de sdk sun pour linux/sparc, ou *BSD): la communauté s'habitue à ces soutils, parcequ'elle prend le monde "Lintel" (linux/intel) pour le tout. La consequence c'est que les archis et plateformes minoritaires sont toujours plus isolées par les "Linteliens" cedant leur liberté et celle des autres par inconscience ...
[^] # Re: Quel avantage ?
Posté par herodiade . En réponse à la dépêche NeroLINUX : Un nouveau logiciel de gravure de CD et DVD. Évalué à 4.
[^] # Re: Mais au fait comment proteger?
Posté par herodiade . En réponse à la dépêche Maui X-Stream aurait volé du code sous GPL et se serait approprié le copyright de PearPC. Évalué à 0.
Et s'envoyer une enveloppe ouverte, la remplir et la fermer au besoin (après coup)?
non, le coup de l'enveloppe comme preuve légale, c'est une légende.
[^] # Re: Pof, faille refermée
Posté par herodiade . En réponse à la dépêche Le projet PaX compromis. Évalué à 2.
[^] # Re: Pas de ports ps2 en 2.6.11
Posté par herodiade . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 4.
Si oui, peut-être devrait tu essayer le 2.6.11.1 (http://www.kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/)(...)
[^] # Re: oops pardon
Posté par herodiade . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 4.
From: Linus Torvalds <torvalds () osdl ! org>
"[...]I think we should drop the
original even/odd suggestion for now, and see if this would make more
sense.."
http://marc.theaimsgroup.com/?l=linux-kernel&m=110987495523158&(...)
[^] # Re: brevets
Posté par herodiade . En réponse à la dépêche IBM, Linux et l'Open Source. Évalué à 6.
[^] # Re: La FSF se la joue très très fairplay...
Posté par herodiade . En réponse à la dépêche Theo de Raadt reçoit le FSF Award 2004. Évalué à 5.
[^] # Re: La FSF se la joue très très fairplay...
Posté par herodiade . En réponse à la dépêche Theo de Raadt reçoit le FSF Award 2004. Évalué à 7.
[^] # Re: Pas mal
Posté par herodiade . En réponse à la dépêche Un jeu online sur les sous-marins 100% libre. Évalué à 1.
Touché-coullé doit être dans le domaine publique maintenant ;)
[^] # Re: Pressions diplomatiques ?
Posté par herodiade . En réponse à la dépêche Brevets Logiciels : le Parlement néerlandais à la rescousse. Évalué à 5.