Une ville gaspille l'argent du contribuable pour acheter des licences Microsoft dont elle se passait très bien pendant plus d'une décennie (depuis 2003), et vous vous en foutez? Parce que ce n'est pas votre ville?
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
je suis sûr que le maire a accepté parce que cromosift a dit qu'ils allaient financer des trams dopés.
Kevin Kofler (./7170) :
Une ville gaspille l'argent du contribuable pour acheter des licences Microsoft dont elle se passait très bien pendant plus d'une décennie (depuis 2003), et vous vous en foutez? Parce que ce n'est pas votre ville?
En effet, si tu doit te soucier de toutes les décisions des services achat de toute les villes qui ne sont pas la tienne tu es bon pour faire ça non stop pour le reste de ta vie.

En l’occurrence ceci dit, ce cas est intéressant car ça a montré que Microsoft a pris très au sérieux la menace que représentait Linux / LibreOffice pour son business. Et qu'il a carrément mis les moyens pour entretenir son quasi monopole sur le domaine de la bureautique. Il faut voir qu'au delà de l'aspect Libre/Commercial, l'informatique est un domaine ou les problèmes de compatibilité et les habitudes des utilisateurs font que les solutions logicielles ont une énorme force d’inertie et Microsoft a très bien su jouer la dessus.
avatar
Kevin Kofler (./7170) :
Une ville gaspille l'argent du contribuable pour acheter des licences Microsoft dont elle se passait très bien pendant plus d'une décennie (depuis 2003), et vous vous en foutez? Parce que ce n'est pas votre ville?
Et une ville qui gaspille l'argent du contribuable pour acheter de la maintenance ? Peut-être que ça revenait plus cher, va savoir ?
Nouveau maire fanatique de (ou payé par?) Microsoft. Ça pue la corruption en effet.
Peut-être que l'ancien maire était un fanatique de (ou payé par?) les distributeurs de sa... distribution. Ça puait la corruption en effet.
Quelques infos sur la sécurité et la qualité de Linux, par quelqu'un dont le style est abrasif, mais qui sait vraiment de quoi il parle:

* le backport des fixes de sécurité vers les kernels LTS par mainline est très partiel, spender le fait beaucoup plus à fond et plus rapidement: (thread) & . La durée du LTS sur les (certains ?) kernels LTS à partir de 4.4 est récemment passée à 6 ans, mais en l'état actuel des choses, l'effet sera partiel;

* la copie de versions obsolètes de features de PaX/grsecurity vers mainline par le KSPP ajoute des bugs, un bon exemple est détaillé à (et il n'y a rien à redire sur le fond, l'argumentation est technique);

* sur le kernel 4.14 LTS standard, KVM ne fonctionne plus bien sur les processeurs AMD ( ) et à cause des copies buggées sus-mentionnées, si on les active, il y a apparemment moyen de bricker des ordinateurs: / https://twitter.com/grsecurity/status/933465734423961601 ;

* spender en a vraiment marre de prendre les critiques pour l'incompétence de Linus et du KSPP, qui, en plus de mal copier et de mal faire évoluer les copies buggées, refusent certaines des protections les plus utiles (MEMORY_UDEREF & KERNEXEC parce que "le hardware le fait", ce qui est faux, surtout sur le matériel obsolète encore bien présent; MPROTECT; etc.) et passent beaucoup de temps sur, ou s'intéressent à, des "protections" sans intérêt (KASLR n'apporte rien quand il y a quantité d'infoleaks, un des derniers connus en date étant https://twitter.com/ProjectZeroBugs/status/934079561125519360 ) ou coûteuses et d'intérêt limité (KAISER en ce moment, là aussi moins utile à cause de tous les infoleaks).

Alors non seulement spender, et j'imagine PaXTeam, n'a / n'ont plus du tout envie d'essayer de travailler à l'amélioration du kernel standard avec Google (principal support de KSPP, qui n'essaie pas de coopérer correctement avec eux, et leur casse à tort du sucre sur le dos, cf. mon deuxième point plus haut), mais de plus, il vient de se remettre à publier des 0-days, et il a bien raison smile
S'il peut le faire pendant suffisamment longtemps (pas par manque de possibilités - je n'ai aucun doute sur le fait qu'il puisse en produire des tonnes - mais par manque de temps et/ou de sous), ça fera probablement bouger des choses... mais pour l'instant, on voit surtout les connards qui ne connaissent rien, s'arrêtent à la forme des interventions de spender en oubliant le fond qui a pourtant beaucoup de sens, pardonnent à Linus des écarts de langage qui ne sont pas tolérés dans certains cercles et qui renforcent l'impression d'hostilité que dégage le développement du kernel Linux (même si, fait rarissime, il a posté un "sorry" récemment après un de ses posts) et ne savent que critiquer, et les trolls qui postent des menaces physiques ( https://twitter.com/grsecurity/status/933864650327887879 ).

En persistant dans cette direction, le trou entre Windows 10+ et Linux en termes de travail sur le durcissement et les mitigations (pour rendre plus difficile l'exploitation et limiter l'impact des bugs embarrassants qui continuent à être découverts en permanence sur tous les OS d'usage général dans du code plus ou moins vieux) va continuer à s'élargir...
Par exemple, MS a commencé à mettre une forme de CFI, même si elle n'est pas aussi puissante que RAP de PaX; une forme convenable de CFI n'existe tout simplement pas dans les GCC publiés, si je me souviens bien, et presque personne n'utilise Clang (qui a une forme de CFI, là aussi moins puissante que RAP) pour compiler un Linux standard. Android, en revanche, passe à Clang: https://twitter.com/CopperheadOS/status/933682010932965376 .

Ca sera amusant de voir si, et le cas échéant quand, Google abandonnera Linux comme kernel d'Android smile
Ne pas corriger les problèmes de Linux, et même le dégrader de façon mesurable, est d'ailleurs une des façons de parvenir à renforcer la base technique et rationnelle pour prendre une telle décision à moyen terme...
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Tu défends un connard qui a rendu son fork du noyau payant et non-redistribuable, essayant ainsi de contourner la GPL par un contrat supplémentaire (c'est bien pour ça que le KSPP ne peut pas intégrer la version la plus récente au noyau), qui dévoile des trous de sécurité de manière non coopérative et met donc à risque des millions d'utilisateurs et qui en plus est verbalement abrasif. roll
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
Kevin Kofler (./7167) :
C'était déjà prévu depuis quelques mois, hélas. Nouveau maire fanatique de (ou payé par?) Microsoft. Ça pue la corruption en effet.
et au-delà des accusations gratuites, limites diffamatoires, as-tu des éléments concrets à opposer ?
avatar<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant
LIonel: et ils utiliseraient quoi? FreeBSD?
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
epee Cela dit, ils sont tout à fait capable de forker définitivement Linux.
avatar<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant
Non, les BSDs ne sont pas bons en mitigation non plus. Il est plus probable qu'ils pensent davantage à Fuchsia: https://en.wikipedia.org/wiki/Google_Fuchsia .
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
tiens, intéressant comme projet. Par contre, ça fait beaucoup de langages d'après wikipedia ( C, C++, Dart, Go, Rust, Python, Swift, avec des domaines qui se recouvrent largement).
avatar<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant
C'est vrai, ça fait beaucoup de langages, dont un (Dart) rare hors de Google... même si comme ils ne sont habituellement pas idiots, on pourrait s'attendre à ce qu'ils les utilisent à bon escient.

Si les principales APIs utiles sont accessibles directement à travers plusieurs langages de programmation répandus (je n'ai pas regardé), ça va aider à la popularité de l'OS. Tout comme l'ensemble de licences utilisées [EDIT: +qui] est beaucoup plus permissif que la licence de Linux et GCC... qu'on aime ou pas cet état de fait, la GPL est de plus en plus considérée comme un frein.

Si Google passe à Fuchsia, Linux perdra à terme ce qui est de très loin son principal déploiement dans le monde réel... et son futur à long terme sera moins brillant, surtout si les vendeurs de Linux ne bougent pas très sérieusement et rapidement leurs fesses pour améliorer la sécurité du kernel et du user-space.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Je vois mal Google switcher d'OS du jour au lendemain. Y'a une quantité énorme d'applis Android qui existent, et même si ce n'est pas impossible de les faire tourner sur un autre OS, ça ne se fait pas en un claquement de doigts.

Par ailleurs Linux existait bien avant Android, donc même s'il perd le "soutien" de Google, il y survivra.
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
Hmmmm il me semble que taper directemetn dans le kernel n'est pas autorisé pour des appli android, mais je ne suis pas expert je peux me tromper
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Autant je suis d'accord que Linux peut très bien vivre sans Android, autant je pense que Google a les moyens de changer d'OS facilement, et ce pour deux raisons :
- Certains applications Android peuvent déjà fonctionner sur ChromeOS
- Fuchsia devrait être capable d'accueillir des applis Android recompilées avec peu de modifications (en fonction du type d'appli et du langage utilisé)
Enfin, la durée de vie des applications est assez fugace ; à mon avis, c'est typiquement le genre de migration qui peut se faire sur deux ans de façon quasi transparente. Il suffit de voir qu'il y avait une logithèque conséquente pour Symbian, et que les gens ont tout laissé tomber du jour au lendemain pour Android...
avatar
Je suis tout à fait d'accord que Linux survivrait au passage d'Android vers un autre kernel. Cependant, un tel événement n'aiderait certainement pas Linux, d'où ma formulation "moins brillant" smile

Je connais également mal la programmation Android, mais pour autant que je sache, les applications écrites en langages de plus haut niveau sont très largement majoritaires.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Nil (./7184) :
Il suffit de voir qu'il y avait une logithèque conséquente pour Symbian, et que les gens ont tout laissé tomber du jour au lendemain pour Android...
Pas convaincu. Android (et iOS) ont amené énormément de nouveaux utilisateurs, qui n'avaient pas de smartphone avant. Leur poids a très rapidement éclipsé les alternatives préexistantes (Symbian, Windows CE/Phone, etc.), qui n'avaient comparativement que peu d'utilisateurs, par ailleurs plutôt technophiles (donc plus enclins à switcher). C'est une vraie rupture.

Avec Android, on n'est pas du tout dans la même situation. Il y a beaucoup plus d'applis, d'équipements existants et d'utilisateurs. Et ces derniers n'ont pas forcément envie de changer.
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
Changer de kernel peut être techniquement compliqué, mais c'est transparent pour l'utilisateur. Personnellement, je pense que je ne me rendrais pas compte si macOS passait à un autre noyau. On peut également citer Debian qui existe en version BSD et Hurd.

Lionel Debroux (./7185) :
Je suis tout à fait d'accord que Linux survivrait au passage d'Android vers un autre kernel.
Bof. À mon avis, beaucoup de projets industriels utilisent Linux parce que ça ne coûte rien et que beaucoup de choses fonctionnent. S'ils trouvent un concurrent avec moins de problèmes de licence, tout aussi gratuit, plus sécurisé et avec le support de Google, un certain nombre pourraient basculer.
avatar<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant
Personnellement, je pense que je ne me rendrais pas compte si macOS passait à un autre noyau. On peut également citer Debian qui existe en version BSD et Hurd.
Ou encore le Windows Subsystem for Linux de Win10, qui permet maintenant d'exécuter et de compiler un nombre significatif d'applis non graphiques, bien plus que dans les toutes premières versions où les limitations avec notamment les symlinks le rendaient difficilement utilisable.
Il faut que je regarde s'ils ont mis à jour leur niveau de syscalls, parce que le 3.10 avec lequel ils visaient à être compatibles au début date quand même beaucoup maintenant...

À mon avis, beaucoup de projets industriels utilisent Linux parce que ça ne coûte rien et que beaucoup de choses fonctionnent.
C'est là que malgré la force de développement de Google, le bât pourrait blesser pendant un moment, pour les industriels, avec tout autre projet que Linux: le jeu de drivers de Linux est inégalé. Pour pouvoir remplacer Linux, il faudra que quelqu'un se colle le "portage" d'une façon ou d'une autre... pour bien faire, à terme, ledit portage devrait plutôt être une réécriture, parce qu'une couche de compatibilité avec les APIs d'un autre kernel (comme ça se fait sur les BSDs et Haiku) ne résoudrait pas les problèmes de sécurité du code d'origine.

J'ai oublié de le mentionner plus haut dans la catégorie sécurité du kernel Linux, mais j'ai vu que de façon tout à fait prévisible, un fuzzer fait et tourné par des employés de Google est en train de massacrer les drivers USB de Linux pour divers matériels plus ou moins courants. Les autres kernels et drivers qu'ils fournissent (ou souvent pire, drivers fabricant, fréquents sous Windows) ne feraient pas mieux.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Lionel Debroux (./7188) :
Ou encore le Windows Subsystem for Linux de Win10, qui permet maintenant d'exécuter et de compiler un nombre significatif d'applis non graphiques, bien plus que dans les toutes premières versions où les limitations avec notamment les symlinks le rendaient difficilement utilisable.
Il paraît que les applications graphiques marchent aussi plus ou moins avec un serveur X tiers comme VcXsrv, mais que leur complexité puisse encore faire foirer le Windows Subsystem for Linux. C'est à peu près WINE à l'envers, avec le même genre de problèmes.

C'est là que malgré la force de développement de Google, le bât pourrait blesser pendant un moment, pour les industriels, avec tout autre projet que Linux: le jeu de drivers de Linux est inégalé. Pour pouvoir remplacer Linux, il faudra que quelqu'un se colle le "portage" d'une façon ou d'une autre... pour bien faire, à terme, ledit portage devrait plutôt être une réécriture, parce qu'une couche de compatibilité avec les APIs d'un autre kernel (comme ça se fait sur les BSDs et Haiku) ne résoudrait pas les problèmes de sécurité du code d'origine.
Euh si, si c'est une architecture microkernel (et Fuchsia l'est), les pilotes peuvent être sandboxés.

Cela dit, à mon avis, tu surestimes de loin l'importance que les utilisateurs réels donnent à la sécurité.
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
quand les arguments de sécurité tournent a la politique comme je le vois dans les tweets de grsecurity, je me dis que ces gens ne font pas de l'infosec mais du concours de bite.
C'est à peu près WINE à l'envers, avec le même genre de problèmes.
Vrai, mais avec énormément plus de force de développement disponible (à plein temps) chez MS que chez Codeweavers pour résoudre ledits problèmes. MS a un nombre énorme de développeurs internes pour avancer ses projets, et un cash fou pour en acheter davantage tout en leur fournissant de bonnes conditions matérielles et organisationnelles de travail quand ils veulent se développer sur certains axes - ils le font beaucoup ces derniers temps avec leur nouveau management beaucoup plus malin.

Cela dit, à mon avis, tu surestimes de loin l'importance que les utilisateurs réels donnent à la sécurité.
C'est un fait que sauf exception, les utilisateurs que nous sommes se foutent de la sécurité, préférant facilité d'utilisation / paresse (on peut rarement combiner sécurité et facilité d'utilisation), compatibilité et vitesse d'exécution. Ce en quoi nous ne sommes pas à blâmer, bien entendu - l'être humain est ainsi. Quand nous avons eu trop de gros problèmes (utilisation par des tiers des comptes bancaires, usurpation d'identité, etc.), ou que ça nous fait chier de devoir installer tous les mois les correctifs des bugs qui facilitent encore la survenue des plus gros problèmes (davantage que le social engineering et l'incompétence), nous nous mettons à s'en soucier un peu plus, même si ça n'est pas toujours facile à utiliser.
Mais en Europe et aux USA, Mirai et consorts ne sont pas passés inaperçus du législateur, même si ça prend du temps pour faire quelque chose. J'ai vu passer que des deux côtés de l'Atlantique, on commence à parler de réglementations obligeant les fabricants, en particulier de matériels IoT, à gérer leurs matériels à long terme. La prise de conscience que si on continue à faire l'informatique comme on a fait ces 30 dernières années, en traitant la sécurité comme une externalité, tout va exploser, a fait pas mal de chemin. Donc les utilisateurs ne vont pas directement se soucier de sécurité, les structures commerciales plus ou moins grosses s'en soucieront pour eux (partiellement en utilisant du code ouvert, d'ailleurs)... et pour faire une plaque plutôt étanche, c'est habituellement plus facile de partir d'une plaque trouée (ce que pourrait être Fuchsia, ou un de ses concurrents qui pourrait par exemple être issu de MS Research ou IBM research) plutôt que des grillages de la génération précédente: *BSD, Windows, Linux, MacOS X / iOS / tvOS.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Flan: oui ca existe deja, et c'est bien plus compatible qu'un kernel e zero: Free/Net/OpenBSD.

Lionel: pour l'USB ca n'a rien d'étonant, surtout quand on voir les choses comme les tests officiels pour savoir si ton periph/driver est fonctionel..

L'USB n'a rien de deterministe dans tout les sens, hardware comme software/


Quand a un "OS nouveau aui est une plaque troué mais qu'on peux faire mieux, mais pas avec les os existant" l'argument est bidon. Surtout avec une usine a gaz comme Fuchsia. Si on peux faire avec du code "neuf" qu'on ne maitrise qu'a moitié, on peux aussi le faire avec du code plus ancien, mais mieux maitrisé.
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
C'est quand même connu qu'il est difficile de sécuriser du code (non trivial) qui n'a pas été pensé pour la sécurité dès le départ.
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
oui ca existe deja, et c'est bien plus compatible qu'un kernel e zero: Free/Net/OpenBSD.
Pour la compatibilité, oui. Pour améliorer significativement la sécurité, les BSDs dérivés d'une base de code plus vieille que Linux et écrite dans le même langage difficile à sécuriser ne sont pas vraiment une meilleure solution que Linux. OpenBSD est considéré comme le moins mauvais, mais sa réputation de sécurité est largement usurpée: spender les défonce assez régulièrement pour ce qu'ils font mal ou peu utilement (W^X, pledge, KARL, etc.), ou encore, la première tentative de faire tourner (pas très longtemps) un fuzzer sur OpenBSD s'est soldée par une dizaine de bugs graves, dont un DoS complet du kernel par un utilisateur non privilégié.
L'ajout des fonctionnalités kernel permettant d'implémenter des mitigations user-space est nettement en retard sur les BSDs: il a fallu 6 ans à OpenBSD pour mettre quelque chose d'aussi faible qu'ASLR après que PaXTeam l'ait inventé (seulement 1 an pour Windows et Linux), 13 ans ou plus (!) aux autres BSD - et certains ne doivent même pas encore l'avoir. Idem pour le sandboxing basé sur les blacklists ou whitelists de syscall. Pour Linux, seccomp mode 2 est difficile à utiliser, probablement de granularité trop fine (alors que pledge est trop grossier), mais au moins, il existe.

Si on peux faire avec du code "neuf" qu'on ne maitrise qu'a moitié, on peux aussi le faire avec du code plus ancien, mais mieux maitrisé.
Nous sommes d'accord, on peut le faire en y passant suffisamment d'effort. Du code plus ancien mais mieux maîtrisé, c'est ce que PaX + grsecurity font depuis 16 ans. Et pour plusieurs raisons, pas toutes bonnes, même du temps où le patch était publiquement disponible, seule une faible minorité d'utilisateurs en tirait parti, et ils n'arrivaient pas à vivre de leur travail. Je ne sais même pas s'ils y arrivent maintenant.
Le problème, c'est qu'il semble qu'on ne va pas le faire, en ce qui concerne Linux. Le groupe des principaux mainteneurs du kernel est assez fermé et n'est pas compétent en sécurité, ceux qui travaillent sur le KSPP n'arrivent pas à rentrer les choses les plus utiles pour des raisons politiques et ne sont pas assez compétents pour rentrer correctement des choses moins invasives et de plus faible valeur de protection. Ca ne prend toujours pas le chemin de rendre beaucoup plus étanche le code utilisé par la majorité des utilisateurs de Linux, et sans un difficile changement complet des mentalités (et des personnes ?), ainsi que de gros investissements, ça n'en prendra "jamais" le chemin.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Zero: oui dépends de l'usine a gaz
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Lionel:

Only two [red]remote[/red] holes in the default install, in a heck of a long time!

Quand t'as les mains sur le clavier la machine est évidemment morte.
Un bug hardware des CPU Intel permettant une attaque sur des VMs a été découvert.

Le patch de sécurité mis en œuvre par les dévs Linux va faire ralentir tous les CPU Intel : http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table
#pointsqualyl#
avatar<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant
allez le quinte grin