2) RH a des adversaires particulier comme Hupstream (debian, mageia, etc.), mais il est encore petit.
Ah ah ah. Arrête de parler de ce que tu ne connais pas. Y a autant de salles de réunions dans les bureau du bureau français de RH que de salariés de Hupstream dans le monde ( soit 6 personnes, voir 7 ), pour te donner une idée des écarts de moyens entre les 2.
Et au moins, *buntu reste légale dans les pays où les brevets logiciels sont reconnus (comme les États Unis).
Si tu fait abstraction du fait que le paquet openssl active le support des courbes elliptiques (ECDSA) ( https://bugzilla.redhat.com/show_bug.cgi?id=319901 ) alors que c'est une fonctionnalité jugé problématique du point de vue des brevets logiciels.
Canonical n'a pas la même R&D que Apple, et ne peux pas se permettre de devoir faire ses propres drivers si jamais il y a besoin. Bien que Canonical contribues upstream ( sur pulseaudio, twisted, mailman pour ne citer que 3 exemples ), le kernel n'est pas dans la liste. Donc sauf à imaginer que Canonical recrute beaucoup de codeurs kernels, ils sont dépendant du travail des autres pour les couches basses.
Et puis le support des pilotes proprios, c'est pas encore ça. Si Canonical part sur mir, c'est aussi pour aller à coté des kernels android, pour simplifier la vie des OEMs pour les téléphones. Passer sur BSD ferait perdre tout ça.
On verra quand ça va pêter … C'est pas souvent que ça arrive mais c'est dans ces cas là que tu apprécies les choses simples.
avec les scripts bash, tu as pas besoin d'attendre que ça pete pour être déjà en train d'avoir des emmerdes. Les scripts de 50 lignes pour charger ton service, ça n'a rien de simple ( et encore, je parle pas des horreurs que j'ai vu par des OEMs sur HP-UX, car la production, c'est ça aussi, des vieux trucs moisis ). Gérer des merdes comme bind ( avec rdnc et le fait de devoir faire un sleep parce que tu peux pas savoir de façon race-free que bind est vraiment arrêter ), ça n'a rien de simple.
je peux comprendre que c'est familier, que c'est rassurant, que systemd force à apprendre des nouveaux trucs, voir qu'il y a des nouveaux bugs, mais le système d'init en bash n'a rien de simple. Il est pauvre en fonction, il est lent, il requiert de connaitre un langage de merde qui n'a rien de prévu pour faire du développement sérieux, et un langage des plus non intuitif sur des points comme le calcul décimal, les sockets ( via /dev/tcp ), etc.
autant de doute vis à vis des constructeurs qui installent par défaut un Windows ?
ben faut croire que windows réponds aux besoins des clients de microsoft. Les OEMs ont la certifs, des drivers, et ont l'argument de vente d'avoir une logithèque énorme. Et les clients des OEMs ont pareil, l'accès à la logithèque.
Si la plupart des gens voulaient vraiment du Linux, quelqu'un le proposerait et se ferait des couilles en or. C'est pas faute d'avoir tenté plus d'une fois ( mndrake, suse, RH, lycrosi, corel linux, mint, Ubuntu, entre autres ), et d'avoir à chaque fois fait un pétard mouillé.
Qu'est-ce qui empêche les autres distribs de l'adopter ?
Canonical pense que pour gagner des parts de marché, il faut faire preuve d'agilité et de vitesse. C'est une position comme une autre, ç'est pas déconnant. Ensuite, le souci, c'est que ça implique plusieurs choses :
- des hacks parfois court termes plus que des corrections propres long termes. par exemple, qui se souviens de la controverse autour de xsplash et plymouth.
- ne pas hésiter à refaire tout de 0 si besoin. Il suffit de voir justement l'histoire d'unity, ou les bases sont passés de gtk à qt à compiz ( ou dans un autre ordre ).
- ne pas hésiter à corriger rapidement sur sa distro que de négocier avec upstream. un exemple d'école, c'est android et le kernel, genre les waveocks. Dans le même genre, ubuntu à tendance à patcher pour le support des indicateurs, et tout le monde ne voit pas d'un bon oeil que de rajouter des patchs pour ça un peu partout.
Et on pourrait laisser le bénéfice du doute à Canonical, mais c'est exactement pour ça que Unity est dispo officiellement dans quasiment aucune distro autre que downstream de ubuntu. Debian n'a pas le paquet, la communauté Fedora a tenté 2 fois de l'avoir, etc.
on va pas reprocher à Canonical de foncer, de coder. Ou du moins, moi, je reproche pas ça. Au contraire, qu'ils foncent, qu'ils arrivent à gagner du pognon et à devenir une boite à l'équilibre, pour le bien du libre et de ses salariés.
Par contre, faire ça et se vanter de "bosser upstream" (cf blog de Jono bacon : http://www.jonobacon.org/2010/07/30/red-hat-canonical-and-gnome-contributions/ ou il liste tout les softs 'upstreams' qui tourne que sur Unity et qu'ils ont commencés ) et de "consulter la communauté", et de "bosser de maniére ouverte" alors qu'il y a des trucs fait en secret.
Encore une fois, y a rien de mal à tout ça. Si Canonical pense que c'est valable pour faire vivre la boite, parfait, j'ai pas les infos pour juger (autre que "pour le moment, ça marche pas"). Mais c'est le contraste entre ce qu'ils disent et ce qu'ils font en pratique qui énervent une part des gens qui expriment des critiques sur Canonical.
Parce que moi, sur une de mes machines, j’ai un besoin qui est « traitement complexe dans rc.local », et je peux te dire que systemd se
vautre lamentablement là dessus.
Je doute que ton besoin soit stricto sensu "je doit lancer ça dans rc.local". Mais "je doit lancer ça au démarrage". Donc je pense que faire une unité systemd devrait marcher. Quand à dire "il se vautre la dessus", sans plus d'info, c'est difficile de voir si c'est un bug ou une erreur de ta part ( et ça peut être les 2, une doc pas assez claire qui fait que tu fait une erreur parce que ça réagit pas comme tu crois ).
Si le souci est que tu lances une tache longue et que systemd tues la tache, je pense qu'une unité de type "oneshot" est exactement ce que tu veux. Mais sur ma machine, c'est déjà comme ça que rc.local est lancé (et sans timeout). Peut être que le souci, c'est d'être isolé de façon plus drastique qu'avant, c'est difficile de t'aider sans plus d'info.
Non, pas vraiment. Prends un script d'init bsd et mets le sur un linux, qu'on regarde comment ça marche bien. C'est pas parce que tu peux faire un script qui va marcher partout que tout les scripts marchent partout, ni même que l'intégration soit correct. Si tu veux suivre les coutumes locales, la config du script va aller dans /etc/default pour debian et consorts, et /etc/sysconfig pour RH et dérivé, et ailleurs pour suse, sauf erreur de ma part. Ou les BSD et arch.
Donc permet moi de dire que tu surestimes la portabilité, et que tu sous estimes le travail des packageurs à ce niveau. ( et l'imagination dont font preuves certains upstreams pour faire des trucs chiants à lancer correctement )
Si c'est l'init, on lui demande juste de démarrer ce qu'il faut, et d'arrêter ce qu'il faut.
/sbin/init fait plus que ça. Il se charge aussi de tuer les process zombies qui se rattache à lui, de relancer si tu demandes ( respawn ), il gère les touches ctrl alt del, il gère le fait d'avoir courant coupé (via l'action powerwait, powerfail et consort ).
Je veux bien croire que les gens veulent un init minimal, mais ça fait des années que /sbin/init n'est pas aussi minimal et fait des trucs qui ne le regarde pas ( exemple, powerwait, powerfail ) , et bien sur, personne n'a jamais rien dit ni trouver ça anormal. ( et je parle pas de "refaire sa propre implémentation d'un système de message" via un pipe dans /dev, ce qui n'a rien à faire la d'après la FHS, sauf si ça rentre dans "special file" et ça me semble être vraiment tirer par les cheveux comme raison, car "un pipe pour communiquer avec l'userspace", ça n'a rien de spécial ).
je suis favorable à la réutilisation, mais pour un truc de bas niveau comme l'init, je préfère qu'il ne dépende pas des bugs des autres …
en pratique, il va dépendre des bugs dans le kernel, dans le bios, et dans la libc. Et des bugs dans les compilos, bien sur. Soit une somme de code bien plus importante que tout ce que systemd va tirer.
Et toutes les 6 mn il va devoir réitérer son exploit de 0. A mon avis il va être vite dégoûté…
Pas vraiment. quand tu sais que pour exploiter une race condition, il faut faire parfois des tas d'essais, ou parfois pour contourner les canries, pour deviner une adresse, etc, les attaquants ont appris à faire ce qu'il faut, à savoir, des boucles. Si tu rebootes tout les 6 minutes, ç'est pas forcément grave. Sur un téléphone, il faut sans doute moins de 6 minutes pour te faire appeler un numero surtaxé à l'étranger, rendant rentable la chose. Et sur un pc, bah, 6 minutes et ensuite, il reste plus de trace, ça me semble être un bon deal. Voir pire, utiliser chaque cpu pour attaquer les 2 autres pour rester en permanence.
Donc le schema n'a de sécurisé que le fait qu'il soit inhabituel et non courant. Et on peut dire autant de "mettre ton repertoire windows sur D:/win32", qui arrète (ou du moins à l'époque, il y a 10 ans) une bonne part des malwares qui hardcodent des chemins.
Ca existe encore? C'est pas mort, enterré sous 18 pieds de terre?
ce projet, visiblement si. Ensuite, c'est un exemple que les gens connaissent.
Et puis ça ne fait pas de l'analyse protocolaire, ça fait de la reconnaissance d'appli.
ça fait du pattern matching sur les chaines, pour analyser le flux pour reconnaitre les applis, je pensais que ça rentrais dans analyse protocolaire. Ceci dit, à 1h du matin les détails de ce genre m'échappe parfois.
Et sinon, je pense que qosmo a un produit pour toi :)
La pile zrtp en question est vachement utilisé, tu pourrais croire que c'est de la sécurité, ça a été relu, et visiblement, pas trop. Mais bon, à part ça, faut se méfier des LSMs bien sur :)
SELinux est une sécurité « en plus », si vous envisagez qu'une backdoor ait pu y être introduite, il suffit de ne pas l'utiliser
En fait, selinux est un système de label et de permission. Chaque objet a son label ( stocké via xattr sur les fs, rien de spécial ), et un moteur de regle, avec un minimum d'optimisation pour pas faire ramer ( voir les détails sur https://www.imperialviolet.org/2009/07/14/selinux.html ). Donc ne pas l'utiliser pour éviter une backdoor, c'est revenir au système par défaut qui donne beaucoup plus de permissions et , et c'est comme dire que sans firewall, on est plus en sureté.
Retirer un firewall parce que ça fait chier, parce qu'on a pas le temps de le maintenir et que ça a un cout, pourquoi pas, ça se défend. Dire qu'on a pas besoin car il peut y avoir des failles dans le traitement des chaines( genre l7, le super truc qui fait de l'analyse protocolaire ), à la rigueur, mais c'est pas lié au concept de firewall lui même mais au code.
Par contre, j'ai vu personne dire "je retire le firewall car c'est plus sur, j'ai pas de risque de backdoor". Dire pareil de selinux, ça tiens plus du cargo cult qu'autre chose.
Sinon, oui le code de selinux a été audité par les gens de RH avant de l'intégrer ( comme tout ce qui est rajouté dans le kernel de RHEL ), et aussi par le même group de gens qui ont audités tout le reste du kernel sur la lklm ( surtout vu le selinux a mis du temps à rentrer ), et aussi par les gens de tresys.
Ensuite, quand on parle du code de selinux, c'est superbement imprécis. Est ce qu'on parle des LSMs, d'un LSM en particulier, du code en userspace, de la policy ?
Et prendre apparmor, je dirais qu'il y a pas la même couverture fonctionnelle, ni les mêmes fonctions. Le but, c'est pas de charger un LSM pour charger un LSM, mais de voir les menaces, les risques, les besoins tu as et quels solutions tu va déployer. Et pour un utilisateur, garder la solution choisi par le distributeur me semble logique, vu que la plupart dépende d'une politique de régles, soit c'est complet sur un LSMs, soit c'est grossièrement incomplet sur tout les LSMs. Donc le choix se fait plus au niveau de la distribution choisi qu'autre chose.
On peut dire qu'en effet, j'ai une journée aussi chargé que d'habitude, mais c'est surtout répondre pendant que mes collègues anglophones sont en réunion qui me perturbe.
Pour en revenir au sujet, j'aurais quand même tendance à dire qu'on doit pas voir les entreprises comme des unités parfaitement uniformes, la communication passe en général lentement, donc les choix d'une partie de l'entreprise n'a aucune importance pour une autre partie de la boite, voir la même partie passé ou futur. Sauf à croire que le PDG s'engage fortement sur un produit et qu'il arrive à articuler sa vision tel que tout le monde le suit ( ou qu'il soit ultra autoritaire ), ça n'arrive jamais, surtout pour un conglomérat de la taille de Sony.
Chaque sous groupe a sa propre autonomie, et à l'intérieur, chaque département, chaque équipe, etc, peut faire ses choix technologiques. Donc l'impact est bon pour Freebsd, mais je pense que Freebsd n'avait pas vraiment un grand besoin de crédibilité, étant déjà une solution crédible pour ça, et que ça va pas impacter la popularité de Linux, qui est déjà aussi une solution crédible depuis des années.
Et pour aller plus loin, ceux qui espéraient faire du windows avec SONY, et ils sont légions les windowsiens, ils sont contents d'apprendre qu'il n'y a pas de place pour eux?
Si les mecs pensaient que Sony aller mettre Windows sur sa nouvelle console en étant en concurrence contre Microsoft, je pense qu'ils ont d'autres soucis. Comme par exemple le fait d'avoir des idées à la con.
Tu as compris l'inverse de ce que CHP a dit. Il a dit qu'il y avait, en entreprise, plus de RHEL ou Suse que de Debian ou Fedora parce que justement ces deux premières proposent du support, commercialement,
par opposition à un support communautaire ou par une entreprise tiers.
Je croise plus souvent du Debian en entreprise que du Fedora ceci dit. Debian est vu comme étant pour serveur, ou comme base pour faire une distribution personnalisé, alors que Fedora est vu comme étant pour les hobbyistes, et pour les postes de travail. Ensuite, je pense qu'il y a avec l'arrivée du cloud et de ce que ça implique ( à savoir des machines jetables, du bétail contrairement à des serveurs plus classiques qui sont des animaux de compagnies, pour reprendre l'image d'un admin du CERN ), les choses peuvent changer.
Oui mais je pense que les décideurs en entreprise considèrent, à tort ou à raison, qu'un support proposé directement par l'éditeur c'est mieux.
Ben surtout que personne ne dit "je garantit" sur un produit ou il n'a pas la main.
RH garantit RHEL car c'est contractuellement faisable. Par exemple, Debian ne s'est jamais fatigué à faire les démarches pour l'exportation au niveau de la cryptographie avec le département d'état américain. Bien que le risque de souci soit faible voir nulle, et qu'on s'en fout franchement (au contraire des brevets, ou les risques sont plus gros), je pense qu'il y a des cas ou ça compte. Debian ne se fait pas certifié FIPS, trop cher, trop long. Pareil, il y a des cas ou ça compte. Ou PCI-DSS, ce genre de choses. Des histoires de régulations, y en a dans plein de secteurs, les assurances, les hopitaux et la santé, etc.
Ça semble ridicule pour un particulier ou même pour une PME. Pour une grande entreprise, c'est plus compliqué.
Des trucs tout con comme "j'ai besoin d'avoir des cours sur la technologie pour former les 50 admins", faut avoir déjà une grosse boite pour mettre ça en place. Etc, etc.
C'est pas que Debian soit mauvais ou RHEL meilleur, c'est que RH a mis en place que ce que les clients veulent pour pas perdre de temps sur des détails.
Et que RH a la main d'oeuvre pour faire de la revue de code, pour tout les trucs chiants qu'on a tendance à ne pas voir. Avoir des consultants disponibles, du support.
Et c'est bien parce que Debian et Fedora sont des communautés qu'il y a des produits forkés pour les entreprises ( en l'occurrence, RHEL et Ubuntu ), parce que personne saint d'esprit ne peut donner le même niveau de garantie sur Debian qu'il pourrait donner sur un produit séparé qu'il contrôle.
Le moinsage par principe existe partout, et ici aussi.
des preuves ? (non "ça existe partout, j'ai pas besoin de le prouver" ou variation comme "j'ai déjà expliqué ailleurs", c'est pas une preuve, et se citer soi même quand tout le monde demande plus d'info, c'est juste n'importe quoi )
Dans la vraie vie si tu fais face aux gangs de Los Angeles, tu es mort.
Cool story bro, et le rapport avec Linuxfr ? Quelqu'un t'a menacé physiquement ?
Parce que je cite toi même aujourd'hui ailleurs sur la page :
Si un mot qui s'apparente de près ou de loin à menace apparaît quelque part, j'ai cru comprendre que pour vous c'est une arme sur la tempe…
Si tu compares les gens qui discutent avec toi à des gangs de LA et que tu compares le fait de te faire contredire au fait de risquer ta vie, permet moi de te dire que tu es totalement hors sujet.
Imaginez maintenant la personne normale qui vient sur linuxFR, il voit ça ou pire le vit, vous croyez honnêtement qu'il restera ?
donc les gens qui viennent sur linuxfr en dehors de la personne normale, c'est quoi, des personnes anormales ? Tu te rends pas compte que tu es insultant dans ta façon de présenter les choses ?
Des parents aux USA ont peur pour leur enfant, de même des personnes aiment linux mais ne veulent pas critiquer de peur d'être moinsés et
d'être mis au ban du site par les membres.
Ah oui, tout ces gens qui seront mis au ban par l'élite linuxfrienne qui a droit de vie ou de mort sur tout le web, capable d'un coup de souris de forcer l'usage des fourches caudines de la censure sur le pauvre innocent, qui du coup va … perdre un point de karma, un truc dont il n'avait aucun idée avant de venir ici, qui ne sert à rien à part monter ou pas e commentaire pour une sous partie des quelques utilisateurs du site. Oui, c'est totalement comparable avec les gangs à LA. Risquer sa vie dans une fusillade, perdre un point de karma en disant des trucs, exactement la même chose.
Priez le ciel que ce n'est pas votre ennemi si le karma est important pour vous.
Dieu merci, c'est pas important pour toi. Et pourtant, tu en parles avec une telle conviction qu'on pourrait croire qu'il y a une importance personnelle pour toi.
(Je suis de très près mon tableau de bord)
Encore une preuve que tu t'en fout complétement du karma.
Depuis le temps que je dis que la licence BSD est justement de permettre de faire du propriétaire.
Donc je le refait, :
"si Sony veut faire des drivers proprios, ils peuvent le faire sans souci sur un noyau linux sous GPL 2, vu qu'ils le font déjà pour android sur leur téléphones experia"
Donc la valeur de prendre le noyau FreeBSD ne saute pas directement aux yeux au niveau de la licence.
Mais j'ai remarqué que tu ne lis pas ce que j'écris, d'où ma conclusion que ton but est de m'inciter à écrire pour me moinser…
(J'ai constaté ça dans ma dépêche).
Alors sachant que :
tu te fous du karma
tu ne sais pas qui clique sur quoi
tu n'as aucun moyen de le savoir ( donc tes affirmations sont au mieux de la vantardise, au pire de la paranoia)
ton karma est déjà à la ramasse,
Je vois ni le rapport, ni même la moindre inférence lointainement logique entre les 2 affirmations, ni même de quoi corroborer la première ou la deuxième.
En rajoutant qu'il est plus que pénible de te lire, que la valeur ajouté des commentaires est proche de 0, que tu ressors toujours les mêmes théories fumeuses et simplistes qu'un gamin de 5 ans ( et d'ailleurs, vu qu'on te retire le droit de t'exprimer sur un journal, c'est comme si on avait décidé que tu n'était pas assez majeur pour voter ), je trouve que j'ai déjà bien que je lise une sous partie de tes commentaires. Tout le monde n'est pas en permanence de lire tout ce que tu dis, et vu tes productions passées, je suis globalement sur de rien loupé qui va changer ma vie.
J'ajouterais à ça que ça deviens usant à la longue de traiter avec un mec ayant un comportement bipolaire comme le tien. Tantôt, je suis la pour te moinser cf ce journal, cf https://linuxfr.org/nodes/98638/comments/1461557
Et puis plus loin, tu dis que je te coaches à nouveau.
Faut te mettre un truc dans le crane. Si tu as pas de point de karma, c'est uniquement ta faute. Et si selon toi, je te fait poster des commentaires pour que tu perdes du karma, c'est aussi ta faute. Poste moins des trucs inutiles, tu va pas en perdre, comme 99% des gens qui postent sur le site et qui n'ont aucun souci. Si tu es incapable de te retenir de poster des trucs inutiles, c'est pas la faute des autres. C'est ton manque de volonté qui fait que tu peux pas te retenir.
Et tu sembles louper le point principal, à savoir que si Sony veut faire des drivers proprios, ils peuvent. Tout les OEMs android le font, nvidia le fait, AMD le fait. Donc Sony peut aussi le faire. Et il y a assez de softs en BSD pour faire un userspace minimaliste suffisant pour une console, sachant que toute la valeur ajouté va être ailleurs que dans les fonctions déjà existantes comme l’accès à des partages CIFS ou ce genre de choses.
Un ami bossant sur des drivers X m'avait dit que les specs donné par AMD ne donne pas tout, notamment la partie décodage de vidéo pour divers raisons de DRM, vis à vis du décodage hardware, de la vérification de la chaine de confiance pour HDMI, etc.
Et il m'avait aussi dit que les cartes nvidia sont obscurcis au niveau hardware pour bloquer le reverse engineering des puces.
Ceci dit, c'est bien le style de kadalka. Des … (enfin des …), des affirmations non vérifiés, des liens avec des boites qui n'ont rien à faire la (wtf sur le rapport avec intel), et le seul truc pertinent, c'est presque du hasard, à savoir la license de grub.
Sony n'ayant sans doute pas envie de filer un truc en GPL, en V3 de surcroit, c'est en effet surprenant. Mais la réponse est pourtant facile à deviner quand on cherche des articles plus en profondeur :
http://www.extremetech.com/gaming/159476-ps4-runs-orbis-os-a-modified-version-of-freebsd-thats-similar-to-linux
En lisant, on voit que ça serait des screenshots leakés du kit de développement. À partir de la, si on est à fond dans le milieu, on sait qu'une bonne part des demos faites à l'E3 sont faites sur un PC boosté en ram/GPU (merci Nolife) pour divers raisons comme "on file pas des prototypes aux éditeurs pour filer sur un salon" et ce genre de choses. On voit aussi que le matos de la ps4, c'est rien de magique (en tout cas, ça me fait moins rêvé d'avoir un cpu x86_64 qu'autre chose)
Donc on peut supposer, au vue du cadrage des captures d'écrans (et en supposant que ça soit vrai) qu'il s'agit juste d'un pc (certes de courses). Sinon, quelqu'un aurait pris la console, même ouverte, pour faire plus véridique. Parfois, on lit plus dans ce qu'on ne voit pas que dans ce qu'on voit.
Je trouve plutôt dommage de devoir se passer de SELinux (surtout sur un Hyperviseur).
Surtout que si c'est juste un ou deux domaines qui posent souci, tu peux les mettre en unconfined le temps de corriger la policy (cf http://danwalsh.livejournal.com/42394.html en provenance du blog de Dan Walsh)
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 5.
Ah ah ah. Arrête de parler de ce que tu ne connais pas. Y a autant de salles de réunions dans les bureau du bureau français de RH que de salariés de Hupstream dans le monde ( soit 6 personnes, voir 7 ), pour te donner une idée des écarts de moyens entre les 2.
[^] # Re: « Vivent les Logiciels Privateurs ! »
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 4.
Si tu fait abstraction du fait que le paquet openssl active le support des courbes elliptiques (ECDSA) ( https://bugzilla.redhat.com/show_bug.cgi?id=319901 ) alors que c'est une fonctionnalité jugé problématique du point de vue des brevets logiciels.
[^] # Re: Java Web Start le fait déjà
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 2.
Canonical n'a pas la même R&D que Apple, et ne peux pas se permettre de devoir faire ses propres drivers si jamais il y a besoin. Bien que Canonical contribues upstream ( sur pulseaudio, twisted, mailman pour ne citer que 3 exemples ), le kernel n'est pas dans la liste. Donc sauf à imaginer que Canonical recrute beaucoup de codeurs kernels, ils sont dépendant du travail des autres pour les couches basses.
Et puis le support des pilotes proprios, c'est pas encore ça. Si Canonical part sur mir, c'est aussi pour aller à coté des kernels android, pour simplifier la vie des OEMs pour les téléphones. Passer sur BSD ferait perdre tout ça.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 4.
avec les scripts bash, tu as pas besoin d'attendre que ça pete pour être déjà en train d'avoir des emmerdes. Les scripts de 50 lignes pour charger ton service, ça n'a rien de simple ( et encore, je parle pas des horreurs que j'ai vu par des OEMs sur HP-UX, car la production, c'est ça aussi, des vieux trucs moisis ). Gérer des merdes comme bind ( avec rdnc et le fait de devoir faire un sleep parce que tu peux pas savoir de façon race-free que bind est vraiment arrêter ), ça n'a rien de simple.
je peux comprendre que c'est familier, que c'est rassurant, que systemd force à apprendre des nouveaux trucs, voir qu'il y a des nouveaux bugs, mais le système d'init en bash n'a rien de simple. Il est pauvre en fonction, il est lent, il requiert de connaitre un langage de merde qui n'a rien de prévu pour faire du développement sérieux, et un langage des plus non intuitif sur des points comme le calcul décimal, les sockets ( via /dev/tcp ), etc.
ben faut croire que windows réponds aux besoins des clients de microsoft. Les OEMs ont la certifs, des drivers, et ont l'argument de vente d'avoir une logithèque énorme. Et les clients des OEMs ont pareil, l'accès à la logithèque.
Si la plupart des gens voulaient vraiment du Linux, quelqu'un le proposerait et se ferait des couilles en or. C'est pas faute d'avoir tenté plus d'une fois ( mndrake, suse, RH, lycrosi, corel linux, mint, Ubuntu, entre autres ), et d'avoir à chaque fois fait un pétard mouillé.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 3.
c'est libre.
Canonical pense que pour gagner des parts de marché, il faut faire preuve d'agilité et de vitesse. C'est une position comme une autre, ç'est pas déconnant. Ensuite, le souci, c'est que ça implique plusieurs choses :
- des hacks parfois court termes plus que des corrections propres long termes. par exemple, qui se souviens de la controverse autour de xsplash et plymouth.
- ne pas hésiter à refaire tout de 0 si besoin. Il suffit de voir justement l'histoire d'unity, ou les bases sont passés de gtk à qt à compiz ( ou dans un autre ordre ).
- ne pas hésiter à corriger rapidement sur sa distro que de négocier avec upstream. un exemple d'école, c'est android et le kernel, genre les waveocks. Dans le même genre, ubuntu à tendance à patcher pour le support des indicateurs, et tout le monde ne voit pas d'un bon oeil que de rajouter des patchs pour ça un peu partout.
Et on pourrait laisser le bénéfice du doute à Canonical, mais c'est exactement pour ça que Unity est dispo officiellement dans quasiment aucune distro autre que downstream de ubuntu. Debian n'a pas le paquet, la communauté Fedora a tenté 2 fois de l'avoir, etc.
on va pas reprocher à Canonical de foncer, de coder. Ou du moins, moi, je reproche pas ça. Au contraire, qu'ils foncent, qu'ils arrivent à gagner du pognon et à devenir une boite à l'équilibre, pour le bien du libre et de ses salariés.
Par contre, faire ça et se vanter de "bosser upstream" (cf blog de Jono bacon : http://www.jonobacon.org/2010/07/30/red-hat-canonical-and-gnome-contributions/ ou il liste tout les softs 'upstreams' qui tourne que sur Unity et qu'ils ont commencés ) et de "consulter la communauté", et de "bosser de maniére ouverte" alors qu'il y a des trucs fait en secret.
Encore une fois, y a rien de mal à tout ça. Si Canonical pense que c'est valable pour faire vivre la boite, parfait, j'ai pas les infos pour juger (autre que "pour le moment, ça marche pas"). Mais c'est le contraste entre ce qu'ils disent et ce qu'ils font en pratique qui énervent une part des gens qui expriment des critiques sur Canonical.
[^] # Re: De l'influence de l'employeur.
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 4.
Foutaises.
Facebook paye le développeur principal de mercurial pour bosser sur mercurial à temps plein. Et va bientôt en payer un 2eme.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 5.
Je doute que ton besoin soit stricto sensu "je doit lancer ça dans rc.local". Mais "je doit lancer ça au démarrage". Donc je pense que faire une unité systemd devrait marcher. Quand à dire "il se vautre la dessus", sans plus d'info, c'est difficile de voir si c'est un bug ou une erreur de ta part ( et ça peut être les 2, une doc pas assez claire qui fait que tu fait une erreur parce que ça réagit pas comme tu crois ).
Si le souci est que tu lances une tache longue et que systemd tues la tache, je pense qu'une unité de type "oneshot" est exactement ce que tu veux. Mais sur ma machine, c'est déjà comme ça que rc.local est lancé (et sans timeout). Peut être que le souci, c'est d'être isolé de façon plus drastique qu'avant, c'est difficile de t'aider sans plus d'info.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 7.
Non, pas vraiment. Prends un script d'init bsd et mets le sur un linux, qu'on regarde comment ça marche bien. C'est pas parce que tu peux faire un script qui va marcher partout que tout les scripts marchent partout, ni même que l'intégration soit correct. Si tu veux suivre les coutumes locales, la config du script va aller dans /etc/default pour debian et consorts, et /etc/sysconfig pour RH et dérivé, et ailleurs pour suse, sauf erreur de ma part. Ou les BSD et arch.
Donc permet moi de dire que tu surestimes la portabilité, et que tu sous estimes le travail des packageurs à ce niveau. ( et l'imagination dont font preuves certains upstreams pour faire des trucs chiants à lancer correctement )
/sbin/init fait plus que ça. Il se charge aussi de tuer les process zombies qui se rattache à lui, de relancer si tu demandes ( respawn ), il gère les touches ctrl alt del, il gère le fait d'avoir courant coupé (via l'action powerwait, powerfail et consort ).
Je veux bien croire que les gens veulent un init minimal, mais ça fait des années que /sbin/init n'est pas aussi minimal et fait des trucs qui ne le regarde pas ( exemple, powerwait, powerfail ) , et bien sur, personne n'a jamais rien dit ni trouver ça anormal. ( et je parle pas de "refaire sa propre implémentation d'un système de message" via un pipe dans /dev, ce qui n'a rien à faire la d'après la FHS, sauf si ça rentre dans "special file" et ça me semble être vraiment tirer par les cheveux comme raison, car "un pipe pour communiquer avec l'userspace", ça n'a rien de spécial ).
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 7.
en pratique, il va dépendre des bugs dans le kernel, dans le bios, et dans la libc. Et des bugs dans les compilos, bien sur. Soit une somme de code bien plus importante que tout ce que systemd va tirer.
[^] # Re: Miam
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 4.
Pas vraiment. quand tu sais que pour exploiter une race condition, il faut faire parfois des tas d'essais, ou parfois pour contourner les canries, pour deviner une adresse, etc, les attaquants ont appris à faire ce qu'il faut, à savoir, des boucles. Si tu rebootes tout les 6 minutes, ç'est pas forcément grave. Sur un téléphone, il faut sans doute moins de 6 minutes pour te faire appeler un numero surtaxé à l'étranger, rendant rentable la chose. Et sur un pc, bah, 6 minutes et ensuite, il reste plus de trace, ça me semble être un bon deal. Voir pire, utiliser chaque cpu pour attaquer les 2 autres pour rester en permanence.
Donc le schema n'a de sécurisé que le fait qu'il soit inhabituel et non courant. Et on peut dire autant de "mettre ton repertoire windows sur D:/win32", qui arrète (ou du moins à l'époque, il y a 10 ans) une bonne part des malwares qui hardcodent des chemins.
[^] # Re: Deux idées
Posté par Misc (site web personnel) . En réponse au journal [non-troll] Faire confiance à (N)S(A)ELinux ou aux *BSD ?. Évalué à 3.
ce projet, visiblement si. Ensuite, c'est un exemple que les gens connaissent.
ça fait du pattern matching sur les chaines, pour analyser le flux pour reconnaitre les applis, je pensais que ça rentrais dans analyse protocolaire. Ceci dit, à 1h du matin les détails de ce genre m'échappe parfois.
Et sinon, je pense que qosmo a un produit pour toi :)
# BSD et Confort.
Posté par Misc (site web personnel) . En réponse au journal [non-troll] Faire confiance à (N)S(A)ELinux ou aux *BSD ?. Évalué à 9.
Moi, je pense que tu devrais passer à du BSD.
Non pas parce que c'est plus sur, moins sur, ou la licence est meilleur ou pas. Ou parce que la NSA a envoyé un patch sur le kernel.
Non je pense que tu devrais car c'est important de connaitre plus qu'une distribution, plus qu'un système libre.
[^] # Re: Audit
Posté par Misc (site web personnel) . En réponse au journal [non-troll] Faire confiance à (N)S(A)ELinux ou aux *BSD ?. Évalué à 2.
Si tu cherches du code buggué sur du truc peu répandu, c'est tout chaud :
http://blog.azimuthsecurity.com/2013/06/attacking-crypto-phones-weaknesses-in.html
La pile zrtp en question est vachement utilisé, tu pourrais croire que c'est de la sécurité, ça a été relu, et visiblement, pas trop. Mais bon, à part ça, faut se méfier des LSMs bien sur :)
[^] # Re: Deux idées
Posté par Misc (site web personnel) . En réponse au journal [non-troll] Faire confiance à (N)S(A)ELinux ou aux *BSD ?. Évalué à 3.
En fait, selinux est un système de label et de permission. Chaque objet a son label ( stocké via xattr sur les fs, rien de spécial ), et un moteur de regle, avec un minimum d'optimisation pour pas faire ramer ( voir les détails sur https://www.imperialviolet.org/2009/07/14/selinux.html ). Donc ne pas l'utiliser pour éviter une backdoor, c'est revenir au système par défaut qui donne beaucoup plus de permissions et , et c'est comme dire que sans firewall, on est plus en sureté.
Retirer un firewall parce que ça fait chier, parce qu'on a pas le temps de le maintenir et que ça a un cout, pourquoi pas, ça se défend. Dire qu'on a pas besoin car il peut y avoir des failles dans le traitement des chaines( genre l7, le super truc qui fait de l'analyse protocolaire ), à la rigueur, mais c'est pas lié au concept de firewall lui même mais au code.
Par contre, j'ai vu personne dire "je retire le firewall car c'est plus sur, j'ai pas de risque de backdoor". Dire pareil de selinux, ça tiens plus du cargo cult qu'autre chose.
Sinon, oui le code de selinux a été audité par les gens de RH avant de l'intégrer ( comme tout ce qui est rajouté dans le kernel de RHEL ), et aussi par le même group de gens qui ont audités tout le reste du kernel sur la lklm ( surtout vu le selinux a mis du temps à rentrer ), et aussi par les gens de tresys.
Ensuite, quand on parle du code de selinux, c'est superbement imprécis. Est ce qu'on parle des LSMs, d'un LSM en particulier, du code en userspace, de la policy ?
Et prendre apparmor, je dirais qu'il y a pas la même couverture fonctionnelle, ni les mêmes fonctions. Le but, c'est pas de charger un LSM pour charger un LSM, mais de voir les menaces, les risques, les besoins tu as et quels solutions tu va déployer. Et pour un utilisateur, garder la solution choisi par le distributeur me semble logique, vu que la plupart dépende d'une politique de régles, soit c'est complet sur un LSMs, soit c'est grossièrement incomplet sur tout les LSMs. Donc le choix se fait plus au niveau de la distribution choisi qu'autre chose.
[^] # Re: La vraie question
Posté par Misc (site web personnel) . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 4.
On peut dire qu'en effet, j'ai une journée aussi chargé que d'habitude, mais c'est surtout répondre pendant que mes collègues anglophones sont en réunion qui me perturbe.
Pour en revenir au sujet, j'aurais quand même tendance à dire qu'on doit pas voir les entreprises comme des unités parfaitement uniformes, la communication passe en général lentement, donc les choix d'une partie de l'entreprise n'a aucune importance pour une autre partie de la boite, voir la même partie passé ou futur. Sauf à croire que le PDG s'engage fortement sur un produit et qu'il arrive à articuler sa vision tel que tout le monde le suit ( ou qu'il soit ultra autoritaire ), ça n'arrive jamais, surtout pour un conglomérat de la taille de Sony.
Chaque sous groupe a sa propre autonomie, et à l'intérieur, chaque département, chaque équipe, etc, peut faire ses choix technologiques. Donc l'impact est bon pour Freebsd, mais je pense que Freebsd n'avait pas vraiment un grand besoin de crédibilité, étant déjà une solution crédible pour ça, et que ça va pas impacter la popularité de Linux, qui est déjà aussi une solution crédible depuis des années.
[^] # Re: La vraie question
Posté par Misc (site web personnel) . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 5.
Si les mecs pensaient que Sony aller mettre Windows sur sa nouvelle console en étant en concurrence contre Microsoft, je pense qu'ils ont d'autres soucis. Comme par exemple le fait d'avoir des idées à la con.
[^] # Re: La vraie question
Posté par Misc (site web personnel) . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 2.
Je croise plus souvent du Debian en entreprise que du Fedora ceci dit. Debian est vu comme étant pour serveur, ou comme base pour faire une distribution personnalisé, alors que Fedora est vu comme étant pour les hobbyistes, et pour les postes de travail. Ensuite, je pense qu'il y a avec l'arrivée du cloud et de ce que ça implique ( à savoir des machines jetables, du bétail contrairement à des serveurs plus classiques qui sont des animaux de compagnies, pour reprendre l'image d'un admin du CERN ), les choses peuvent changer.
Ben surtout que personne ne dit "je garantit" sur un produit ou il n'a pas la main.
RH garantit RHEL car c'est contractuellement faisable. Par exemple, Debian ne s'est jamais fatigué à faire les démarches pour l'exportation au niveau de la cryptographie avec le département d'état américain. Bien que le risque de souci soit faible voir nulle, et qu'on s'en fout franchement (au contraire des brevets, ou les risques sont plus gros), je pense qu'il y a des cas ou ça compte. Debian ne se fait pas certifié FIPS, trop cher, trop long. Pareil, il y a des cas ou ça compte. Ou PCI-DSS, ce genre de choses. Des histoires de régulations, y en a dans plein de secteurs, les assurances, les hopitaux et la santé, etc.
Ça semble ridicule pour un particulier ou même pour une PME. Pour une grande entreprise, c'est plus compliqué.
Des trucs tout con comme "j'ai besoin d'avoir des cours sur la technologie pour former les 50 admins", faut avoir déjà une grosse boite pour mettre ça en place. Etc, etc.
C'est pas que Debian soit mauvais ou RHEL meilleur, c'est que RH a mis en place que ce que les clients veulent pour pas perdre de temps sur des détails.
Et que RH a la main d'oeuvre pour faire de la revue de code, pour tout les trucs chiants qu'on a tendance à ne pas voir. Avoir des consultants disponibles, du support.
Et c'est bien parce que Debian et Fedora sont des communautés qu'il y a des produits forkés pour les entreprises ( en l'occurrence, RHEL et Ubuntu ), parce que personne saint d'esprit ne peut donner le même niveau de garantie sur Debian qu'il pourrait donner sur un produit séparé qu'il contrôle.
[^] # Re: La vraie question
Posté par Misc (site web personnel) . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 4.
des preuves ? (non "ça existe partout, j'ai pas besoin de le prouver" ou variation comme "j'ai déjà expliqué ailleurs", c'est pas une preuve, et se citer soi même quand tout le monde demande plus d'info, c'est juste n'importe quoi )
Cool story bro, et le rapport avec Linuxfr ? Quelqu'un t'a menacé physiquement ?
Parce que je cite toi même aujourd'hui ailleurs sur la page :
Si tu compares les gens qui discutent avec toi à des gangs de LA et que tu compares le fait de te faire contredire au fait de risquer ta vie, permet moi de te dire que tu es totalement hors sujet.
donc les gens qui viennent sur linuxfr en dehors de la personne normale, c'est quoi, des personnes anormales ? Tu te rends pas compte que tu es insultant dans ta façon de présenter les choses ?
Ah oui, tout ces gens qui seront mis au ban par l'élite linuxfrienne qui a droit de vie ou de mort sur tout le web, capable d'un coup de souris de forcer l'usage des fourches caudines de la censure sur le pauvre innocent, qui du coup va … perdre un point de karma, un truc dont il n'avait aucun idée avant de venir ici, qui ne sert à rien à part monter ou pas e commentaire pour une sous partie des quelques utilisateurs du site. Oui, c'est totalement comparable avec les gangs à LA. Risquer sa vie dans une fusillade, perdre un point de karma en disant des trucs, exactement la même chose.
Dieu merci, c'est pas important pour toi. Et pourtant, tu en parles avec une telle conviction qu'on pourrait croire qu'il y a une importance personnelle pour toi.
Encore une preuve que tu t'en fout complétement du karma.
[^] # Re: Pourquoi parler d'intel ...
Posté par Misc (site web personnel) . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 8.
Donc je le refait, :
"si Sony veut faire des drivers proprios, ils peuvent le faire sans souci sur un noyau linux sous GPL 2, vu qu'ils le font déjà pour android sur leur téléphones experia"
Donc la valeur de prendre le noyau FreeBSD ne saute pas directement aux yeux au niveau de la licence.
Alors sachant que :
Je vois ni le rapport, ni même la moindre inférence lointainement logique entre les 2 affirmations, ni même de quoi corroborer la première ou la deuxième.
En rajoutant qu'il est plus que pénible de te lire, que la valeur ajouté des commentaires est proche de 0, que tu ressors toujours les mêmes théories fumeuses et simplistes qu'un gamin de 5 ans ( et d'ailleurs, vu qu'on te retire le droit de t'exprimer sur un journal, c'est comme si on avait décidé que tu n'était pas assez majeur pour voter ), je trouve que j'ai déjà bien que je lise une sous partie de tes commentaires. Tout le monde n'est pas en permanence de lire tout ce que tu dis, et vu tes productions passées, je suis globalement sur de rien loupé qui va changer ma vie.
J'ajouterais à ça que ça deviens usant à la longue de traiter avec un mec ayant un comportement bipolaire comme le tien. Tantôt, je suis la pour te moinser cf ce journal, cf https://linuxfr.org/nodes/98638/comments/1461557
Tantôt je suis ton coach
https://linuxfr.org/nodes/98837/comments/1464851
Et puis ensuite, tu part dans des délires de paranoïas ou j'aurais des soucis avec toi :
https://linuxfr.org/nodes/98718/comments/1462821
Et puis plus loin, tu dis que je te coaches à nouveau.
Faut te mettre un truc dans le crane. Si tu as pas de point de karma, c'est uniquement ta faute. Et si selon toi, je te fait poster des commentaires pour que tu perdes du karma, c'est aussi ta faute. Poste moins des trucs inutiles, tu va pas en perdre, comme 99% des gens qui postent sur le site et qui n'ont aucun souci. Si tu es incapable de te retenir de poster des trucs inutiles, c'est pas la faute des autres. C'est ton manque de volonté qui fait que tu peux pas te retenir.
[^] # Re: Pourquoi parler d'intel ...
Posté par Misc (site web personnel) . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 3.
Y a ça :
http://opensource.apple.com/release/mac-os-x-1083/
( tu noteras par exemple les sources de XNU, le kernel )
Et tu sembles louper le point principal, à savoir que si Sony veut faire des drivers proprios, ils peuvent. Tout les OEMs android le font, nvidia le fait, AMD le fait. Donc Sony peut aussi le faire. Et il y a assez de softs en BSD pour faire un userspace minimaliste suffisant pour une console, sachant que toute la valeur ajouté va être ailleurs que dans les fonctions déjà existantes comme l’accès à des partages CIFS ou ce genre de choses.
[^] # Re: Pourquoi parler d'intel ...
Posté par Misc (site web personnel) . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 3.
ah oui, alors qu'avec Linux, on peut pas, comme on le voit avec la profusion de drivers libres sur android.
[^] # Re: Pourquoi parler d'intel ...
Posté par Misc (site web personnel) . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 3.
Un ami bossant sur des drivers X m'avait dit que les specs donné par AMD ne donne pas tout, notamment la partie décodage de vidéo pour divers raisons de DRM, vis à vis du décodage hardware, de la vérification de la chaine de confiance pour HDMI, etc.
Et il m'avait aussi dit que les cartes nvidia sont obscurcis au niveau hardware pour bloquer le reverse engineering des puces.
[^] # Re: La vraie question
Posté par Misc (site web personnel) . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 3.
Ensuite se pose la question de :
- qui veut la place de kadalka
ou
- qui se sent menacé par les commentaires de kadalka sur linuxfr
Autant je pense que le 1 est une supposition risible, autant je suis sur que je vais me délecter des réponses de l'intéressé sur la 2eme partie.
[^] # Re: La vraie question
Posté par Misc (site web personnel) . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 10.
Je noterais que le journal est retombé à 11
Ceci dit, c'est bien le style de kadalka. Des … (enfin des …), des affirmations non vérifiés, des liens avec des boites qui n'ont rien à faire la (wtf sur le rapport avec intel), et le seul truc pertinent, c'est presque du hasard, à savoir la license de grub.
Sony n'ayant sans doute pas envie de filer un truc en GPL, en V3 de surcroit, c'est en effet surprenant. Mais la réponse est pourtant facile à deviner quand on cherche des articles plus en profondeur :
http://www.extremetech.com/gaming/159476-ps4-runs-orbis-os-a-modified-version-of-freebsd-thats-similar-to-linux
En lisant, on voit que ça serait des screenshots leakés du kit de développement. À partir de la, si on est à fond dans le milieu, on sait qu'une bonne part des demos faites à l'E3 sont faites sur un PC boosté en ram/GPU (merci Nolife) pour divers raisons comme "on file pas des prototypes aux éditeurs pour filer sur un salon" et ce genre de choses. On voit aussi que le matos de la ps4, c'est rien de magique (en tout cas, ça me fait moins rêvé d'avoir un cpu x86_64 qu'autre chose)
Donc on peut supposer, au vue du cadrage des captures d'écrans (et en supposant que ça soit vrai) qu'il s'agit juste d'un pc (certes de courses). Sinon, quelqu'un aurait pris la console, même ouverte, pour faire plus véridique. Parfois, on lit plus dans ce qu'on ne voit pas que dans ce qu'on voit.
[^] # Re: Mouais
Posté par Misc (site web personnel) . En réponse à la dépêche Disponibilité du dépôt Xen4CentOS. Évalué à 3.
Surtout que si c'est juste un ou deux domaines qui posent souci, tu peux les mettre en unconfined le temps de corriger la policy (cf http://danwalsh.livejournal.com/42394.html en provenance du blog de Dan Walsh)