moi1392 a écrit 730 commentaires

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 ;)

La vrai question est : a-t-il souligné "ortho" également?

C'est rigolo les "arguments" pour se défendre suivant quel adorateur de Linux j'ai en face : des fois, je pourris Linux parce que je fais des bêtises de débutant et que je ne suis pas expert, des fois je le pourris parce que je suis expert.

Tu essais de contrer ce que je te dit en me parlant de ce que tu disent les autres ??
Donc soit, je ne sais pas si tu es un expert ou pas... explique moi comment tu fais pour pourrir ton linux en 5 minutes avec des connaissances dont je jugerai par la suite du niveau d'expertise.

Sinon, je connais une tonne de monde qui ont Windows XP qui tourne très bien et qui ne sont pas experts, juste qu'ils n'installent pas tout et n'importe quoi

Quelqu'un qui n'installe pas tout et n'importe quoi est déjà quelqu'un qui a une certaine connaissance et expérience, qui sait ce qu'il doit installer et ce qu'il ne doit pas installer.
Un non expert installe tout et n'importe quoi!

je te pourri un Linux de la même manière qu'un Windows XP [...] vous comparez une Mme Michu sous Windows XP à un expert sous Linux

Là c'est toi qui fait la comparaison inverse, tu pourris linux en 5 minutes parce que tu es un expert... La différence est que windows, il faut être un expert pour ne pas le pourrir, alors que linux, il faut être un expert pour le pourrir...
A ce petit jeu là, je peux aussi mettre le feu à la machine et aucun os ne résiste...

C'est LE poste pour Pierre Tramo ça !