Pinaraf a écrit 3674 commentaires

Super journal…

Standard ouvert, certes. Mais s'il faut taxer (cher, j'imagine) pour avoir sa clé et son certificat acceptés par la banque… Pas glop, pas glop… :-/

Tu as tout compris ! :/

Quand on est un particulier, on pleure devant les sites moisis de nos banques… Quand tu touches à des outils pros, tu découvres qu'il y a plein de clients qui marchent partout, mais il faut aligner un bon chèque pour avoir les accès…

À titre de comparaison, en Allemagne, les banques implémentent toutes (ou presque ?) le protocole HBCI, et ça semble suffisamment ouvert aux clients pour que des logiciels libres comme aqbanking soient utilisables par des particuliers.

Je suis tombé sur ce logiciel par hasard il y a deux jours, j'étais surpris de ne pas trouver de client EBICS libre, ça remplit un besoin réel.

Par contre, le non-site web et la mauvaise organisation du code donnent un côté brouillon au projet : le fichier ebics.jar de 9Mo contient à la fois le code source du projet, les fichiers compilés, les dépendances externes, un ensemble pour compiler en Makefile et en ant (pour pas faire de jaloux ?)… Heureusement, le dépôt SVN est plus propre (à l'exception des dépendances externes).

Après, je ne suis pas fan de Java outre mesure, mais c'est une première notable et cela peut servir de point de départ pour comprendre et implémenter la norme EBICS dans d'autres langages.

À noter également, dans la dépêche : «En fait EBICS est un standard Allemand, adopté en 2008, pour effectuer des transactions bancaire.»

Ce n'est pas tout à fait vrai : EBICS est un protocole de transmission de fichiers sécurisé avec la banque. Il permet d'envoyer des ordres de prélèvement ou de virement, mais aussi de demander des relevés de compte par exemple.

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...