CoinKoin a écrit 698 commentaires

La censure a été renforcée en Corée du Nord. En effet, XXXXXX XXX XX XXXXXX XX, et XXXXXX XXXX X le XXXXX, car XXXXX XX XXXXXX XX. XXXXX XX XXX du XXXXXXXXX, pour XXXX XXX XXXXX.

D'après la présentation sur afjv, c'est compatible "PC (Windows ou Linux) ou Mac". Donc je pense que ça n'a été développé que pour Linux sur PC.

Viens à Paris, il pleut.

>La seule implémentation java correcte (en termes de performances) reste celle de windows. Les autres sont toutes baclées.

Ah? Moi, j'avais entendu dire que celle d'IBM pour AIX PPC était très efficace (mais seulement par ouï-dire). Tes sources?

>[...] tu peux les mixer

Heu? Tu parviens à lancer deux gestionnaires de fenêtres en même temps sur le même serveur X? Donne ta recette!

Deux bogues et une anomalie postés en l'espace de 7 minutes! On dirait qu'il y a un problème avec ton compte...

Oui, mais si tu veux parler de Linux à un windowsien, il faudra bien lui expliquer ce que c'est, et donc le comparer à Window$...

Quant à répondre "Window$, je ne sais pas, je ne l'utilise pas. Mais Linux blah blah...", outre le fait que cela fait vraiment penser à la "secte fermé et bornée du libre", cela n'est absolument pas un argumentaire convainquant.

On pourrait aussi bien entendre "Linux, je ne sais pas, je ne l'utilise pas, mais la réécriture à la volée de l'OS en langage machine en utilisant les valeurs des scancodes du clavier, blah blah..." Et pourtant, curieusement, l'interlocuteur garde des doutes :-) .

[...], be aware that tar will first unlink(2) an inode before creating a new device node. The unlink(2) has the effect of breaking the connection between a devfs entry and the device driver. If you use the "devfs=only" boot option, you lose access to the device driver, requiring you to reload the module. I consider this a bug in tar (there is no real need to unlink(2) the inode first).

Extrait de :
http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html(...)

Cela dit, personnellement, je n'ai jamais essayé de manipulation de ce genre.

>L'OS lui fait tout correctement, il voit un soft qui n'est pas sur la whitelist en train d'essayer d'executer du code sur une page marquee non-executable, il tue le processus.

Ben, je ne comprends pas.

Si un processus tente de faire un "jmp" sur une adresse située dans une page marquée "non-exécutable" dans la TLB, il devrait échouer et l'erreur devrait être générée au niveau du matériel, indépendamment du système d'exploitation.

Evidemment, ça n'est valable que pour les PCs avec MMU, c'est-à-dire i386 et suivants, mais je ne pense pas que Windows XP soit conçu pour tourner sur des machines plus anciennes.

Alors, où est la nouveauté? Et qu'est-ce que vient faire l'OS là-dedans (à part marquer les pages correctement) ?

>dans quelques années il faudra 8 Go de mémoire, puis plus, c'est inéluctable.

Ca dépend dans combien de temps aura lieu le passage de la majorité des ordinateurs de 32 à 64 bits. Tant que tu resteras à 32 bits, tes programmes tourneront forcément au plus avec 4Go.

Ce qui fait quand-même beaucoup.

>Les jeux de mots vont bon train :
- Bleeding etch
- Are you sick of problems? Just fetch the etch!

< italien >
- Etch... ellente !
- T'as raison, parce que gentoo est rapido, lui.
< /italien >

========>[]

Au fait, méfie-toi, il y a un bogue dans tar lorsqu'on veut archiver /dev.

...Qu'il n'y a plus assez de place pour créer l'archive à l'endroit où tu veux la créer! (enfin, je pense, le fait que l'échec ne se produise pas après le même nombre de fichiers est plutôt bizarre).

Fais un df -h, pour vérifier...

Je ne sais pas.

Peut-être que certains n'ont pas apprécié l'orthographe de "kases" et "klavier" ? (peu probable.)

Peut-être que certains n'ont pas apprécié que l'on qualifie KDE de "klickodrome" ? (ah, c'est peut-être ça.)

Où bien peut-être que certains n'ont pas aimé que tu donnes une solution à un débutant sans lui signaler que c'est un truc à éviter.

En tout cas, moi, ton moinssage me paraît peu justifié, puisqu'il répond à la question, et que, à l'heure où il a été posté, cet avertissement avait déjà été posté.

Je pense que Pascal a raison, execve dans le noyau n'est pas un appel jouable.

Je pense que, pour réaliser ce coup-là, il vaut mieux toucher au scheduler, de sorte que, lorsque le processus que tu veux voir exécuté en mode maître passe élu, le scheduler n'effectue pas le passage en mode esclave. Comme ça, tu n'auras qu'à lancer ton processus en mode esclave (où execve est valide), puis le passer en mode maître lors d'un changement de processus.

Cela-dit, sois conscient que cela constitue une évidente faille de sécurité, puisque cela permettrait potentiellement à n'importe qui d'exécuter un processus en mode protégé.

Ah, un détail encore : il faudra faire attention aux registres de segment lors du passage en mode maître, car leur valeur diffère selon le mode considéré (typiquement, le mode maître a accès à toute la mémoire).

Bon amusement avec l'assembleur!

>C'est tout a fait impossible, pasbill dit que windows xp tourne avec 64 mo de ram. Donc c'est que c'est vrai.

L'article ne parle pas de "faire tourner", mais de "profiter dans de bonnes conditions".

Cela dit, moi, je trouve que la seule boîte à laquelle Wndow$ XP soit profitable, c'est M$...

========>[]

Une autre proposition :

Le noyau de Windows 2000 est connu pour avoir une gestion très fine de l'allocation de la mémoire aux processus. En particulier, si un processus demande trop de mémoire par rapport à ce qui peut être accordé, c'est lui qui est tué (contrairement à Linux, où l'exterminateur de gestion de mémoire tue les processus au hasard).

D'après leur page Web, websense a besoin de pas mal de mémoire pour fonctionner (configuration minimale : 512 Mo de RAM).

Du coup, voilà mon idée (un peu pirate, il faut le dire) :
Ecris-toi un programme qui fait un petit malloc(), puis boucle infiniment sans rien faire.

Puis bourre ton disque dur de telle sorte que W$ ne puisse plus agrandir le fichier d'échange.

Ensuite, lance ton programme autant de fois que tu peux pour remplir la ram et le fichier d'échange.

Et ensuite, file sur internet...

Cela va avoir pour effet de lancer websense, qui va demander beaucoup de ressources mémoires,... et se faire tuer par le noyau en réponse.

Ensuite, plus qu'à libérer le disque dur et tuer les processus chipeurs de mémoire, et le tour est joué!

Qu'est-ce que tu en penses?

Et si tu redémmares en mode sans échec ou MS-DOS, tu es toujours bloqué?

>Pour ce qui est de KDE "mal" codé, quand est-il de Konsole ?

s/quand/qu'en/g :-)

Quant à Konsole, ma foi, je ne sais pas si ce programme est bien ou mal codé, mais quelle est la différence avec un xterm, au juste? (si ce n'est sur le plan esthétique, je reconnais que metacity est excellent de ce point de vue).

>Faut il revenir 10ans en arrière et utiliser que le mode console ?

<mode emm... bêteur>

s/utiliser/n'utiliser/g :-)

</mode emm... bêteur>


Non, non, ce n'est pas ce que j'ai dit! "su" dans Konsole ou xterm, ça marche très bien, et c'est largement suffisant, dans l'immense majorité des cas, d'ailleurs, c'est ce que je fais généralement.

Par contre, je déconseille quand-même le lancement de Konsole par le root, qui me semble avoir peu d'intérêt par rapport à "su".

alias rm rm -i, et tu as l'avertissement en mode texte :-) .

Cela dit, KDE n'aurait rien changé, puisque, si j'avais été sous KDE (il ne faut pas confondre KDE et mode graphique, ce jour-là, j'étais en mode graphique avec un xterm sous twm), il m'aurait demandé confirmation de la suppression du répertoire "home" et de son contenu, or je voulais réellement supprimer "home" (pas ce "home"-là, mais ça, je m'en serais rendu compte trop tard).

Bon, cela dit, peut-être que je n'aurais pas sélectionné le mauvais répertoire.

Quant à l'administration du système grâce à KDE, je ne m'en sers jamais, car je m'y perds un peu (ce qui doit être une question d'habitude, je suppose), et que je crains que les possibilités soient plus limitées que dans le mode texte. Cela dit, je comprends fort bien que cela puisse rendre service, mais je pense que, sur le plan des erreurs, on n'évitera guère plus de bêtises que l'on n'en fera de nouvelles...

>ça n'a pas grand chose à voir avec le fait de se logguer sous root en graphique pour moi

Effectivement, c'était plus adapté à l'illustration des risques du passage en root lui-même que le login graphique du root.

Une fois, j'étais dans /tmp, et je voulais supprimer un répertoire /tmp/home... Et j'ai tapé rm -rf /home au lieu de rm -rf home.

Et je peux te dire que j'ai été très content de ne pas être root...

A mon avis, l'erreur de manipulation est (aujourd'hui) plus à craindre que le piratage, mais aucun des risques ne doit être négilgé.

D'autant que KDE n'est pas parfaitement codé, à mon avis (t'as déjà essayé
"echo startkde > ~/.xinitrc && xinit -- :1 &",
et regardé les messages d'erreur?), et que le risque d'effacement de données par suite d'un bogue dans une appli KDE existe aussi...

>J'aurai aimé, mais ici on a un truc appelé websense qui me met une grosse page de la mort m'indiquant clairement que je peux pas aller sur ce site car il contient des trucs pas clairs

D'après ce que j'ai vu sur le site de websense, leur filtrage ne fonctionne qu'au niveau des urls des machines, pas des IPs. Donc si tu récupère l'ip et que tu t'en sers comme url, websense devrait être mis hors-jeu.

De plus, tu dois aussi pouvoir le contourner en utilisant le cache de google au lieu de l'accès direct.

>Merci pour la patience des pros pour les novices aux questions si bêtes.

La différence entre les novices qui posent des questions bêtes et ceux qui n'en posent pas, c'est que ceux qui n'en posent pas restent novices plus longtemps :-) .

Je crois que l'idée, c'est que tu dois te loguer en utilisateur normal, puis lancer un des outils mandrake de configuration du système (genre drakeconf, ou quelque chose comme ça).

A ce moment-là, il te demandera le mot de passe root, et donc tes modifications seront identiques à ce qui se passerait si tu étais logué en root.

Quant à lancer KDE en root, ça me paraît très hautement déconseillé, du point de vue de la sécurité...

Ah, ben alors là, moi non plus, je ne comprends pas. Désolé.