moi1392 a écrit 759 commentaires

on retrouve clairement le fonctionnement de bien des Castlevania : un monde vaste et "ouvert", un enchaînement de bonus qui rendent accessibles des parties auparavant ingérables, une absence de "niveaux"

Pour info, les premiers castlevania n'étaient pas du tout de ce genre, c'est avec la PS1 c'est arrivé.
Par contre, le premier jeu avec ce genre de gameplay que j'ai énormément aimé (si bien que j eme le sui srefait plusieurs fois sur émulateur depuis) c'est métroïde sur snes (qui lui aussi à bien changé depuis, ça n'était absolument pas du fps à l'époque...)

Pour ton QT_NO_DBUS, tu peux essayer de passer sur le pré-compilateur sur un fichier pour voir le résultat et trouver d'ou il viens.
Sinon, ouvre un fichier cpp dans kdevelop et ajoute un QT_NO_DBUS quelque part, quand il aura fini d'analyser ton fichier et ses inclusions, passe la souris sur le QT_NO_DBUS que tu as ajouté et il te dira d'où il est défini (s'il l'est)

Si aucune de ces 2 méthodes ne te donne de résultat, il y a de fortes chances que ce soit définit depuis la ligne de compilation, essais de vérifier pour voir (fais le en premier même...)

Ça doit bien se trouver des cartes wifi bluetooth...

Et c'est un FF7.

C'est la Shinra qui a fait le coup !

Ce qui ne veut pas dire qu'un acte illégal effectué massivement est légitime, cf les excès de vitesse

J'aime bien comme au passage tu essais de faire accepter à tout le monde que l'excès de vitesse est illégitime :)

Il y a moyen de bloquer ces systèmes comme avec kiosk et KDE3?

à priori oui, plasma est en partie branché sur kiosk pour autoriser/interdire des actions. C'est juste qu'il n'y a plus d'outil graphique (que je sache, il devait à plusieurs reprises être ressucité, mais je ne l'ai jamais revu) qui permette de changer ce que tu souhaites, alors il faut passer par l'édition à la main des fichiers de config.
Maintenant, je ne peux pas non plus te garantir que la fonctionnalité que tu cherches à bloquer en particulier est bien dépendante d'un attribut kiosk. (il me semble que c'est le cas pour le vérouillage/déverouillage du bureau)

Tu as de la musique taguée linuxfr ???

.config est recommandé pour ranger la config des applications.
akonadi (qui pour rappel, n'est pas la suite kdepim) se voulant non lié à un environement de bureau en particulier (même si dans les faits, ça n'est pas le cas) les dev ont trouvé logique de mettre sa config ailleurs que dans .kde

Je trouve ça logique aussi que si j'utilise akonadi (et pas la suite kdepim) sous XFCE, je n'ai pas besoin d'une dossier .kde

mais on ne s'en rends compte qu'en relisant la phrase...

Le multi process/thread est une stratégie parmi d'autres pour résoudre ce genre problème, et la stratégie en question est de délèguer la difficulté sur l'OS et sa gestion des processus.
Rien n'empêche d'avoir un pool de thread de taille fixe et d'en allouer un disponible à chaque page qui à besoin d'un chargement quelconque en plus du principal qui gère l'application.
Rien n'empêche non plus de ne pas geler l'application quand une page charge, que je sache, les entrées sorties peuvent avoir un timeout qui est nul, ce qui reviendrai à faire du polling sur l'arrivée de données depuis le serveur distant, et de ne les traiter que lorsque qu'il y en a suffisamment pour décider de la prochaine action.

En fait, il y a juste des tas de stratégies, et quand on est dans l'application, on est censé mieux connaitre les besoins qu'une gestion générique faite par le noyau (même si elle est excellement bien faite, comme dans le cas du noyau linux), et donc pouvoir avoir une gestion plus optimisée de ses ressources.

Sinon en un poil plus fin, j'aime bien celle là moi : http://vidberg.blog.lemonde.fr/2011/10/06/un-peu-plus-quun-patron/

J'en profite pour présenter un blog que je lis régulièrement et que j'apprécie.
N'hésitez pas à remonter dans les archives, il y a de vrais perles.

Donc on n'a le droit de ne rien dire si on n'a pas de proposition concrète ?

Ça me rappelle une citation de Raymond Devos tout ça...

Et on n'a plus de nouvelles du cuisto depuis...

On va se retrouver avec une dépêche rachitique.

tu veux dire qu'au lieu de 1400 lignes, on risque de n'en avoir que 1392 ?? ça va être tristounet à lire...

parce que "Vous n'avez pas les droits suffisants pour accéder à cette partie du site." (c'est quoi l'intérêt de limiter l'accès au fait ?)

Ça n'a strictement rien à voir avec ton problème, mais si tu dois réinstaller/repartitionner pour une distribution récente, évite de séparer / et /usr.
Depuis quelques temps (en particulier avec pulseaudio et systemd), si /usr n'est pas accessible au boot (AVANT que les partitions ne soient montées) certaines choses marchent mal, tu ne t'en rends pas compte, car cela échoue silencieusement, mais ce qu'il y a dans /usr est indispensable pour la bonne initialisation de pas mal de nouveaux services. (entre autre pour mapper les id du bus PCI vers des nom de périphériques)
Pour plus d'infos sur le sujet, http://lists.freedesktop.org/archives/systemd-devel/2011-February/001364.html et il s'ensuit une assez longue discussion sur la mailing list de systemd.

j'ai pas dit que c'était spécifique, j'ai dit que c'était un point fort.

d'ailleurs, c'est dans les avantages de scons aussi :

range tous les produits de la compilation dans un "build directory", pratique pour séparer les choux et les carottes.

Et pour les autotools, quand je m'en sers, mais c'est peut-être moi qui ne sait pas m'en servir, j'ai des fichiers générés dans les sources moi (des Makefile ou autre fichiers intermédiaires du configure)

Dans les avantages de CMake, il y en a un qui est très important pour mes cas d'utilisation et qui me semble important de préciser, c'est la construction du système de compilation et la compilation elle même hors sources.

Je peux, avec la même arborescence de sources créer 4 dossiers de compilation avec des options différentes (debug/optim/cross toolchain/...) et tout est généré dans ces dossier.
Si bien qu'un "make distclean" (ou un truc du genre) se résume en un "rm -rf build_dir"

Waou ! Un jeu où on peut poutrer le pote à casimir, trop bon !

Ça suppose alors que tu ais plusieurs de ports PS2 pour clavier et pour souris, sans compter les ports USB, et en sachant que tant que tu n'as qu'un clavier et qu'une souris, pas mal de place est inutile sur ta tour. Pas grave tu me diras, jusqu'à ce que tu te mettes à faire des périphériques plus petits, comme des ultra portables, puis des tablettes, des smartphones, ...
Ensuite, même si l'on suppose que l'on en garde qu'un pour le clavier dit "maitre" et que les autres son en USB, ça veut sur que tu as un ou plusieurs clavier PS2 et un ou plusieurs clavier usb, ou alors plein d'adaptateurs...

Au final, je pense que tout mettre sur la même interface (USB ou une autre, là n'est pas la question) n'est pas une mauvais idée en soi, et on pourrait effectivement colorier en rose et vert deux ports USB particuliers (ceux qui ont des numéro de BUS 0 et 1, ou je ne sais quoi qui les représente) et que l'OS n'accepte par défaut que sur ces dernier un clavier et une souris, sur les autres une validation est requise.
Après, je repose ma question car je n'ai malheureusement plus de feutres rose chez moi : Est-ce que je peux faire ça de façon logicielle (assez facilement quand même) avec des règles udev par exemple simplement avec les outils actuels ?

et du coup la validation du clavier à la souris ;)
Cela pose quand même un soucis de bootstrap, car ça suppose qu'il y ait toujours au moins un périphérique d'entrée déjà actif sur le système grâce auquel il est possible de valider un nouveau périphérique.
Je pense que la solution de limiter les types de HID par port USB (par liste blanche, liste noire ou autre) est tout de même nécessaire. Après on peut, dans les cas ou le périphérique n'est pas autorisé sur le port en question, demander validation par l'utilisateur plutôt que de complètement interdire, effectivement.

Je suis assez surpris de la différence entre konqueror et rekonq.
As-tu testé konquéror avec la moteur webkit (le même que rekonq du coup) ou khtml ?

Il me semble aussi que dans sa page de démarrage, rekonq charge des preview des 5 derniers sites visités, ça pourrait aussi expliquer la différence, s'il a chargé en interne 5 sites en plus.

Généralement, si je branche un clavier, c'est que j'en ai pas, du coup, la confirmation, je vais avoir du mal à la valider.
Une solution efficace dans mon cas serait de limité les HID autorisés à charger le pilote correspondant selon le port USB sur lequel ils sont branchés.
Du coup, j'ai des ports USB qui n'autorisent que les USB mass storage, et si je branche autre chose, rien ne se passe. Là, je vais voir les messages systèmes et je vois alors que mon périphérique est un clavier/un modem/un vibro ou autre chose d'exotique et je sais prendre la bonne décision.

la seule défense que je puisse voir est d'avoir des ports USB spécifiques marqués "clavier" et "souris" et de n'autoriser le matériel type clavier et souris que sur ces ports, très peu probable que ce soit implémenter un jour..

Ne serait-il pas possible avec les outils actuels, de n'autoriser sur certains port USB bien définis (ceux de devant ma machine par exemple) que les HID de type mass storage ?

au moins, on aurait des ports un peu moins vulnérables. Il y aurait toujours le problème de la faille dans le driver de système de fichier, mais ça resterait une faille qui serait corrigée aussitôt trouvée, alors que là, c'est plutôt un problème de conception duquel qu'il est beaucoup plus dur de se protéger de mon point de vue.

mais tu achètes plus de baguettes de pain quand tu es riche.
Donc tu payes plus de TVA au final ;)