Pinaraf a écrit 3671 commentaires

Nan, à mon avis ils ont pas été assez intelligents.

J'avais du écrire un programme python pour choisir la façon de m'abonner. J'en étais arrivé à deux abonnements : GLMF + MISC + MISC HS et Open Silicium. Ils ont pas du s'en rendre compte.

Mais je pense qu'ils avaient essayé, c'est indiqué dans leur courrier...

Je partage ce point de vue, c'est tout simplement inimaginable de la part de Linux Magazine.

Jean-Pierre Troll, revient !!

Tant mieux tu veux dire ?

(Sous linux, optimus fait juste perdre de la batterie par rapport à uniquement du nvidia, en effet la carte nvidia est alors activée tout le temps, donc nvidia+intel > nvidia.
nvidia devrait peut-être se débrouiller pour avoir un mode basse consommation au même niveau que la carte intel, ça éviterait de se trimballer 2 cartes graphiques! En plus, ils doivent savoir le faire maintenant, avec leurs travaux sur Tegra.)

Tu penses que c'est un choix de nVidia ?
Intel impose son GPU dans ses processeurs, nVidia n'a pas le choix, il va y avoir deux GPU dans chaque machine, ou pas de GPU nVidia...

1) Les pilotes sont disponibles maintenant (et ce depuis fin 2009)

2) Ils avaient a priori des raisons techniques pour cela, et les ont listées : http://wiki.freebsd.org/NvidiaFeatureRequests

"Cliquez ici pour tirer à pile ou face et risquer d'endommager définitivement votre matériel"

Ouais, ça aurait de la gueule comme option.

Microsoft fait ça pour augmenter la compatibilité avec les pilotes apparemment...

De toute façon, plus de 3Go de ram sur une machine 32 bits, c'est souvent un mauvais calcul...

Ça touche beaucoup de laptop ça?

A priori, beaucoup beaucoup... (plus de 75%)
Ça touche également de nombreuses machines de bureau. Un bon correctif serait que les fabricants corrigent leurs BIOS. Gigabyte a déclaré à propos de ce bug "ben, utilisez windows"... Donc c'est mal barré.

Sinon ça touche que les noyaux récents parce qu'avant ils activaient l'ASPM comme des brutes, ce qui était dangereux et plantogène sur certaines machines...

Les noyaux récents souffrent d'un "bug" : ils font l'inimaginable, ils essayent de respecter la norme ASPM (gestion de l'énergie en PCI : extinction des périphériques PCI pour économiser de l'énergie).
Donc quand le BIOS dit "Il n'y a pas d'ASPM ici", Linux dit "ha, zut, tant pis alors". Or, sous windows, on ne sait pas comment c'est déterminé... En tout cas pas comme ça.
Résultat : la majorité des machines récentes ont un bios qui dit "Il n'y a pas d'ASPM ici", et donc Linux, par sécurité (cela pourrait endommager le matériel) le désactive.

Contournement 1 : ajouter au boot l'option pcie_aspm=force
Contournement 2 : faire du reverse engineering de cette partie de windows et faire les modifs requises pour Linux.

Et donc il a payé une certaine somme pour windows pour rien finalement.

Il l'a pris, il a tout compris...

Quand au "secure boot", c'est aussi du BS marketing. Prèsque aucun malware ne modifie le fichier de démarrage de l'OS. L'objectif est uniquement de rendre plus difficile l'ajout de pilotes non signés pour les gens qui veulent contourner les DRM.

Là par contre secure boot me semble répondre à un vrai problème, en tout cas sur la plateforme windows : comment lutter contre un rootkit qui va s'insérer au niveau du noyau, via un pilote ? (Réponse : en obligeant la signature du pilote... mais justement, pour contourner cette obligation de signature, les rootkit peuvent s'insérer "sous" le noyau via les technos de virtualisation par exemple)

Après, on peut douter de l'efficacité de la protection quand on voit que des rootkits ont été diffusés avec un pilote signé... Hé oui, les failles des autorités de confiance SSL, c'est mignon... mais on a le même genre de faille dans toute chaîne de confiance, et quand un constructeur de matériel (c'était realtek) se fait compromettre sa clé... Toute la sécurité du système s'en trouve compromise finalement.

T'as jamais eu de conflits avec le plug and play ?
Perso je considère qu'il faut prier pour que ça marche dans tous les cas, parce que quand ça foire, c'est devenu très difficile à corriger.

Ou on rédige à minuit avec des gens qui vous emmerde sur jabber…
Et pour mutualiser la réponse : merci pour les corrections sur GPT et le BIOS, c'est effectivement un argument très répandu, mais je ne le savais pas aussi faux…

Non, vu qu'avec Secure boot, tu pourrais même pas lancer le shell EFI, à moins d'avoir un shell EFI signé avec une clé présente dans ton EFI…

Merci pour la correction sur les interruptions.
La "laideur" du bios, c'est le fait qu'il n'ait jamais ete documente/normalise et donc que personne ne soit sur a 100% qu'une appli soit un bios fonctionnel ou non.
Apres, les solutions pour le boot sur cd notamment sont rarement elegantes... PAr exemple il y a peu, je suis tombe sur un bios buggue utilisant par erreur l'emulation d'un lecteur de disquette pour la cle usb, rendant le boot impossible... Il a fallu triturer le bios pour le forcer a emuler un disque dur a la place...

P.S : desole pour les accents, le clavier qwerty du N950 ne les permet pas...

Hey, spoiler alert, comment je fais mon prochain journal maintenant ?

Coreboot peut utiliser tiano core… Un ensemble core boot + tiano core fait un firmware UEFI.

Quant au support de coreboot par AMD, on manque de nouvelles…

J'ai oublié deux points :

1) pourquoi je voulais faire ça
C'est simple : c'est un exercice intéressant pour découvrir les technologies qui nous sont imposées aujourd'hui, et je souhaitais voir si la couche d'émulation BIOS était à l'origine des problèmes de compatibilité de ma machine (pas d'ASPM, S3 qui plante…)
Malheureusement, c'est pas le cas.

2) microsoft et intel, je ne vous aime pas. Vous forcez la diffusion des technologies buggées, inutilement compliquées…

Passe à l'IPv6 et redirige les vers ::dead, c'est autrement plus amusant.

Pfff, tu veux argumenter comme ça ?
OpenSSL contrait cette faille avant la sortie de TLS 1.1. Et Konqueror utilise OpenSSL.
Après j'argumenterai pas sur le fait que c'est nul de la part de mozilla, vu que je le pense.

si tu as confiance dans ton réseau, point besoin de SSL!
Si, tu as besoin de SSL parce que tu communiques pas que avec ton réseau. Mais après tu dois faire confiance en ton FAI pour qu'il te fasse pas une attaque MITM.

Ouais, enfin... Trouve des sites n'utilisant pas TLS 1.0, c'est beaucoup plus dur...

Heu...

T'as pas compris.

Tu vas sur le site https://www.paysecam.com.
Mais à côté, dans un autre onglet corrompu, t'as un JS qui joue à envoyer des requêtes vers https://www.paysecam.com, lui aussi. Et paf le chien.
Et ça, c'est pas interdit.

La faille reste tout de même sévère.
Mais la dépêche n'est pas claire : il ne suffit pas d'insérer du texte, il faut injecter du JS qui soit exécuté et qui effectue une série de requêtes HTTPS vers la victime.
Et il faut aussi avoir un moyen pour écouter le traffic réseau.

Concrêtement, cette attaque réduit énormément la sécurité du HTTPS sur un réseau pas du tout sécurisé, genre un réseau wifi public. Mais heureusement, pas grand chose de plus...

L'utilisation de sepgsql permet des choses assez rigolotes, comme indiqué dans la documentation http://www.postgresql.org/docs/9.1/static/sepgsql.html

Dans l'exemple, une table contient des numéros de carte bleue. Et seules les procédures avec un label SELinux adéquat peuvent accéder aux données…
Après ce support n'est pas encore complet, la granularité ne se fait pas encore au niveau des enregistrements dans les tables… mais ça ne saurait tarder :)