Kevin Kofler (./7170) :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.
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?
Kevin Kofler (./7170) :Et une ville qui gaspille l'argent du contribuable pour acheter de la maintenance ? Peut-être que ça revenait plus cher, va savoir ?
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?
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.
&Can't believe I missed this quality addition from Vladis on the first read: https://t.co/PFjM8gABcM pic.twitter.com/Ac6blzeYCf
— grsecurity (@grsecurity) November 15, 2017
. 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;We backported this fix last month already, since we monitor upstream commits regardless of any stable or fixes tags (often they are missing, and there's separate handling for the net subsystem): https://t.co/LrhuS5oXe4
— grsecurity (@grsecurity) November 24, 2017
(et il n'y a rien à redire sur le fond, l'argumentation est technique);Then of course there was the claim from Kees earlier this year that "Hardened usercopy found bugs in grsecurity's slab implementation": https://t.co/k022ChuGA6 which the PaX Team thoroughly demolished pic.twitter.com/ibZSfFaZGi
— grsecurity (@grsecurity) November 24, 2017
) et à cause des copies buggées sus-mentionnées, si on les active, il y a apparemment moyen de bricker des ordinateurs:AMD/KVM still broken in 4.14.1, fix isn't queued up for 4.14.2 either. Tell me more Linus about how well the upstream kernels are tested!
— grsecurity (@grsecurity) November 22, 2017
/ https://twitter.com/grsecurity/status/933465734423961601 ;https://t.co/Y47TUxJupX My second paragraph couldn't have predicted this very situation any better, one year to the day: https://t.co/q90O9vxeGP 4.14 final release imminent, do they brick systems or admit I was right all along?
— grsecurity (@grsecurity) November 11, 2017
Kevin Kofler (./7167) :et au-delà des accusations gratuites, limites diffamatoires, as-tu des éléments concrets à opposer ?
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.
Nil (./7184) :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.
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...
Lionel Debroux (./7185) :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.
Je suis tout à fait d'accord que Linux survivrait au passage d'Android vers un autre kernel.
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.
À 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.
Lionel Debroux (./7188) :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.
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.
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.
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.
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é.
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.
Only two [red]remote[/red] holes in the default install, in a heck of a long time!