D'après l'article en question :
>>Novell will continue updating AppArmor and using and it in its Suse Linux Enterprise Server software, but the development mechanism has changed since Novell released AppArmor as open-source software in 2006. Some companies outsource programming work to India, but with active open-source software projects, there's even lower-cost options.
Ce n'est pas un abandon, c'est surtout une histoire de gros sous, ça coûte moins cher de faire développer un produit opensource par des développeurs indiens.
Tu dis, en référence à ce qu'a dit un développeur "impartial" dans des articles de 2006
>>Pour faire court, AppArmor c'est naze. Sa conception est naze, AppArmor restera naze.Donc peut-être que Novell a vu que AppArmor ne lui permettrait pas d'avoir certaines certifications et préfère abandonner AppArmor (mais l'air de rien).
Dans ce cas, tu devrais te dépêcher de modifier l'article de Wikipedia qui dit que :
>>While there has been considerable debate about which approach is better, there is no strong evidence as of yet that one approach is preferable to the other. The discussion about the advantages and disadvantages of either method often revolve around which approach is more aligned with existing UNIX/Linux access control mechanisms, but UNIX and Linux use a combination of path-based and inode-based access control. Note also that existing access control mechanisms remain in place with either system.
D'ailleurs, si tu lis la page de discussion sur SELinux, tu verras une forte discussion sur les NPOV (Neutral Point Of View) http://en.wikipedia.org/wiki/Talk:Security-Enhanced_Linux#NP(...)
>>The technical advantages and drawbacks of each approach can easily and more usefully be discussed without specific reference to the other by discussing design tradeoffs ("the designers of methods Q wanted to have property X even if that made property Y harder to achieve") and specific examples ("method Q can handle specific example A, but not specific example B"). Of course, statements of such tradeoffs and examples should be based on references to the literature, not the imagination of the Wikipedia contributors.
et aussi j'aime beaucoup :
>>The last paragraph in the preceding section "AppArmor was created in part as an alternative to SELinux, which critics claim is difficult for administrators to set up and maintain. Unlike SELinux, which is based on applying labels to files, ..." seems fairly biased as well. Which critics are we talking about? Which administrators found it difficult? I could not find a reference on the AppArmor website that said it was created as an alternative to SELinux. Why are path-based controls easier to manage than file-based?
En conclusion : Il y a encore beaucoup de discussions, sur la validité d'un choix de sécurité par les chemins ou par les inodes, cependant :
1) arrêtons de nourrir les trolls basés sur l'imagination, fournissons de véritables éléments de comparaison
2) arrêtons les délires sur les contre-projets de projets
3) >>> "On est rebelz ou on ne l'est pas, après tout." Arrêtons ces phrase sans intérêt dignes de jeunes de 13 ans.
[^] # Re: Novell se désengage de AppArmor ?
Posté par Bruce Le Nain (site web personnel) . En réponse au journal AppArmor is teh lulz. Évalué à 4.
>>Novell will continue updating AppArmor and using and it in its Suse Linux Enterprise Server software, but the development mechanism has changed since Novell released AppArmor as open-source software in 2006. Some companies outsource programming work to India, but with active open-source software projects, there's even lower-cost options.
Ce n'est pas un abandon, c'est surtout une histoire de gros sous, ça coûte moins cher de faire développer un produit opensource par des développeurs indiens.
Tu dis, en référence à ce qu'a dit un développeur "impartial" dans des articles de 2006
>>Pour faire court, AppArmor c'est naze. Sa conception est naze, AppArmor restera naze.Donc peut-être que Novell a vu que AppArmor ne lui permettrait pas d'avoir certaines certifications et préfère abandonner AppArmor (mais l'air de rien).
Dans ce cas, tu devrais te dépêcher de modifier l'article de Wikipedia qui dit que :
>>While there has been considerable debate about which approach is better, there is no strong evidence as of yet that one approach is preferable to the other. The discussion about the advantages and disadvantages of either method often revolve around which approach is more aligned with existing UNIX/Linux access control mechanisms, but UNIX and Linux use a combination of path-based and inode-based access control. Note also that existing access control mechanisms remain in place with either system.
D'ailleurs, si tu lis la page de discussion sur SELinux, tu verras une forte discussion sur les NPOV (Neutral Point Of View) http://en.wikipedia.org/wiki/Talk:Security-Enhanced_Linux#NP(...)
>>The technical advantages and drawbacks of each approach can easily and more usefully be discussed without specific reference to the other by discussing design tradeoffs ("the designers of methods Q wanted to have property X even if that made property Y harder to achieve") and specific examples ("method Q can handle specific example A, but not specific example B"). Of course, statements of such tradeoffs and examples should be based on references to the literature, not the imagination of the Wikipedia contributors.
et aussi j'aime beaucoup :
>>The last paragraph in the preceding section "AppArmor was created in part as an alternative to SELinux, which critics claim is difficult for administrators to set up and maintain. Unlike SELinux, which is based on applying labels to files, ..." seems fairly biased as well. Which critics are we talking about? Which administrators found it difficult? I could not find a reference on the AppArmor website that said it was created as an alternative to SELinux. Why are path-based controls easier to manage than file-based?
En conclusion : Il y a encore beaucoup de discussions, sur la validité d'un choix de sécurité par les chemins ou par les inodes, cependant :
1) arrêtons de nourrir les trolls basés sur l'imagination, fournissons de véritables éléments de comparaison
2) arrêtons les délires sur les contre-projets de projets
3) >>> "On est rebelz ou on ne l'est pas, après tout." Arrêtons ces phrase sans intérêt dignes de jeunes de 13 ans.