C'est exactement ça. Merci de les avoir retrouvé.
Et puisque ça parle de SMACK, les développeurs smack ne sont pas opposés à la suppression de LSM et sont prêt à intégrer les spécificités de smack dans selinux. Ceci sera d'autant plus facile que LSM sera viré et donc le code sera plus propre, lancer des grosses modifications plus facile, etc. Les développeurs selinux accueillont évidemment les développeurs smack avec grand plaisir. D'autant (j'espère que tu l'as remarqué) que smack est jugé positivement par les développeurs de SeLinux. Donc les développeurs ne disent pas qu'il n'y a qu'eux qui font des trucs bien. Ils sont ouverts. Mais ouvert à des solutions solides et pas des trucs bancales comme AppArmor.
> L'ennui évidemment c'est que son avis doit être interprété à la lumière de ce qu'il est : un des plus visibles développeur de SeLinux.
Certe. Mais la vision "les développeurs SeLinux sont des tirants qui ne pense qu'à SeLinux et rien d'autre" est ri-di-cu-le.
Le soucis de James Morris, et je le crois vraiment saincère, ce n'est pas SeLinux spécifiquement, c'est Linux. C'est de faire de Linux le meilleur OS pour la sécurité. Ses arguments sont pertinents. Qu'il soit un développeur SeLinux ou non.
> Les autres projets ont un avis différent et je ne vois pas en quoi on pourrait le rejeter sans examen.
Un avis différent sur quoi ?
Les autres projets doivent aussi penser qu'il ne faut qu'une infrastructure de sécurité et pas 50 (ni même 2).
Lorsqu'il y a eu "compétition" pour le multithread, il restait deux solutions techniquement très intéressants et très proches NGT(c'etait ce non ?) et NPTL. Mais toujours il a été été considéré (aussi bien par ceux qui développaient NGT que NPTL) qu'il ne fallait au final qu'une solution pour thread. Ceci pour le bien de Linux.
NPTL a "gagné", NGT n'en a pas fait un fromage.
Le problème avec LSM, est qu'il n'y a pas vraiment de compétition puisqu'il n'y a pas de gagnant. On garde LSM est espérant faire plaisir à tout le monde. On est dans du politique correct contre productif.
> Dire qu'il y a consensus en citant la NSA c'est un peu bizarre.
Mouaif. Dit aussi qu'il n'y a pas de consensus au niveau W3C alors ...
La NSA n'est pas une entreprise qui doit vendre son bébé. Son rôle est de chercher les meilleurs solutions. La NSA reste ouverte. L'implication de Red Hat dans SeLinux le montre. Red Hat (et la communauté Linux qui travaille sur SeLinux) a énormément influencé la NSA. IBM, HP, etc participent aussi aux réflexions et travaux de la NSA.
La NSA ou SeLinux travaille beaucoup plus dans le consensus et la recherche de l'excellence que AppArmor. AppArmor c'est à l'origine un solution d'une boite proprio. Puis ça été repris par Novell et tu connais la suite.
Donc sur ce point, SeLinux est largement devant AppArmor, Grsecurity, etc.
> Ce qu'il faut bien voir c'est que SeLinux, aussi puissant soit-il, n'est pas la panacée.
Rien n'est la panacée. Le scheduler de Linux n'était pas la panacé, etc, etc.
Ça n'a aucun sens de dire ça.
> qu'une solution complexe poussée par des grosses boites afin de se faire du fric en support.
Ben dit ça aussi de Linux.
Ce type d'argument c'est de la connerie.
Teo de Raadt peut te faire la même tirade sur Linux ou gcc. C'est du grand classique niveau FUD.
> Oh, that's right, SELinux conveniently leaves kernel exploits out of their "threat model," and no one questions it. By pure coincidence
Tu peux me mettre un exploit ?
Tu peux me mettre la réponse de SeLinux ?
> ignoring this fact allows them to continue to propagate the myth that SELinux's information flow graphs are proven,
RHEL 5 a été certifier AEL+ lspp (le plus haut niveau) : http://www.niap-ccevs.org/cc-scheme/st/?vid=10125
Et pour le "information flow graphs", voir la doc de RHEL 5.1 que j'ai donné dans ce journal.
Ton argumentaire ne tient pas. Il sous-entend que la NSA c'est des branleurs, Red Hat c'est des branleurs, etc, etc.
C'est un peu^Wtrès facile.
> contre la lenteur quand il faut mettre à jour tous les labels.
Et tu le fais quand ça ?
Pratiquement jamais.
Ça prend grosso modo autant de temps qu'un fsck.
La relabélisation totale je l'ai fait deux fois maxi (je me rappèle pas quand j'ai fait ça pour la derrière fois...). Des fsck beaucoup plus.
Enfin, tu peux mettre à jour qu'une partie des labels. Si t'as modifié que httpd, ben tu vas relabéliser que /var/www et peut-être /etc/httpd.
La sécurité c'est du sérieux. Tu ne t'amuses pas à bouleverser toutes tes règles de sécurité tous les matins.
Notes comme l'exemple de mon journal ne demande aucun relabélisation.
Enfin, tu dis plein de bien de smack, mais smack utilise aussi les labels. Donc le reproche tu peux aussi le faire à smack.
> Si une autre techno entrait en mainline qui soit plus simple que SeLinux on pourrait très bien assister a un ralliement de plusieurs distros.
Possible. Mais reste le problème d'avoir une solution que tu peux vendre au armée, aux adminstrations sensibles, etc...
Tu veux laisser ce marché aux autres ?
> Les fans de SeLinux en sont très conscient et ils veulent vite virer LSM pour que cela ne soit pas possible...
C'est une bête vision machiavélique.
> Je trouve qu'il est assez révélateur de voir que James Morris s'est opposé à l'entrée de SMACK
Il a donné ses raisons. Et il a dit :
I think the decision to merge Smack is something that needs to be
considered in the wider context of overall security architecture.
> "Smack itself looks fine. It seems like clean code with interesting ideas, and appears to be based upon sound principles."
Ce qui montre que James Morris est quelqu'un d'honnète. Quand il dit que AppArmor pue, ben il le pense. Il ne le dit pas pour sauver SeLinux.
Alan Cox a aussi une honnèté remarquable et il trouve que AppArmor pue.
> Si Morris reconnait que SMACK est une bonne solution technique et qu'il apporte (enfin!) une relative simplicité dans la mise en place d'une politique de sécurité alors pourquoi il s'oppose à son entrée ?
Il n'est pas opposé à smack comme il est opposé à AppArmor. Il est opposé à LSM. L'entrée de smack implique de garder LSM.
> Son projet de virer LSM pour ne laisser que SeLinux dans le noyau s'en trouverait anéanti.
Son projet n'est pas SeLinux. Son projet est de faire de Linux le top de la sécurité comme Linux est le top pour le réseau. Et on y est presque avec Selinux. C'est un fait. Actuellement ça passe par SeLinux et ce n'est pas l'objectif de smack. Smack le reconnait et smack est d'accord pour bosser avec SeLinux si LSM est viré.
Enfin pour la simplicité, je le répète pour la millième fois, tu peux faire simple avec SeLinux si ton modèle de sécurité est simple. Faire des trucs type AppArmor avec SeLinux est possible (mais en moins bancale).
Tu peux faire des trucs super compliqué avec Gtk et aussi des trucs super simples.
> On dirait vraiment un mec qui est arrivé le premier dans un bunker et qui essaye de claquer la porte derrière lui pour empêcher les autres d'entrer.
C'est ta "petite vision" des choses. Alan Cox ne veut pas de AppArmor et il veut qu'une infrastructure sécurité dans Linux.
Mais à chaque fois que quelqu'un ou un organisme est favorable à SeLinux, tu les accuses d'arrière pensé. Pourquoi tu ne fais pas de même avec AppArmor (qui maintenant est une petite boite qui cherche a faire du pognon comme tu le "dénoncait" pour SeLinux) ?
Le noeud du problème est là. Des gens (toi apparament) ne veulent pas de SeLinux. Pourquoi ? Ben grosso-modo comme à une époque la majorité des gens étaient systèmatique contre Red Hat et ne voyait dans les choix et actions de Red Hat que des basses manoeuvres.
Si SeLinux c'est si puant, alors pourquoi Red Hat fait un succès avec RHEL ?
Pourquoi CentOS est aussi un énorme succès ?
Pourquoi Fedora a une si grande communauté de contributeur ?
SeLinux c'est ce qu'il y a de mieux actuellement sous Linux. Il y a quelques soucis pour faire plus simples, etc. Les travaux sont en cours et ça progresse fort.
SeLinux ce n'est pas qu'une communauté de gens qui veulent faire du pognon ou surfer sur une mode. C'est aussi une énorme communauté de développeurs. Le travail réalisé le prouve largement.
> Je trouve donc que l'attitude de Linus est logique
L'attitude de Linus a effectivement une logique (j'ai donné mon avis plus haut). Et je n'ai jamais dit que Linus était un anti-SeLinux primaire.
Mais je pense que son attitude est mauvaise pour Linux.
Très bonne question. Réponse trop difficile. Joker.
> - un utilisateur de linux (desktop, chez lui ou au boulot, il connaît un peu les lignes de commande sans être un grand maître du script qui tue en 3min).
> A-t-il besoin de SeLinux sur sa machine (à part pour se la péter un peu)?
Ce type d'utilisateur ne va pas installer Bugzilla ou faire des règles SeLinux aux petits oignons pour un cgi d'apache qu'il développe.
> A-t-il besoin de SeLinux sur sa machine (à part pour se la péter un peu)?
SeLinux ça ne se vois pas. Pour se la péter, Compiz c'est mieux.
Sinon oui, c'est utile (NB: je ne dis pas indispensable). Par exemple sous F8, tous les programmes utilisateurs ne peuvent pas accéder librement à .gnupg ou a gpg-agent sans un contrôle. Si Firefox (ou bittorrent ou azureus ...) est cracké, tes clées gpg reste au chaud. Si Firefox fait n'importe quoi, une petite applet va tu prévenir. Tu peux aussi confiner Firefox.
Tu peux proposer deux Firefox (même binaire mais des règles SeLinux différentes d'appliqué). Un Firefox qui est peu confiné mais n'accèpte d'excécuter que les plugins signé par son distributeur. Un Firefox très confiné mais qui accèpte d'utiliser n'importe quel plugin.
> - un utilisateur de linux (desktop, chez lui ou au boulot, il connaît un peu les lignes de commande sans être un grand maître du script qui tue en 3min).
> A-t-il besoin de SeLinux sur sa machine (à part pour se la péter un peu)?
Ce type d'utilisateur sous Windows a besoin d'anti-virus. La réponse de Linux, ce n'est pas un anti-virus, c'est l'excellence dans le domaine de la sécurité.
> Ah bon c'est AppArmor qui "impose" LSM ? Et comment il fait pour l'imposer ? Il met un pistolet sur la tempe de Linus Torvalds ?
Évidemment que non. Mais s'il n'y avait pas AppArmor, il n'y aurait probablement pas aujourd'hui LSM. Linus envisageait de virer LSM vers 2005 si j'ai bonne mémoire.
M'enfin, constatons qu'il y a AppArmor et voilà. On ne va pas aligner les développeurs d'AppArmor face et un mur etc. Évidemment que non.
Autre problème avec AppArmor, et en fait plus avec ceux qui détestent SeLinux et supportent le "cette solution simpliste devrait suffire", c'est la confusion que ça a mis dans ce qui est perçu comme la communauté des experts sécurités de Linux. Un beau bordel avec des arguments à la con (même Linus qui ne veut pas se méler de questions de sécurité c'est énervé). Ce qui est perçu comme la communauté des spécialités sécurités Linux a maintenant plusieurs discours qui sont incompatibles. La crédibilité en prend un gros coup. Et ça c'est arrivé avec AppArmor. Tu peux dire que c'est un hazard, mais je n'y crois pas. Tu peux aussi dire qu'avant tout le monde n'était pas d'accord, mais à 90 % ils étaient d'accord sur les grands principes.
Maintenant il y a les pro label et ceux qui dise que ça sert rien, c'est compliqué et blabla. Les pro pathname et ceux qui disent que c'est pourri au niveau conception. Les pro "ça devrait suffir" et les pro "il faut être rigoureux avec les sécurités". Etc. Un beau bordel.
> La vérité c'est qu'il n'y a pas du tout de consensus sur la sécurité
Comment tu entends ça ?
Au niveau NSA, DOG (armé américhaine), certains grandes comptes, administrations, etc et les spécialistes qui sont largement reconnus, il y a consensus. Et le concensus est (pour faire court) : Le principe adopté par AppArmor "sucks". Il n'y aurait pas SeLinux, alors mieux vaux AppArmor que rien (pour faire court). Et le gros de l'affaire tourne ici. Des gens ne veulent pas SeLinux (souvent avec des arguments vaseux), donc pour eux au niveau sécurité c'est AppArmor ou rien. Donc ils défendent AppArmor "à mort".
Il n'y a pas concensus dans la communauté Linux. Mais chez les personnes qui ont une forte crédibilité au niveau sécurité il y a consensus.
> Linus garde LSM en mainline pour permettre a toutes les solutions de fonctionner.
This code has suffered from broken core design and lack of developer attention. Broken security modules are too dangerous to leave around. It is time to remove this one.
Il avait accèpté du n'importe quoi, puis il l'a viré. Il peut très bien accèpter AppArmor (et ça va probablement arriver) et le virer dans quelques mois si le vent change de direction. NB : Linus n'est pas comme ça pour tout.
M'enfin, je le comprend. C'est le leader d'un projet avec une vaste communauté. Notons bien ce qu'a dit Linus lorsqu'on le lit "entre les lignes" :
- Il ne prétend pas être un spécialiste sécurité et ne veut pas l'être. Donc il ne veut pas prendre de lui seul la responsabilité de virer LSM.
- Il trouve que beaucoup d'arguments autours de la sécurité ces derniers temps sont du n'importe quoi (crap).
- Il constate qu'il n'y a pas consensus pour virer LSM.
Donc Linus garde LSM mais sans grande motivation. Seulement pour des raisons de "confort" car il ne veut pas prendre de décision et espère ainsi faire plaisir à tout le monde. Il changerait d'avis assez vite que ça ne m'étonnerait pas.
> Bien entendu il y a de la propagande a tous les étages.
Oui et non, voir ce que j'ai déjà écrit. Mais clairement il y propagande dans Linux et Linus la subit même s'il ne le veut pas.
Notons bien que c'est Novell qui a principalement initialisé/participé à ce bordel afin de se démarquer de Red Hat en poussant AppArmor. Mais maintenant Novell abandonne AppArmor. Novell a virer 5 développeurs d'AppArmor je crois et il doit n'en rester qu'un. Crois-tu qu'une grosse administration qui doit gérer des données sensibles va le faire avec une solution Novell/AppArmor alors que Novell n'a qu'un developpeur pour faire le support ? Ce n'est pas sérieux. On voit déjà Novell faire moins de FUD sur SeLinux (j'en est pas vu depuis longtemps). Ils prépareraient leur retour à SeLinux que ça ne m'étonnerait pas. Continuer sur AppArmor interdirait à Novell tout ce qui est armé américaine, administrations sensibles, etc...
> Il y a ceux (SeLinux) qui disent : "Je suis le seul vrai module de sécurité alors pas besoin de LSM".
C'est un peu plus compliqué. Tu simplifies le discours voire le fausse. Il y avait un excellent article sur lwn.net, mais je n'arrive pas à le retrouver. Article écrit par James Morris (gros figure de SeLinux).
Le but de virer LSM, n'est pas de virer les concurrents. C'est une conséquence. Le problème est que LSM sucks et suckera toujours. C'est aussi des points d'entrés que des modules proprios peuvent utiliser pour faire n'importe quoi.
Se trainer LSM pose des problèmes à tous les développeurs (et pas seulement aux développeurs de SeLinux ou de modules de sécurité).
Se trainer LSM pose de gros problème quand il faut faire évoluer l'API (il faut l'accord de tous ceux qui utilisent LSM).
Avoir plusieurs solutions pour la sécurité disperce les efforts. Par exemple il n'y a qu'une pile tcp/ip dans Linux. C'est un problème ? Non. Et s'il y avait plusieurs piles tcp/ip, la pile tcp/ip de Linux n'aurait pas atteind le formidable niveau qu'elle a actuellement. Il n'y a qu'un scheduler. C'est un problème ? Non. Il n'y a qu'un gestionnaire de la VM. C'est un problème ? Non. Etc.
N'avoir qu'une solution pour l'infrastructure sécurité de Linux, pourrait donner un gros coup de boost à cette dernière et donc aussi à Linux. Évidemment cette solution doit permettre les trucs archis compliqués et les trucs simples.
J'image que tu va rétorquer qu'il y a plusieurs FS. Mais c'est car il y a différents besoins techniques. Ramfs ou ext3 ou NFS ce n'est pas la même chose, ça répond à différents besoins techniques (et pas philosophique). Aucun FS n'a comme philosophie "on préfère faire simple pour l'utilisateur même si c'est au risque de perdre ses données".
Je ne suis pas un spécialiste sécurité. SeLinux est compliqué. Mais j'ai des oreille et j'écoute. J'ai des yeux et je regarde ce qui se fait.
Les oreilles ont entendu du côté de SeLinux à ses débuts et jusqu'à peu :
- "Ne cherchons pas à faire simple, faisons juste. La simplicité (ou l'accessibilité) sera faite par des applis et/ou règles qui utiliseront SeLinux"
Les yeux voient aujourd'hui que c'est le cas (du moins c'est un bon début). Par exemple pour faire des règles SeLinux voilà une petite applis (c'est un module de system-config-selinux) : http://www.redhatmagazine.com/2007/08/21/a-step-by-step-guid(...)
Les applications qui utilisent Selinux permettront (voire le permettent déjà) de faire aussi simple qu'AppArmor pour l'utilisateur mais sans se baser sur un principe qui sucks sur une architecture qui sucks.
Au exemple : http://seedit.sourceforge.net/
NB : Ça utilise un modèle de sécurité moins puissant/souple que celui de la NSA/Red Hat.
SeLinux devrait être la base de la sécurité de Linux. Pas le "tout". S'il n'y avait que SeLinux, il y aurait par exemple concurrence entre Fedora et Ubuntu dans l'utilisation de SeLinux. L'un cherchant à être complet et utilisable par les clients qui exigent un controle du "workflow" et/ou des attributs de sécurité qui passent de bécanes en bécanes, etc. L'autre serait moins puissant en terme de configuration mais plus facile à assimiler. Il pourrait y avoir une concurrence plus frontale entre Mandriva avec seedit et Ubuntu.
SeLinux ce n'est pas l'uniformité.
> Clair non ?
Et alors ?
T'as trouvé un coup de sang de Linus.
Linus ne voulait pas entendre parler de la GPL v3 il y a quelques mois. Maintenant il dit "pourquoi pas".
Et regardons les forces en présence puisque sur le dossier sécurité c'est actuellement plus le lobbying qui compte que les arguments techniques (J'ai presque envis d'ajouter "dexit Linus").
- Red Hat/Fedora utilise SeLinux (Linus utilise Fedora ;-)).
- Novell va revenir à SeLinux. J'en suis persuadé.
T'as ici les deux distributions qui contribuent le plus à Linux (et de très très loins).
- IBM : Pro SeLinux.
IBM fait partit des plus gros contributeurs à Linux.
Les autres contributeurs majeurs (Intel par exemple) à Linux s'en foute que ce soit SeLinux ou AppArmor ou autre.
Si on prend en compte que l'aspect contribution (ou "méritocratie"), SeLinux l'emporte facilement.
Pour l'aspect "popularité" :
Debian semble plus impliqué dans SeLinux que AppArmor.
Ubuntu propose actuellement AppArmor mais ne ferme pas la porte à SeLinux.
Quand SeLinux sera plus accessible (avec des jolis outils graphiques), Ubuntu pourrait très bien passer à SeLinux. Ubuntu ne vise pas que le desktop (même si c'est l'impression que donne Ubuntu). Pour certains grands comptes ou administrations sensibles, il faut SeLinux.
Reste notamment Mandriva. Je ne vois pas Mandriva passez à SeLinux de lui-même.
Reste aussi peut-être OpenSuse que je vois rester avec AppArmor (Novell passant à SeLinux). M'enfin, OpenSuse est passé de Reiser à ext3 (décision prise avant les pépins juridiques de Hans).
Même si AppArmor est upstream, les choses peuvent changer. Et vite (pas en 2 ou 3 semaines évidemment).
Bizarre, pasBill pasGates l'a trouvait très bien cette organisation. Enfin... à partir du moment où elle a lâché ODF.
Et quand on disait que c'était une organisation de nazes, pasBill pasGates disait qu'on faisait l'autruche ou qu'on avait la tête dans le sable (un truc dans goût).
Une petite précision car ce n'est pas très claire. Le module bugzilla que j'ai créé, ne remplace pas les règles déjà fournies, il les complète. Donc on profite toujours des règles déjà en place.
> on me sors des fichiers de config dans /etc en XML.
Certe XML partout n'est pas une solution à tout.
Mais c'est bien pratique pour les développeurs, la compatibilité, l'interropérabilité, etc...
Faire son parseur à la main c'est sympa mais qu'une fois.
Normalement les fichiers xml ne doit pas être édité à main (même si c'est possible).
> Ton exemple bilingue est à mon sens significatif, c'est lourdigue. Je me vois mal faire un document de 200 pages ainsi.
Ce n'était qu'un exemple. Tu peux faire deux fichiers séparées si tu veux. On peut aussi faire deux documents séparés évidemment.
Tu peux aussi faire un truc dans ce gout :
<section lang=fr>
<title">Amusant</title>
<para>Je veux te tuer !</para>
[plein de blabla]
</section>
<section lang=en>
<title>Fun</title>
<para>I want to kill you !</para>
[plein de blabla]
</section>
> Sur une debian, il suffit d'installer quelques paquets
Sur toutes les distributions c'est comme ça. Juste pour t'énerver :-) j'ai seulement fait :
# yum groupinstall "Authoring and Publishing"
Mais sous Windows c'est une autre histoire (d'où le fait que je suis interessé pour faire marcher ça aussi sous Eclipse).
J'ai bien regardé du côté de MoinMoin qui peut faire aussi du Docbook ou pdf, mais il y a toujours un petit truc qui coinse (en plus de ne pas avoir vraiment la doc dans un gestionnaire de version, le bilingue, arrivé à faire un seul pdf pour toute la doc, etc).
J'ai aussi regardé du côté de Drupal et tikiwiki.
Pour le site web (qui sera modeste), je vais probablement utiliser un wiki ou dotclear (j'ai un faible pour dotclear).
Je le redis, j'ai fait le choix Docbook, il y a du subjectif. Si mon boss me dit d'utiliser un truc type Wiki ou POD, ben je le prendrais sans protester.
Merci, c'est cool.
J'ai presque fini d'installer bugzilla, après je teste Mylyn
Il me faut quelque chose pour la gestion et la communication (d'où bugzilla (+ mailing list)).
Si je peux attaquer bugzilla depuis eclipse via une interface sympa (Mylyn), c'est un plus.
Et Mylyn gère d'autres trucs sympa pour le développeur (pas indispensables, mais sympa).
Ici encore, je ne veux pas que le projet soit dépendant d'Eclipse. Eclipse ne fait "que" IDE.
Je vais oublier ce qui est lié à xplanner car çe ne me semble pas une plus pour mon projet.
Par exemple faire une belle documentation pdf avec wiki est un défit. En général il peut faire un pdf par page wiki.
Autre problème, wiki n'est pas très adapté avec un gestionnaire de version. D'accord wiki a un gestionnaire de version. Mais c'est par page.
Autre problème, comment faire pour bien synchroniser une traduction (on veut faire une doc en français et une en anglais). Avec Docbook c'est possible et dans le même fichier (il faut que je valide la solution que j'envisage).
Ça donnera un truc dans ce goût : <section>
<title lang="fr">Amusant</title>
<title lang="en">Fun</title>
<para lang="fr">Je veux te tuer !</para>
<para lang="en">I want to kill you !</para>
</section>
Si on veut faire un fichier .chm pour Windows, ça se fait assez facilement avec Docbook.
Enfin, j'ai lu des longues discutions sur la mailing documentation de Fedora pour voir s'il y avait une alternative au "lourdingue" Docbook. Rien de sérieux a été trouvé.
Docbook n'est pas si compliqué que ça. Par contre sa mise en oeuvre (les divers bidules à installer) est assez pénible.
Eclipse (ou pgsml d'emacs) rend l'édition docbook assez simple (validation en un clique, format en un clique, convertit en entité xml automatiquement si c'est nécessaire, liste des balises ou attributs autorisés en fonction du contexte en un clique, une petite fenêtre qui indique la structure du document pour y naviguer rapidement, etc).
J'ai fait le choix Docbook, il y a du subjectif.
Wiki a des atouts indéniables. Par contre restructurer un document avec wiki est assez casse couille. La navigation dans le document aussi (au faut coder des trucs). Avec Docbook ça se fait les doigts dans le nez.
C'est un peu un détail cette histoire.
Par exemple j'ai lu que MS vendait Windows+Office à 3 $ l'unité (!) en russie pour les écoles. L'amende pour "piratage" de MS a été ramené à 14 $ !. Autant dire rien.
Pour le Nigéria, il me semble avoir lu que MS proposait 400 000 $ (!) pour passer à Windows. Vous voyez le tableau : Windows gratuit + une enveloppe de 400 000 $.
MS a le même type de pratique pour la Chine et l'Inde où Linux y a un fort potentiel.
Ces pratiques, et vu le pognon fabuleux qu'a MS, ne devrait pas se calmer avant longtemps et ne concerne pas que ce petit marché de 17 000 postes.
Reconnaissont que cette histoire est significative des pratiques de MS.
Très bonne remarque et on est globalement sur la même longueur d'onde.
La méthode de référence pour construire la doc sera docbook-utils (utilisable depuis make). C'est moi qui le fait et sous Linux. Pour l'édition, Eclipse est une possibilité (moi je vais utiliser Eclipse). Par contre il y aura d'autres personnes (en fait une seule autre personne allergique à Linux :-)) qui vont éditer la doc et il faut qu'ils aient un "preview" en html et/ou pdf. Ceci doit pouvoir être fait avec Windows. Si on peut le faire avec Eclipse, alors ça marchera partout où Eclipse tourne (et donc Windows).
Il faut que je propose au moins une solution pour faire les "preview" sous Windows. Si après l'autre veut utiliser autre chose que Eclipse, c'est ses oignons.
On doit pouvoir installer docbook-util sous Windows. Mais après c'est un peu le "bordel" pour celui qui veut seulement éditer du docbook (il faut installer cygwin, il faut qu'il utilise Make, etc). Avoir une solution que ne demande que eclipse pour l'édition (+ preview) est un gros plus.
NB: l'autre personne qui va s'occuper d'une partie de la doc, n'est pas du tout un développeur.
> Il suffit ensuite de rajouter dans l'IDE, quel qu'il soit, le lancement de la commande 'make' et c'est bon.
C'est exactement ce que je fais. Il y a même des trucs que je fais hors Eclipse car c'est plus efficace de le faire à coup de grep/sed/vim/make.
> - Tu peux compiler du C/C++ avec ant et les cpptasks [1]
Mouaif. Eclipse me lance make et ça roule. De plus je ne veux pas que eclipse soit indispensable pour le projet. C'est seulement un IDE (excellent). Je fais une appli en C++, pas en java. D'autres pourront utiliser Vim, Emacs, qu'importe.
> - Pour la documentation doxygen : eclox [2] : te permet de configurer le doxyfile et de lancer la construction de la doc.
Merci pour l'info. Je regarderai ça avec beaucoup de sérieux (c'est bookmarker).
Pour la doc developpeur, jusqu'à maintenant j'ai surtout pensé à Doxygen et BoostBook (qui permet entre autre de générer du Docbook via du Doxygen).
> - Pour l'intégration avec SVN : subclipse [4], mais honnêtement subversive [5] est bien mieux. (plante moins...).
Je ne suis pas arrivé à faire marcher subclipse :-(
M'enfin, l'utilisation de la ligne de commande ne me dérange pas. Subversion a une excellente ligne de commande. Subversion a aussi de bon programmes graphiques dédités. Et comme tu me dis que subversive n'est pas encore au top... je crois que je ne vais pas l'utiliser pour le moment.
> autant je suis convaincu par Eclipse quand il s'agit de faire du Java, autant Eclipse pour c++ ne m'a jamais vraiment satisfait.
Ce n'est pas génial, mais ça le fait. C'est plus facile d'accès qu'Emacs, on se balade plus facilement dans l'arborescence des fichiers, c'est adapté à l'utilisation de make, etc.
Je suis globalement très satisfait. J'ai durant 3 ans utilisé Xemacs (il y a longtemps). Maintenant je préfère Eclipse sans l'ombre d'un doute.
> Finalement, il y a beaucoup d'instabilité entre tous les plugins que l'on assemble pour faire un IDE "perso".
Pour la partie C++/make, je suis très satisfait et je n'ai pas de problème (il y a bien 1 ou 2 petits glitchs).
> L'autocomplétion c/c++ ne vaut pas celle d'un omnicompletion
J'ai bien remarqué que l'autocomplétion ne marchait pas nickel, mais ça ne me dérange pas trop (du moins pour le project sur lequel je suis).
> et en règle générale, l'interface est très lourde.
C'est indiscutablement vrai. Peut-être que ça me dérange peu car il y a encore beaucoup de chose que je fais en ligne de commande.
Mais il faut juger l'ensemble. Es-ce que Emacs est mieux ? Pas pour moi. Il y a des menus à n'en plus finir, des tonnes de raccourcis claviers à retenir, la navigation dans les sources n'est pas pratiques, la doc d'eclipse est plus accessible, etc...
Globalement j'adore Eclipse même pour le C++, même si ce n'est pas dans ce language qu'il exprime le meilleur de son potentiel.
Par exemple tu me parles de Mylyn (que je ne connais pas). Je vais regarder de près Mylyn car je veux que bugzilla ait une place centrale dans mon développement (j'aime peu Tracks pour son mélange des genres (wiki, doc, gestionnaire de version, de bug, de planning...).
Es-ce que Mylyn existe sous Emacs ?
Autre aspect important, eclipse marche quasi à l'indentique sous Linux et sous Windows. Il s'installe avec la même facilité aussi, on y retrouve les même fonctionnalité. C'est un gros gros plus quand on développe sous Linux et Windows (comme je le fais actuellement).
Peux tu me confirme que tu penses du bien de Mylyn ?
J'ai survoler le lien que tu m'as donné et ça semble très "cool".
As-tu un avis sur la partie "gestion de planning" ?
Merci pour toutes ces infos.
PS : j'utilise Eclipse depuis plus de 6 mois.
J'ai longtemps utilisé Xemacs. Excellent, mais il devient vite un job à temps complet à lui tout seul. Si tu n'utilises plus (X)emacs durant quelques mois, t'es perdu. Je n'ai plus utilisé (X)emacs durant plusieurs mois.
J'ai hésité.
Ce n'est pas un "appel au secours" afin de corriger quelque chose que ne marche pas. C'est pour ouvrir une discussion, faire quelques échanges, avoir des informations, etc.
Tu remarqueras, par exemple, que je ne dis pas quelle version d'Eclipse j'utilise, etc.
Cet probablement dans l'infrastructure qu'il y a la plus forte influence de la communauté.
Max Spevack ne tarit pas d'éloge : http://spevack.livejournal.com/36141.html
I believe that our Fedora Infrastructure team is one of the best production operations, system administration, and networking groups anywhere. I have written about it before, but they keep finding new ways to impress me.
Murphy's Law dictated that we would be struck with a really unlucky (and almost unpredictable) hardware failure on the same day as the release, and our Infrastructure team kept us going with a bare minimum of downtime, and with the team lead about to head out on his honeymoon.
[...]
never even realized that there were any technical difficulties.
[...]
Did you know that almost all of the people on that team are volunteers? Did you know that the volunteer group that we have is so geographically diversified that we almost have 24x7 sysadmin coverage of Fedora infrastructure machines?
[...]
Do you know that Fedora Infrastructure is not only a world class example of how to manage a global system administration project, but that they are also one of the best examples of "eating our own dog food" based on the amount of Fedora and Xen that they use in their infrastructure?
En passant, et on peut insister sur ce point, toute l'infrastructure de Fedora est libre !
Certes ce n'est pas la seule distribution dans ce cas. Mais pour d'autres distributions bien connues ce n'est pas le cas.
Cette infrastructure est aussi utilisée pour RHEL. C'est très très important pour CentOS et autres clones de RHEL.
Peut-être qu'il y aura des "spins" 100 % optimisé i686 ou athlon (afin qu'on confirme que ça ne change rien :-)).
Peut-être pas aujourd'hui (NB: C'était dans F7 mais non activé par défaut nous a apris GeneralZod). Mais je crois que la majorité des distributions vont ajouter cette fonctionnalisté.
En passant, l'infrastructure de Fedora a formidablement évoluée. J'étais déconnecté du projet depuis plusieurs mois et les progrès sont impressionnants.
Par exemple koji : http://koji.fedoraproject.org/koji/
Ça a l'air de rien, mais ça m'a bien rendu service. J'avais des gels très aléatoires avec le premier noyau F8 (2.6.23.1-42.fc8), j'ai installé le dernier noyau sur koji (qui n'est pas diffusé en update pour des raisons que j'ignore mais probablement pour de bonnes raisons), et je n'ai plus de gel (ça reste à confirmer, mais j'ai stressé comme un ouf ma bécane durant plus de 12h et ça roule). Youpi !
Pour ceux qui ont le même problème : http://koji.fedoraproject.org/koji/buildinfo?buildID=23605
NB : le 2.6.23.1-49.fc8 est sorti.
Avant il fallait récupérer les patchs sur le cvs et compiler. C'était laborieux.
Through a combination of new Web tools, community growth, and better processes, translators can use Fedora Web-based tools to contribute directly to any upstream project, large or small, through one translator-oriented Web interface.
[^] # Re: LSM
Posté par IsNotGood . En réponse au journal Le nouveau SeLinux. Évalué à 0.
Bref, sans intérêt.
[^] # Re: LSM
Posté par IsNotGood . En réponse au journal Le nouveau SeLinux. Évalué à 2.
C'est exactement ça. Merci de les avoir retrouvé.
Et puisque ça parle de SMACK, les développeurs smack ne sont pas opposés à la suppression de LSM et sont prêt à intégrer les spécificités de smack dans selinux. Ceci sera d'autant plus facile que LSM sera viré et donc le code sera plus propre, lancer des grosses modifications plus facile, etc. Les développeurs selinux accueillont évidemment les développeurs smack avec grand plaisir. D'autant (j'espère que tu l'as remarqué) que smack est jugé positivement par les développeurs de SeLinux. Donc les développeurs ne disent pas qu'il n'y a qu'eux qui font des trucs bien. Ils sont ouverts. Mais ouvert à des solutions solides et pas des trucs bancales comme AppArmor.
> L'ennui évidemment c'est que son avis doit être interprété à la lumière de ce qu'il est : un des plus visibles développeur de SeLinux.
Certe. Mais la vision "les développeurs SeLinux sont des tirants qui ne pense qu'à SeLinux et rien d'autre" est ri-di-cu-le.
Le soucis de James Morris, et je le crois vraiment saincère, ce n'est pas SeLinux spécifiquement, c'est Linux. C'est de faire de Linux le meilleur OS pour la sécurité. Ses arguments sont pertinents. Qu'il soit un développeur SeLinux ou non.
> Les autres projets ont un avis différent et je ne vois pas en quoi on pourrait le rejeter sans examen.
Un avis différent sur quoi ?
Les autres projets doivent aussi penser qu'il ne faut qu'une infrastructure de sécurité et pas 50 (ni même 2).
Lorsqu'il y a eu "compétition" pour le multithread, il restait deux solutions techniquement très intéressants et très proches NGT(c'etait ce non ?) et NPTL. Mais toujours il a été été considéré (aussi bien par ceux qui développaient NGT que NPTL) qu'il ne fallait au final qu'une solution pour thread. Ceci pour le bien de Linux.
NPTL a "gagné", NGT n'en a pas fait un fromage.
Le problème avec LSM, est qu'il n'y a pas vraiment de compétition puisqu'il n'y a pas de gagnant. On garde LSM est espérant faire plaisir à tout le monde. On est dans du politique correct contre productif.
> Dire qu'il y a consensus en citant la NSA c'est un peu bizarre.
Mouaif. Dit aussi qu'il n'y a pas de consensus au niveau W3C alors ...
La NSA n'est pas une entreprise qui doit vendre son bébé. Son rôle est de chercher les meilleurs solutions. La NSA reste ouverte. L'implication de Red Hat dans SeLinux le montre. Red Hat (et la communauté Linux qui travaille sur SeLinux) a énormément influencé la NSA. IBM, HP, etc participent aussi aux réflexions et travaux de la NSA.
La NSA ou SeLinux travaille beaucoup plus dans le consensus et la recherche de l'excellence que AppArmor. AppArmor c'est à l'origine un solution d'une boite proprio. Puis ça été repris par Novell et tu connais la suite.
Donc sur ce point, SeLinux est largement devant AppArmor, Grsecurity, etc.
> Ce qu'il faut bien voir c'est que SeLinux, aussi puissant soit-il, n'est pas la panacée.
Rien n'est la panacée. Le scheduler de Linux n'était pas la panacé, etc, etc.
Ça n'a aucun sens de dire ça.
> qu'une solution complexe poussée par des grosses boites afin de se faire du fric en support.
Ben dit ça aussi de Linux.
Ce type d'argument c'est de la connerie.
Teo de Raadt peut te faire la même tirade sur Linux ou gcc. C'est du grand classique niveau FUD.
> Oh, that's right, SELinux conveniently leaves kernel exploits out of their "threat model," and no one questions it. By pure coincidence
Tu peux me mettre un exploit ?
Tu peux me mettre la réponse de SeLinux ?
> ignoring this fact allows them to continue to propagate the myth that SELinux's information flow graphs are proven,
RHEL 5 a été certifier AEL+ lspp (le plus haut niveau) :
http://www.niap-ccevs.org/cc-scheme/st/?vid=10125
Et pour le "information flow graphs", voir la doc de RHEL 5.1 que j'ai donné dans ce journal.
Ton argumentaire ne tient pas. Il sous-entend que la NSA c'est des branleurs, Red Hat c'est des branleurs, etc, etc.
C'est un peu^Wtrès facile.
> contre la lenteur quand il faut mettre à jour tous les labels.
Et tu le fais quand ça ?
Pratiquement jamais.
Ça prend grosso modo autant de temps qu'un fsck.
La relabélisation totale je l'ai fait deux fois maxi (je me rappèle pas quand j'ai fait ça pour la derrière fois...). Des fsck beaucoup plus.
Enfin, tu peux mettre à jour qu'une partie des labels. Si t'as modifié que httpd, ben tu vas relabéliser que /var/www et peut-être /etc/httpd.
La sécurité c'est du sérieux. Tu ne t'amuses pas à bouleverser toutes tes règles de sécurité tous les matins.
Notes comme l'exemple de mon journal ne demande aucun relabélisation.
Enfin, tu dis plein de bien de smack, mais smack utilise aussi les labels. Donc le reproche tu peux aussi le faire à smack.
> Si une autre techno entrait en mainline qui soit plus simple que SeLinux on pourrait très bien assister a un ralliement de plusieurs distros.
Possible. Mais reste le problème d'avoir une solution que tu peux vendre au armée, aux adminstrations sensibles, etc...
Tu veux laisser ce marché aux autres ?
> Les fans de SeLinux en sont très conscient et ils veulent vite virer LSM pour que cela ne soit pas possible...
C'est une bête vision machiavélique.
> Je trouve qu'il est assez révélateur de voir que James Morris s'est opposé à l'entrée de SMACK
Il a donné ses raisons. Et il a dit :
> "Smack itself looks fine. It seems like clean code with interesting ideas, and appears to be based upon sound principles."
Ce qui montre que James Morris est quelqu'un d'honnète. Quand il dit que AppArmor pue, ben il le pense. Il ne le dit pas pour sauver SeLinux.
Alan Cox a aussi une honnèté remarquable et il trouve que AppArmor pue.
> Si Morris reconnait que SMACK est une bonne solution technique et qu'il apporte (enfin!) une relative simplicité dans la mise en place d'une politique de sécurité alors pourquoi il s'oppose à son entrée ?
Il n'est pas opposé à smack comme il est opposé à AppArmor. Il est opposé à LSM. L'entrée de smack implique de garder LSM.
> Son projet de virer LSM pour ne laisser que SeLinux dans le noyau s'en trouverait anéanti.
Son projet n'est pas SeLinux. Son projet est de faire de Linux le top de la sécurité comme Linux est le top pour le réseau. Et on y est presque avec Selinux. C'est un fait. Actuellement ça passe par SeLinux et ce n'est pas l'objectif de smack. Smack le reconnait et smack est d'accord pour bosser avec SeLinux si LSM est viré.
Enfin pour la simplicité, je le répète pour la millième fois, tu peux faire simple avec SeLinux si ton modèle de sécurité est simple. Faire des trucs type AppArmor avec SeLinux est possible (mais en moins bancale).
Tu peux faire des trucs super compliqué avec Gtk et aussi des trucs super simples.
> On dirait vraiment un mec qui est arrivé le premier dans un bunker et qui essaye de claquer la porte derrière lui pour empêcher les autres d'entrer.
C'est ta "petite vision" des choses. Alan Cox ne veut pas de AppArmor et il veut qu'une infrastructure sécurité dans Linux.
Mais à chaque fois que quelqu'un ou un organisme est favorable à SeLinux, tu les accuses d'arrière pensé. Pourquoi tu ne fais pas de même avec AppArmor (qui maintenant est une petite boite qui cherche a faire du pognon comme tu le "dénoncait" pour SeLinux) ?
Le noeud du problème est là. Des gens (toi apparament) ne veulent pas de SeLinux. Pourquoi ? Ben grosso-modo comme à une époque la majorité des gens étaient systèmatique contre Red Hat et ne voyait dans les choix et actions de Red Hat que des basses manoeuvres.
Si SeLinux c'est si puant, alors pourquoi Red Hat fait un succès avec RHEL ?
Pourquoi CentOS est aussi un énorme succès ?
Pourquoi Fedora a une si grande communauté de contributeur ?
SeLinux c'est ce qu'il y a de mieux actuellement sous Linux. Il y a quelques soucis pour faire plus simples, etc. Les travaux sont en cours et ça progresse fort.
SeLinux ce n'est pas qu'une communauté de gens qui veulent faire du pognon ou surfer sur une mode. C'est aussi une énorme communauté de développeurs. Le travail réalisé le prouve largement.
> Je trouve donc que l'attitude de Linus est logique
L'attitude de Linus a effectivement une logique (j'ai donné mon avis plus haut). Et je n'ai jamais dit que Linus était un anti-SeLinux primaire.
Mais je pense que son attitude est mauvaise pour Linux.
[^] # Re: SeLinux pour les nuls
Posté par IsNotGood . En réponse au journal Le nouveau SeLinux. Évalué à 2.
Très bonne question. Réponse trop difficile. Joker.
> - un utilisateur de linux (desktop, chez lui ou au boulot, il connaît un peu les lignes de commande sans être un grand maître du script qui tue en 3min).
> A-t-il besoin de SeLinux sur sa machine (à part pour se la péter un peu)?
Ce type d'utilisateur ne va pas installer Bugzilla ou faire des règles SeLinux aux petits oignons pour un cgi d'apache qu'il développe.
> A-t-il besoin de SeLinux sur sa machine (à part pour se la péter un peu)?
SeLinux ça ne se vois pas. Pour se la péter, Compiz c'est mieux.
Sinon oui, c'est utile (NB: je ne dis pas indispensable). Par exemple sous F8, tous les programmes utilisateurs ne peuvent pas accéder librement à .gnupg ou a gpg-agent sans un contrôle. Si Firefox (ou bittorrent ou azureus ...) est cracké, tes clées gpg reste au chaud. Si Firefox fait n'importe quoi, une petite applet va tu prévenir. Tu peux aussi confiner Firefox.
Tu peux proposer deux Firefox (même binaire mais des règles SeLinux différentes d'appliqué). Un Firefox qui est peu confiné mais n'accèpte d'excécuter que les plugins signé par son distributeur. Un Firefox très confiné mais qui accèpte d'utiliser n'importe quel plugin.
> - un utilisateur de linux (desktop, chez lui ou au boulot, il connaît un peu les lignes de commande sans être un grand maître du script qui tue en 3min).
> A-t-il besoin de SeLinux sur sa machine (à part pour se la péter un peu)?
Ce type d'utilisateur sous Windows a besoin d'anti-virus. La réponse de Linux, ce n'est pas un anti-virus, c'est l'excellence dans le domaine de la sécurité.
[^] # Re: LSM
Posté par IsNotGood . En réponse au journal Le nouveau SeLinux. Évalué à 4.
Évidemment que non. Mais s'il n'y avait pas AppArmor, il n'y aurait probablement pas aujourd'hui LSM. Linus envisageait de virer LSM vers 2005 si j'ai bonne mémoire.
M'enfin, constatons qu'il y a AppArmor et voilà. On ne va pas aligner les développeurs d'AppArmor face et un mur etc. Évidemment que non.
Autre problème avec AppArmor, et en fait plus avec ceux qui détestent SeLinux et supportent le "cette solution simpliste devrait suffire", c'est la confusion que ça a mis dans ce qui est perçu comme la communauté des experts sécurités de Linux. Un beau bordel avec des arguments à la con (même Linus qui ne veut pas se méler de questions de sécurité c'est énervé). Ce qui est perçu comme la communauté des spécialités sécurités Linux a maintenant plusieurs discours qui sont incompatibles. La crédibilité en prend un gros coup. Et ça c'est arrivé avec AppArmor. Tu peux dire que c'est un hazard, mais je n'y crois pas. Tu peux aussi dire qu'avant tout le monde n'était pas d'accord, mais à 90 % ils étaient d'accord sur les grands principes.
Maintenant il y a les pro label et ceux qui dise que ça sert rien, c'est compliqué et blabla. Les pro pathname et ceux qui disent que c'est pourri au niveau conception. Les pro "ça devrait suffir" et les pro "il faut être rigoureux avec les sécurités". Etc. Un beau bordel.
> La vérité c'est qu'il n'y a pas du tout de consensus sur la sécurité
Comment tu entends ça ?
Au niveau NSA, DOG (armé américhaine), certains grandes comptes, administrations, etc et les spécialistes qui sont largement reconnus, il y a consensus. Et le concensus est (pour faire court) : Le principe adopté par AppArmor "sucks". Il n'y aurait pas SeLinux, alors mieux vaux AppArmor que rien (pour faire court). Et le gros de l'affaire tourne ici. Des gens ne veulent pas SeLinux (souvent avec des arguments vaseux), donc pour eux au niveau sécurité c'est AppArmor ou rien. Donc ils défendent AppArmor "à mort".
Il n'y a pas concensus dans la communauté Linux. Mais chez les personnes qui ont une forte crédibilité au niveau sécurité il y a consensus.
> Linus garde LSM en mainline pour permettre a toutes les solutions de fonctionner.
Linus botte en touche.
Sur les trucs de sécurité ce n'est pas la première fois.
http://marc.info/?l=git-commits-head&m=115954981329305&a(...)
Il avait accèpté du n'importe quoi, puis il l'a viré. Il peut très bien accèpter AppArmor (et ça va probablement arriver) et le virer dans quelques mois si le vent change de direction. NB : Linus n'est pas comme ça pour tout.
M'enfin, je le comprend. C'est le leader d'un projet avec une vaste communauté. Notons bien ce qu'a dit Linus lorsqu'on le lit "entre les lignes" :
- Il ne prétend pas être un spécialiste sécurité et ne veut pas l'être. Donc il ne veut pas prendre de lui seul la responsabilité de virer LSM.
- Il trouve que beaucoup d'arguments autours de la sécurité ces derniers temps sont du n'importe quoi (crap).
- Il constate qu'il n'y a pas consensus pour virer LSM.
Donc Linus garde LSM mais sans grande motivation. Seulement pour des raisons de "confort" car il ne veut pas prendre de décision et espère ainsi faire plaisir à tout le monde. Il changerait d'avis assez vite que ça ne m'étonnerait pas.
> Bien entendu il y a de la propagande a tous les étages.
Oui et non, voir ce que j'ai déjà écrit. Mais clairement il y propagande dans Linux et Linus la subit même s'il ne le veut pas.
Notons bien que c'est Novell qui a principalement initialisé/participé à ce bordel afin de se démarquer de Red Hat en poussant AppArmor. Mais maintenant Novell abandonne AppArmor. Novell a virer 5 développeurs d'AppArmor je crois et il doit n'en rester qu'un. Crois-tu qu'une grosse administration qui doit gérer des données sensibles va le faire avec une solution Novell/AppArmor alors que Novell n'a qu'un developpeur pour faire le support ? Ce n'est pas sérieux. On voit déjà Novell faire moins de FUD sur SeLinux (j'en est pas vu depuis longtemps). Ils prépareraient leur retour à SeLinux que ça ne m'étonnerait pas. Continuer sur AppArmor interdirait à Novell tout ce qui est armé américaine, administrations sensibles, etc...
> Il y a ceux (SeLinux) qui disent : "Je suis le seul vrai module de sécurité alors pas besoin de LSM".
C'est un peu plus compliqué. Tu simplifies le discours voire le fausse. Il y avait un excellent article sur lwn.net, mais je n'arrive pas à le retrouver. Article écrit par James Morris (gros figure de SeLinux).
Le but de virer LSM, n'est pas de virer les concurrents. C'est une conséquence. Le problème est que LSM sucks et suckera toujours. C'est aussi des points d'entrés que des modules proprios peuvent utiliser pour faire n'importe quoi.
Se trainer LSM pose des problèmes à tous les développeurs (et pas seulement aux développeurs de SeLinux ou de modules de sécurité).
Se trainer LSM pose de gros problème quand il faut faire évoluer l'API (il faut l'accord de tous ceux qui utilisent LSM).
Avoir plusieurs solutions pour la sécurité disperce les efforts. Par exemple il n'y a qu'une pile tcp/ip dans Linux. C'est un problème ? Non. Et s'il y avait plusieurs piles tcp/ip, la pile tcp/ip de Linux n'aurait pas atteind le formidable niveau qu'elle a actuellement. Il n'y a qu'un scheduler. C'est un problème ? Non. Il n'y a qu'un gestionnaire de la VM. C'est un problème ? Non. Etc.
N'avoir qu'une solution pour l'infrastructure sécurité de Linux, pourrait donner un gros coup de boost à cette dernière et donc aussi à Linux. Évidemment cette solution doit permettre les trucs archis compliqués et les trucs simples.
J'image que tu va rétorquer qu'il y a plusieurs FS. Mais c'est car il y a différents besoins techniques. Ramfs ou ext3 ou NFS ce n'est pas la même chose, ça répond à différents besoins techniques (et pas philosophique). Aucun FS n'a comme philosophie "on préfère faire simple pour l'utilisateur même si c'est au risque de perdre ses données".
Je ne suis pas un spécialiste sécurité. SeLinux est compliqué. Mais j'ai des oreille et j'écoute. J'ai des yeux et je regarde ce qui se fait.
Les oreilles ont entendu du côté de SeLinux à ses débuts et jusqu'à peu :
- "Ne cherchons pas à faire simple, faisons juste. La simplicité (ou l'accessibilité) sera faite par des applis et/ou règles qui utiliseront SeLinux"
Les yeux voient aujourd'hui que c'est le cas (du moins c'est un bon début). Par exemple pour faire des règles SeLinux voilà une petite applis (c'est un module de system-config-selinux) :
http://www.redhatmagazine.com/2007/08/21/a-step-by-step-guid(...)
Les applications qui utilisent Selinux permettront (voire le permettent déjà) de faire aussi simple qu'AppArmor pour l'utilisateur mais sans se baser sur un principe qui sucks sur une architecture qui sucks.
Au exemple :
http://seedit.sourceforge.net/
NB : Ça utilise un modèle de sécurité moins puissant/souple que celui de la NSA/Red Hat.
SeLinux devrait être la base de la sécurité de Linux. Pas le "tout". S'il n'y avait que SeLinux, il y aurait par exemple concurrence entre Fedora et Ubuntu dans l'utilisation de SeLinux. L'un cherchant à être complet et utilisable par les clients qui exigent un controle du "workflow" et/ou des attributs de sécurité qui passent de bécanes en bécanes, etc. L'autre serait moins puissant en terme de configuration mais plus facile à assimiler. Il pourrait y avoir une concurrence plus frontale entre Mandriva avec seedit et Ubuntu.
SeLinux ce n'est pas l'uniformité.
> Clair non ?
Et alors ?
T'as trouvé un coup de sang de Linus.
Linus ne voulait pas entendre parler de la GPL v3 il y a quelques mois. Maintenant il dit "pourquoi pas".
Et regardons les forces en présence puisque sur le dossier sécurité c'est actuellement plus le lobbying qui compte que les arguments techniques (J'ai presque envis d'ajouter "dexit Linus").
- Red Hat/Fedora utilise SeLinux (Linus utilise Fedora ;-)).
- Novell va revenir à SeLinux. J'en suis persuadé.
T'as ici les deux distributions qui contribuent le plus à Linux (et de très très loins).
- IBM : Pro SeLinux.
IBM fait partit des plus gros contributeurs à Linux.
Les autres contributeurs majeurs (Intel par exemple) à Linux s'en foute que ce soit SeLinux ou AppArmor ou autre.
Si on prend en compte que l'aspect contribution (ou "méritocratie"), SeLinux l'emporte facilement.
Pour l'aspect "popularité" :
Debian semble plus impliqué dans SeLinux que AppArmor.
Ubuntu propose actuellement AppArmor mais ne ferme pas la porte à SeLinux.
Quand SeLinux sera plus accessible (avec des jolis outils graphiques), Ubuntu pourrait très bien passer à SeLinux. Ubuntu ne vise pas que le desktop (même si c'est l'impression que donne Ubuntu). Pour certains grands comptes ou administrations sensibles, il faut SeLinux.
Reste notamment Mandriva. Je ne vois pas Mandriva passez à SeLinux de lui-même.
Reste aussi peut-être OpenSuse que je vois rester avec AppArmor (Novell passant à SeLinux). M'enfin, OpenSuse est passé de Reiser à ext3 (décision prise avant les pépins juridiques de Hans).
Même si AppArmor est upstream, les choses peuvent changer. Et vite (pas en 2 ou 3 semaines évidemment).
# Re:
Posté par IsNotGood . En réponse au journal La pseudo fondation opendocument est dissoute!. Évalué à 9.
Et quand on disait que c'était une organisation de nazes, pasBill pasGates disait qu'on faisait l'autruche ou qu'on avait la tête dans le sable (un truc dans goût).
# Petite précision
Posté par IsNotGood . En réponse au journal Le nouveau SeLinux. Évalué à 2.
[^] # Re: Comprends pas
Posté par IsNotGood . En réponse au journal Eclipse & Docbook. Évalué à 2.
Certe XML partout n'est pas une solution à tout.
Mais c'est bien pratique pour les développeurs, la compatibilité, l'interropérabilité, etc...
Faire son parseur à la main c'est sympa mais qu'une fois.
Normalement les fichiers xml ne doit pas être édité à main (même si c'est possible).
Pour docbook il y a des éditeurs pro :
http://www.xmlmind.com/xmleditor/
http://www.xmlmind.com/xmleditor/flash_demos/demo1.htm
Je n'ai pas essayé la version personal edition. Mon projet est commercial. Mais peut-être qu'on se prendra la version pro si la voie Docbook est validée. Mais pour l'instant c'est trop tôt.
[^] # Re: Comprends pas
Posté par IsNotGood . En réponse au journal Eclipse & Docbook. Évalué à 1.
Ce n'était qu'un exemple. Tu peux faire deux fichiers séparées si tu veux. On peut aussi faire deux documents séparés évidemment.
Tu peux aussi faire un truc dans ce gout :
<section lang=fr>
<title">Amusant</title>
<para>Je veux te tuer !</para>
[plein de blabla]
</section>
<section lang=en>
<title>Fun</title>
<para>I want to kill you !</para>
[plein de blabla]
</section>
> Sur une debian, il suffit d'installer quelques paquets
Sur toutes les distributions c'est comme ça. Juste pour t'énerver :-) j'ai seulement fait :
# yum groupinstall "Authoring and Publishing"
Mais sous Windows c'est une autre histoire (d'où le fait que je suis interessé pour faire marcher ça aussi sous Eclipse).
J'ai bien regardé du côté de MoinMoin qui peut faire aussi du Docbook ou pdf, mais il y a toujours un petit truc qui coinse (en plus de ne pas avoir vraiment la doc dans un gestionnaire de version, le bilingue, arrivé à faire un seul pdf pour toute la doc, etc).
J'ai aussi regardé du côté de Drupal et tikiwiki.
Pour le site web (qui sera modeste), je vais probablement utiliser un wiki ou dotclear (j'ai un faible pour dotclear).
Je le redis, j'ai fait le choix Docbook, il y a du subjectif. Si mon boss me dit d'utiliser un truc type Wiki ou POD, ben je le prendrais sans protester.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Comment porter plainte pour un DOS ?. Évalué à 6.
Dans ce cas c'est un gros con.
> Si quelqu'un connait un plugin dotclear 1
Un petit Captcha ?
http://www.dotclear.net/trac/wiki/DotClear/Plugins (chercher Captcha).
# Re:
Posté par IsNotGood . En réponse au journal Comment porter plainte pour un DOS ?. Évalué à 9.
Attend 2 ou 3 jours pour avoir les idées froides.
C'était probablement un petit con, ça ne mérite peut-être de porter plainte.
> Que me conseillez-vous ?
Vu qu'il a fait 40 000 commentaires en quelques secondes, il y a peut-être moyen d'améliorer la sécurité. Tu ne crois pas ?
[^] # Re: Le java, oui, le c++ ferrugineux, non
Posté par IsNotGood . En réponse au journal Eclipse & Docbook. Évalué à 1.
J'ai presque fini d'installer bugzilla, après je teste Mylyn
Il me faut quelque chose pour la gestion et la communication (d'où bugzilla (+ mailing list)).
Si je peux attaquer bugzilla depuis eclipse via une interface sympa (Mylyn), c'est un plus.
Et Mylyn gère d'autres trucs sympa pour le développeur (pas indispensables, mais sympa).
Ici encore, je ne veux pas que le projet soit dépendant d'Eclipse. Eclipse ne fait "que" IDE.
Je vais oublier ce qui est lié à xplanner car çe ne me semble pas une plus pour mon projet.
[^] # Re: Comprends pas
Posté par IsNotGood . En réponse au journal Eclipse & Docbook. Évalué à 2.
Mais il y a quelques problèmes.
Par exemple faire une belle documentation pdf avec wiki est un défit. En général il peut faire un pdf par page wiki.
Autre problème, wiki n'est pas très adapté avec un gestionnaire de version. D'accord wiki a un gestionnaire de version. Mais c'est par page.
Autre problème, comment faire pour bien synchroniser une traduction (on veut faire une doc en français et une en anglais). Avec Docbook c'est possible et dans le même fichier (il faut que je valide la solution que j'envisage).
Ça donnera un truc dans ce goût :
<section>
<title lang="fr">Amusant</title>
<title lang="en">Fun</title>
<para lang="fr">Je veux te tuer !</para>
<para lang="en">I want to kill you !</para>
</section>
Si on veut faire un fichier .chm pour Windows, ça se fait assez facilement avec Docbook.
Enfin, j'ai lu des longues discutions sur la mailing documentation de Fedora pour voir s'il y avait une alternative au "lourdingue" Docbook. Rien de sérieux a été trouvé.
Docbook n'est pas si compliqué que ça. Par contre sa mise en oeuvre (les divers bidules à installer) est assez pénible.
Eclipse (ou pgsml d'emacs) rend l'édition docbook assez simple (validation en un clique, format en un clique, convertit en entité xml automatiquement si c'est nécessaire, liste des balises ou attributs autorisés en fonction du contexte en un clique, une petite fenêtre qui indique la structure du document pour y naviguer rapidement, etc).
J'ai fait le choix Docbook, il y a du subjectif.
Wiki a des atouts indéniables. Par contre restructurer un document avec wiki est assez casse couille. La navigation dans le document aussi (au faut coder des trucs). Avec Docbook ça se fait les doigts dans le nez.
[^] # Re: et hop
Posté par IsNotGood . En réponse au journal Eclipse & Docbook. Évalué à -1.
J'utilise l'eclipse de Fedora. Comme ça tu pourras dire que j'ai fait un journal de plus sur Fedora.
Content ?
# Détail ?
Posté par IsNotGood . En réponse au journal Mandriva / Microsoft : Renversement de situation. Évalué à 8.
Par exemple j'ai lu que MS vendait Windows+Office à 3 $ l'unité (!) en russie pour les écoles. L'amende pour "piratage" de MS a été ramené à 14 $ !. Autant dire rien.
Pour le Nigéria, il me semble avoir lu que MS proposait 400 000 $ (!) pour passer à Windows. Vous voyez le tableau : Windows gratuit + une enveloppe de 400 000 $.
MS a le même type de pratique pour la Chine et l'Inde où Linux y a un fort potentiel.
Ces pratiques, et vu le pognon fabuleux qu'a MS, ne devrait pas se calmer avant longtemps et ne concerne pas que ce petit marché de 17 000 postes.
Reconnaissont que cette histoire est significative des pratiques de MS.
[^] # Re: Comprends pas
Posté par IsNotGood . En réponse au journal Eclipse & Docbook. Évalué à 2.
La méthode de référence pour construire la doc sera docbook-utils (utilisable depuis make). C'est moi qui le fait et sous Linux. Pour l'édition, Eclipse est une possibilité (moi je vais utiliser Eclipse). Par contre il y aura d'autres personnes (en fait une seule autre personne allergique à Linux :-)) qui vont éditer la doc et il faut qu'ils aient un "preview" en html et/ou pdf. Ceci doit pouvoir être fait avec Windows. Si on peut le faire avec Eclipse, alors ça marchera partout où Eclipse tourne (et donc Windows).
Il faut que je propose au moins une solution pour faire les "preview" sous Windows. Si après l'autre veut utiliser autre chose que Eclipse, c'est ses oignons.
On doit pouvoir installer docbook-util sous Windows. Mais après c'est un peu le "bordel" pour celui qui veut seulement éditer du docbook (il faut installer cygwin, il faut qu'il utilise Make, etc). Avoir une solution que ne demande que eclipse pour l'édition (+ preview) est un gros plus.
NB: l'autre personne qui va s'occuper d'une partie de la doc, n'est pas du tout un développeur.
> Il suffit ensuite de rajouter dans l'IDE, quel qu'il soit, le lancement de la commande 'make' et c'est bon.
C'est exactement ce que je fais. Il y a même des trucs que je fais hors Eclipse car c'est plus efficace de le faire à coup de grep/sed/vim/make.
[^] # Re: Le java, oui, le c++ ferrugineux, non
Posté par IsNotGood . En réponse au journal Eclipse & Docbook. Évalué à 1.
Mouaif. Eclipse me lance make et ça roule. De plus je ne veux pas que eclipse soit indispensable pour le projet. C'est seulement un IDE (excellent). Je fais une appli en C++, pas en java. D'autres pourront utiliser Vim, Emacs, qu'importe.
> - Pour la documentation doxygen : eclox [2] : te permet de configurer le doxyfile et de lancer la construction de la doc.
Merci pour l'info. Je regarderai ça avec beaucoup de sérieux (c'est bookmarker).
Pour la doc developpeur, jusqu'à maintenant j'ai surtout pensé à Doxygen et BoostBook (qui permet entre autre de générer du Docbook via du Doxygen).
> - Pour l'intégration avec SVN : subclipse [4], mais honnêtement subversive [5] est bien mieux. (plante moins...).
Je ne suis pas arrivé à faire marcher subclipse :-(
M'enfin, l'utilisation de la ligne de commande ne me dérange pas. Subversion a une excellente ligne de commande. Subversion a aussi de bon programmes graphiques dédités. Et comme tu me dis que subversive n'est pas encore au top... je crois que je ne vais pas l'utiliser pour le moment.
> autant je suis convaincu par Eclipse quand il s'agit de faire du Java, autant Eclipse pour c++ ne m'a jamais vraiment satisfait.
Ce n'est pas génial, mais ça le fait. C'est plus facile d'accès qu'Emacs, on se balade plus facilement dans l'arborescence des fichiers, c'est adapté à l'utilisation de make, etc.
Je suis globalement très satisfait. J'ai durant 3 ans utilisé Xemacs (il y a longtemps). Maintenant je préfère Eclipse sans l'ombre d'un doute.
> Finalement, il y a beaucoup d'instabilité entre tous les plugins que l'on assemble pour faire un IDE "perso".
Pour la partie C++/make, je suis très satisfait et je n'ai pas de problème (il y a bien 1 ou 2 petits glitchs).
> L'autocomplétion c/c++ ne vaut pas celle d'un omnicompletion
J'ai bien remarqué que l'autocomplétion ne marchait pas nickel, mais ça ne me dérange pas trop (du moins pour le project sur lequel je suis).
> et en règle générale, l'interface est très lourde.
C'est indiscutablement vrai. Peut-être que ça me dérange peu car il y a encore beaucoup de chose que je fais en ligne de commande.
Mais il faut juger l'ensemble. Es-ce que Emacs est mieux ? Pas pour moi. Il y a des menus à n'en plus finir, des tonnes de raccourcis claviers à retenir, la navigation dans les sources n'est pas pratiques, la doc d'eclipse est plus accessible, etc...
Globalement j'adore Eclipse même pour le C++, même si ce n'est pas dans ce language qu'il exprime le meilleur de son potentiel.
Par exemple tu me parles de Mylyn (que je ne connais pas). Je vais regarder de près Mylyn car je veux que bugzilla ait une place centrale dans mon développement (j'aime peu Tracks pour son mélange des genres (wiki, doc, gestionnaire de version, de bug, de planning...).
Es-ce que Mylyn existe sous Emacs ?
Autre aspect important, eclipse marche quasi à l'indentique sous Linux et sous Windows. Il s'installe avec la même facilité aussi, on y retrouve les même fonctionnalité. C'est un gros gros plus quand on développe sous Linux et Windows (comme je le fais actuellement).
Peux tu me confirme que tu penses du bien de Mylyn ?
J'ai survoler le lien que tu m'as donné et ça semble très "cool".
As-tu un avis sur la partie "gestion de planning" ?
Merci pour toutes ces infos.
PS : j'utilise Eclipse depuis plus de 6 mois.
[^] # Re: ne sois pas désolé,
Posté par IsNotGood . En réponse au journal Eclipse & Docbook. Évalué à 2.
[^] # Re: et hop
Posté par IsNotGood . En réponse au journal Eclipse & Docbook. Évalué à 1.
Ce n'est pas un "appel au secours" afin de corriger quelque chose que ne marche pas. C'est pour ouvrir une discussion, faire quelques échanges, avoir des informations, etc.
Tu remarqueras, par exemple, que je ne dis pas quelle version d'Eclipse j'utilise, etc.
[^] # Re: CDs d'installation disponibles sur FedoraUnity.org
Posté par IsNotGood . En réponse à la dépêche Fedora 8: le loup-garou est lâché !. Évalué à 2.
Max Spevack ne tarit pas d'éloge :
http://spevack.livejournal.com/36141.html
http://spevack.livejournal.com/18495.html
Chapeau bas.
[^] # Re: CDs d'installation disponibles sur FedoraUnity.org
Posté par IsNotGood . En réponse à la dépêche Fedora 8: le loup-garou est lâché !. Évalué à 1.
Certes ce n'est pas la seule distribution dans ce cas. Mais pour d'autres distributions bien connues ce n'est pas le cas.
Cette infrastructure est aussi utilisée pour RHEL. C'est très très important pour CentOS et autres clones de RHEL.
Peut-être qu'il y aura des "spins" 100 % optimisé i686 ou athlon (afin qu'on confirme que ça ne change rien :-)).
[^] # Re: Infinity
Posté par IsNotGood . En réponse à la dépêche Fedora 8: le loup-garou est lâché !. Évalué à 1.
Peut-être pas aujourd'hui (NB: C'était dans F7 mais non activé par défaut nous a apris GeneralZod). Mais je crois que la majorité des distributions vont ajouter cette fonctionnalisté.
Patience :-)
[^] # Re: CDs d'installation disponibles sur FedoraUnity.org
Posté par IsNotGood . En réponse à la dépêche Fedora 8: le loup-garou est lâché !. Évalué à 2.
Il devrait prendre de l'ampleur pour F9.
En passant, l'infrastructure de Fedora a formidablement évoluée. J'étais déconnecté du projet depuis plusieurs mois et les progrès sont impressionnants.
Par exemple koji :
http://koji.fedoraproject.org/koji/
Ça a l'air de rien, mais ça m'a bien rendu service. J'avais des gels très aléatoires avec le premier noyau F8 (2.6.23.1-42.fc8), j'ai installé le dernier noyau sur koji (qui n'est pas diffusé en update pour des raisons que j'ignore mais probablement pour de bonnes raisons), et je n'ai plus de gel (ça reste à confirmer, mais j'ai stressé comme un ouf ma bécane durant plus de 12h et ça roule). Youpi !
Pour ceux qui ont le même problème :
http://koji.fedoraproject.org/koji/buildinfo?buildID=23605
NB : le 2.6.23.1-49.fc8 est sorti.
Avant il fallait récupérer les patchs sur le cvs et compiler. C'était laborieux.
Notons aussi Transifex :
http://fedoraproject.org/wiki/Features/Transifex
[^] # Re: L'annonce de la sortie de Fedora 8 en chanson.
Posté par IsNotGood . En réponse à la dépêche Fedora 8: le loup-garou est lâché !. Évalué à 1.
http://www.redhatmagazine.com/2007/11/08/video-fedora-8-high(...)
Ce n'est pas en chanson, c'est en vidéo. Très sympa.
[^] # Re: Infinity
Posté par IsNotGood . En réponse à la dépêche Fedora 8: le loup-garou est lâché !. Évalué à 4.
[^] # Re: technique, pas technologie
Posté par IsNotGood . En réponse à la dépêche Fedora 8: le loup-garou est lâché !. Évalué à -1.
Et ?
Ext3 c'est simplement un système de fichier.