Je pense qu'il y a comme une erreur dans la nouvelle: c'est le Conseil des Ministres et non la Commission, qui a validé les brevets logiciels, dans le cadre de la procédure de codécision qui a été démarrée après que le Parlement ait infligé un camouflet à la Commission (enfin, à Bolkestein).
Il faut corriger cette nouvelle, l'erreur étant d'importance !
Sinon, il faut également préciser que le revirement de l'Allemagne est vraisemblablement la cause de cette adoption.
Pour finir, je vous invite également à aller voir ce sujet connexe: http://fr.news.yahoo.com/040518/7/3t2aj.html(...)
(ou comment la commission -enfin, Bolkestein- fait grand cas des données personnelles des européens...)
J'ai pas dit ça, j'ai dit que une grande structure pouvait plus facilement se payer des gens compétents.
financièrement c'est vrai, politiquement c'est loin d'être toujours vrai. et dans une grosse boite, c'est l'aspect politique qui prime tout le temps. reste à savoir le poids du coté financier dans la boite, par rapport aux autres dimensions de la vie politique interne à l'entreprise (relation de copinages, de renvois d'ascenceur, etc.).
à l'inverse, une structure de taille plus petite (en gros une PME d'une centaine de personnes), a souvent des décisions plus rationnelles, et sa capacité financière n'est pas forcément si ridicule que ça.
Mais qu'est-ce que vous avez tous à trouver cette distro (je parle de la woody) géniale ? (je te demande pas ça à toi en particulier)
J'administre un certain nombre de serveurs (heu... trop en fait).
Il y a du Debian, du RedHat, et meme maintenant du WhiteBox (sur une seule machine pas très importante, pour tester).
Ce sont systématiquement des serveurs.
Eh bien il m'est aujourd'hui totalement impossible d'utiliser une Debian Woody sans modifications ou rétroportages, et ce pour plusieurs raisons:
1- support matériel très mauvais. Les serveurs DELL qui viennent de sortir de la gamme ne marchaient PAS sur une Debian Woody (alors ceux qui les ont remplacés, n'en parlons meme pas). En cause: version trop ancienne du noyau Linux (entre autres). Ca veut dire que le support matériel est en retard non pas sur la génération courante, comme c'est le cas sur toutes les distros (ou à peu près), mais de plus d'une génération. C'est énorme. Pour mémoire, la RHEL3 tourne sans problème sur ces matériels.
2- logiciels incroyablement mal empaquetés. Attention, les .deb en eux-meme sont plutot de bonne facture, mais manque de pot, pour beaucoup de paquets, il y a des manques grossièrs dans la configuration du logiciel, qui donnent à penser que le mainteneur n'a jamais tapé de sa vie ./configure --help . Je précise que ces problèmes sont presque tous corrigés en unstable. Pour ceux que ça intéresse, il y a par exemple Linux (support QoS entre autres), solid-pop3d (audit de sécurité-logs pas activé), pdnsd, ....
3- il est impossible aujourd'hui de réaliser un serveur mail sous Debian Woody pure (antivirus, antispam etc. à la ramasse), ainsi qu'un firewall un peu musclé (support QoS foireux, cf. point 2), un serveur web sur lequel on a besoin de apache2, un serveur de fichier avec du bon support des dernières "évolutions" de chez Redmond (et donc de samba3), l'authentification par LDAP sur un serveur avec un schéma un peu incomplet, et la liste continue. Point à incriminer ici: versions trop vieilles des logiciels.
4- encore plus grave, il n'y a pas de support de LVM ni du RAID (logiciel) au niveau de l'installation. Si on veut ces fonctionnalités là (extrêmement importantes pour un serveur de prod, dans une vraie boite), il faut galérer.
Alors ma question est: qu'est ce que vous faites tourner vous comme Debian Woody (pure, hein, sans rétroports, paquets testing, etc.) ? A part un serveur LAMP (et encore, sur du matériel pas trop trop récent), j'avoue que je vois pas.
Pour moi, la Debian Woody "pure" est une distribution avec un installeur dépassé, des logiciels dépassés et mal empaquetés et du support parfait pour du vieux matériel (voire très vieux).
Honnêtement, tout ce qui retardera la sortie de Sarge est préjudiciable à l'utilisation de Debian, ce qui est très dommage, car j'apprécie par ailleurs la simplicité de conception de cette distribution, et le fait qu'on controle vraiment tout bien.
Par ailleurs, j'utilise "massivement" les rétroports (de backports.org pour la plupart), et je n'ai jamais eu à m'en plaindre, alors que je n'en dirais pas autant de security.debian.org, qui, par exemple, il y a deux semaines, a réussi à sortir un .deb du noyau (pour x86 et une ou deux autres archi), sans les modules ! (avec juste le vmlinuz). Problème corrigé quelques heures après bien sur, mais on peut pas dire que le controle qualité soit là.
A vrai dire, je n'ai pas cherché sur google, mais simplement je travaille (entre autres) dans ce secteur, et les documents en question, je les ai eus en main propre.
Certains de ces documents sont publics, notamment ceux écrits dans le cadre de la mission interministérielle "compétitivité numérique des PME" (eh oui, ce sont d'abord les petits garagistes qui souffrent de cette propriétarisation des logiciels et des accès à l'information): http://www.competitivite-numerique.com/compnum/succes/exemples_auto(...)
(le site est plutot pas terrible, et pas très explicite, mais bon...)
> Si tu veux savoir comment (et avec quoi) c'est fait ou comment certaines choses fonctionnent (gestion de l'injection par exemple), il te faudra décortiquer et analyser.
non seulement l'injection, mais aussi le freinage (ABS, etc.), la gestion du faisceau électrique (multiplexage), et tous les rafinements technologiques d'une voiture moderne (controle de la clim, des essuie-glace, etc.).
ce n'est souvent meme plus de l'électronique, mais bien de l'informatique.
il y a deux ans, j'ai amené par extraordinaire ma vieille Mégane à réparer chez un concessionnaire Renault (au lieu du petit agent Renault à coté de chez moi). Il s'est aperçu que le firmware du logiciel d'injection n'était pas à jour, et il l'a flashé (seuls les concessionnaires peuvent faire cela, la "malette" d'accès à l'injection coutant dans les 10 000 euros, et étant assez souvent spécifique au moteur). Résultat: autonomie avec un réservoir passée de 450 à 650 km. Intéressant pour un simple changement de firmware... (pour etre parfaitement juste, il me semble que, grace à leur, malette ils avaient détecté un autre truc, mais il m'a été confirmé que des écarts importants de consommation peuvent etre constatés rien qu'en changeant le firmware de l'injection)
En fait, les constructeurs automobile ont très bien compris l'intérêt du logiciel propriétaire pour leur métier, et vont tous dans cette direction. L'objectif étant de forcer les utilisateurs à faire les réparations et l'entretien dans le réseau du constructeur au lieu de tous ces centres autos qui fleurissent (Midas, Feu Vert, ...). Ceci permettant évidemment de faire monter la note en maintenant le client captif.
Dès aujourd'hui, à cause de ces logiciels propriétaires, sur certaines marques, il est impossible de faire l'entretien courant des modèles récents dans ces centres autos. Et ça va encore empirer.
Dernier point, au sujet de la RTA. En effet, les données techniques mécaniques doivent etre publiques (et le sont). Mais les constructeurs ont trouvé là encore la parade. C'est qu'il faut encore pouvoir identifier précisément le véhicule après coup (pour savoir quel jeu de données techniques utiliser). Et évidemment, ils font tout pour noyer le poisson, réservant la seule vraie information d'identification (à partir du numéro de série référencé sur la carte grise) à leur réseau. Ce point est beaucoup plus subtil à appréhender, mais bien réel.
En bref, la comparaison avec l'automobile est de nos jours une mauvaise idée, parce que l'automobile rencontre exactement les memes problèmes liés aux logiciels et aux standards que le monde des logiciels ! D'ailleurs, ces problèmes sont généralisables à la totalité des produits modernes un tant soit peu sophisitqués, pour les memes raisons (pensez magnétoscopes "intelligents", téléphones portables, ...). A mon sens, c'est d'ailleurs encore plus grave que de ne pas pouvoir relire un document Word dans dix ans.
Pour finir, sachez que tous ces problèmes sont très bien connus, et que plusieurs personnes travaillent au niveau de la commission européenne et du gouvernement pour mettre sinon un terme, du moins un frein à ces dérives (dans le monde de l'automobile).
les paquets kernel-*-13.1 corrigeant le problème (je parle pour x86) ont été sortis quelques heures après (hier en soirée, les paquets défectueux étant sortis dans la matinée, ce me semble)
> Ah ben voilà, je sais, je vais passer à une Debian Woody.
avec la Mandrake, tu étais au bord du précipice
avec la debian woody, tu fais un grand pas en avant ;-)
pour info, pas plus tard qu'hier, le debian security team a sorti un noyau ne contenant que le vmlinuz, pas les modules. résultat: machines HS après la MAJ. d'ailleurs, amha, la gestion des noyaux sur la Debian est incroyablement mal foutue (par rapport aux autres distros).
bon, je plaisante quand meme (pour le grand pas en avant), c'est pas si grave, d'abord pratiquement personne n'utilise une "vraie" woody (sans backports), ce serait tout bonnement inutilisable (ou alors pour faire juste un petit firewall à deux balles -plus compliqué ça marcherait pas, pour cause de support QoS foireux-), et de plus, comme tu es un utilisateur mainteannt aguerri de linux, tu aurais convenablement reconfiguré ton lilo avec des copies de noyau de secours, hein ? (faut pas attendre que la debian te le fasse pour toi).
après, ça fait déjà un bon moment que je me demande en quoi une distro peut etre soit-disant stable, à partir du moment où, pour l'utiliser il faut utiliser tous ces backports qui eux le sont moins, stables (meme si l'équipe de backports.org et des gens comme Aurélien Jarno font un travail fantastique, et que, dans la pratique, on est pas très loin du niveau de stabilité de la woody).
d'ailleurs, il y a une croyance comme quoi le problème de la Debian Woody, c'est d'avoir de vieux logiciels. ceci est en effet un problème pour quelques logiciels (clamav, spamassassin, gaim, WFree86, voire linux ...), mais le plus gros problème de la woody, c'est que beaucoup de logiciels et non des moindres (linux, solid-pop3d, pdnsd, bind, ...) sont MAL empaquetés ! Trop d'options de compilation n'ont pas été activées dans ces logiciels, pénalisant lourdement leur utilisation (QoS dans linux par ex., audit dans solid-pop3d, support tcp dans pdnsd, ...), ou alors la gestion de l'installation de ces paquets est fantaisiste (cf. linux), ou encore deux versions différentes se marchent plus ou moins sur les pieds.
la plupart des ces problèmes sont corrigés dans la sarge ou dans les backports.
ne vous méprenez pas, ceci n'est pas un plaidoyer anti-debian. mais ce serait juste sympa d'avoir un minimum d'honnêteté vis-à-vis des gens qui veulent aujourd'hui essayer de l'utiliser: il faut savoir à quoi s'attendre. dans la pratique, ceux qui essaient de mettre une woody pour un usage de bureau/jeux/développement finissent souvent avec une sarge, et les autres avec pleins de backports.
Bien sur, on t'enseigne dans toutes les ecoles qu'il faut faire des tests. Mais combien prennent le temps d'introduire des methodologies de tests ? Combien montrent par la pratique ce que c'est qu'un bon test ? Combien t'introduisent a des bibliotheques de tests ? Combien font la difference entre un test exhaustif et juste un test a la con ? Combien font la difference entre un test et un test automatise que tu dois lancer toutes les 5 minutes de developpement ?
Encore une fois, les tests ne sont pas le propre de XP. En méthode classique il devrait y avoir:
1- des tests unitaires avant tout commit CVS (pour vérifier que la fonctionnalité implémentée fonctionne), et si le code produit n'est pas immédiatement testable (ce qui est le cas quand on développe les couches les plus profondes du logiciel - métier, accès base de données par exemple), il faut le préciser dans le commit CVS et revenir dessus ultérieurement (lors de l'implémentation de la partie de la couche de présentation/interface correspondante)
2- une phase de tests et d'intégration lourde en fin de palier de développement (correspondant à un livrable)
la phase numéro 2, en particulier, doit comporter un mélange de tests automatisés (qualité de code, tests de charge, etc.) et de plan de tests pour un testage manuel.
et ce n'est pas que de la théorie, dans ma boite on a toujours travaillé comme ça (sauf l'aventure XP, sur laquelle ont avait pas la main, en fait), et ça marche.
Pour faire court:
1- oui, j'ai déjà utilisé XP (sur un projet de taille moyenne), et j'ai également été témoin de l'utilisation d'XP sur un gros projet
2- un biologiste c'est un scientifique. maintenant, quand ton client c'est un commercial (par exemple), je te garantis que si il y a pas de phase de specifications, tu te plantes
3- pour les interfaces, je cite le bouquin (qui cite des posts usenet je crois)
4- pour le design général, on s'est jamais plantés. maintenant, on s'est en gros arrêtés au schéma de la base de données, et on a jamais eu à modifier le nombre de tables (rajouter des colonnes, en revanche, oui). encore une fois, je suis pas non plus un fan du "tout-UML" à l'extrême.
5- l'appropriation ne marche pas, en particulier lors d'un remplacement d'équipe entre deux versions (évidemment). ce qui est un truc courant sur des projets un peu gros.
En gros, fais attention, tu ne fais pas la meme informatique que la mienne (clients scientifiques et bas niveau, alors que moi c'est plutot clients "littéraires" et assez haut niveau, gestion de l'information). Je reviens donc sur ce que je disais: tout n'est pas à jeter dans XP, mais il y a clairement pas que du bon.
J'ai fait un résumé du résumé, il va de soit que je suis plus que simpliste... mais je pointe un lien vers l'article qui détaille tout et que je t'engage à lire.
Si tu me dis que parmi les points préconisés par XP il y a des trucs pas trop mauvais, voire bons, je suis d'accord (personnellement, je suis plus nuancé que le lien que je pointe).
Mais nul besoin de faire d'XP pour faire des tests. Ceci doit etre inclus dans un cycle de développement plus traditionnel.
De même, les releases courtes sur les fonctions clés, cela peut exister aussi sous une autre forme dans le développement "traditionnel", on appelle ça le maquettage, et c'est aussi préconisé sur les gros projets.
La transparence, c'est aussi conseillé en mode de développement traditionnel, mais il vaut mieux la faire en général sur les points que le client a une chance de comprendre, et il faut lui expliquer clairement, dans les termes de son métier, pas en utilisant de métaphores stupides (ou alors ce sont des points absolument pas métier, mais très techniques, et en ce cas, aucune métaphore ne permettra de lui expliquer de manière suffisament pertinente les choses).
En revanche, le système des fiches de tâches, du développement en binome (bien en théorie, ridicule en pratique), l'absence de design général de l'application (XP déconseille l'utilisation d'interfaces - au sens java du terme, au profit du refactoring permanent, ce qui rejoint aussi le fait que l'optimisation ne doit s'effectuer qu'à la fin), appropriation collective du code (souvent au détriment de sa documentation, et même lorsqu'un projet fait plusieurs dizaines de milliers de lignes de code), et la gestion de la relation avec le client (présence permanente, tests, planning game). Tout ça c'est absolument n'importe quoi, et encore, j'oublie des trucs.
Bref, en général, XP c'est une méthode qui est poussée par des gens qui n'y comprennent rien au développement logiciel, et qui ont trouvé une bonne occasion de glander un peu plus (ben oui, parce que du coup le boulot des chefs et directeurs de projet est très sensiblement allégé, puisque la majeure partie des taches qui leur incombent est effectué par les développeurs directement, avec la qualité qu'on imagine).
Reste que, dans certains cas particuliers (développeur indépendant, etc.), ça peut présenter certains intérêts.
Dernière remarque: sur le codage proprement dit (pas la gestion de la relation avec le client, qui est pourtant une des parties les plus importantes d'un projet logiciel), XP propose finalement quelque chose qui se rapproche (pas complètement toutefois) de la méthode de développement "bazar" utilisé par la plupart des LL. Comme quoi, tout n'est pas forcément à jeter dans XP, mais je vous incite à la plus grande prudence !
pour résumer: Extreme Programming, c'est un chateau de cartes constitué par toutes les mauvaises pratiques du développement logiciel, et qui tient debout parce qu'on les as agencées de telle manière que chaque mauvaise pratique en contre une autre. mais comme personne n'arrive jamais à suivre la totalité de ces mauvaises pratiques, le projet foire immanquablement (du moins la raison avancée au foirage du projet par les experts d'extreme programming est qu'un certain nombre de préceptes n'y ont pas été scrupuleusement suivis), ce qui n'est pas si grave vu que, selon les promoteurs d'extreme programming, la seule issue possible à un projet logiciel est l'annulation.
bref, du n'importe quoi absolu, et, pour avoir déjà vu un certain nombre de projets se casser la gueule à cause de cette soit-disant méthode miracle, je dirais qu'il y a plus qu'un fond de vérité... mais c'est pas si grave, du coup ça nous donne du boulot, quand il s'agit de reprendre les débris et d'en faire quelque chose.
en fait, la plupart des partis ont voté pour un texte fortement amendé, vidé de sa substance néfaste. et ceux qui ont voté contre ce texte l'ont pour la plupart fait parce qu'ils trouvaient que le texte n'était pas encore assez amendé.
donc, tu peux voter pour qui tu veux (ou à peu près, il me semble qu'un des partis a soutenu le projet de base, mais je sais meme plus lequel, et en tous cas le PSE et le PPE ont voté majoritairement pour) !
par contre, le problème que nous avons est très grave: des bureaucrates contournent la volonté du peuple souverain exprimé par ses représentants. et ça, le vote de juin prochain n'y changera rien, hélas.
4eme république (celle qui a reconstruit en 5 ans le pays ravagé, en unissant les Gaullistes et les communistes)
unir les gaulliste et les communistes ? ah tiens, je croyais que c'était surtout le MRP, la SFIO et autres radicaux, qui avaient gouverné le pays d'alliances improbables en alliances improbables.
redressé le pays ? ah tiens, je croyais que c'était (aussi) le plan Marshall (eh oui, un truc qu'on oublie...)
1er septennat de Mitterrand: La proportionelle est introduite
sauf erreur de ma part, il s'agissait de proportionnelle corrigée, avec un seuil à 5% si je me souviens bien, et par conséquent pas de proportionnelle pure. c'est aussi le seul scrutin qui a vu l'élection du FN à l'assemblée (pas assez de députés pour former un groupe, cependant)
je ne prends pas parti, j'ai juste ouvert un bouquin d'histoire de temps à autre quand j'étais plus jeune ;-))
Une simple recherche google montre que Pierre Tramo est un gros trolleur apparu sur HFR, puis ensuite sur DLFP (ou l'inverse). Le pseudo (qui est tout simplement un anagramme d'"ami reporter") a ensuite été repris par plusieurs personnes ici.
C'est le pote méconnu de Pierre Tramo, son bras droit, un peu comme Alan et Linus. D'ailleurs, c'est pas normal qu'on ne parle pas de lui sur la page que tu pointes.
La seule clause légale, c'est la signature manuscrite avec la mention "lu et approuvé" tout autant écrite à la main.
C'est faux. La signature électronique a valeur en France depuis deux ans déjà.
Après, cliquer sur un bouton "ok", ça ne constitue pas du tout une signature électronique, de quelque forme que ce soit (la loi distingue plusieurs formes de signatures électroniques).
Ensuite, le respect de la licence est évidemment lié au respect du droit d'auteur, et au code de la propriété intellectuelle (cf. l'article L.122-4 notamment), et la sanction n'est pas une sanction de violation de contrat, mais une sanction de contrefaçon (article 335-2 et suivants) : en droit français, la licence est vue comme la liste des conditions auxquelles un auteur subordonne l'utilisation de son oeuvre (donc son consentement à cette utilisation). On doit donc se borner à pouvoir prouver que l'utilisateur a bien eu connaissance de ces conditions, ou a eu le moyen d'en prendre connaissance (le "ou" n'étant pas innocent, mais la jurisprudence semble plutot confirmer la deuxième interprétation).
D'ailleurs, vivement la traduction de la GPL en français (traduction juridique, pas linguistique), car, meme si ce n'est pas l'usage pour les licences de logiciel notamment, son utilisation telle quelle pourrait etre remise en question (au motif que l'utilisateur peut ne pas comprendre la liste de conditions auxquelles il doit se plier). Mais il me semble que la FSF-France y travaille.
le SPF n'est pas spécifiquement dirigé contre le spam, mais contre le spoofing d'adresse, c'est à dire contre la possibilité qui existe à l'heure actuelle d'usurper une adresse "From". il va de soi que ceci a une incidence sur le spam, les spammeurs étant friands de cette technique.
cependant, en aucun cas ceci n'est suffisant pour lutter contre le spam. en effet, tant que les spammeurs pourront aller s'installer dans des pays sans législation restrictive, et y acheter des domaines, ils pourront envoyer du spam, et cela ne sera pas beaucoup plus compliqué qu'aujourd'hui (on pourra toujours "griller" ces domaines dans les RBL, mais ça prendra toujours un certain temps). de meme, cela n'améliore pas beaucoup les choses dans le cas du spam envoyé depuis des ordinateurs vérolés par les virus appropriés. il suffira alors de forger une adresse correspondant à le FAI utilisé par l'ordinateur en question, et banco ! certes, c'est un peu plus compliqué, mais quand je vois l'ingéniosité déployée par les spammeurs pour passer les différents systèmes anti-spam, je me dis qu'ils trouveront de quoi contourner ces petits problèmes assez aisément...
bref, la seule amélioration que ça apporte, c'est la fin des messages d'erreur quand une adresse d'un domaine qu'on possède a été utilisée pour envoyer du spam (et encore, sous réserve qu'il n'y ait pas eu de machine compromise par un virus ou autre dans le domaine en question).
enfin, le "pop3 à l'envers" comme tu dis, existe depuis longtemps, et c'est bien ce qui est préconisé par les gens de SPF (SMTPS, SMTP+SASL), et il y a meme des versions pas basiques du tout (du genre DIGEST-MD5, CRAM-MD5, etc. pour l'authentification).
Non, c'est exactement l'inverse: il faudrait que tu rajoutes dans ton champ DNS TXT d'ufoot.org un "include: wanadoo.fr", pour que tu puisses poster avec ton adresse ufoot.org depuis wanadoo.
En fait, elle est là, la limite de SPF: si elle n'est pas adoptée par tout le monde, elle marche pas. En l'espèce, si wanadoo n'a pas renseigné son champ DNS SPF, ça sert à rien.
Dans l'immédiat, il y a un drapeau, ~all, qui permet de dire dans le champ DNS TXT SPF si on a décrit la totalité des IP pouvant poster depuis cette adresse. donc, si on ne met pas ce drapeau, on ne bloque rien, mais on permet à SpamAssassin de rajouter une règle avec un certain poids en cas de non-concordance entre le domaine de l'envoyeur, l'adresse IP de l'envoyeur et le DNS SPF.
Pour finir, reste encore à ce que les fournisseurs de domaines/DNS comme gandi et amen laissent la possibilité de renseigner un champ TXT, ce qui n'est pas gagné...
repositories (dépôts ?)
la traduction plus ou moins officielle pour repository est référentiel, ce qui "rend" très bien les caractéristiques de la chose, et notamment l'aspect "référence" que constitue cet élément du système de controle de versions (alors qu'un dépôt a l'inconvénient d'être dans son sens plus statique, moins "intelligent", notamment par rapport au mécanisme de mise à jour avec fusion effectué à partir de cet élément).
Pour commit, je proposerais du coup "envoyer", mais il est vrai que "valider" reste pas mal. Ceci dit, je ne suis pas sûr qu'il y ait tellement d'équivalents français pour le terme, et il serait peut etre sage à ce niveau de faire un enrichissement de la langue française, ce qui permettrait de discuter plus avant sur les bienfaits du commit de situation ou de répétition.
je me suis retrouvé l'autre jour dans le cas où, pour yum, il n'y avait pas de mise à jour à faire, alors que apt-get, lancé juste après, a mis à jour une dizaine de paquets (à juste titre, d'ailleurs).
la question est plutot: la plupart des distros utilisent soit APT, soit URPMI depuis des années, et meme avec RPM (Conectiva a pas commencé à porter APT pour RPM hier). Pourquoi les gens de RH sont allés choisir YUM, un outil relativement jeune (vieux de un an et demi, en gros, voir un an si on compte à partir des premières versions 1.0 - donc stables), pas forcément léger à utiliser (sa stratégie de fonctionnement, avec tous ces fichiers .hdr, bien différente des deux autres systèmes, a des avantages, mais surtout un paquet d'inconvénients), avec relativement peu d'utilisateurs ?
C'est sur que, pour RH, il y a plus d'espoir de controler l'évolution de YUM, utilisée juste pour la "petite" YellowDog, que les deux autres, utilisés par des poids lourds comme Mandrake ou Debian/Conectiva. Mais alors, qu'on ne mette pas un pseudo argument d'excellence technique en avant... Surtout quand on voit le temps qu'il a fallu à APT et URPMI pour arriver à des versions qui marchent vraiment bien !
Mais bon, RH, ça les a pas gêné de livrer des versions de RPM horriblement bugguées en RH8 et 9, alors, ils ne sont pas à ça près. Reste à voir ce que le poids de cette "communauté Fedora", qui peine à se construire (mais en meme temps, vu les délais...), apportera à tout ça.
Oui, c'est bien entendu de la taxe dont je voulais parler.
Ceci étant dit, taxe ou pas, le jour où l'upload devient payant (comme à la glorieuse époque de Noos), et si ça se généralise (dans le contexte actuel, je doute qu'un FAI isolé se lance tout seul dans l'affaire), je crois que je déciderais de me passer d'internet chez moi. D'ailleurs, avec n'importe quelle limite de trafic. Pour moi, le débit en soi, ça m'intéresse peu (enfin, dans certaines limites). Par contre, avoir une connexion permanente et illimitée, ça c'est une vrai service pour lequel je suis prêt à payer.
Comme je doute d'être le seul dans ce cas, j'ai dans l'idée que la mise en place de cette taxe freinera sérieusement l'adoption d'internet en France (a-t-on vraiment besoin de ça ?).
Il ne dit pas que le P2P n'est pas utilisé à des fins illégales, il dit que l'upload n'est pas forcément utilisé à des fins illégales, et il a diablement raison !
J'héberge un (petit) serveur web sur ma ligne ADSL (parfaitement légal), et je ne vois absolument pas pourquoi je paierais l'upload dû à ce serveur. De meme, je ne vois pas pourquoi je paierais l'upload utilisé pour lire MES mails depuis ce serveur, copier MES fichiers depuis ce serveur, etc.
C'est n'importe quoi cette histoire. C'est comme si on démontrait que la contrebande de cigarette arrive en majorité dans le sud-est de la France, et était consiommée en majorité en région parisienne, et qu'on mettait une surtaxe sur l'autoroute entre marseille et paris au bénéfice des fabricants de cigarettes lésés. Il y a pas, ils sont brillants les mineurs de paris.
Moui... personnellement, je trouve aussi et surtout que les choses ont changé.
Je travaille depuis des années sur un projet opensource, relativement modeste en taille et en fonctionnalités, et j'ai quand meme observé les choses suivantes:
1- une contribution à un projet, c'est pas forcément du code. J'ai reçu nombre de traductions, documentations, rapports de bugs, ... Et de plus, je considère que les gens qui "supportent" le logiciel à ma place (ie en aidant les autres utilisateurs à l'aide du forum), sont également des contributeurs du projet.
2- au sujet de la contribution au code proprement dit, j'ai observé une érosion. Il y a 3 ans, j'avais de temps à autre quelqu'un qui envoyait un patch ou une idée suffisament bien documentée pour que l'implémentation suive de suite. De nos jours, c'est plus rare.
3- à l'inverse, il m'est arrivé d'envoyer des patches pour plein d'autres projets, pas toujours suivis de retour par les responsables des projets (pourtant, les patches étaient corrects et fixaient des bugs bien réels).
4- je suis abonné (et parfois participant) à plusieurs ML de projets opensource, et je constate que les points 2 et 3 sont partagés par la plupart des projets de cet échantillon.
tout ça me semble donc refléter une genre de tendance "sociale" assez profonde dans le monde de l'opensource :
1- les nouveaux arrivés dans ce monde sont de plus en plus des utilisateurs simples ne cherchant pas à s'impliquer
2- les nouveaux arrivés viennent d'horizons bien différents et ne sont plus seulement des informaticiens
3- la multiplication du nombre de projets (y compris pour des logiciels à fonctionnalités équivalentes), a globalement nuit à l'efficacité du modèle en dispersant les développeurs sur plusieurs ressources, mais, en contrepartie, a augmenté les choix des utilisateurs (mais également diminué le nombre de retours utiles par projet)
après, reste encore des spécificités à examiner projet par projet. Typiquement, plus un projet a de doublons, moins le modele opensource fonctionne en moyenne pour chacun de ces projets...
j'ai préféré le modèle à 500MHz: moins cher et sans ventilateur. en y adjoignant un des nouveaux seagate (40Go: mono-plateau, mono-face, donc mono-tete), j'ai un truc hyper silencieux (j'ai meme pas eu à brancher les ventilos du boitier pour l'instant), qui ne chauffe pas, et qui ne consomme rien. Et pour ce qu'il fait (firewall/routeur/serveur mail-web-fichiers), c'est plus que suffisant.
Attention, 15 000 euros, c'est l'amende, ensuite, reste encore les éventuels dommages et intérêts.
Néanmoins, pour une atteinte à la liberté d'expression je trouve ça étonnamment faible, surtout qu'il s'agit d'une amende maximale (dans les textes de loi on note toujours les peines et amendes maximales, la peine réelle étant laissée à l'apprécisation du juge, en fonction des circonstances - et du brio des avocats).
Je m'étonne également de ne pas voir l'obligation de publication légale du jugement, aux frais de l'auteur de l'abus, évidemment. Vu le domaine concerné, je trouve que cela devrait être rajouté, ce serait bien la moindre des choses, et, en termes d'image, ça aurait déjà plus de consquences, et ce serait peut etre un peu plus apte à brider les ardeurs de certains (quand, au bout de la dixième récidive, ils se voient forcés de payer en spot tv pour dire que la liberté d'expression, ils s'assoient dessus, le tout à 20h30 sur TF1..)
Pour finir, le principe est de toutes façons pourri. Qui va aller trainer de telles grosses organisations avec leur armées d'avocats, pour un site web ? Cet article de loi ne sera appliqué au mieux qu'à la demande de quelques associations, et encore, au train ou vont les choses, il y aura bien d'autres moyens de les faire taire. :-(
# C'est le Conseil, et non la Commission
Posté par anonyme512 . En réponse à la dépêche Le Conseil européen valide les brevets logiciels. Évalué à 5.
Il faut corriger cette nouvelle, l'erreur étant d'importance !
Sinon, il faut également préciser que le revirement de l'Allemagne est vraisemblablement la cause de cette adoption.
Pour finir, je vous invite également à aller voir ce sujet connexe:
http://fr.news.yahoo.com/040518/7/3t2aj.html(...)
(ou comment la commission -enfin, Bolkestein- fait grand cas des données personnelles des européens...)
[^] # Re: Bis repetita
Posté par anonyme512 . En réponse à la dépêche Red Hat revient sur les postes clients. Évalué à 2.
financièrement c'est vrai, politiquement c'est loin d'être toujours vrai. et dans une grosse boite, c'est l'aspect politique qui prime tout le temps. reste à savoir le poids du coté financier dans la boite, par rapport aux autres dimensions de la vie politique interne à l'entreprise (relation de copinages, de renvois d'ascenceur, etc.).
à l'inverse, une structure de taille plus petite (en gros une PME d'une centaine de personnes), a souvent des décisions plus rationnelles, et sa capacité financière n'est pas forcément si ridicule que ça.
[^] # Re: La sortie de la prochaine Debian menacée ?
Posté par anonyme512 . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 5.
J'administre un certain nombre de serveurs (heu... trop en fait).
Il y a du Debian, du RedHat, et meme maintenant du WhiteBox (sur une seule machine pas très importante, pour tester).
Ce sont systématiquement des serveurs.
Eh bien il m'est aujourd'hui totalement impossible d'utiliser une Debian Woody sans modifications ou rétroportages, et ce pour plusieurs raisons:
1- support matériel très mauvais. Les serveurs DELL qui viennent de sortir de la gamme ne marchaient PAS sur une Debian Woody (alors ceux qui les ont remplacés, n'en parlons meme pas). En cause: version trop ancienne du noyau Linux (entre autres). Ca veut dire que le support matériel est en retard non pas sur la génération courante, comme c'est le cas sur toutes les distros (ou à peu près), mais de plus d'une génération. C'est énorme. Pour mémoire, la RHEL3 tourne sans problème sur ces matériels.
2- logiciels incroyablement mal empaquetés. Attention, les .deb en eux-meme sont plutot de bonne facture, mais manque de pot, pour beaucoup de paquets, il y a des manques grossièrs dans la configuration du logiciel, qui donnent à penser que le mainteneur n'a jamais tapé de sa vie ./configure --help . Je précise que ces problèmes sont presque tous corrigés en unstable. Pour ceux que ça intéresse, il y a par exemple Linux (support QoS entre autres), solid-pop3d (audit de sécurité-logs pas activé), pdnsd, ....
3- il est impossible aujourd'hui de réaliser un serveur mail sous Debian Woody pure (antivirus, antispam etc. à la ramasse), ainsi qu'un firewall un peu musclé (support QoS foireux, cf. point 2), un serveur web sur lequel on a besoin de apache2, un serveur de fichier avec du bon support des dernières "évolutions" de chez Redmond (et donc de samba3), l'authentification par LDAP sur un serveur avec un schéma un peu incomplet, et la liste continue. Point à incriminer ici: versions trop vieilles des logiciels.
4- encore plus grave, il n'y a pas de support de LVM ni du RAID (logiciel) au niveau de l'installation. Si on veut ces fonctionnalités là (extrêmement importantes pour un serveur de prod, dans une vraie boite), il faut galérer.
Alors ma question est: qu'est ce que vous faites tourner vous comme Debian Woody (pure, hein, sans rétroports, paquets testing, etc.) ? A part un serveur LAMP (et encore, sur du matériel pas trop trop récent), j'avoue que je vois pas.
Pour moi, la Debian Woody "pure" est une distribution avec un installeur dépassé, des logiciels dépassés et mal empaquetés et du support parfait pour du vieux matériel (voire très vieux).
Honnêtement, tout ce qui retardera la sortie de Sarge est préjudiciable à l'utilisation de Debian, ce qui est très dommage, car j'apprécie par ailleurs la simplicité de conception de cette distribution, et le fait qu'on controle vraiment tout bien.
Par ailleurs, j'utilise "massivement" les rétroports (de backports.org pour la plupart), et je n'ai jamais eu à m'en plaindre, alors que je n'en dirais pas autant de security.debian.org, qui, par exemple, il y a deux semaines, a réussi à sortir un .deb du noyau (pour x86 et une ou deux autres archi), sans les modules ! (avec juste le vmlinuz). Problème corrigé quelques heures après bien sur, mais on peut pas dire que le controle qualité soit là.
[^] # Re: Pourquoi le Libre va changer le monde
Posté par anonyme512 . En réponse à la dépêche Pourquoi le Libre va changer le monde. Évalué à 2.
Certains de ces documents sont publics, notamment ceux écrits dans le cadre de la mission interministérielle "compétitivité numérique des PME" (eh oui, ce sont d'abord les petits garagistes qui souffrent de cette propriétarisation des logiciels et des accès à l'information):
http://www.competitivite-numerique.com/compnum/succes/exemples_auto(...)
(le site est plutot pas terrible, et pas très explicite, mais bon...)
[^] # Re: Pourquoi le Libre va changer le monde
Posté par anonyme512 . En réponse à la dépêche Pourquoi le Libre va changer le monde. Évalué à 6.
non seulement l'injection, mais aussi le freinage (ABS, etc.), la gestion du faisceau électrique (multiplexage), et tous les rafinements technologiques d'une voiture moderne (controle de la clim, des essuie-glace, etc.).
ce n'est souvent meme plus de l'électronique, mais bien de l'informatique.
il y a deux ans, j'ai amené par extraordinaire ma vieille Mégane à réparer chez un concessionnaire Renault (au lieu du petit agent Renault à coté de chez moi). Il s'est aperçu que le firmware du logiciel d'injection n'était pas à jour, et il l'a flashé (seuls les concessionnaires peuvent faire cela, la "malette" d'accès à l'injection coutant dans les 10 000 euros, et étant assez souvent spécifique au moteur). Résultat: autonomie avec un réservoir passée de 450 à 650 km. Intéressant pour un simple changement de firmware... (pour etre parfaitement juste, il me semble que, grace à leur, malette ils avaient détecté un autre truc, mais il m'a été confirmé que des écarts importants de consommation peuvent etre constatés rien qu'en changeant le firmware de l'injection)
En fait, les constructeurs automobile ont très bien compris l'intérêt du logiciel propriétaire pour leur métier, et vont tous dans cette direction. L'objectif étant de forcer les utilisateurs à faire les réparations et l'entretien dans le réseau du constructeur au lieu de tous ces centres autos qui fleurissent (Midas, Feu Vert, ...). Ceci permettant évidemment de faire monter la note en maintenant le client captif.
Dès aujourd'hui, à cause de ces logiciels propriétaires, sur certaines marques, il est impossible de faire l'entretien courant des modèles récents dans ces centres autos. Et ça va encore empirer.
Dernier point, au sujet de la RTA. En effet, les données techniques mécaniques doivent etre publiques (et le sont). Mais les constructeurs ont trouvé là encore la parade. C'est qu'il faut encore pouvoir identifier précisément le véhicule après coup (pour savoir quel jeu de données techniques utiliser). Et évidemment, ils font tout pour noyer le poisson, réservant la seule vraie information d'identification (à partir du numéro de série référencé sur la carte grise) à leur réseau. Ce point est beaucoup plus subtil à appréhender, mais bien réel.
En bref, la comparaison avec l'automobile est de nos jours une mauvaise idée, parce que l'automobile rencontre exactement les memes problèmes liés aux logiciels et aux standards que le monde des logiciels ! D'ailleurs, ces problèmes sont généralisables à la totalité des produits modernes un tant soit peu sophisitqués, pour les memes raisons (pensez magnétoscopes "intelligents", téléphones portables, ...). A mon sens, c'est d'ailleurs encore plus grave que de ne pas pouvoir relire un document Word dans dix ans.
Pour finir, sachez que tous ces problèmes sont très bien connus, et que plusieurs personnes travaillent au niveau de la commission européenne et du gouvernement pour mettre sinon un terme, du moins un frein à ces dérives (dans le monde de l'automobile).
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par anonyme512 . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 1.
http://lists.debian.org/debian-security/2004/debian-security-200404(...)
http://lists.debian.org/debian-security/2004/debian-security-200404(...)
les paquets kernel-*-13.1 corrigeant le problème (je parle pour x86) ont été sortis quelques heures après (hier en soirée, les paquets défectueux étant sortis dans la matinée, ce me semble)
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par anonyme512 . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 2.
avec la Mandrake, tu étais au bord du précipice
avec la debian woody, tu fais un grand pas en avant ;-)
pour info, pas plus tard qu'hier, le debian security team a sorti un noyau ne contenant que le vmlinuz, pas les modules. résultat: machines HS après la MAJ. d'ailleurs, amha, la gestion des noyaux sur la Debian est incroyablement mal foutue (par rapport aux autres distros).
bon, je plaisante quand meme (pour le grand pas en avant), c'est pas si grave, d'abord pratiquement personne n'utilise une "vraie" woody (sans backports), ce serait tout bonnement inutilisable (ou alors pour faire juste un petit firewall à deux balles -plus compliqué ça marcherait pas, pour cause de support QoS foireux-), et de plus, comme tu es un utilisateur mainteannt aguerri de linux, tu aurais convenablement reconfiguré ton lilo avec des copies de noyau de secours, hein ? (faut pas attendre que la debian te le fasse pour toi).
après, ça fait déjà un bon moment que je me demande en quoi une distro peut etre soit-disant stable, à partir du moment où, pour l'utiliser il faut utiliser tous ces backports qui eux le sont moins, stables (meme si l'équipe de backports.org et des gens comme Aurélien Jarno font un travail fantastique, et que, dans la pratique, on est pas très loin du niveau de stabilité de la woody).
d'ailleurs, il y a une croyance comme quoi le problème de la Debian Woody, c'est d'avoir de vieux logiciels. ceci est en effet un problème pour quelques logiciels (clamav, spamassassin, gaim, WFree86, voire linux ...), mais le plus gros problème de la woody, c'est que beaucoup de logiciels et non des moindres (linux, solid-pop3d, pdnsd, bind, ...) sont MAL empaquetés ! Trop d'options de compilation n'ont pas été activées dans ces logiciels, pénalisant lourdement leur utilisation (QoS dans linux par ex., audit dans solid-pop3d, support tcp dans pdnsd, ...), ou alors la gestion de l'installation de ces paquets est fantaisiste (cf. linux), ou encore deux versions différentes se marchent plus ou moins sur les pieds.
la plupart des ces problèmes sont corrigés dans la sarge ou dans les backports.
ne vous méprenez pas, ceci n'est pas un plaidoyer anti-debian. mais ce serait juste sympa d'avoir un minimum d'honnêteté vis-à-vis des gens qui veulent aujourd'hui essayer de l'utiliser: il faut savoir à quoi s'attendre. dans la pratique, ceux qui essaient de mettre une woody pour un usage de bureau/jeux/développement finissent souvent avec une sarge, et les autres avec pleins de backports.
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par anonyme512 . En réponse à la dépêche Rencontre AFUP sur l'Extreme Programming. Évalué à 1.
Encore une fois, les tests ne sont pas le propre de XP. En méthode classique il devrait y avoir:
1- des tests unitaires avant tout commit CVS (pour vérifier que la fonctionnalité implémentée fonctionne), et si le code produit n'est pas immédiatement testable (ce qui est le cas quand on développe les couches les plus profondes du logiciel - métier, accès base de données par exemple), il faut le préciser dans le commit CVS et revenir dessus ultérieurement (lors de l'implémentation de la partie de la couche de présentation/interface correspondante)
2- une phase de tests et d'intégration lourde en fin de palier de développement (correspondant à un livrable)
la phase numéro 2, en particulier, doit comporter un mélange de tests automatisés (qualité de code, tests de charge, etc.) et de plan de tests pour un testage manuel.
et ce n'est pas que de la théorie, dans ma boite on a toujours travaillé comme ça (sauf l'aventure XP, sur laquelle ont avait pas la main, en fait), et ça marche.
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par anonyme512 . En réponse à la dépêche Rencontre AFUP sur l'Extreme Programming. Évalué à 1.
1- oui, j'ai déjà utilisé XP (sur un projet de taille moyenne), et j'ai également été témoin de l'utilisation d'XP sur un gros projet
2- un biologiste c'est un scientifique. maintenant, quand ton client c'est un commercial (par exemple), je te garantis que si il y a pas de phase de specifications, tu te plantes
3- pour les interfaces, je cite le bouquin (qui cite des posts usenet je crois)
4- pour le design général, on s'est jamais plantés. maintenant, on s'est en gros arrêtés au schéma de la base de données, et on a jamais eu à modifier le nombre de tables (rajouter des colonnes, en revanche, oui). encore une fois, je suis pas non plus un fan du "tout-UML" à l'extrême.
5- l'appropriation ne marche pas, en particulier lors d'un remplacement d'équipe entre deux versions (évidemment). ce qui est un truc courant sur des projets un peu gros.
En gros, fais attention, tu ne fais pas la meme informatique que la mienne (clients scientifiques et bas niveau, alors que moi c'est plutot clients "littéraires" et assez haut niveau, gestion de l'information). Je reviens donc sur ce que je disais: tout n'est pas à jeter dans XP, mais il y a clairement pas que du bon.
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par anonyme512 . En réponse à la dépêche Rencontre AFUP sur l'Extreme Programming. Évalué à 1.
Si tu me dis que parmi les points préconisés par XP il y a des trucs pas trop mauvais, voire bons, je suis d'accord (personnellement, je suis plus nuancé que le lien que je pointe).
Mais nul besoin de faire d'XP pour faire des tests. Ceci doit etre inclus dans un cycle de développement plus traditionnel.
De même, les releases courtes sur les fonctions clés, cela peut exister aussi sous une autre forme dans le développement "traditionnel", on appelle ça le maquettage, et c'est aussi préconisé sur les gros projets.
La transparence, c'est aussi conseillé en mode de développement traditionnel, mais il vaut mieux la faire en général sur les points que le client a une chance de comprendre, et il faut lui expliquer clairement, dans les termes de son métier, pas en utilisant de métaphores stupides (ou alors ce sont des points absolument pas métier, mais très techniques, et en ce cas, aucune métaphore ne permettra de lui expliquer de manière suffisament pertinente les choses).
En revanche, le système des fiches de tâches, du développement en binome (bien en théorie, ridicule en pratique), l'absence de design général de l'application (XP déconseille l'utilisation d'interfaces - au sens java du terme, au profit du refactoring permanent, ce qui rejoint aussi le fait que l'optimisation ne doit s'effectuer qu'à la fin), appropriation collective du code (souvent au détriment de sa documentation, et même lorsqu'un projet fait plusieurs dizaines de milliers de lignes de code), et la gestion de la relation avec le client (présence permanente, tests, planning game). Tout ça c'est absolument n'importe quoi, et encore, j'oublie des trucs.
Bref, en général, XP c'est une méthode qui est poussée par des gens qui n'y comprennent rien au développement logiciel, et qui ont trouvé une bonne occasion de glander un peu plus (ben oui, parce que du coup le boulot des chefs et directeurs de projet est très sensiblement allégé, puisque la majeure partie des taches qui leur incombent est effectué par les développeurs directement, avec la qualité qu'on imagine).
Reste que, dans certains cas particuliers (développeur indépendant, etc.), ça peut présenter certains intérêts.
Dernière remarque: sur le codage proprement dit (pas la gestion de la relation avec le client, qui est pourtant une des parties les plus importantes d'un projet logiciel), XP propose finalement quelque chose qui se rapproche (pas complètement toutefois) de la méthode de développement "bazar" utilisé par la plupart des LL. Comme quoi, tout n'est pas forcément à jeter dans XP, mais je vous incite à la plus grande prudence !
# Re: Rencontre AFUP sur l'Extreme Programming
Posté par anonyme512 . En réponse à la dépêche Rencontre AFUP sur l'Extreme Programming. Évalué à 7.
http://books.slashdot.org/article.pl?sid=04/03/24/2118215(...)
pour résumer: Extreme Programming, c'est un chateau de cartes constitué par toutes les mauvaises pratiques du développement logiciel, et qui tient debout parce qu'on les as agencées de telle manière que chaque mauvaise pratique en contre une autre. mais comme personne n'arrive jamais à suivre la totalité de ces mauvaises pratiques, le projet foire immanquablement (du moins la raison avancée au foirage du projet par les experts d'extreme programming est qu'un certain nombre de préceptes n'y ont pas été scrupuleusement suivis), ce qui n'est pas si grave vu que, selon les promoteurs d'extreme programming, la seule issue possible à un projet logiciel est l'annulation.
bref, du n'importe quoi absolu, et, pour avoir déjà vu un certain nombre de projets se casser la gueule à cause de cette soit-disant méthode miracle, je dirais qu'il y a plus qu'un fond de vérité... mais c'est pas si grave, du coup ça nous donne du boulot, quand il s'agit de reprendre les débris et d'en faire quelque chose.
[^] # Re: Conférences et manifestation contre la Tyrannie des brevets dans l'Union Européenne, le 14/04/2004 à Bruxelles
Posté par anonyme512 . En réponse à la dépêche Conférences et manifestation contre la Tyrannie des brevets dans l'Union Européenne, le 14 Avril 2004 à Bruxelles. Évalué à 1.
donc, tu peux voter pour qui tu veux (ou à peu près, il me semble qu'un des partis a soutenu le projet de base, mais je sais meme plus lequel, et en tous cas le PSE et le PPE ont voté majoritairement pour) !
par contre, le problème que nous avons est très grave: des bureaucrates contournent la volonté du peuple souverain exprimé par ses représentants. et ça, le vote de juin prochain n'y changera rien, hélas.
[^] # Re: EUCD, LEN, LIL : offensive annoncée après les régionales
Posté par anonyme512 . En réponse à la dépêche EUCD, LEN, LIL : offensive annoncée après les régionales. Évalué à 1.
unir les gaulliste et les communistes ? ah tiens, je croyais que c'était surtout le MRP, la SFIO et autres radicaux, qui avaient gouverné le pays d'alliances improbables en alliances improbables.
redressé le pays ? ah tiens, je croyais que c'était (aussi) le plan Marshall (eh oui, un truc qu'on oublie...)
1er septennat de Mitterrand: La proportionelle est introduite
sauf erreur de ma part, il s'agissait de proportionnelle corrigée, avec un seuil à 5% si je me souviens bien, et par conséquent pas de proportionnelle pure. c'est aussi le seul scrutin qui a vu l'élection du FN à l'assemblée (pas assez de députés pour former un groupe, cependant)
je ne prends pas parti, j'ai juste ouvert un bouquin d'histoire de temps à autre quand j'étais plus jeune ;-))
[^] # Re: Mon hacker préféré
Posté par anonyme512 . En réponse au sondage Mon hacker préféré. Évalué à 1.
Une simple recherche google montre que Pierre Tramo est un gros trolleur apparu sur HFR, puis ensuite sur DLFP (ou l'inverse). Le pseudo (qui est tout simplement un anagramme d'"ami reporter") a ensuite été repris par plusieurs personnes ici.
[^] # Re: Qui es-tu Pierre Tramo ?
Posté par anonyme512 . En réponse au sondage Mon hacker préféré. Évalué à 0.
C'est le pote méconnu de Pierre Tramo, son bras droit, un peu comme Alan et Linus. D'ailleurs, c'est pas normal qu'on ne parle pas de lui sur la page que tu pointes.
[^] # Re: Theo de Raadt décide le fork de Apache
Posté par anonyme512 . En réponse à la dépêche Theo de Raadt décide le fork de Apache. Évalué à 1.
La seule clause légale, c'est la signature manuscrite avec la mention "lu et approuvé" tout autant écrite à la main.
C'est faux. La signature électronique a valeur en France depuis deux ans déjà.
Après, cliquer sur un bouton "ok", ça ne constitue pas du tout une signature électronique, de quelque forme que ce soit (la loi distingue plusieurs formes de signatures électroniques).
Ensuite, le respect de la licence est évidemment lié au respect du droit d'auteur, et au code de la propriété intellectuelle (cf. l'article L.122-4 notamment), et la sanction n'est pas une sanction de violation de contrat, mais une sanction de contrefaçon (article 335-2 et suivants) : en droit français, la licence est vue comme la liste des conditions auxquelles un auteur subordonne l'utilisation de son oeuvre (donc son consentement à cette utilisation). On doit donc se borner à pouvoir prouver que l'utilisateur a bien eu connaissance de ces conditions, ou a eu le moyen d'en prendre connaissance (le "ou" n'étant pas innocent, mais la jurisprudence semble plutot confirmer la deuxième interprétation).
D'ailleurs, vivement la traduction de la GPL en français (traduction juridique, pas linguistique), car, meme si ce n'est pas l'usage pour les licences de logiciel notamment, son utilisation telle quelle pourrait etre remise en question (au motif que l'utilisateur peut ne pas comprendre la liste de conditions auxquelles il doit se plier). Mais il me semble que la FSF-France y travaille.
[^] # Re: Anti-spam : adoptons SPF maintenant !
Posté par anonyme512 . En réponse à la dépêche Anti-spam : adoptons SPF maintenant !. Évalué à 2.
cependant, en aucun cas ceci n'est suffisant pour lutter contre le spam. en effet, tant que les spammeurs pourront aller s'installer dans des pays sans législation restrictive, et y acheter des domaines, ils pourront envoyer du spam, et cela ne sera pas beaucoup plus compliqué qu'aujourd'hui (on pourra toujours "griller" ces domaines dans les RBL, mais ça prendra toujours un certain temps). de meme, cela n'améliore pas beaucoup les choses dans le cas du spam envoyé depuis des ordinateurs vérolés par les virus appropriés. il suffira alors de forger une adresse correspondant à le FAI utilisé par l'ordinateur en question, et banco ! certes, c'est un peu plus compliqué, mais quand je vois l'ingéniosité déployée par les spammeurs pour passer les différents systèmes anti-spam, je me dis qu'ils trouveront de quoi contourner ces petits problèmes assez aisément...
bref, la seule amélioration que ça apporte, c'est la fin des messages d'erreur quand une adresse d'un domaine qu'on possède a été utilisée pour envoyer du spam (et encore, sous réserve qu'il n'y ait pas eu de machine compromise par un virus ou autre dans le domaine en question).
enfin, le "pop3 à l'envers" comme tu dis, existe depuis longtemps, et c'est bien ce qui est préconisé par les gens de SPF (SMTPS, SMTP+SASL), et il y a meme des versions pas basiques du tout (du genre DIGEST-MD5, CRAM-MD5, etc. pour l'authentification).
[^] # Re: Anti-spam : adoptons SPF maintenant !
Posté par anonyme512 . En réponse à la dépêche Anti-spam : adoptons SPF maintenant !. Évalué à 5.
En fait, elle est là, la limite de SPF: si elle n'est pas adoptée par tout le monde, elle marche pas. En l'espèce, si wanadoo n'a pas renseigné son champ DNS SPF, ça sert à rien.
Dans l'immédiat, il y a un drapeau, ~all, qui permet de dire dans le champ DNS TXT SPF si on a décrit la totalité des IP pouvant poster depuis cette adresse. donc, si on ne met pas ce drapeau, on ne bloque rien, mais on permet à SpamAssassin de rajouter une règle avec un certain poids en cas de non-concordance entre le domaine de l'envoyeur, l'adresse IP de l'envoyeur et le DNS SPF.
Pour finir, reste encore à ce que les fournisseurs de domaines/DNS comme gandi et amen laissent la possibilité de renseigner un champ TXT, ce qui n'est pas gagné...
[^] # Re: Comparatif des systèmes de contrôle de version
Posté par anonyme512 . En réponse à la dépêche Comparatif des systèmes de contrôle de version. Évalué à 1.
la traduction plus ou moins officielle pour repository est référentiel, ce qui "rend" très bien les caractéristiques de la chose, et notamment l'aspect "référence" que constitue cet élément du système de controle de versions (alors qu'un dépôt a l'inconvénient d'être dans son sens plus statique, moins "intelligent", notamment par rapport au mécanisme de mise à jour avec fusion effectué à partir de cet élément).
Pour commit, je proposerais du coup "envoyer", mais il est vrai que "valider" reste pas mal. Ceci dit, je ne suis pas sûr qu'il y ait tellement d'équivalents français pour le terme, et il serait peut etre sage à ce niveau de faire un enrichissement de la langue française, ce qui permettrait de discuter plus avant sur les bienfaits du commit de situation ou de répétition.
[^] # Re: gueulante contre Fedora
Posté par anonyme512 . En réponse à la dépêche Dans la série "Une semaine avec...", aujourd'hui la SuSE 9.0. Évalué à 2.
je me suis retrouvé l'autre jour dans le cas où, pour yum, il n'y avait pas de mise à jour à faire, alors que apt-get, lancé juste après, a mis à jour une dizaine de paquets (à juste titre, d'ailleurs).
la question est plutot: la plupart des distros utilisent soit APT, soit URPMI depuis des années, et meme avec RPM (Conectiva a pas commencé à porter APT pour RPM hier). Pourquoi les gens de RH sont allés choisir YUM, un outil relativement jeune (vieux de un an et demi, en gros, voir un an si on compte à partir des premières versions 1.0 - donc stables), pas forcément léger à utiliser (sa stratégie de fonctionnement, avec tous ces fichiers .hdr, bien différente des deux autres systèmes, a des avantages, mais surtout un paquet d'inconvénients), avec relativement peu d'utilisateurs ?
C'est sur que, pour RH, il y a plus d'espoir de controler l'évolution de YUM, utilisée juste pour la "petite" YellowDog, que les deux autres, utilisés par des poids lourds comme Mandrake ou Debian/Conectiva. Mais alors, qu'on ne mette pas un pseudo argument d'excellence technique en avant... Surtout quand on voit le temps qu'il a fallu à APT et URPMI pour arriver à des versions qui marchent vraiment bien !
Mais bon, RH, ça les a pas gêné de livrer des versions de RPM horriblement bugguées en RH8 et 9, alors, ils ne sont pas à ça près. Reste à voir ce que le poids de cette "communauté Fedora", qui peine à se construire (mais en meme temps, vu les délais...), apportera à tout ça.
[^] # Re: La loi va-t-elle obliger les FAI à taxer l'upload ?
Posté par anonyme512 . En réponse à la dépêche La loi va-t-elle obliger les FAI à taxer l'upload ?. Évalué à 2.
Ceci étant dit, taxe ou pas, le jour où l'upload devient payant (comme à la glorieuse époque de Noos), et si ça se généralise (dans le contexte actuel, je doute qu'un FAI isolé se lance tout seul dans l'affaire), je crois que je déciderais de me passer d'internet chez moi. D'ailleurs, avec n'importe quelle limite de trafic. Pour moi, le débit en soi, ça m'intéresse peu (enfin, dans certaines limites). Par contre, avoir une connexion permanente et illimitée, ça c'est une vrai service pour lequel je suis prêt à payer.
Comme je doute d'être le seul dans ce cas, j'ai dans l'idée que la mise en place de cette taxe freinera sérieusement l'adoption d'internet en France (a-t-on vraiment besoin de ça ?).
[^] # Re: La loi va-t-elle obliger les FAI à taxer l'upload ?
Posté par anonyme512 . En réponse à la dépêche La loi va-t-elle obliger les FAI à taxer l'upload ?. Évalué à 2.
J'héberge un (petit) serveur web sur ma ligne ADSL (parfaitement légal), et je ne vois absolument pas pourquoi je paierais l'upload dû à ce serveur. De meme, je ne vois pas pourquoi je paierais l'upload utilisé pour lire MES mails depuis ce serveur, copier MES fichiers depuis ce serveur, etc.
C'est n'importe quoi cette histoire. C'est comme si on démontrait que la contrebande de cigarette arrive en majorité dans le sud-est de la France, et était consiommée en majorité en région parisienne, et qu'on mettait une surtaxe sur l'autoroute entre marseille et paris au bénéfice des fabricants de cigarettes lésés. Il y a pas, ils sont brillants les mineurs de paris.
[^] # Re: Un cri de désespoir du développeur dun projet Open Source.
Posté par anonyme512 . En réponse à la dépêche Un cri de désespoir du développeur d'un projet Open Source.. Évalué à 9.
Je travaille depuis des années sur un projet opensource, relativement modeste en taille et en fonctionnalités, et j'ai quand meme observé les choses suivantes:
1- une contribution à un projet, c'est pas forcément du code. J'ai reçu nombre de traductions, documentations, rapports de bugs, ... Et de plus, je considère que les gens qui "supportent" le logiciel à ma place (ie en aidant les autres utilisateurs à l'aide du forum), sont également des contributeurs du projet.
2- au sujet de la contribution au code proprement dit, j'ai observé une érosion. Il y a 3 ans, j'avais de temps à autre quelqu'un qui envoyait un patch ou une idée suffisament bien documentée pour que l'implémentation suive de suite. De nos jours, c'est plus rare.
3- à l'inverse, il m'est arrivé d'envoyer des patches pour plein d'autres projets, pas toujours suivis de retour par les responsables des projets (pourtant, les patches étaient corrects et fixaient des bugs bien réels).
4- je suis abonné (et parfois participant) à plusieurs ML de projets opensource, et je constate que les points 2 et 3 sont partagés par la plupart des projets de cet échantillon.
tout ça me semble donc refléter une genre de tendance "sociale" assez profonde dans le monde de l'opensource :
1- les nouveaux arrivés dans ce monde sont de plus en plus des utilisateurs simples ne cherchant pas à s'impliquer
2- les nouveaux arrivés viennent d'horizons bien différents et ne sont plus seulement des informaticiens
3- la multiplication du nombre de projets (y compris pour des logiciels à fonctionnalités équivalentes), a globalement nuit à l'efficacité du modèle en dispersant les développeurs sur plusieurs ressources, mais, en contrepartie, a augmenté les choix des utilisateurs (mais également diminué le nombre de retours utiles par projet)
après, reste encore des spécificités à examiner projet par projet. Typiquement, plus un projet a de doublons, moins le modele opensource fonctionne en moyenne pour chacun de ces projets...
[^] # Re: Les "small form factors"
Posté par anonyme512 . En réponse au sondage Les "small form factors". Évalué à 1.
[^] # Re: LEN : Grogne des fournisseurs d'accès à Internet
Posté par anonyme512 . En réponse à la dépêche LEN : Grogne des fournisseurs d'accès à Internet. Évalué à 2.
Néanmoins, pour une atteinte à la liberté d'expression je trouve ça étonnamment faible, surtout qu'il s'agit d'une amende maximale (dans les textes de loi on note toujours les peines et amendes maximales, la peine réelle étant laissée à l'apprécisation du juge, en fonction des circonstances - et du brio des avocats).
Je m'étonne également de ne pas voir l'obligation de publication légale du jugement, aux frais de l'auteur de l'abus, évidemment. Vu le domaine concerné, je trouve que cela devrait être rajouté, ce serait bien la moindre des choses, et, en termes d'image, ça aurait déjà plus de consquences, et ce serait peut etre un peu plus apte à brider les ardeurs de certains (quand, au bout de la dixième récidive, ils se voient forcés de payer en spot tv pour dire que la liberté d'expression, ils s'assoient dessus, le tout à 20h30 sur TF1..)
Pour finir, le principe est de toutes façons pourri. Qui va aller trainer de telles grosses organisations avec leur armées d'avocats, pour un site web ? Cet article de loi ne sera appliqué au mieux qu'à la demande de quelques associations, et encore, au train ou vont les choses, il y aura bien d'autres moyens de les faire taire. :-(