Admettons que chacun d'entre eux ne contribue qu'une heure par semaine, [...]. On peut donc estimer que les logiciels libres sont équivalents à une entreprise de 100k à 200k personnes ce qui est équivalent à la taille de HP ou d'IBM qui ont bien d'autres activités que du logiciel sur catalogue.
Il ne faut oublier qu'il y a aussi des developpeurs de logiciels libres salariés et à temps plein. Par exemple chez IBM et HP ;)
MS a annoncé qu'en aucun cas le format OASIS ne sera intégré dans la suite MS Office.
Quelles sont les suites bureautiques compatibles, si cette décision du Massachussets était confirmée ?
Je ne vois qu'OpenOffice.org et Koffice. Existe-t-il d'autres alternatives ?
p.s.: par ailleur, les versions d'Ooo supportant OD (2.0 et 1.1.5) sont encore en béta si je ne me trompe. Qu'en est-il pour koffice ? peut-on se prévaloir d'une suite complète et finalisée pour faire du prosélytisme pour OD ? et/ou d'une suite propriétaire (ce qui permetrai de prouver facilement que tout l'univers de l'informatique de bureautique est conceré, pas seulement le libre) ?
Il faut noter que l'atelier des développeurs n'a pas pour vocation d'implémenter (en un temps si court !) les fonctionalités indiquées, mais plutôt d'en discuter.
Un des sujets de discussion, pas indiqué dans la dépêche mais très important : « Connection tracking IPv6 support: nf_conntrack ». En gros, pour les anglophobes: support du suivi de connexions pour IPv6 via nf_conntrack. En effet Netfilter ne gère toujours pas le traffic IPv6 de façon statefull ("suivi des connexions avec états").
Celà signifie qu'il est à ce jour beaucoup plus difficile d'obtenir un niveau de sécurité correct sous Linux en IPv6 qu'en IPv4, ce qui n'aide pas à la promotion de ce protocole. Et sur ce point Linux/Netfilter est très en retard par rapport aux autres firewall libres (en particulier dans le monde *BSD, les firewalls ipf et pf). Souhaitons que l'atelier Netfilter 2005 donne l'impulsion nécéssaire !
Debian cherche à être aussi universels que possible (à priori pas une mauvaise chose). Cet état d'esprit est hélas vu l'ampleur de la tâche incompatible avec un quelconque planning indispensable dans les entreprises ayant une certaine taille.
Si tu parle de la portabilité, je ne vois pas en quoi ça empecherai de plannifier. Par exemple NetBSD et OpenBSD sont au moins aussi portables que Debian mais n'ont pas de problèmes de planning.
Au restaurant, on décide du menu à l'avance (lorsqu'on prend commande), on change rarement de choix en cours de route, et la préparation est suffisament rapide pour que les produits soient encore frais lorsqu'ils sont servis ...
Je ne vois absolument pas en quoi le fait de mettre trois ans à preparer une release, en incluant, du coup, de tres nombreux et importants changements, est gage d'une meilleure qualité.
Peut tu m'éclairer ?
De nombreux projets libres choisissent, au nom de la qualité, justement, de faire des releases fréquentes (eg. le kernel linux, apache) voir fréquentes et prévisibles dans le temps (eg. Gnome, OpenBSD).
Chaque release inclue alors un nombre limité de changements. L'attention de tout les developpeurs et testeurs porte sur ces changements car ils sont en nombre suffisament limité pour être listables et bien connus de tous. Si l'un de ces changements s'avere necessiter plus de travail (est trop buggué), il est "backouté" (enlevé) avant la release. Bref, des evolutions frequentes plutot que des revolutions, cela permet un travail très focalisé.
Cette demarche permet en outre d'appuyer les developpements suivants sur des bases saines et bien établies, évitant de perdre du temps par exemple avec des bugs mysterieux lors de l'integration d'une nvlle version d'x.org parceque la version de gcc ou du kernel n'est pas encore bien au point (alors que si on a fait une release auparavant incluant le nouveau gcc, les bugs seront bien polis et/ou connus)...
Je me souviens que pendant son cycle de developpement, Sarge a intégré successivement un gnome 2.2, puis un 2.4, puis un 2.6 (avec à chaque fois de nouveaux bugs, de nouveaux rapports de bugs etc.). Que de temps perdu, pour les devs et les testeurs ... à chaque fois je pensait qu'il s'agissait de la version qui sera intégré dans la release et je passer beaucoup de temps à tester ... tout ça bien sûr parceque la release tardait à venir ...
D'autre part les analyses concernant ce problème de temps de release pour Sarge par des membres de la release team et des ftp masters évoquent généralement des problèmes d'infrastructure (serveur de compilation en panne, trop d'architectures, membres de la release team occupés sur ubuntu, etc.). En tout cas tout les developpeurs important (y compris les leaders sucessifs) s'accordent à reconnaitre qu'il y a là un problème majeur.
J'ai l'impression que seuls les dévots Debian (non developpeurs) refusent encore de considérer le temps de dev de Sarge comme un problème, au nom du très falacieux et légerement sybilin "on release quand c'est pret" (btw: donne moi une definition, stp, du "c'est pret").
Ceci dit sans préjuger de Debian, que je trouve d'excellente qualité. Mais elle ne le restera (de bonne qualité) qu'à condition que ses developpeurs et utilisateurs sachent être objectifs pour analyser les points faibles. En particulier le problème d'échéance des releases.
Mais lorsque tu prends du Cisco c'est en général que tu dois pouvoir tenir une charge importante
Oui et non, Cisco vend de plus en plus de petits matériels (routeurs SOHO, passerelles adsl, petits firewalls, petites passerelles ipsec, access points ...).
Dans ces condition le logiciel libre excelle par sa souplesse et peu aisément remplacer Cisco.
grsecurity/PaX n'existe pas sous *BSD :p
C'est un troll ou quoi ?
OpenBSD possède les mêmes protections mémoires que fournis PaX (et d'autres aussi), et de plus, est compilé avec un gcc+propolice (aka spp, "smashing stack protection"). Parfois j'aimerai que les linuxiens regardent un peu ce qui se fait autour d'eux ... (bon, les windowsiens encore plus, hein ;).
Et puisqu'on parle de remplacer cisco, OpenBSD intègre maintenant par default des serveur isakmp, bgp et ospf très sécurisés (developpés par les mêmes gars qui ont fait le firewall pf).
que mettre à la place de routeurs Cisco sur des infrastructure réseau complexes
Ca c'est le resultat brillant de l'intox cisco ("il n'y a que nous"). Je connais au moins une marque de routeurs très haut de gamme, Juniper, qui explose cisco sur les réseaux très exigeants (malheureusement ces routeurs sont très chers).
Je suis certain qu'il existe plein d'autres bonnes marques de routeurs.
Et on peut d'ors et déjà leur substituer des logiciels libres sur du simple pécé dans de très nombreuses PME, lorsque les besoins en perfs sont moindres, ou dans les cas d'utilisations (peut etre tres frequents) où ce n'est pas le nombre de pps routés qui compte: endpoits ipsec, petits firewalls, access points wifi, serveurs d'authentification, passerelles rnis ...
ils pourraient se justifier en arguant que révéler la faille fait courir un risque très important aux infrastructures réseau,
Heu ... ?
Si "ne pas la révéler" a comme conséquence qu'elle ne soit patchée, je dirait que c'est l'inverse: se taire fait courir un risque important.
Par ailleur Cisco ne peut définitivement plus arguer d'irresponsabilité des chercheurs dans les cas (comme celui-la) de full disclosure étant donné que leurs pratiques ignobles à l'encontre des chercheurs qui les contactent avant de révéler les failles sont maintenant connues et publiques (cf. les liens ci-dessus).
Cisco se conduit plus mal que n'importe quelle autre société, y compris microsoft, en ce qui concerne sa façon de réagir aux failles de sécurité.
Il semble que leur nouvelle politique consiste breveter la solution à la faille si elle touche d'autres systèmes (même s'ils n'ont pas inventé la solution) et intenter des procès aux chercheurs qui découvrent les failles.
Leur utilisation extensive et abusive des brevets au sein de l'ietf est une autre affaire, mais pas vraiment plus reluisante.
Ca ressemble à une société dont les décisions (y compris concernant la technique) sont prises par l'equipe de comm'. Esperons que cette afaire leur fasse assez mauvaise presse pour rectifier le tir dorénavant.
Quelqu'un sait-il comment faire en sorte que le kernel dumpe un core automatiquement, en cas de problème (par exemple lors des kernel panics, et avec ou sans kdump) ?
Suffit-il de compiler le kernel avec -g ou bien ?
Et où se trouvera le coredump ?
À mon avis, c'est pas demain la veille que les devs BSD accepteront des kludges pareils dans leur noyau ...
Quant au reste de la problèmatique, c'est aussi la question de savoir si l'on accepte de transgresser allègrement les standards (en l'occurence la sémantique posix d'accès aux systèmes de fichiers).
En tant qu'utilisateur de systèmes BSD je peut vous dire qu'il est souvent désesperant de constater le nombre d'applications libres linuxentriques (eg. qui vont taper dans /proc là ou un appel système posix ferait l'affaire etc.). Heureusement ce sont souvent les applications les plus mal codées: on peut se servir de ce genre de choses comme d'un filtre qui permet de garder un système stable.
Concernant FUSE, des solutions alternatives et portables fonctionnent en userland, comme le gnome-vfs par exemple.
Par exemple l'an dernier Cisco a breveté les solutions proposées aux failles dite "Slipping In The window: TCP Reset Attacks". cf. http://kerneltrap.org/node/3085(...)
Vous préferez avoir un kernel patent-free ou un kernel dont les failles sont corrigées ?
Dans la même veine, Cisco a tenté de fagociter le travail du groupe de l'IETF sur VRRP (après avoir bien laissé le temps à tout le monde de designer bénévolement de nouveaux concepts) sous pretexte qu'ils auraient enfreint leurs brevets sur HSRP (entre autres). cf. http://www.ietf.org/ietf/IPR/VRRP-CISCO(...)
Il semblerait donc que la nouvelle politique de Cisco soit de breveter le plus vite possible le travail des autres (enfin, en attendant tout de même que ce travail soit bien fini, tant qu'à faire), pour ensuite revendiquer leur brevets et s'approprier ce travail. Si possible en utilisant l'IETF comme un labo dont on s'approprie les idées et où les gens travaillent gratos (et puis c'est tellement pratique, quand son brevet vérouille une rfc ou autre standard officiel béni par l'IETF ...).
C'est bien entendu particulièrement calamiteux lorsque le brevet concerne la solution à une faille de sécurité.
Bref Cisco mérite bien une dépêche critique. On ne doit pas se laisser faire, face a un tel comportement. Même microsoft ne pousse pas le bouchon aussi loin.
Et c'est sans parler de la qualité des outils qui vont avec, le nouvel OpenBGBD, pf, carp etc. Et bientôt un OpenOSPFSD et un sytème de redondance des passerelles IPSec/ISAKMP à la façon pfsync+carp ... une tuerie !
Pas trop compris les motivations de cette accusations, si c'est juste, la colère de ne finalement pas avoir pu breveter le machin, cette réaction est digne d'un élève de maternelle.
Le propos de Cisco c'est qu'en annonçant publiquement la faille (full disclosure), plutot que d'attendre que les diverses parties l'aient corrigé discrétement (ou breveté la solution, btw), le chercheur pointe une vulnérabilité encore ouverte, dont les "terroristes" pourraient tirer partie.
C'est une démarche de culpabilisation dont la société Microsoft est d'ailleur familliere: le chercheur est censé divulguer les détails de tout problème de sécurité à MS seulement (même lorsqu'il s'agit, comme dans ce cas, d'un problème générique touchant tout les OS), et MS décide de la date de publication de la faille (comprendre: quand ils ont décidé que ça les arrengeait commerciallement). Grace à la docilité de nombreux chercheurs MS peut ainsi affirmer corriger les failles plus vite que Linux (ou avoir a un instant t moins de failles connues/publiées).
on reste comme avant avec un office des brevets qui brevette n'importe quoi en toute illegalite.
Justement, que ce passe-t-il si une société attaque sur la base d'un tel brevet ?
Est-ce qu'un developpeur sans argent pourra gagner dans un tribunal, face à une grosse entreprise, en arguant du rejet de la directive (mais necessitant le désaveu en justice d'un document produit par une administration officielle) ?
Oui. Il faut les sources d'une version précise de ffmepg (le cvs du 27 Avril 2005) sinon ça ne marche pas. Et ces sources doivent être configurées (sans ogg) et compilées.
Il faut reconnaitre (aux vues des warnings de gcc notamment, mais pas seulement) que le code et le "configure" de vlc sont vraiment ultra crades. Le fait de dépendre de moultes libs externes (nécessaire, pour avoir un bon support des codecs vidéos exotiques) n'aide en rien (mais avec les mêmes contraintes, mplayer fait beaucoup mieux amha).
Oui, attention, je ne remet pas en cause l'importance et l'interet des discussions (et même des trolls).
Mon propos était seulement de faire remarquer qu'il y a de sérieux problèmes de prise de décision et de passage à l'action, à tout les niveaux.
En termes d'éfficacité et de résultats, je crois que la démarche un peu "despotique" des projets comme OpenBSD ou Slackware tient souvent la dragée haute à la démarche "démocratique" de Debian. Et ce malgrè des ressources (nombre de developpeurs) très restreintes.
Justement, il me semble que le problème significatif, c'est que de longues discussions ou trolls ont étés engagés, les idées de solutions pleuvent, plein de developpeurs sont mobilisés pour débatre sur ce sujet sur les mailing-lists ... mais rien ne se passe.
Même les membres autorisés de l'équipe de sécurité (déclarés "inactifs", certes, mais qui se manifestent pour participer au bruit général) préfèrent troller sur le problème sur les mailing-lists plutôt que de le résoudre (sachant qu'il s'agit en gros de poser des paquets déjà prets sur un ftp).
Le fonctionement de Debian est devenu tellement bureaucratique que rien n'avance, que les décisions urgentes ne sont jamais prises à temps.
Il suffit de se souvenir de la façon dont a été géré le problème des dépôts trojannés il y a un an ou deux pour voir que le problème est chronique, que le problème actuel n'est pas une exception. Sans parler de tout ce qui a conduit à un tel délai pour la release de Sarge (avec, au passage, 0 décision pour rectifier le tir pour etch, alors que tout le monde est conscient du problème).
Autrement dit, ce n'est plus seulement un problème de l'équipe de sécurité, c'est devenu (ou ça révèle) un problème plus profond de prises de décisions et de passage à l'action. Le timing de la dépêche linuxfr est donc parfait, il permet de se rendre compte de l'ampleur des dégats.
[^] # Re: format OpenDocument: une utopie ?
Posté par herodiade . En réponse à la dépêche Le Massachussets dit non à MSOffice, puis oui, puis non. Évalué à 1.
Admettons que chacun d'entre eux ne contribue qu'une heure par semaine, [...]. On peut donc estimer que les logiciels libres sont équivalents à une entreprise de 100k à 200k personnes ce qui est équivalent à la taille de HP ou d'IBM qui ont bien d'autres activités que du logiciel sur catalogue.
Il ne faut oublier qu'il y a aussi des developpeurs de logiciels libres salariés et à temps plein. Par exemple chez IBM et HP ;)
# Support OpenDocument
Posté par herodiade . En réponse à la dépêche Le Massachussets dit non à MSOffice, puis oui, puis non. Évalué à 10.
Quelles sont les suites bureautiques compatibles, si cette décision du Massachussets était confirmée ?
Je ne vois qu'OpenOffice.org et Koffice. Existe-t-il d'autres alternatives ?
p.s.: par ailleur, les versions d'Ooo supportant OD (2.0 et 1.1.5) sont encore en béta si je ne me trompe. Qu'en est-il pour koffice ? peut-on se prévaloir d'une suite complète et finalisée pour faire du prosélytisme pour OD ? et/ou d'une suite propriétaire (ce qui permetrai de prouver facilement que tout l'univers de l'informatique de bureautique est conceré, pas seulement le libre) ?
# États pour IPv6
Posté par herodiade . En réponse à la dépêche Préparation de l'atelier Netfilter 2005. Évalué à 9.
Un des sujets de discussion, pas indiqué dans la dépêche mais très important : « Connection tracking IPv6 support: nf_conntrack ». En gros, pour les anglophobes: support du suivi de connexions pour IPv6 via nf_conntrack. En effet Netfilter ne gère toujours pas le traffic IPv6 de façon statefull ("suivi des connexions avec états").
Celà signifie qu'il est à ce jour beaucoup plus difficile d'obtenir un niveau de sécurité correct sous Linux en IPv6 qu'en IPv4, ce qui n'aide pas à la promotion de ce protocole. Et sur ce point Linux/Netfilter est très en retard par rapport aux autres firewall libres (en particulier dans le monde *BSD, les firewalls ipf et pf). Souhaitons que l'atelier Netfilter 2005 donne l'impulsion nécéssaire !
[^] # Re: Intérêt?
Posté par herodiade . En réponse à la dépêche Lancement de Debian Common Core. Évalué à 2.
Pourtant LSB 2 est maintenant supporté par les distros majeures (Debian, Ubuntu, RH/Fedora, Mandriva, Suse, ...).
À votre avis, pourquoi cette norme a si peut de succès auprès des éditeurs (qui continuent de préférer certifier leurs produits pour RHEL ou SUSE) ?
Je trouve ça dommage, et je ne comprend pas bien cet échec.
[^] # Re: Correction : Je n'utilise PLUS Debian.
Posté par herodiade . En réponse à la dépêche Lancement de Debian Common Core. Évalué à 0.
Si tu parle de la portabilité, je ne vois pas en quoi ça empecherai de plannifier. Par exemple NetBSD et OpenBSD sont au moins aussi portables que Debian mais n'ont pas de problèmes de planning.
[^] # Re: sorties prévisibles ????
Posté par herodiade . En réponse à la dépêche Lancement de Debian Common Core. Évalué à 1.
[^] # Re: sorties prévisibles ????
Posté par herodiade . En réponse à la dépêche Lancement de Debian Common Core. Évalué à 0.
Peut tu m'éclairer ?
De nombreux projets libres choisissent, au nom de la qualité, justement, de faire des releases fréquentes (eg. le kernel linux, apache) voir fréquentes et prévisibles dans le temps (eg. Gnome, OpenBSD).
Chaque release inclue alors un nombre limité de changements. L'attention de tout les developpeurs et testeurs porte sur ces changements car ils sont en nombre suffisament limité pour être listables et bien connus de tous. Si l'un de ces changements s'avere necessiter plus de travail (est trop buggué), il est "backouté" (enlevé) avant la release. Bref, des evolutions frequentes plutot que des revolutions, cela permet un travail très focalisé.
Cette demarche permet en outre d'appuyer les developpements suivants sur des bases saines et bien établies, évitant de perdre du temps par exemple avec des bugs mysterieux lors de l'integration d'une nvlle version d'x.org parceque la version de gcc ou du kernel n'est pas encore bien au point (alors que si on a fait une release auparavant incluant le nouveau gcc, les bugs seront bien polis et/ou connus)...
Je me souviens que pendant son cycle de developpement, Sarge a intégré successivement un gnome 2.2, puis un 2.4, puis un 2.6 (avec à chaque fois de nouveaux bugs, de nouveaux rapports de bugs etc.). Que de temps perdu, pour les devs et les testeurs ... à chaque fois je pensait qu'il s'agissait de la version qui sera intégré dans la release et je passer beaucoup de temps à tester ... tout ça bien sûr parceque la release tardait à venir ...
D'autre part les analyses concernant ce problème de temps de release pour Sarge par des membres de la release team et des ftp masters évoquent généralement des problèmes d'infrastructure (serveur de compilation en panne, trop d'architectures, membres de la release team occupés sur ubuntu, etc.). En tout cas tout les developpeurs important (y compris les leaders sucessifs) s'accordent à reconnaitre qu'il y a là un problème majeur.
J'ai l'impression que seuls les dévots Debian (non developpeurs) refusent encore de considérer le temps de dev de Sarge comme un problème, au nom du très falacieux et légerement sybilin "on release quand c'est pret" (btw: donne moi une definition, stp, du "c'est pret").
Ceci dit sans préjuger de Debian, que je trouve d'excellente qualité. Mais elle ne le restera (de bonne qualité) qu'à condition que ses developpeurs et utilisateurs sachent être objectifs pour analyser les points faibles. En particulier le problème d'échéance des releases.
[^] # Re: Compléments et correction
Posté par herodiade . En réponse au journal Cisco voit rouge.. Évalué à 2.
Oui et non, Cisco vend de plus en plus de petits matériels (routeurs SOHO, passerelles adsl, petits firewalls, petites passerelles ipsec, access points ...).
Dans ces condition le logiciel libre excelle par sa souplesse et peu aisément remplacer Cisco.
grsecurity/PaX n'existe pas sous *BSD :p
C'est un troll ou quoi ?
OpenBSD possède les mêmes protections mémoires que fournis PaX (et d'autres aussi), et de plus, est compilé avec un gcc+propolice (aka spp, "smashing stack protection"). Parfois j'aimerai que les linuxiens regardent un peu ce qui se fait autour d'eux ... (bon, les windowsiens encore plus, hein ;).
Et puisqu'on parle de remplacer cisco, OpenBSD intègre maintenant par default des serveur isakmp, bgp et ospf très sécurisés (developpés par les mêmes gars qui ont fait le firewall pf).
[^] # Re: Bugs == IP
Posté par herodiade . En réponse au journal Cisco voit rouge.. Évalué à 3.
cf. http://linuxfr.org/2005/07/14/19309.html(...)
Cisco les multiplie ces derniers temps ...
[^] # Re: Monopole .....
Posté par herodiade . En réponse à la dépêche Politique sécurité de Cisco. Évalué à 9.
Ca c'est le resultat brillant de l'intox cisco ("il n'y a que nous"). Je connais au moins une marque de routeurs très haut de gamme, Juniper, qui explose cisco sur les réseaux très exigeants (malheureusement ces routeurs sont très chers).
Je suis certain qu'il existe plein d'autres bonnes marques de routeurs.
Et on peut d'ors et déjà leur substituer des logiciels libres sur du simple pécé dans de très nombreuses PME, lorsque les besoins en perfs sont moindres, ou dans les cas d'utilisations (peut etre tres frequents) où ce n'est pas le nombre de pps routés qui compte: endpoits ipsec, petits firewalls, access points wifi, serveurs d'authentification, passerelles rnis ...
ils pourraient se justifier en arguant que révéler la faille fait courir un risque très important aux infrastructures réseau,
Heu ... ?
Si "ne pas la révéler" a comme conséquence qu'elle ne soit patchée, je dirait que c'est l'inverse: se taire fait courir un risque important.
Par ailleur Cisco ne peut définitivement plus arguer d'irresponsabilité des chercheurs dans les cas (comme celui-la) de full disclosure étant donné que leurs pratiques ignobles à l'encontre des chercheurs qui les contactent avant de révéler les failles sont maintenant connues et publiques (cf. les liens ci-dessus).
# Ils n'ont pas tardé à recidiver ...
Posté par herodiade . En réponse à la dépêche Comment des vendeurs essaient de breveter les solutions à des failles de sécurité qui leur sont fournies. Évalué à 2.
http://linuxfr.org/2005/08/03/19393.html(...)
# Encore une fois ...
Posté par herodiade . En réponse à la dépêche Politique sécurité de Cisco. Évalué à 10.
Cisco se conduit plus mal que n'importe quelle autre société, y compris microsoft, en ce qui concerne sa façon de réagir aux failles de sécurité.
Il semble que leur nouvelle politique consiste breveter la solution à la faille si elle touche d'autres systèmes (même s'ils n'ont pas inventé la solution) et intenter des procès aux chercheurs qui découvrent les failles.
L'affaire des failles du protocole icmp de juillet 2005:
http://linuxfr.org/2005/07/14/19309.html(...)
L'affaire des failles du protocole tcp de mai 2004:
http://kerneltrap.org/node/3085(...)
Leur utilisation extensive et abusive des brevets au sein de l'ietf est une autre affaire, mais pas vraiment plus reluisante.
Ca ressemble à une société dont les décisions (y compris concernant la technique) sont prises par l'equipe de comm'. Esperons que cette afaire leur fasse assez mauvaise presse pour rectifier le tir dorénavant.
# Position de Bruce Schneier
Posté par herodiade . En réponse à la dépêche Politique sécurité de Cisco. Évalué à 6.
http://www.schneier.com/blog/archives/2005/07/cisco_harasses.html(...)
[^] # Re: ...
Posté par herodiade . En réponse à la dépêche PC portables sous Linux : le bout du tunnel ?. Évalué à -1.
# Kdump
Posté par herodiade . En réponse à la dépêche Bilan du sommet 2005 des développeurs du noyau Linux. Évalué à 2.
Suffit-il de compiler le kernel avec -g ou bien ?
Et où se trouvera le coredump ?
[^] # Re: Vert et Noir comme ...
Posté par herodiade . En réponse à la dépêche Bilan du sommet 2005 des développeurs du noyau Linux. Évalué à 7.
Quant au reste de la problèmatique, c'est aussi la question de savoir si l'on accepte de transgresser allègrement les standards (en l'occurence la sémantique posix d'accès aux systèmes de fichiers).
En tant qu'utilisateur de systèmes BSD je peut vous dire qu'il est souvent désesperant de constater le nombre d'applications libres linuxentriques (eg. qui vont taper dans /proc là ou un appel système posix ferait l'affaire etc.). Heureusement ce sont souvent les applications les plus mal codées: on peut se servir de ce genre de choses comme d'un filtre qui permet de garder un système stable.
Concernant FUSE, des solutions alternatives et portables fonctionnent en userland, comme le gnome-vfs par exemple.
[^] # Re: multi récidivistes
Posté par herodiade . En réponse à la dépêche Comment des vendeurs essaient de breveter les solutions à des failles de sécurité qui leur sont fournies. Évalué à 6.
Oui, c'est ce que disent tout les zélotes du brevet logiciel.
Cet exemple (celui de la dépêche) prouve que les entreprises ne sont pas capables de se réguler pour faire un usage décent de la brevetabilité.
[^] # Re: Terroriste!?
Posté par herodiade . En réponse à la dépêche Comment des vendeurs essaient de breveter les solutions à des failles de sécurité qui leur sont fournies. Évalué à 4.
# multi récidivistes
Posté par herodiade . En réponse à la dépêche Comment des vendeurs essaient de breveter les solutions à des failles de sécurité qui leur sont fournies. Évalué à 10.
Par exemple l'an dernier Cisco a breveté les solutions proposées aux failles dite "Slipping In The window: TCP Reset Attacks". cf. http://kerneltrap.org/node/3085(...)
Vous préferez avoir un kernel patent-free ou un kernel dont les failles sont corrigées ?
Dans la même veine, Cisco a tenté de fagociter le travail du groupe de l'IETF sur VRRP (après avoir bien laissé le temps à tout le monde de designer bénévolement de nouveaux concepts) sous pretexte qu'ils auraient enfreint leurs brevets sur HSRP (entre autres). cf. http://www.ietf.org/ietf/IPR/VRRP-CISCO(...)
Il semblerait donc que la nouvelle politique de Cisco soit de breveter le plus vite possible le travail des autres (enfin, en attendant tout de même que ce travail soit bien fini, tant qu'à faire), pour ensuite revendiquer leur brevets et s'approprier ce travail. Si possible en utilisant l'IETF comme un labo dont on s'approprie les idées et où les gens travaillent gratos (et puis c'est tellement pratique, quand son brevet vérouille une rfc ou autre standard officiel béni par l'IETF ...).
C'est bien entendu particulièrement calamiteux lorsque le brevet concerne la solution à une faille de sécurité.
Bref Cisco mérite bien une dépêche critique. On ne doit pas se laisser faire, face a un tel comportement. Même microsoft ne pousse pas le bouchon aussi loin.
[^] # Re: Terroriste!?
Posté par herodiade . En réponse à la dépêche Comment des vendeurs essaient de breveter les solutions à des failles de sécurité qui leur sont fournies. Évalué à 1.
Et c'est sans parler de la qualité des outils qui vont avec, le nouvel OpenBGBD, pf, carp etc. Et bientôt un OpenOSPFSD et un sytème de redondance des passerelles IPSec/ISAKMP à la façon pfsync+carp ... une tuerie !
Btw, puisqu'on parle des réactions d'OpenBSD face à Cisco et leur délire avec les brevets: http://openbsd.org/lyrics.html#35(...)
[^] # Re: Terroriste!?
Posté par herodiade . En réponse à la dépêche Comment des vendeurs essaient de breveter les solutions à des failles de sécurité qui leur sont fournies. Évalué à 6.
Le propos de Cisco c'est qu'en annonçant publiquement la faille (full disclosure), plutot que d'attendre que les diverses parties l'aient corrigé discrétement (ou breveté la solution, btw), le chercheur pointe une vulnérabilité encore ouverte, dont les "terroristes" pourraient tirer partie.
C'est une démarche de culpabilisation dont la société Microsoft est d'ailleur familliere: le chercheur est censé divulguer les détails de tout problème de sécurité à MS seulement (même lorsqu'il s'agit, comme dans ce cas, d'un problème générique touchant tout les OS), et MS décide de la date de publication de la faille (comprendre: quand ils ont décidé que ça les arrengeait commerciallement). Grace à la docilité de nombreux chercheurs MS peut ainsi affirmer corriger les failles plus vite que Linux (ou avoir a un instant t moins de failles connues/publiées).
[^] # Re: C'est fini pour aujourd'hui ...
Posté par herodiade . En réponse à la dépêche Manifestation contre les brevets logiciels au Parlement Européen à Strasbourg. Évalué à 2.
Justement, que ce passe-t-il si une société attaque sur la base d'un tel brevet ?
Est-ce qu'un developpeur sans argent pourra gagner dans un tribunal, face à une grosse entreprise, en arguant du rejet de la directive (mais necessitant le désaveu en justice d'un document produit par une administration officielle) ?
[^] # Re: CGI
Posté par herodiade . En réponse au journal modeste contribution gfreeplayer. Évalué à 1.
Il faut reconnaitre (aux vues des warnings de gcc notamment, mais pas seulement) que le code et le "configure" de vlc sont vraiment ultra crades. Le fait de dépendre de moultes libs externes (nécessaire, pour avoir un bon support des codecs vidéos exotiques) n'aide en rien (mais avec les mêmes contraintes, mplayer fait beaucoup mieux amha).
[^] # Re: Un problème de prise de décisions chronique chez Debian
Posté par herodiade . En réponse à la dépêche Debian Sarge a des problèmes sérieux de gestion de la sécurité. Évalué à 1.
Mon propos était seulement de faire remarquer qu'il y a de sérieux problèmes de prise de décision et de passage à l'action, à tout les niveaux.
En termes d'éfficacité et de résultats, je crois que la démarche un peu "despotique" des projets comme OpenBSD ou Slackware tient souvent la dragée haute à la démarche "démocratique" de Debian. Et ce malgrè des ressources (nombre de developpeurs) très restreintes.
[^] # Un problème de prise de décisions chronique chez Debian
Posté par herodiade . En réponse à la dépêche Debian Sarge a des problèmes sérieux de gestion de la sécurité. Évalué à 5.
Même les membres autorisés de l'équipe de sécurité (déclarés "inactifs", certes, mais qui se manifestent pour participer au bruit général) préfèrent troller sur le problème sur les mailing-lists plutôt que de le résoudre (sachant qu'il s'agit en gros de poser des paquets déjà prets sur un ftp).
Le fonctionement de Debian est devenu tellement bureaucratique que rien n'avance, que les décisions urgentes ne sont jamais prises à temps.
Il suffit de se souvenir de la façon dont a été géré le problème des dépôts trojannés il y a un an ou deux pour voir que le problème est chronique, que le problème actuel n'est pas une exception. Sans parler de tout ce qui a conduit à un tel délai pour la release de Sarge (avec, au passage, 0 décision pour rectifier le tir pour etch, alors que tout le monde est conscient du problème).
Autrement dit, ce n'est plus seulement un problème de l'équipe de sécurité, c'est devenu (ou ça révèle) un problème plus profond de prises de décisions et de passage à l'action. Le timing de la dépêche linuxfr est donc parfait, il permet de se rendre compte de l'ampleur des dégats.