Pinaraf a écrit 3682 commentaires

Tu pourrais m'envoyer des infos sur ta connexion ?

Genre ton nichandle OVH ou ton numéro de ligne (si t'as plusieurs lignes sur ton nichandle, précise laquelle aussi)…

Ça sera plus pratique pour moi chercher ce qu'il se passe exactement avec les collègues…

Ça dépend de plein de choses…

Le taux que te prend paypal est variable et dépend de l'acheteur, j'ai déjà remarqué des différences allant jusqu'à 1% du prix… Au passage ils ont des formules plus compliquées selon le type de vendeur…

Et surtout… les CBs hors paypal, auprès de fournisseurs de solutions de paiement tiers, sont à des taux largement plus faibles que ceux de paypal. Je n'ai pas de taux en tête (et surtout c'est fait à la tronche du client), mais c'est vraiment moins.

De plus… si tu lis les conditions de vente paypal et tous les contrats immondes, tu te rends compte que c'est hyper risqué de vendre du bien immatériel via Paypal : leur système de gestion des litiges n'est pas fait pour ça, et le vendeur est juste au dépourvu face à l'acheteur en cas de litige, vu que paypal n'accepte comme preuve que des bons de livraisons d'expéditeurs tiers type UPS, fedex…

Bon, pour avoir du implémenter les paiements Paypal, je peux te répondre : c'est dans l'API, tu dis si tu souhaites accepter ou non les paiements sans compte Paypal…
Après le marchand peut décider d'activer ou non ces paiements en fonction de ton pays et des moyens de paiement qu'ils gèrent.

Exemple : si ils ont les CBs, ils vont t'interdire de passer par paypal sans compte parce que ça leur coûte beaucoup beaucoup plus cher…

C'est déjà implémenté dans systemd, et le scheduler du noyau a eu un patch qui a fait beaucoup de bruit y'a quelques mois (ou 1 an ou 2, je sais plus) pour ajouter une fonctionnalité similaire : ordonnancement plus équitable en fonction des sessions… C'est ce qui fait qu'un make -j 64 dans un shell va pas faire ramer ta vidéo…

Si je loue un dédié, je le prends sans OS et je l'installe tout seul, comme cela pas de problème de clefs SSH et autres accès non contrôlé. Sinon quel intérêt d'avoir un dédié ?

Après, faut se mettre à la place du support OVH qui doit se prendre plein de demandes de personnes qui prennent un dédié et ne savent pas le gérer correctement…

Le mieux serait que ça soit corrigé…

https://bugzilla.mindrot.org/show_bug.cgi?id=2027

Sinon…

Tu fais comme moi : mode rescue et debootstrap pour avoir une debian aux petits oignons…

Hé non…

C'était super tentant, j'ai paniqué aussi…
Mais c'est qu'un bug d'OpenSSH.

J'ai pu reproduire le même message alors qu'aucune clé SSH dans mon authorized keys ne correspondait…
Dès qu'il y a un from sur une clé, si on tente de se connecter avec une clé, même hors de la liste, ça provoque ce message.

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…