hmm, pour ceux qui ne connaissent pas Eugenia Loli-Queru, elle était utilisatrice de gnome, et editorialiste professionelle de gnome-files.org et osnews.org. Mais voir: http://www.osnews.com/story.php?news_id=9933 ...
Pour ce qui est de Linus, on a tous en mémoire sa récente intervention sur le thème "les devs gnome sont des nazis" non ? ;)
Oui tu a raison, ce n'est pas le même problème que pour FF, et je parlais de façon trop générale du "design by committee".
Ce qui est un peu spécifique dans le cas de gnome, et diffère par exemple d'Apache/FF/MySQ/Qt/x.org ..., c'est qu'il n'y a pas un petit groupe qui design & décide, mais plusieurs (et ça, oui, c'est casse gueule).
Je rejoint la remarque d'Alan Cox pour admettre que ça n'est pas une situation idéale (et qu'il vaut mieux au moins prévenir lorsqu'on s'aprete à travailler un aspect susceptible d'interesser d'autres gens).
Pour l'histoire de la débacle XFree865 -> x.org, je crois me souvenir que les critiques concernant l'aspect "fermé" du développement concernait surtout les comptes cvs en écriture (et le droit d'intégrer des modifications etc.), en nombre restreints et controlés par une minorité plus vraiment active dans le dev.
Moi non plus je ne suis pas un utilisateur gnome, et le desktop en 3d ne m'intéressent pas, mais j'ai souvent été frappé par l'incroyable toupet de nombreux utilisateurs de ce projet, qui lancent plus souvent qu'ailleur des débats publics contre les décisions des devs de façon très violente (cf. la fatiguante Eugenia Loli-Queru, ou plus récement John Williams, et même Linus Torvalds), plutot que de remercier les devs pour l'outils qu'ils utilisent -- ou au moins leur foutre la paix.
Dans l'échange que tu cite, il est question de conception et de prise de décision, je pense que "la communauté c'est gentil, mais ils préfèrent coder de manière "fermée"" est une (petite) exagération.
Ce qui est certain, c'est que sur le point de la "conception" (le design initial etc.) ils soulèvent un débat intéressant et qui mérite, au moins, d'être invoqué.
Très récement, le leader d'un autre très gros projet libre (Ben Goodger) faisait exactement la même remarque pour expliquer le succès de firefox.
cf. son excellent historique de FF http://weblogs.mozillazine.org/ben/archives/009698.html :
le succès de FF, selon lui, est surtout du au fait qu'il ai été (et soit toujours) conçu par un petit groupe qui tente de maintenir une cohérence et une vision d'ensemble du projet (bref, l'inverse de ce qui arrivait auparant, dit Goodger, lorsqu'on additionnait des "opinions" disparates pour aboutir sur des bloatwares mal fagotés).
Combien de gros projets, parmis ceux qui ont fait les beaux succès du logiciel libre, fonctionne sur un processus de décision collégial ?
Très peu. En tout cas pas Apache, pas Linux, pas Qt, pas Gtk, pas *BSD, pas MySQL, pas Firefox, pas Fedora, pas Mdv, pas Ubuntu etc. Il reste debian, mais l'efficacité / la productivité de leur (pourtant énorme) communauté n'est pas un modèle adéquat pour beaucoup de projets.
La plupart du temps, la méritocratie prévaut (ou en tout cas, les participants les plus impliqués, ceux qui écrivent le code décident).
Finallement nous sommes des hordes d'utilisateurs ou developpeurs du dimanche à réclamer telle ou telle fonctionalité, telle direction etc. Ça doit être un pression bien pénible pour ces developpeurs travaillant sur des gros projets.
Autant laisser le soin de concevoir et décider *à ceux qui écrivent le code* (et qui ne sont pas des esclaves au service de la "communauté" !).
> merci beaucoup, enfin quelqu'un qui s'interesse au contenu et pas au contenant
Bin ... c'est parce qu'on s'interesse au contenu que le contenant nous à dépité ! ;) En effet (en tout cas pour moi) le contenu n'était tout bonnement pas accessible (donc ç'aurait été très difficile de le juger) !
> sinon pour adobe, c'est juste que c'est un projet décole, et pour le site, le flash est ce qu'il y a de plus tape-a-l'oeil, donc ca plait,
Si ta document s'adresse à des admins unix (et à qui d'autres ?) tu te trompe très fortement. Cherche un peu sur internet les sites dédiés aux admins (et à commencer par la doc officiel de l'OS que tu utilise, par exemple): tu ne trouvera pas de doc tape à l'oeil (et encore moins en flash !). De même, si tes profs sont aussi des utilisateurs d'OpenBSD, je crois que tu regrettera qu'ils ne puissent pas accéder aux documents.
Ce qui "plait", comme tu dit, pour ce genres de papiers universitaires c'est plutot l'utilisation de latex ou docbook, pas l'utilisation du générateur html/pdf sous Ms Word ... Les admins unix sont généralement ... des unixiens ! (et idem pour le texte en noir sur fond noir, qui montre que ça n'a pas été testé sous unix+firefox, ou les erreurs "ipconfig" à la place de "ifconfig" dans les docs ...). Bref, en tant qu'admin unix professionel, je peut te dire que ça ne fait pas très sérieux, contrairement à ce que tu semble penser. Autre preuve: les réactions des gens intéréssés ici. Sinon, le minimum de bienseance consiste à mettre un lien vers le site "version html" sur la page d'acceuil, en dessous du flash.
Sinon, voici une petite série de corrections:
- Document "Howto détaillé d'installation de la solution" :
Lexique, Sasync: "lors d'un crash" -> "lors d'une indisponibilité", car Sasync & pfsync sont aussi très utiles lorsque l'on veut faire des interuptions volontaires (par exemple pour upgrader l'OS de sa passerelle, ce qui est très important pour maintenir un bon niveau de sécurité, on peut maintenant ne pas interompre le service).
Lexique, CARP: "balance de charge" (pas français) -> "répartition de charge" (nb: cette erreur est présente à d'autres endroits du document).
Lexique, Pf: Pf n'est pas un fichier de configuration !! cf. la page de man pf. pf est "le firewall d'OpenBSD dont le fichier de configuration est /etc/pf.conf".
Lexique, "Haute Disponibilité" est définis deux fois. Ensemble du document: s/Packet Filtering/Packet Filter/
Page 14, creation et paramétrage des interfaces: la méthode préconisée et maintenable sous OpenBSD est d'utiliser /etc/hostname.ifname (cf la page de man hostname.if), y compris pour les interfaces CARP et pfsync. C'est d'ailleur ainsi que le documentent les auteurs de pf et carp, sur http://www.countersiege.com/doc/pfsync-carp/ et dans la page de man de pfsync(4).
Par exemple dans ton cas, ca donnerai un fichier /etc/hostname.carp1 contenant quelque chose comme:
inet 10.0.0.10 netmask 0xffffff00 vhid 1 carpdev rl0 pass itivpn description iternal
etc. pour les autres interfaces (hostname.carp2, hostname.pfsync0, hostname.xl0, hostname.rl0, ...).
Page 15: s/ipconfig/ifconfig/ ; attention, cette erreur trahis un manque d'aisance en environement unix. Ipconfig est une commande windows...
Page 19-25: cf. ma remarque dans l'autre poste, concernant ipsec.conf
Page 26: la méthode recommandée (et moins bidouille) pour lancer isakmpd est de placer : isakmpd_flags=-v4 dans /etc/rc.conf.local (pas d'utiliser un shell script). La bonne préconisée (openbsdiste) de lancer d'initialiser les interfaces, (dont psync0 et carp*), c'est de créer des fichiers hostname.if (comme dit plus haut). Et la bonne façon de lancer pf, c'est de mettre pf=YES dans /etc/rc.conf.local (dans ce cas il sera automatiquement initialisé, pas la peine d'en remettre une couche dans rc.local).
Bref, l'ensemble des manips dans /etc/rc.local ne sont pas très openbsdistes, et on pourrait s'en passer.
Page 29: à quoi sert ce fichier /etc/pf.vpn.conf (il n'est jamais appellé depuis tes scripts) ? pourquoi ne pas placer toute ta conf dans /etc/pf.conf ? D'ailleur ton fichier pf.conf n'est pas indiqué dans le document (page 17: le fichier pf.conf n'est pas présent en fin de document). Au passage, on pourrai grandement simplifier ce ruleset, en factorisant les regles concernant GATEWAY* et NETWORK*.
Pages 32-42: cf. mon autre post sur ipsec.conf. La config de isakmpd prend plus d'un tiers de ta doc (p. 19-25 et 32-42) est n'est quasiment pas réutilisable (elle correspond à un besoin réseau très spécifique, le genre de choses qui change à chaque install). L'utilisation de ipsec.conf (et des clefs générées automatiquement) prendrait maximum une page dans ton document...
- Document pdf "Etude finale" :
Mêmes remarques concernant le glossaire.
Cf. la remarque dans l'autre post concernant la puissance.
page 14: 3.8 n'est plus une version "testing".
Juste un petit complément d'infos: depuis une ou deux versions d'OpenBSD, la nouvelle façon en vogue (en fait, encouragée par les mainteneurs) de construire un vpn simple comme le tien, c'est d'utiliser ipsecctl(8) et ipsec.conf(5) et de le laisser configurer/piloter isakmpd.
Au résultat, on obtient un fichier de conf /etc/ipsec.conf d'une dizaine de lignes au lieu d'un isakmpd.conf + keynote + ... de centaines de lignes.
On peut aussi laisser le système générer les clefs RSA au premier démarage (à la manière d'OpenSSH, il le fait automatiquement, tout seul, si aucune clef n'est trouvée).
Ça pourrait être doublement interessant dans le cas de ta démonstration, car tu pourrai ainsi gagner en clarté, en réduisant la configuration à l'essentiel de ton sujet (sasyncd, la redondance, la haute disponibilité, ...), tout en réduisant la partie "paramétrage et mise en place des tunnels ESP et serveurs de clefs IKE", (moins interessante à mon avis: on trouve des centaines de docs sur ça, et c'est une partie que chacun devra adapter à son environement réseau), à quelques lignes de configuration très claires et simples. Bref, aller à l'essentiel de ton sujet: la haute disponibilité.
Et faire confiance au mainteneur d'ipsecctl (qui est aussi le mainteneur d'isakmpd) pour faire un bon paramétrage automatique d'isakmpd n'est pas forcément une mauvaise chose.
Autre détail: mieux vaut utiliser "current" (la version HEAD du cvs d'OpenBSD, ou mieux, un snapshot) car des problèmes très importants ont étés corrigés dans sasyncd(8) depuis la release 3.8. Actuellement "current" est très proche du feature freeze, et au grand public pour tests est en cours depuis presque un mois, c'est donc stable.
Dernier point: la partie sur les spécifications matérielles sont assez vagues (tu parle d'une machine d'"au moins 1Ghz"). Tu ne dit pas non plus quel volume de traffic tu doit gérer, mais attention, IPsec est gourmand. Si tu doit travailler à la vitesse du fast ethernet (ou pire, du gigabit), ça va être très difficile avec un pentium 1Ghz ! la commande "openssl speed" te montrera la vitesse de (de)chiffrement atteignable, selon l'algo, sur ta machine.
> La documentation est ouverte à toute remarques ou critiques (constructives bien entendu :) )
[...]
> http://itinet.fr/vpnredondants/
Peut-être un lien pour les utilisateur ne disposant pas du lecteur flash ? parceque là, je crois qu'on va être nombreux à ne pas pouvoir lire ta page (par exemple: tout les utilisateurs d'OpenBSD ;) mais aussi les utilisateurs de linux sur !i386 etc.).
Fondamentalement, le manque de modularité et 'interopérabilité des composants des divers framework est ce dont se plaint GvR, et je trouve sa remarque très pertinente.
Il note que la plupart des composants ne sont pas (ou sont peut) interchangeables, à l'exceptions des seules parties reposant sur WSGI: pas d'API unifiée pour les framework d'auth, de templating, de persistance, de réécriture d'url etc. Par ailleur il note que les gros framework sont souvent documentés pour une utilisation "tout en un" (pas de tuto sur l'utilisation spécifique d'un composant précis).
La conséquence c'est qu'il faut choisir un environement complet ou rien, meme si, ce qui nous conviendrai le mieux serai par ex. une utilisation combinée du moteur de template de django, de l'ORM sqlobject, de l'interface avec le serveur web WSGI, Twisted pour les accès soap/rpc/webservices, Route pour la réécriture d'url, une combinaison ldap/coockie/sessions pour l'auth, mochikit pour ajax...
Ce manque de modularité / interopérabilité / documentation est d'autant plus dommage qu'aucun framework ne peut prétendre couvrir tout les besoins/priorités des developpeurs, et que tous sont pensés à partir d'idées/d'attentes pré-conçues. Cf. le commentaire de GvR sur RoR par ex., ou bien sur les moteurs de templates conçus pour génerer du xml/html mais pas du texte brut, sur les couches de persistances supposant un accès sql à l'exclusion d'une serialisation directement dans des fichiers (ou pire: qui imposent un schema préderminé de base, donc incomatible avec une base déjà existante) et surtout sur l'authentification/authorisation (à mon avis le pire problème, parce que la gestion des utilisateurs est vraiment une problèmatique au cas par cas selon l'entreprise, ldap, kerberos, sql, unix pwd, ... les possibilités sont nombreuses).
Je trouve d'autre part que ce débat à mis à jour une incroyable multiplicité de solutions (frameworks complets ou composants), entre lesquelles il devient très difficile de choisir (d'autant que le choix est généralement décisif, bloquant, et sans retour, vu le manque d'interopérabilité). Le fait que GvR pose sa question est la preuve qu'il y a un problème de lisibilité dans cet ensemble de framework (et le fouilli de réponse prouve combien il est difficile de s'y retrouver).
Il faudrait des mois pour évaluer ces différents framework (ou composants plus ou moins compatibles) web: turbogears, zope/plone, django, web.py, cheetah, myghty, stan, Kid, pylons, Paste, Nitro, cherrypy, rhubarbtart, route, karrigel, web.py, quixote, webware, skunkweb, subway, aquarium, webstack, nevow, ...
C'est énorme !
Pourquoi autant de developpeurs python écrivent (et publient !) leur propre framework web ? et, par contraste, pourquoi si peu de travail et documentation sur l'intéropérabilité / l'unification ?
GvR note aussi que l'utilisation des gros frameworks combinés est beaucoup plus longue et difficile qu'il n'y parrait (cf. son commentaire: RoR permet de coder vite .. uniquement si on maitrise déjà parfaitement ruby, le sql, le javascript, et tt les différents composants du framework, ou sa réponse a Lunh: tu t'en sort facilement avec django parceque tu es expert python, celementree etc.).
Est-ce qu'un bon jeux de petites libs, à l'API stable et bien documentée, sous tests unitaires indépendants, réutilisables, combinables entres elles à volontée et des tutos sur la façon de les combiner ne serait pas mieux que d'énormes usines à ga^W^W monuments comme zope ou django ? (c'est ce qu'on fait perl -avec cpan - et php avec pear, et non, pypy n'est pas du même ordre).
J'espère que GvR sera entendu lorsqu'il appelle à faire des PEP equivalents à WSGI sur les autres composants des frameworks web (l'auth, les templates etc).
Si si, avant d'adopter TCP/IP (dont la popularité était aussi aidée par la disponibilité d'une multitude d'OS le supportant grace aux premières implems BSD), MS misait sur sa propre tambouille maison (NetBEUI + NetBIOS).
Dans le même ordre d'idée, les devs d'OpenSSH affirment que la licence BSD a permi à ce logiciel d'être intégré dans tout les Unix (libres ou pas), et beaucoup de routeurs etc. à la place de telnet (pour des réseaux de meilleur qualité ;).
En un certain sens on pourrait aussi dire que la priorité des utilisateurs de la licence BSD est la compatibilité (par ex. du code sous licence BSD révisée sera compatible avec du code GPL ou LGPL, alors que la réciproque n'est pas vraie).
Il y a aussi la zlib, qu'on retrouve un peu partout (de IE à MS Office en passant par Messenger ou DirectX): http://www.zlib.net/apps.html
Je ne crois pas que beaucoup de devs de libs libres se soient amusés à vérifier, comme pour zlib, si MS et d'autres utilisaient leur code. Mais j'aurait tendance à croire que les devs de MS ne se gènent pas.
Oui, la lib est sans doute capable de lire les fichiers précédement produits ; mais mon "problème" était plutot inverse. C'est pour ça que je parlais de la rétrocompatibilité des fichiers (pas de la lib elle-même).
La mise à jour des lecteurs multimédias (et des libs dont ils dépendent) n'est pas toujours simple (parfois impossible !), en particulier dans le monde des lecteurs hardware (sans parler des distributions qui ne "releasent" pas souvent, comme la Debian stable): y a-t-il un risque accru de rencontrer des fichiers illisibles dans de tels environements ?
Nope, pas d'Enigmail, ni de support PGP, OpenPGP, PGP/MIME etc.
Mais attention, OpenPGP n'est pas le seul protocole qui definit les fonctionalités cryptographiques (signature, chiffrement, gestion des certificats ...) et leur utilisation pour le courrier électronique.
En l'occurence TB implémente S/MIME (on accède au paramétrage par le menu Edition/Paramètre des comptes/Sécurité).
Pour plus d'infos sur S/MIME, voir les RFC concernées (3850, 3851, 3852, 4134 et 4262 en particulier) et l'entrée wikipedia ( http://en.wikipedia.org/wiki/S/MIME ).
S/MIME et OpenPGP sont malheureusement « incompatibles » (on ne peut pas déchiffrer ou verifier une signature d'un proto à l'autre, comme expliqué ici: http://www.imc.org/smime-pgpmime.html ). Enigmail reste donc utile pour l'interopérabilité.
Toutes les annonces concernant la sortie de TB 1.5 restent vagues sur ce point (et rien dans la "TB FAQ", "Knowledge Base" ou dans "TB Help" sur le site web).
J'administre des serveurs SMTP/POP3/IMAP et je serait heureux d'aider les utilisateurs de TB à lutter contre le spam, mais avec si peut d'infos ça ne va pas être facile !
C'est très juste, l'enjeu de la diffusion de Thunderbird n'est pas le même que celui de la diffusion de Firefox.
Mais une plus grande popularité de Thunderbird presenterai de nombreux intérets, quoiqu'il en soit concernant le respect des standards.
- Une plus grande diversité des clients rendrait les malwares (virus, trojans, worms etc.) moins efficients. Ils se propageraient plus difficilement.
Celà ne concerne pas seulement les outlooko-windowsiens: un voisinage plus sûr est aussi bénéfique pour nous (penser aux effets de congestion réseau à l'apparition de certains worms, ou aux effets d'un keylogger sur sur un réseau d'entreprise....)
Je ne sait pas si TB est en soi plus sûr qu'Outlook (celà dit, le fait de demander confirmation lors de l'envoi d'un attachement rend ses faiblesses moins contagieuses) mais il s'agit ici de sécurité par la diversité.
La monoculture logicielle est toujours mauvaise pour la sécurité.
- TB offre une grande indépendance à l'environement logiciel sous jacent. Il est portable. Par conséquent, s'habituer à l'utilisation de TB (comme à l'utilisation d'OOo et de FF) constitue un pas vers l'independance de l'OS de Redmont (mais aussi de l'OS de Torvalds).
Là encore, ça ne concerne pas seulement l'utilisateur d'Outlook. Par exemple si de nombreux utilisateurs en entreprises (et les fonctionnaires) étaient utilisateurs d'OOo + FF + TB, les migrations vers des solutions moins chères et plus faciles à administrer, voir libres, seraient souvent possibles, au bénéfice des admins et des contribuables.
- Au delà du respect des standards, il y a celui de la netiquette. Je ne saurait dire à quel point TB est meilleur sur ce plan, mais Outlook encourage les utilisateurs à répondre au-dessus du texte cité, enlève l'espace dans "-- ", active la composition en html par défault etc.
- Au delà d'IMAP, SMTP et POP3, certains clients mails (dont Outlook et Notes) sont conçus pour pouvoir dialoguer avec des applis serveurs de type "groupwares" (comme MS Exchange), qui font beaucoup plus que la gestion du courriel, et rendent presque impossible l'utilisation d'un poste client sous Linux, *BSD ou Mac dans ce contexte.
- Le fait que nos correspondants puissent valider des signatures ou dechiffrer des messages soit un besoin important n'est plus à démontrer. Lire par exemple l'explication de Phil Zimmermann ici: http://www.animatedsoftware.com/hightech/philspgp.htm
TB permet d'utiliser les standards de la cryptographie dès l'installation (bon, pour être honnète, il y a encore du travail ... mais c'est mieux qu'Outlook).
- L'utilisation à grande echelle de filtres antispams rendra le spam moins interessant economiquement. Pour le bénéfice de tous.
Celà étant dit, TB n'est pas le seul client libre possédant tout ces atouts; mais c'est peut-être celui qui à le plus de chances de percer auprès du grand public (donc celui vers lequel devraient converger nos efforts de migration, je suppose).
Je recommanderai aussi l'utilisation de 4 disques plutôt qu'un seul, mais à une condition: que le boitier soit 2U ou plus.
4 disques stréssés dans un 1U, ça chauffe trop, et la durée de vie s'en resssent.
(et oui, si tu peut, 5 disques en raid5, c'est aussi un plus).
Évidement dual core plutôt qu'HT, quoique je donnerai prévalence au chipset de la CM pour choisir (selon qu'il est plus ou moins bien supporté -et plus ou moins robuste/éprouvé-, ça change beaucoup de choses);
Ta remarque me fait penser à (encore) une autre limite du comparatif.
La plupart des failles indiquées sur cette page sont des buffers overflows. Or on sait qu'ils sont quasiment inexploitables sur OpenBSD (W^X, propolice, stackghost, toussa).
Ce type de "failles" est aussi devenu très dur à exploiter sur certaines distribution de GNU/Linux (type trustix, debian hardened, ou gentoo dans certaines configurations...). D'autres protections, éventuellement actives par défault, peuvent aussi mitiger les risques (par ex. SELinux).
Ces problemes logiciels ont pourtant fait l'objet d'annonces et de corrections par les distributeur. À l'inverse les failles des produits MS sont généralement reconnues publiquement lorsque quelqu'un aprouvé leur criticité (d'ailleur il serait dur d'assertir qu'on a affaire à un buffer overflow dans une partie potentiellement sensible d'un programme lorsqu'on ne dispose pas du source pour le prouver).
Il y a donc un sérieux très différent dans la façon d'annoncer et corriger les erreurs: dans certains cas on considère des problèmes très hypothétiques comme des "failles de sécurité", dans l'autre on se montre beaucoup plus discret.
Celà doit bien affecter les statistiques.
Combien de failles prouvées par des exploits pour la plateforme windows ? pour une plateforme GNU/Linux "hardened" ? pour OpenBSD ?
Et bien sûr il faudrait une comparaison à fonctionalités equivalentes. Par exemple pour un serveur web + sql + dns + mail "typique".
Les annonces de sécurité Debian ou Mandriva concernent un système contenant plusieurs milliers de logiciels. Combien de logiciels on étés pris en compte pour la comptabilisation des failles Windows ?
Je suis très surpris de trouver de nombreux députés (même Bayrou) défendre le logiciel libre de façon très pertinente et renseignée.
En revanche la réponse du ministre de la culture, Donnedieu de Vabre est vraiment inadéquate, et tout semble montrer qu'il n'a pas assez étudié le dossier; il assimile le besoin des logiciels libres au droit de décompilation:
M. le Ministre - Ce texte ne modifie en rien le droit des logiciels. Il ne remet pas en cause certains droits importants pour le logiciel libre, comme l'exception de décompilation, qui permet de décoder un logiciel pour en comprendre le fonctionnement et recréer un autre logiciel interopérable, celui-ci pouvant ensuite être diffusé sous une licence libre. Des amendements permettront d'apporter les clarifications nécessaires ; je remercie ceux qui y ont contribué.
Cf. aussi le post sur le blog de Glazzman, qui a été invité, au titre de président de Mozilla Europe (et comme d'autres acteurs du logiciel libre: Mandriva, Sun, Nuxeo ...) à discuter des problèmes rencontrés avec cette loi au ministère de la culture avant le débat à l'assemblée:
Oui, OpenSSH pourra créer des tunnels en attachant des interfaces de type tun/tap à la volée (comme le fait, par exemple, OpenVPN).
La question que je me pose maintenant est de savoir s'il faudra impérativement disposer des droits root sur les deux machines (ssh en root, vers un compte root) pour pouvoir faire ça, ou si des "astuces" sont envisageable pour ne déleguer que les droits nécessaires à la création d'interfaces et la manipulation des tables de routage. Ou bien (idéalement) si ceci est géré directement par le daemon sshd, qui tourne en root (avec eventuellement une liste de d'utilisateurs autorisés dans le fichier de conf) plutôt que par un processus fils (qui tourne avec les droits de l'utilisateur qui est connecté).
Avez vous plus d'infos à ce sujet ?
Comme une bonne nouvelle n'arrive jamais seule, PearPC 0.4 est sorti, le 20 décembre aussi, soit plus d'un an après la version 0.3.1.
PearPC est un émulateur libre de machines Mac G3 et G4 (ppc) assez abouti (suffisament pour permettre l'installation et l'utilisation de Mac OS X, de Darwin ou de GNU/Linux ppc).
Au menu des principales nouveautés:
- Le support de l'architecture G4
- Support de l'utilisation du lecteur de cdrom de l'hote
- Nombreux correctifs
à priori le support de l'émulation Altivec n'est pas encore actif par défaut (à vérifier).
Oui c'est juste.
Je pensait 'playstation', et puis je sait pas ce qui m'a pris, j'ai parlé de xbox.
ça doit être le marketing, là encore (avant noël, c'est fatal) ;).
Ok, au temps pour moi.
Celà dit je maitient qu'il faut être prudent avec les annonces venant des employés d'entreprises privées (surtout des grosses boites comme Sun, IBM, Apple etc., qui savent ce qu'attend un geek Linuxien).
Maintenant, les chipset des PC sont ils tous identiques, libres, et documentés?
Pour l'essentiel, oui. (enfin par "identiques" bien sûr): "cablage" du proc à la mémoire, principaux buses, etc.
Celà dit les fabriquants de carte mères utilisent de plus en plus de composants opaques et non documentés (par ex. certains chipsets SATA), donc tout n'est pas rose non plus de ce coté :(
Son code peut donc être repris, utilisé, modifié et adapté et servir à des ports d'autres OS.
Malheureusement non, du fait d'incompatibilité des licences.
Par exemple le code CDDL ne peut être réutilisé dans une appli GPL, comme le kernel Linux.
Il est vrai que je suis souvent bon public et facile à enthousiasmer.
Bah, tu a bien fait de proposer une dépêche sur ce proc, car c'est un sujet interessant.
Seulement la campagne de com de Sun est tellement bien orchestrée (ça va même jusqu'à faire bloguer les employés de Sun) qu'on a du mal à ne pas relayer leur marketing, alors je profite de l'occasion pour demystifier un peu (et je ferai pareil à la prochaine occas, sur IBM et Apple ;).
Maintenant, mieux que la doc des chipsets, il y a un source
Excellent foutage de gueule, bravo !
La license qui vient avec permet aux developeurs d'OpenBSD - ou tout autre OS libre - de re-utiliser ce code, et meme de le modifier, afin de l'adapter a leur OS
Balivernes.
La licence restreint les droits par rapports à la licence BSD.
Et elle n'est pas compatible avec la GPL (donc pas réutilisable dans le kernel linux).
contrairement a Apple, Solaris est en open source
Non. OpenSolaris est open source. Comme l'OpenDarwin d'Aplle quoi.
Sinon (si l'on parle de Solaris): je veux que Gravier me maile les sources de leur driver Nvidia (entre autre), et m'autorise à redistribuer une version de leur implem java modifiée (puisque c'est aussi inclus dans Solaris) :P
CyrrusSmith, quand arretera tu de relayer la propagande marketing de ce M. Gilles Gravier ?! Ou au moins, essaie d'interoger *plusieures sources*, pas seulement les employés de Sun ... (tip: va poser ces questions sur les mailing-lists d'OpenBSD ...).
Pour la réutilisation du code source : TdR et les autres developpeurs d'OpenBSD (mais j'imagine que c'est aussi le cas sur les autres BSD) ont très clairement indiqué qu'ils considéraient la CDDL comme « encore moins libre que la GPL » (il faut comprendre ça du point de vue de leur license de choix : la BSD à deux clause et/ou la MIT/X11).
Recherche sur la mailing-list tech@openbsd.org la réponse des devs à Jörg Schilling, qui voulait que son implem de tar (star) soit intégrée dans le système de base (pas seulement les ports) d'OpenBSD. Donc pour le kernel, où ils sont encore plus pointillieux, ce n'est meme pas la peine d'y penser.
Là aussi, Sun a fait une grosse intox sur l' « extraordinaire permissivité » de leur licence CDDL, et de nombreux developpeurs se sont laissées intoxiquer, et croient que leurs developpement seront acceuillis à bras ouverts par les devs BSD (comme semble le croire Gilles Gravier, que tu cite, ou Schilling dans mon exemple).
En pratique, leur code ne sera pas compatible BSD ni GPL.
Concernant la disponibilité des sources d'OpenSolaris en lieu et place des docs, j'éspère que c'est une blague !
L'implem d'un driver est très souvent remplie de tableaux de "valeurs magiques", d'astuces parfois indiscernables (si on n'est pas avertis) pour contourner les bugs du matériel / des firmwares, necessite de connaire l'API du noyau pour être bien lue etc.
Sun fait beaucoup de marketing autour de leur attachement à l'Open Source
((sic), ils parlent plus rarement de "libre"). Certes, ils sont à l'origine
de nombreuses merveilles (Mozilla, OOo), mais il faut savoir prendre toute campagne de marketing (surtout si elle est ciblée à notre attention, vers
les utilisateurs de logiciels libres) avec des pincettes.
Le résultat est visible ici: les sites d'informations relayent sans analyser
suffisament.
Pour ce qui est de l'implementation de clones de machines Sun (comme il y
a des "clones ibm/x86/pc"): la disponibilité des spécifications du processeur
n'est qu'une goutte d'eau.
Des machines ayant des types de processeurs identiques ne sont pas forcément
des "clones" (c'est à dire compatibles): un powerbook est très différent
d'une Xbox (pourtant POWER aussi), le port de Linux sur Zaurus (arm)
ne le rend pas pour autant compatible avec les autres modèles de PDA
ou les téléphones modernes (arm aussi, en général).
Bref, je conteste la remarque de la dépêche « les ordinateurs "compatibles
SPARC" pourraient connaître un succès comparable aux x86. » qui semble
encourager l'amalgame, au profit évident des responsables marketing de Sun.
Dans la dépêche, il y a un pernicieux glissement, passé inaperçu, entre
"processeurs compatibles SPARC" et "ordinateurs compatibles SPARC".
Sans l'ouverture (patent free) de l'ensemble du chipset (comment le proc est
cablé, les divers bus sur la CM etc.) on n'obtiendra pas de "clones sun". Sans
la disponibilité des specifications du chipset, on n'obtiendra pas de port de
Linux (et des autres OS libres) de qualité (ou bien ce sera très long).
Concernant le droit de réimplementer le processeur, il faudrait aussi parler
des brevets. Il ne suffit pas que les shemas verilog du design soient
"libres", il faut que Sun garantisse ne pas faire valoir ses brevets sur le
Niagara contre les concurents. J'ai eu beau chercher, je n'ai trouvé aucun
engagement de la sorte. Pour une fois, Sun est vraiment discret ...
Je conteste aussi la dernière phrase de la dépêche, « Les spécifications
pour le port de systèmes libres comme GNU/Linux ou NetBSd sur Machines SUN
sont naturellement disponibles. ». Précisément, aucun *BSD n'a été porté
sur UltraSparc III, parceque Sun a toujours refusé d'en donner les specs.
Autres notes, en vrac:
- "Après avoir libéré Solaris" : après avoir libéré _une partie_ de Solaris.
- "OpenSPARC, c'est à dire la mise en open-source du c½ur de leur
plateforme hardware" : libéré les shémas électroniques du processeur.
- "Les cartes graphiques spécifiques SUN sont particulièrement
remarquables.": franchement, c'est hallucinant ça ! Il parle des abominables,
ancestrales, "Elite 3D" / "Creator 3D" et consorts ou j'ai raté un wagon ?
- "d'autres machines SUN utilisent du nvidia" et ATI aussi
- "Étant données les performances de ce matériel" ... que personne, à part
les employés de Sun, n'a encore eu l'occasion d'essayer / benchmarker ...
Désolé, mais cette article est vraiment très peu tempéré, tout aux louanges
de Sun !
J'aimerai savoir chez qui travaille CyrrusSmith.
en lisant mon site prefere, je fut surpris de voir une absurdité de la part d'un homme qui se prend au serieux ;:
"Pour que les pilotes binaires fonctionnent bien, il faut une interface avec le noyau qui ne change pas. Cela est une aberration technique, car une interface gelée freinerait grandement le développement du noyau"
C'est bien Alan Cox ? En fait, c'est réellement un developpeur sérieux, et tu devrait réviser ton analyse ...
[^] # Re: Seulement la partie design + meme remarque de Ben Goodger (Firefox)
Posté par herodiade . En réponse au journal Quand l'union ne fait pas forcement la force.... Évalué à 1.
Pour ce qui est de Linus, on a tous en mémoire sa récente intervention sur le thème "les devs gnome sont des nazis" non ? ;)
[^] # Re: Seulement la partie design + meme remarque de Ben Goodger (Firefox)
Posté par herodiade . En réponse au journal Quand l'union ne fait pas forcement la force.... Évalué à 3.
Ce qui est un peu spécifique dans le cas de gnome, et diffère par exemple d'Apache/FF/MySQ/Qt/x.org ..., c'est qu'il n'y a pas un petit groupe qui design & décide, mais plusieurs (et ça, oui, c'est casse gueule).
Je rejoint la remarque d'Alan Cox pour admettre que ça n'est pas une situation idéale (et qu'il vaut mieux au moins prévenir lorsqu'on s'aprete à travailler un aspect susceptible d'interesser d'autres gens).
Pour l'histoire de la débacle XFree865 -> x.org, je crois me souvenir que les critiques concernant l'aspect "fermé" du développement concernait surtout les comptes cvs en écriture (et le droit d'intégrer des modifications etc.), en nombre restreints et controlés par une minorité plus vraiment active dans le dev.
Moi non plus je ne suis pas un utilisateur gnome, et le desktop en 3d ne m'intéressent pas, mais j'ai souvent été frappé par l'incroyable toupet de nombreux utilisateurs de ce projet, qui lancent plus souvent qu'ailleur des débats publics contre les décisions des devs de façon très violente (cf. la fatiguante Eugenia Loli-Queru, ou plus récement John Williams, et même Linus Torvalds), plutot que de remercier les devs pour l'outils qu'ils utilisent -- ou au moins leur foutre la paix.
# Seulement la partie design + meme remarque de Ben Goodger (Firefox)
Posté par herodiade . En réponse au journal Quand l'union ne fait pas forcement la force.... Évalué à 10.
Ce qui est certain, c'est que sur le point de la "conception" (le design initial etc.) ils soulèvent un débat intéressant et qui mérite, au moins, d'être invoqué.
Très récement, le leader d'un autre très gros projet libre (Ben Goodger) faisait exactement la même remarque pour expliquer le succès de firefox.
cf. son excellent historique de FF http://weblogs.mozillazine.org/ben/archives/009698.html :
le succès de FF, selon lui, est surtout du au fait qu'il ai été (et soit toujours) conçu par un petit groupe qui tente de maintenir une cohérence et une vision d'ensemble du projet (bref, l'inverse de ce qui arrivait auparant, dit Goodger, lorsqu'on additionnait des "opinions" disparates pour aboutir sur des bloatwares mal fagotés).
Combien de gros projets, parmis ceux qui ont fait les beaux succès du logiciel libre, fonctionne sur un processus de décision collégial ?
Très peu. En tout cas pas Apache, pas Linux, pas Qt, pas Gtk, pas *BSD, pas MySQL, pas Firefox, pas Fedora, pas Mdv, pas Ubuntu etc. Il reste debian, mais l'efficacité / la productivité de leur (pourtant énorme) communauté n'est pas un modèle adéquat pour beaucoup de projets.
La plupart du temps, la méritocratie prévaut (ou en tout cas, les participants les plus impliqués, ceux qui écrivent le code décident).
Finallement nous sommes des hordes d'utilisateurs ou developpeurs du dimanche à réclamer telle ou telle fonctionalité, telle direction etc. Ça doit être un pression bien pénible pour ces developpeurs travaillant sur des gros projets.
Autant laisser le soin de concevoir et décider *à ceux qui écrivent le code* (et qui ne sont pas des esclaves au service de la "communauté" !).
[^] # Re: Macromedia Flash obligatoire
Posté par herodiade . En réponse au journal Installation de VPN redondants sous OpenBSD 3.8. Évalué à 6.
Bin ... c'est parce qu'on s'interesse au contenu que le contenant nous à dépité ! ;) En effet (en tout cas pour moi) le contenu n'était tout bonnement pas accessible (donc ç'aurait été très difficile de le juger) !
> sinon pour adobe, c'est juste que c'est un projet décole, et pour le site, le flash est ce qu'il y a de plus tape-a-l'oeil, donc ca plait,
Si ta document s'adresse à des admins unix (et à qui d'autres ?) tu te trompe très fortement. Cherche un peu sur internet les sites dédiés aux admins (et à commencer par la doc officiel de l'OS que tu utilise, par exemple): tu ne trouvera pas de doc tape à l'oeil (et encore moins en flash !). De même, si tes profs sont aussi des utilisateurs d'OpenBSD, je crois que tu regrettera qu'ils ne puissent pas accéder aux documents.
Ce qui "plait", comme tu dit, pour ce genres de papiers universitaires c'est plutot l'utilisation de latex ou docbook, pas l'utilisation du générateur html/pdf sous Ms Word ... Les admins unix sont généralement ... des unixiens ! (et idem pour le texte en noir sur fond noir, qui montre que ça n'a pas été testé sous unix+firefox, ou les erreurs "ipconfig" à la place de "ifconfig" dans les docs ...). Bref, en tant qu'admin unix professionel, je peut te dire que ça ne fait pas très sérieux, contrairement à ce que tu semble penser. Autre preuve: les réactions des gens intéréssés ici. Sinon, le minimum de bienseance consiste à mettre un lien vers le site "version html" sur la page d'acceuil, en dessous du flash.
Sinon, voici une petite série de corrections:
- Document "Howto détaillé d'installation de la solution" :
Lexique, Sasync: "lors d'un crash" -> "lors d'une indisponibilité", car Sasync & pfsync sont aussi très utiles lorsque l'on veut faire des interuptions volontaires (par exemple pour upgrader l'OS de sa passerelle, ce qui est très important pour maintenir un bon niveau de sécurité, on peut maintenant ne pas interompre le service).
Lexique, CARP: "balance de charge" (pas français) -> "répartition de charge" (nb: cette erreur est présente à d'autres endroits du document).
Lexique, Pf: Pf n'est pas un fichier de configuration !! cf. la page de man pf. pf est "le firewall d'OpenBSD dont le fichier de configuration est /etc/pf.conf".
Lexique, "Haute Disponibilité" est définis deux fois. Ensemble du document: s/Packet Filtering/Packet Filter/
Page 14, creation et paramétrage des interfaces: la méthode préconisée et maintenable sous OpenBSD est d'utiliser /etc/hostname.ifname (cf la page de man hostname.if), y compris pour les interfaces CARP et pfsync. C'est d'ailleur ainsi que le documentent les auteurs de pf et carp, sur http://www.countersiege.com/doc/pfsync-carp/ et dans la page de man de pfsync(4).
Par exemple dans ton cas, ca donnerai un fichier /etc/hostname.carp1 contenant quelque chose comme:
inet 10.0.0.10 netmask 0xffffff00 vhid 1 carpdev rl0 pass itivpn description iternal
etc. pour les autres interfaces (hostname.carp2, hostname.pfsync0, hostname.xl0, hostname.rl0, ...).
Page 15: s/ipconfig/ifconfig/ ; attention, cette erreur trahis un manque d'aisance en environement unix. Ipconfig est une commande windows...
Page 19-25: cf. ma remarque dans l'autre poste, concernant ipsec.conf
Page 26: la méthode recommandée (et moins bidouille) pour lancer isakmpd est de placer : isakmpd_flags=-v4 dans /etc/rc.conf.local (pas d'utiliser un shell script). La bonne préconisée (openbsdiste) de lancer d'initialiser les interfaces, (dont psync0 et carp*), c'est de créer des fichiers hostname.if (comme dit plus haut). Et la bonne façon de lancer pf, c'est de mettre pf=YES dans /etc/rc.conf.local (dans ce cas il sera automatiquement initialisé, pas la peine d'en remettre une couche dans rc.local).
Bref, l'ensemble des manips dans /etc/rc.local ne sont pas très openbsdistes, et on pourrait s'en passer.
Page 29: à quoi sert ce fichier /etc/pf.vpn.conf (il n'est jamais appellé depuis tes scripts) ? pourquoi ne pas placer toute ta conf dans /etc/pf.conf ? D'ailleur ton fichier pf.conf n'est pas indiqué dans le document (page 17: le fichier pf.conf n'est pas présent en fin de document). Au passage, on pourrai grandement simplifier ce ruleset, en factorisant les regles concernant GATEWAY* et NETWORK*.
Pages 32-42: cf. mon autre post sur ipsec.conf. La config de isakmpd prend plus d'un tiers de ta doc (p. 19-25 et 32-42) est n'est quasiment pas réutilisable (elle correspond à un besoin réseau très spécifique, le genre de choses qui change à chaque install). L'utilisation de ipsec.conf (et des clefs générées automatiquement) prendrait maximum une page dans ton document...
- Document pdf "Etude finale" :
Mêmes remarques concernant le glossaire.
Cf. la remarque dans l'autre post concernant la puissance.
page 14: 3.8 n'est plus une version "testing".
# utilisation ipsecctl & ipsec.conf
Posté par herodiade . En réponse au journal Installation de VPN redondants sous OpenBSD 3.8. Évalué à 3.
Au résultat, on obtient un fichier de conf /etc/ipsec.conf d'une dizaine de lignes au lieu d'un isakmpd.conf + keynote + ... de centaines de lignes.
On peut aussi laisser le système générer les clefs RSA au premier démarage (à la manière d'OpenSSH, il le fait automatiquement, tout seul, si aucune clef n'est trouvée).
Ça pourrait être doublement interessant dans le cas de ta démonstration, car tu pourrai ainsi gagner en clarté, en réduisant la configuration à l'essentiel de ton sujet (sasyncd, la redondance, la haute disponibilité, ...), tout en réduisant la partie "paramétrage et mise en place des tunnels ESP et serveurs de clefs IKE", (moins interessante à mon avis: on trouve des centaines de docs sur ça, et c'est une partie que chacun devra adapter à son environement réseau), à quelques lignes de configuration très claires et simples. Bref, aller à l'essentiel de ton sujet: la haute disponibilité.
Et faire confiance au mainteneur d'ipsecctl (qui est aussi le mainteneur d'isakmpd) pour faire un bon paramétrage automatique d'isakmpd n'est pas forcément une mauvaise chose.
Autre détail: mieux vaut utiliser "current" (la version HEAD du cvs d'OpenBSD, ou mieux, un snapshot) car des problèmes très importants ont étés corrigés dans sasyncd(8) depuis la release 3.8. Actuellement "current" est très proche du feature freeze, et au grand public pour tests est en cours depuis presque un mois, c'est donc stable.
Dernier point: la partie sur les spécifications matérielles sont assez vagues (tu parle d'une machine d'"au moins 1Ghz"). Tu ne dit pas non plus quel volume de traffic tu doit gérer, mais attention, IPsec est gourmand. Si tu doit travailler à la vitesse du fast ethernet (ou pire, du gigabit), ça va être très difficile avec un pentium 1Ghz ! la commande "openssl speed" te montrera la vitesse de (de)chiffrement atteignable, selon l'algo, sur ta machine.
Le man ipsec.conf(5): http://www.openbsd.org/cgi-bin/man.cgi?query=ipsec.conf
Les snapshots de current: ftp://ftp.openbsd.org/pub/OpenBSD/snapshots
# Macromedia Flash obligatoire
Posté par herodiade . En réponse au journal Installation de VPN redondants sous OpenBSD 3.8. Évalué à 6.
[...]
> http://itinet.fr/vpnredondants/
Peut-être un lien pour les utilisateur ne disposant pas du lecteur flash ? parceque là, je crois qu'on va être nombreux à ne pas pouvoir lire ta page (par exemple: tout les utilisateurs d'OpenBSD ;) mais aussi les utilisateurs de linux sur !i386 etc.).
[^] # Re: à propos de Django,
Posté par herodiade . En réponse au journal Guido juge le monde web Python. Évalué à 6.
Il note que la plupart des composants ne sont pas (ou sont peut) interchangeables, à l'exceptions des seules parties reposant sur WSGI: pas d'API unifiée pour les framework d'auth, de templating, de persistance, de réécriture d'url etc. Par ailleur il note que les gros framework sont souvent documentés pour une utilisation "tout en un" (pas de tuto sur l'utilisation spécifique d'un composant précis).
La conséquence c'est qu'il faut choisir un environement complet ou rien, meme si, ce qui nous conviendrai le mieux serai par ex. une utilisation combinée du moteur de template de django, de l'ORM sqlobject, de l'interface avec le serveur web WSGI, Twisted pour les accès soap/rpc/webservices, Route pour la réécriture d'url, une combinaison ldap/coockie/sessions pour l'auth, mochikit pour ajax...
Ce manque de modularité / interopérabilité / documentation est d'autant plus dommage qu'aucun framework ne peut prétendre couvrir tout les besoins/priorités des developpeurs, et que tous sont pensés à partir d'idées/d'attentes pré-conçues. Cf. le commentaire de GvR sur RoR par ex., ou bien sur les moteurs de templates conçus pour génerer du xml/html mais pas du texte brut, sur les couches de persistances supposant un accès sql à l'exclusion d'une serialisation directement dans des fichiers (ou pire: qui imposent un schema préderminé de base, donc incomatible avec une base déjà existante) et surtout sur l'authentification/authorisation (à mon avis le pire problème, parce que la gestion des utilisateurs est vraiment une problèmatique au cas par cas selon l'entreprise, ldap, kerberos, sql, unix pwd, ... les possibilités sont nombreuses).
Je trouve d'autre part que ce débat à mis à jour une incroyable multiplicité de solutions (frameworks complets ou composants), entre lesquelles il devient très difficile de choisir (d'autant que le choix est généralement décisif, bloquant, et sans retour, vu le manque d'interopérabilité). Le fait que GvR pose sa question est la preuve qu'il y a un problème de lisibilité dans cet ensemble de framework (et le fouilli de réponse prouve combien il est difficile de s'y retrouver).
Il faudrait des mois pour évaluer ces différents framework (ou composants plus ou moins compatibles) web: turbogears, zope/plone, django, web.py, cheetah, myghty, stan, Kid, pylons, Paste, Nitro, cherrypy, rhubarbtart, route, karrigel, web.py, quixote, webware, skunkweb, subway, aquarium, webstack, nevow, ...
C'est énorme !
Pourquoi autant de developpeurs python écrivent (et publient !) leur propre framework web ? et, par contraste, pourquoi si peu de travail et documentation sur l'intéropérabilité / l'unification ?
GvR note aussi que l'utilisation des gros frameworks combinés est beaucoup plus longue et difficile qu'il n'y parrait (cf. son commentaire: RoR permet de coder vite .. uniquement si on maitrise déjà parfaitement ruby, le sql, le javascript, et tt les différents composants du framework, ou sa réponse a Lunh: tu t'en sort facilement avec django parceque tu es expert python, celementree etc.).
Est-ce qu'un bon jeux de petites libs, à l'API stable et bien documentée, sous tests unitaires indépendants, réutilisables, combinables entres elles à volontée et des tutos sur la façon de les combiner ne serait pas mieux que d'énormes usines à ga^W^W monuments comme zope ou django ? (c'est ce qu'on fait perl -avec cpan - et php avec pear, et non, pypy n'est pas du même ordre).
J'espère que GvR sera entendu lorsqu'il appelle à faire des PEP equivalents à WSGI sur les autres composants des frameworks web (l'auth, les templates etc).
[^] # Re: Tiens tant qu'à troller sur les licences
Posté par herodiade . En réponse à la dépêche Le noyau Linux ne se convertira pas à la GPLv3 !. Évalué à 3.
Dans le même ordre d'idée, les devs d'OpenSSH affirment que la licence BSD a permi à ce logiciel d'être intégré dans tout les Unix (libres ou pas), et beaucoup de routeurs etc. à la place de telnet (pour des réseaux de meilleur qualité ;).
En un certain sens on pourrait aussi dire que la priorité des utilisateurs de la licence BSD est la compatibilité (par ex. du code sous licence BSD révisée sera compatible avec du code GPL ou LGPL, alors que la réciproque n'est pas vraie).
[^] # Re: Refus de vente?
Posté par herodiade . En réponse à la dépêche Microsoft "vend" son code source. Évalué à 1.
http://www.zlib.net/apps.html
Je ne crois pas que beaucoup de devs de libs libres se soient amusés à vérifier, comme pour zlib, si MS et d'autres utilisaient leur code. Mais j'aurait tendance à croire que les devs de MS ne se gènent pas.
[^] # Re: Compatibilité arrière
Posté par herodiade . En réponse à la dépêche Le codec vidéo libre XviD 1.1.0 est disponible. Évalué à 2.
La mise à jour des lecteurs multimédias (et des libs dont ils dépendent) n'est pas toujours simple (parfois impossible !), en particulier dans le monde des lecteurs hardware (sans parler des distributions qui ne "releasent" pas souvent, comme la Debian stable): y a-t-il un risque accru de rencontrer des fichiers illisibles dans de tels environements ?
# Compatibilité arrière
Posté par herodiade . En réponse à la dépêche Le codec vidéo libre XviD 1.1.0 est disponible. Évalué à 1.
Un fichier vidéo produit avec XviD 1.1.0, sera-t-il toujours lisible par un lecteur utilisant la bibliothèque XviD 1.0 ?
[^] # Re: spreadthunderbird !
Posté par herodiade . En réponse à la dépêche Sortie de Thunderbird 1.5. Évalué à 2.
Mais attention, OpenPGP n'est pas le seul protocole qui definit les fonctionalités cryptographiques (signature, chiffrement, gestion des certificats ...) et leur utilisation pour le courrier électronique.
En l'occurence TB implémente S/MIME (on accède au paramétrage par le menu Edition/Paramètre des comptes/Sécurité).
Pour plus d'infos sur S/MIME, voir les RFC concernées (3850, 3851, 3852, 4134 et 4262 en particulier) et l'entrée wikipedia ( http://en.wikipedia.org/wiki/S/MIME ).
S/MIME et OpenPGP sont malheureusement « incompatibles » (on ne peut pas déchiffrer ou verifier une signature d'un proto à l'autre, comme expliqué ici: http://www.imc.org/smime-pgpmime.html ). Enigmail reste donc utile pour l'interopérabilité.
# interaction avec un filtre coté serveur
Posté par herodiade . En réponse à la dépêche Sortie de Thunderbird 1.5. Évalué à 2.
Toutes les annonces concernant la sortie de TB 1.5 restent vagues sur ce point (et rien dans la "TB FAQ", "Knowledge Base" ou dans "TB Help" sur le site web).
J'administre des serveurs SMTP/POP3/IMAP et je serait heureux d'aider les utilisateurs de TB à lutter contre le spam, mais avec si peut d'infos ça ne va pas être facile !
[^] # Re: spreadthunderbird !
Posté par herodiade . En réponse à la dépêche Sortie de Thunderbird 1.5. Évalué à 10.
Mais une plus grande popularité de Thunderbird presenterai de nombreux intérets, quoiqu'il en soit concernant le respect des standards.
- Une plus grande diversité des clients rendrait les malwares (virus, trojans, worms etc.) moins efficients. Ils se propageraient plus difficilement.
Celà ne concerne pas seulement les outlooko-windowsiens: un voisinage plus sûr est aussi bénéfique pour nous (penser aux effets de congestion réseau à l'apparition de certains worms, ou aux effets d'un keylogger sur sur un réseau d'entreprise....)
Je ne sait pas si TB est en soi plus sûr qu'Outlook (celà dit, le fait de demander confirmation lors de l'envoi d'un attachement rend ses faiblesses moins contagieuses) mais il s'agit ici de sécurité par la diversité.
La monoculture logicielle est toujours mauvaise pour la sécurité.
- TB offre une grande indépendance à l'environement logiciel sous jacent. Il est portable. Par conséquent, s'habituer à l'utilisation de TB (comme à l'utilisation d'OOo et de FF) constitue un pas vers l'independance de l'OS de Redmont (mais aussi de l'OS de Torvalds).
Là encore, ça ne concerne pas seulement l'utilisateur d'Outlook. Par exemple si de nombreux utilisateurs en entreprises (et les fonctionnaires) étaient utilisateurs d'OOo + FF + TB, les migrations vers des solutions moins chères et plus faciles à administrer, voir libres, seraient souvent possibles, au bénéfice des admins et des contribuables.
- Au delà du respect des standards, il y a celui de la netiquette. Je ne saurait dire à quel point TB est meilleur sur ce plan, mais Outlook encourage les utilisateurs à répondre au-dessus du texte cité, enlève l'espace dans "-- ", active la composition en html par défault etc.
- Au delà d'IMAP, SMTP et POP3, certains clients mails (dont Outlook et Notes) sont conçus pour pouvoir dialoguer avec des applis serveurs de type "groupwares" (comme MS Exchange), qui font beaucoup plus que la gestion du courriel, et rendent presque impossible l'utilisation d'un poste client sous Linux, *BSD ou Mac dans ce contexte.
- Le fait que nos correspondants puissent valider des signatures ou dechiffrer des messages soit un besoin important n'est plus à démontrer. Lire par exemple l'explication de Phil Zimmermann ici: http://www.animatedsoftware.com/hightech/philspgp.htm
TB permet d'utiliser les standards de la cryptographie dès l'installation (bon, pour être honnète, il y a encore du travail ... mais c'est mieux qu'Outlook).
- L'utilisation à grande echelle de filtres antispams rendra le spam moins interessant economiquement. Pour le bénéfice de tous.
Celà étant dit, TB n'est pas le seul client libre possédant tout ces atouts; mais c'est peut-être celui qui à le plus de chances de percer auprès du grand public (donc celui vers lequel devraient converger nos efforts de migration, je suppose).
[^] # Re: Serveur
Posté par herodiade . En réponse au journal P4 HT ou P4 D ?. Évalué à 2.
4 disques stréssés dans un 1U, ça chauffe trop, et la durée de vie s'en resssent.
(et oui, si tu peut, 5 disques en raid5, c'est aussi un plus).
Évidement dual core plutôt qu'HT, quoique je donnerai prévalence au chipset de la CM pour choisir (selon qu'il est plus ou moins bien supporté -et plus ou moins robuste/éprouvé-, ça change beaucoup de choses);
[^] # Re: Petites stats spécifiques à OpenBSD
Posté par herodiade . En réponse au journal Trois fois plus de vulnérabilités chez Linux que Windows. Évalué à 10.
La plupart des failles indiquées sur cette page sont des buffers overflows. Or on sait qu'ils sont quasiment inexploitables sur OpenBSD (W^X, propolice, stackghost, toussa).
Ce type de "failles" est aussi devenu très dur à exploiter sur certaines distribution de GNU/Linux (type trustix, debian hardened, ou gentoo dans certaines configurations...). D'autres protections, éventuellement actives par défault, peuvent aussi mitiger les risques (par ex. SELinux).
Ces problemes logiciels ont pourtant fait l'objet d'annonces et de corrections par les distributeur. À l'inverse les failles des produits MS sont généralement reconnues publiquement lorsque quelqu'un aprouvé leur criticité (d'ailleur il serait dur d'assertir qu'on a affaire à un buffer overflow dans une partie potentiellement sensible d'un programme lorsqu'on ne dispose pas du source pour le prouver).
Il y a donc un sérieux très différent dans la façon d'annoncer et corriger les erreurs: dans certains cas on considère des problèmes très hypothétiques comme des "failles de sécurité", dans l'autre on se montre beaucoup plus discret.
Celà doit bien affecter les statistiques.
Combien de failles prouvées par des exploits pour la plateforme windows ? pour une plateforme GNU/Linux "hardened" ? pour OpenBSD ?
Et bien sûr il faudrait une comparaison à fonctionalités equivalentes. Par exemple pour un serveur web + sql + dns + mail "typique".
Les annonces de sécurité Debian ou Mandriva concernent un système contenant plusieurs milliers de logiciels. Combien de logiciels on étés pris en compte pour la comptabilisation des failles Windows ?
# Seances de Jeudi, celles qui concernent le logiciel libre
Posté par herodiade . En réponse à la dépêche DADVSI - Les minutes du débat à l'Assemblée. Évalué à 3.
http://www.assemblee-nationale.fr/12/cra/2005-2006/111.asp#P(...)
http://www.assemblee-nationale.fr/12/cra/2005-2006/112.asp#P(...)
Je suis très surpris de trouver de nombreux députés (même Bayrou) défendre le logiciel libre de façon très pertinente et renseignée.
En revanche la réponse du ministre de la culture, Donnedieu de Vabre est vraiment inadéquate, et tout semble montrer qu'il n'a pas assez étudié le dossier; il assimile le besoin des logiciels libres au droit de décompilation:
Cf. aussi le post sur le blog de Glazzman, qui a été invité, au titre de président de Mozilla Europe (et comme d'autres acteurs du logiciel libre: Mandriva, Sun, Nuxeo ...) à discuter des problèmes rencontrés avec cette loi au ministère de la culture avant le débat à l'assemblée:
http://standblog.org/blog/2005/12/21/93114562-reunion-a-mati(...)
Bref, c'est vraiment dommage que ce ministre de la culture ai si peu préparé son dossier ...
[^] # Re: VPN
Posté par herodiade . En réponse à la dépêche Interview de Damien Miller, développeur principal d'OpenSSH. Évalué à 3.
La question que je me pose maintenant est de savoir s'il faudra impérativement disposer des droits root sur les deux machines (ssh en root, vers un compte root) pour pouvoir faire ça, ou si des "astuces" sont envisageable pour ne déleguer que les droits nécessaires à la création d'interfaces et la manipulation des tables de routage. Ou bien (idéalement) si ceci est géré directement par le daemon sshd, qui tourne en root (avec eventuellement une liste de d'utilisateurs autorisés dans le fichier de conf) plutôt que par un processus fils (qui tourne avec les droits de l'utilisateur qui est connecté).
Avez vous plus d'infos à ce sujet ?
# ... et PearPC 0.4 !
Posté par herodiade . En réponse à la dépêche Qemu 0.8.0 est sorti !. Évalué à 9.
PearPC est un émulateur libre de machines Mac G3 et G4 (ppc) assez abouti (suffisament pour permettre l'installation et l'utilisation de Mac OS X, de Darwin ou de GNU/Linux ppc).
Au menu des principales nouveautés:
- Le support de l'architecture G4
- Support de l'utilisation du lecteur de cdrom de l'hote
- Nombreux correctifs
à priori le support de l'émulation Altivec n'est pas encore actif par défaut (à vérifier).
Le site de PearPC: http://pearpc.sourceforge.net/
Le changelog: http://cvs.sf.net/viewcvs.py/pearpc/pearpc/ChangeLog?rev=1.8(...)
Bref, tout va pour le mieux dans le monde des émulateurs libres :)
[^] # Re: Ne pas se faire relai du marketing ciblé de Sun sans esprit critique
Posté par herodiade . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 3.
Je pensait 'playstation', et puis je sait pas ce qui m'a pris, j'ai parlé de xbox.
ça doit être le marketing, là encore (avant noël, c'est fatal) ;).
[^] # Re: Ne pas se faire relai du marketing ciblé de Sun sans esprit critique
Posté par herodiade . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 2.
Ok, au temps pour moi.
Celà dit je maitient qu'il faut être prudent avec les annonces venant des employés d'entreprises privées (surtout des grosses boites comme Sun, IBM, Apple etc., qui savent ce qu'attend un geek Linuxien).
Maintenant, les chipset des PC sont ils tous identiques, libres, et documentés?
Pour l'essentiel, oui. (enfin par "identiques" bien sûr): "cablage" du proc à la mémoire, principaux buses, etc.
Celà dit les fabriquants de carte mères utilisent de plus en plus de composants opaques et non documentés (par ex. certains chipsets SATA), donc tout n'est pas rose non plus de ce coté :(
Son code peut donc être repris, utilisé, modifié et adapté et servir à des ports d'autres OS.
Malheureusement non, du fait d'incompatibilité des licences.
Par exemple le code CDDL ne peut être réutilisé dans une appli GPL, comme le kernel Linux.
Il est vrai que je suis souvent bon public et facile à enthousiasmer.
Bah, tu a bien fait de proposer une dépêche sur ce proc, car c'est un sujet interessant.
Seulement la campagne de com de Sun est tellement bien orchestrée (ça va même jusqu'à faire bloguer les employés de Sun) qu'on a du mal à ne pas relayer leur marketing, alors je profite de l'occasion pour demystifier un peu (et je ferai pareil à la prochaine occas, sur IBM et Apple ;).
[^] # Re: L'avis d'OpenBSD
Posté par herodiade . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 6.
Excellent foutage de gueule, bravo !
Balivernes.
La licence restreint les droits par rapports à la licence BSD.
Et elle n'est pas compatible avec la GPL (donc pas réutilisable dans le kernel linux).
Non. OpenSolaris est open source. Comme l'OpenDarwin d'Aplle quoi.
Sinon (si l'on parle de Solaris): je veux que Gravier me maile les sources de leur driver Nvidia (entre autre), et m'autorise à redistribuer une version de leur implem java modifiée (puisque c'est aussi inclus dans Solaris) :P
CyrrusSmith, quand arretera tu de relayer la propagande marketing de ce M. Gilles Gravier ?! Ou au moins, essaie d'interoger *plusieures sources*, pas seulement les employés de Sun ... (tip: va poser ces questions sur les mailing-lists d'OpenBSD ...).
[^] # Re: L'avis d'OpenBSD
Posté par herodiade . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 7.
Recherche sur la mailing-list tech@openbsd.org la réponse des devs à Jörg Schilling, qui voulait que son implem de tar (star) soit intégrée dans le système de base (pas seulement les ports) d'OpenBSD. Donc pour le kernel, où ils sont encore plus pointillieux, ce n'est meme pas la peine d'y penser.
Là aussi, Sun a fait une grosse intox sur l' « extraordinaire permissivité » de leur licence CDDL, et de nombreux developpeurs se sont laissées intoxiquer, et croient que leurs developpement seront acceuillis à bras ouverts par les devs BSD (comme semble le croire Gilles Gravier, que tu cite, ou Schilling dans mon exemple).
En pratique, leur code ne sera pas compatible BSD ni GPL.
Concernant la disponibilité des sources d'OpenSolaris en lieu et place des docs, j'éspère que c'est une blague !
L'implem d'un driver est très souvent remplie de tableaux de "valeurs magiques", d'astuces parfois indiscernables (si on n'est pas avertis) pour contourner les bugs du matériel / des firmwares, necessite de connaire l'API du noyau pour être bien lue etc.
# Ne pas se faire relai du marketing ciblé de Sun sans esprit critique !
Posté par herodiade . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 6.
((sic), ils parlent plus rarement de "libre"). Certes, ils sont à l'origine
de nombreuses merveilles (Mozilla, OOo), mais il faut savoir prendre toute
campagne de marketing (surtout si elle est ciblée à notre attention, vers
les utilisateurs de logiciels libres) avec des pincettes.
Le résultat est visible ici: les sites d'informations relayent sans analyser
suffisament.
Pour ce qui est de l'implementation de clones de machines Sun (comme il y
a des "clones ibm/x86/pc"): la disponibilité des spécifications du processeur
n'est qu'une goutte d'eau.
Des machines ayant des types de processeurs identiques ne sont pas forcément
des "clones" (c'est à dire compatibles): un powerbook est très différent
d'une Xbox (pourtant POWER aussi), le port de Linux sur Zaurus (arm)
ne le rend pas pour autant compatible avec les autres modèles de PDA
ou les téléphones modernes (arm aussi, en général).
Bref, je conteste la remarque de la dépêche « les ordinateurs "compatibles
SPARC" pourraient connaître un succès comparable aux x86. » qui semble
encourager l'amalgame, au profit évident des responsables marketing de Sun.
Dans la dépêche, il y a un pernicieux glissement, passé inaperçu, entre
"processeurs compatibles SPARC" et "ordinateurs compatibles SPARC".
Sans l'ouverture (patent free) de l'ensemble du chipset (comment le proc est
cablé, les divers bus sur la CM etc.) on n'obtiendra pas de "clones sun". Sans
la disponibilité des specifications du chipset, on n'obtiendra pas de port de
Linux (et des autres OS libres) de qualité (ou bien ce sera très long).
Concernant le droit de réimplementer le processeur, il faudrait aussi parler
des brevets. Il ne suffit pas que les shemas verilog du design soient
"libres", il faut que Sun garantisse ne pas faire valoir ses brevets sur le
Niagara contre les concurents. J'ai eu beau chercher, je n'ai trouvé aucun
engagement de la sorte. Pour une fois, Sun est vraiment discret ...
Je conteste aussi la dernière phrase de la dépêche, « Les spécifications
pour le port de systèmes libres comme GNU/Linux ou NetBSd sur Machines SUN
sont naturellement disponibles. ». Précisément, aucun *BSD n'a été porté
sur UltraSparc III, parceque Sun a toujours refusé d'en donner les specs.
Autres notes, en vrac:
- "Après avoir libéré Solaris" : après avoir libéré _une partie_ de Solaris.
- "OpenSPARC, c'est à dire la mise en open-source du c½ur de leur
plateforme hardware" : libéré les shémas électroniques du processeur.
- "Les cartes graphiques spécifiques SUN sont particulièrement
remarquables.": franchement, c'est hallucinant ça ! Il parle des abominables,
ancestrales, "Elite 3D" / "Creator 3D" et consorts ou j'ai raté un wagon ?
- "d'autres machines SUN utilisent du nvidia" et ATI aussi
- "Étant données les performances de ce matériel" ... que personne, à part
les employés de Sun, n'a encore eu l'occasion d'essayer / benchmarker ...
Désolé, mais cette article est vraiment très peu tempéré, tout aux louanges
de Sun !
J'aimerai savoir chez qui travaille CyrrusSmith.
Pour la route: http://kerneltrap.org/node/568
# Alan Cox ?
Posté par herodiade . En réponse au journal Linux et les pilotes binaires.... Évalué à 4.
en lisant mon site prefere, je fut surpris de voir une absurdité de la part d'un homme qui se prend au serieux ;:
"Pour que les pilotes binaires fonctionnent bien, il faut une interface avec le noyau qui ne change pas. Cela est une aberration technique, car une interface gelée freinerait grandement le développement du noyau"
C'est bien Alan Cox ? En fait, c'est réellement un developpeur sérieux, et tu devrait réviser ton analyse ...