Compte_supprime_74291

Entre la crise de foie de Lorinc parce qu'il a mangé trop de galettes en plein dev, et toi... c'est parce que Windu s'est mis à bosser, et qu'il passe moins, que vous vous lâchez ?

Oui, bah, quand on cherche la merde... ... j'ai une horreur absolue des machins tout intégrés en mode click-click-suivant, mais j'ai quand même autre chose à foutre que de me maintenir une sid (edit : ou une Gentoo )...

J'ai foi en Debian stable (et foi dans les doses massives de café pour ce qui est de testing )...

Après, le problème risque d'être de devoir choisir en KDE 3.5 et 4... même si ça dépend des distros...

On pourra aussi espérer une meilleure stabilité au changement de res... parce que ça, ça n'a pas toujours été la joie (et d'ailleurs, c'est ce qui fait lamentablement planter X.org, une fois sur deux, jusqu'au 7.2, en multi-GPU drisé... pour les suivants, évidemment, puisque pas encore de multi-GPU en randr 1.2, la question ne se pose encore même pas)...

Mécréant caprinophile

Deux petites videos en flashkipu pour comparer le mode-setting (changement de résolution) entre le traditionnel user-land, et le nouveau kernel-mode qui s'annonce à l'avenir... yummy

Ce qui, je trouve personnellement, la fout particulièrement mal, pour un logiciel (presque bientôt) libre... d'autant quand ça se voit à ce point-là...

Oui, mais ils ont beaucoup souffert

C'est pas fini, les blagues belgeswallones ?

Pour tes applis redmondianisantes, tu peux quand même jeter un coup d'oeil à Wine, au cas où il pourrait suffire...

Hum, en googlant pour bien me souvenir comme ça marche, il semble que j'aie oublié le "makeactive" entre "rootnoverify" et "chainloader"... Tu peux essayer : title Windows XP rootnoverify (hd0,4) makeactive chainloader +1 Le "savedefault" que tu avais à l'origine sers à positionner l'entrée par défaut de grub, à démarrer si aucune action n'est entreprise par l'utilisateur... Le "rootnoverify" positionne la partition de démarrage, mais sans essayer de la monter, à l'inverse du simple "root"... Par contre, je tilte que ton os redmondien est sur une partition étendue (et "makeactive", pour valider la partition de boot, pour charger un bootloader tiers, ne marche qu'avec les partitions primaires, je crois)... il me semble qu'il y a moult galères, à faire ça avec grub... je crois que ces os ne veulent pas démarrer s'ils sont sur une partition étendue... peut-être qu'en le blousant à coup de map, du genre : map (hd0,4) (hd0,0) map (hd0,0) (hd0,4) avant le rootnoverify, mais je ne suis pas plus sûr que ça que ça puisse marcher (surtout à cause du "makeactive")...

grub n'a pas le même formatage des noms de partitions que linux... Dans grub, (hd0,5) correspond à la 6ème partition (et non la 5ème... il commence à compter à partir de 0) du premier disque déclaré comme bootable par le BIOS (qui n'est pas forcément sda ou hda... enfin, tu n'as l'air d'avoir qu'un seul disque : c'est donc le premier et le seul, et donc le disque 0, puisque grub, je le rappelle commence à compter à partir de 0)... Aussi, ce qui correspond à sda5, c'est (hd0,4), et ce qui correspond à sda6, c'est (hd0,5)... Après, si c'est bien sur sda6 que tu veux booter, j'aurais tendance à plutôt mettre : title Windows XP rootnoverify (hd0,5) chainloader +1 Normalement, ça suffit...

... je sais m'en servir (OpenWRT m'y a bien forcé)... mais même en sachant, sa syntaxe d'édition me fait toujours un truc que je n'aime pas au cul... alors, foutu pour foutu...

Pas besoin d'être root pour faire une recherche dans aptitude

Juste un petit message pour dire du bien d'un projet bien sympathique pour ceux qui en ont raz-plein-de-trucs de cumuler les télécommandes et de jouer le clown jongleur avec... : Concordance ... Concordance (enfin, Harmony, pour l'instant, mais la prochaine version 0.20 qui doit sortir bientôt, en plus d'amener un split entre librairie et frontend, apporte un changement de nom) est un projet permettant de configurer une télécommande logitech harmony (pas toutes, mais peu ou prou apparemment tout ce qui est "moins über-classe" que les 890) à partir de linux. Le tout se base sur libusb, et, bien que très jeune (petit background en langue angloise), marche plutôt pas mal... Pour l'instant, la version stable (pas tant que ça, puisqu'une régression dans la 0.13 m'empêche de mettre à jour la config de ma 555, bien que ça fonctionne bien dans la 0.12... bon, le CVS est très actif, apparemment) ne permet que d'uploader à la télécommande une configuration effectuée sur le site des possesseurs de télécommandes harmony (sur lequel il faut donc s'inscrire, ce qui permet d'accéder à une grosse base de données constructeur... en gros, on rentre son modèle d'appareil, on programme les macros pour certaines actions, et en résulte un fichier à télécharger et à uploader via Concordance), de répondre au test de connection du-dit site, d'apprendre de nouveaux codes non présents dans la base logitech... Que ça ? Bah oui... reste encore un point noir... le firmware... ma télécommande était livrée avec un firmware plus vieux que celui qu'il faut pour utiliser le site en ce moment, et nécessitait donc une mise à jour de celui-ci... ce que Concordance (enfin, Harmony... enfin... euh, bref) ne sait pas encore faire... cependant, à la lecture de la mailing-list, ça a l'air d'être la fonctionnalité la plus travaillée en ce moment, avec le split en une lib et un frontend... il y a donc bon espoir qu'une prochaine release permette de se passer d'os redmondien ou autre propriété (il me semble que ça marche aussi sur macos) pour mettre à jour le firmware (non libre, mais distribué aux inscrits par logitech) de la télécommande... Enfin, bref, un petit projet qui ne demande que les sources de libusb pour être compilé en deux coups de cuiller à pot, qui ne marche pas trop mal pour un truc encore tout jeune, et qui mérite bien qu'on dise du bien de lui... voilà, c'est fait

Ca a l'air d'être sympa, QCA ... c'est un peu ce qu'il faudrait à toutes les applis qt usant de chiffrage...

Plus ça va, plus sha1 est déconseillé... certes, ce n'est pas à la portée de tout le monde de le casser, mais le proof of concept est là... ... ce que je trouve vraiment dommage là-dedans, c'est de ne pas laisser le choix du chiffrement et du hash, avant toute chose (et aussi le fait que je n'aime pas trop le concept d'un wallet ouvert à tout vent une fois qu'on l'a déchiffré, bien que ça n'ait pas grand chose à voir avec ma question initiale)... ... faudrait que je zieute le bts de KDE, et que je formule la demande, au besoin...

Les chiffrer avec l'une de mes clés publiques, non, pas forcément... par contre, être le seul à raisonnablement pouvoir les déchiffrer (une passphrase longue et solide met déjà les risques de brute-forcing hors de "l'usuel"), ça me paraît un minimum... ... et pour ça, un autre minimum éventuel serait de hasher le pass avec quelque chose qui tient la route, et pas une sombre cochonnerie obsolète comme sha1... D'ailleurs, en se basant sur un backend éprouvé et versatile, en sus d'utiliser le chiffrement que l'on veut, avec le hash que l'on veut, on bénéficierait au moins d'un audit sérieux sur la crypto... parce que là, déjà qu'il faut aller fouiller dans le code pour savoir ce que ça utilise, alors de là à ce que kwallet ait été audité sur ce plan... Bref, kwallet, ça ne casse pas trois pattes à un canard... dommage... Pourtant, quelque chose du genre qui serait carré niveau crypto, et qui débloquerait lui-même les mots de passe (m'est avis que ça aurait été un meilleur design, vu que kwallet ne gère que les applis kde... il devrait pouvoir contrôler les applications, plutôt que d'attendre qu'elles viennent y piocher les mots de passe en clair comme elles veulent, sur un plateau d'argent), ce serait tip-top... Bon, je critique (j'espère au moins constructivement), mais après, je ne sais pas coder... donc...

Par contre, sha1 pour le mot de passe maître ... c'est faible... d'autant pour un truc qui "protège" justement des passes (enfin, on pourrait tout autant dire expose ... vu que les applis viennent chercher les passes, plutôt qu'ils ne soient distribués activement aux applis par le wallet, à son ouverture, comme ce serait idéal qu'ils soient)... Dommage qu'ils ne relèguent pas ça à gnupg ou cie, plutôt que de faire à leur sauce, pour le hash (et même le chiffrement)...

Tiens, question-à-la-con... quelqu'un saurait me dire avec quel genre d'algo kwallet chiffre-t-il ses mots de passes ? ... je n'arrive à trouver ça nul part... pas très engageant, surtout pour un bouzin qui est déjà de l'ordre du cache-misère...

cfdisk est très simple (comparé à fdisk ... et même aux cochonneries en GUI qui, je trouve, gèrent peu de choses... et le font mal)... par contre, à chaud, je ne tenterais pas (enfin, j'ai déjà fait, par mégarde... ça marche, mais ce n'est vraiment pas le genre de trucs à faire ... vraiment pas)...

Normalement, pvresize... mais celui-là, je ne l'ai jamais utilisé...