ckyl a écrit 3877 commentaires

Non, sleep() utilise les signaux (un alarm) si nanosleep n'a pas disponible en syscall. Tout les systèmes potables implémentent nanosleep().

Au pire usleep utilise un select().

Un signal c'est pas très rapide mais pas très lent non plus, mettre un bit a 1 c'est encore honnete (bon j'abuse la :-).

Hum désolé j'avais lu que sleep prennait du temps ce qui au vu du code de la libc me surprenait un tantinet. Mauvaise interpretation de la phrase.

non non non je parlais du sleep() ca prend du temps CPU :-)

Tu peux developper ?

Oui et ca s'appelle un jeu. Que ce soit fait par l'armée US ou par une grosse boite capitaliste je m'en tape un peu. Sauf si tu passes ton temps sur armericasarmy.com qui est un model de propagande et que tu passes ton temps à lire les descriptifs des camps d'entrainements avant de rentrer dans une mission je vois pas la différence perso.

(note: avec la 2.1 l'ajout du texte au chargement d'une map me gène un peu mais bon).

Ca reste un *jeu*. Si tu es assez con pour allez signer apres avoir jouer à un FPS je crois que je peux rien pour toi.

Quand tu joues a ET tu joues gentil american qui sauve le monde ou mechant nazi. Hormis les tarres il n'y a aucune identification ce n'est qu'un jeu dans le but de se faire plaisir.

L'US army y gagne peut etre quelque chose pour *moi* ca ne change rien. Tu lances le jeu, tu joues, tu quittes c'est aussi simple que ca.

Le deuxième coté domage de la propagande est que des deux cotés tu joues gentil americain mais l'autre est toujours le mechant (incoherence au niveau des armes...).

Très agréable à jouer, enfin un FPS avec un peu de reflexion (surtout que la 2.1 a renforcé la puissance des impacts). Le moteur graphique est celui d'UT donc pas du tout récent mais le bon coté est que le jeux tourne bien sur du 1Ghz, GF2MX. La 2.1 à pas mal ameilloré le moteur graphique. La prochaine version passera à UT2k4 donc tu peux te racheter un ordi en passant...

Pour le coté propagandiste je laisse ca a ma reponse du message d'en dessous.

Le fait que le jeux soit sous tutel de l'US army à pourtant un coté bénéfique. Les boulets / tricheurs sont vires très rapidement. Cela permet d'avoir moins de gros lourds que sur des jeux genre CS ou Q3 et généralement l'ambiance est assez bonne. Personne ne te sortira des "n00b" toutes les 30 secondes sauf si tu fais vraiment le con. Tant que tu n'emmerdes personne c'est ok.

Le jeux étant aussi basé sur un principe d'"honnor", cela empeche pas mal de connerie. Plus tu joues plus tu montes. Tu ne peux descendre que si tu massacres ton equipe, ca enleve encore une couche de boulets.

Il en reste un jeux très agreable a jouer si tu aimes les jeux d'actions demandant un peu de reflexion. Ici un travail d'équipe est beaucoup plus recompensé qu'un fraggeur fou qui serra, de toute façon, shooté dans les 2 premieres minutes. Si ta came c'est les jeux ou "j'avance et je tire, si je me fais tuer c'est pas grave je respawn dans la seconde" passe ton chemin. Une vie par round un round dure 10 minutes... Essais de rester en vie :-)

De plus etre à l'aise est assez 'long'. Compte 1 journée pour faire tout les training avant de pouvoir jouer en reseau et une semaine avant de toucher terre en ligne (genre savoir qui est dans ton equipe ou pas demande un peu d'habitude pour pas se planter, le pointeur change de couleur pour des distances < 3 metres autrement ca se voit au profil par exemple...)

Un des meilleurs jeux réseau que j'ai pu gouter (je n'ai que du linux et du BSD cela dit...).

http://www.gamekult.com/tout/forum/lire_155545.html(...)

> Il n'y a que Return to castle of Wolfenstein qui vaille la peine comme jeu de guerre, ça reste "fictionnesk" et bien entrainant, les jeux fidèles au réel n'ont pas d'intérêts, (AMHA)

Bin déjà tout les jeux ou tu joues tout seul c'est chiant a mourrir. Avec la super IA de 3 de QI c'est passionant.

Après en reseaux tu as les trucs fictionnesk a mort comme Q3 qui sont des trucs de bourrins fini (et donc assez peu interessant) et quelques très bons FPS qui sont pas mal réalistes et insistent donc pas mal sur l'aspect strategique. Bin ouai quand tu arrêtes de jouer à la première balle recue tu evites de courrir comme un con dans tout les sens; surtout que l'humain de l'autre côté il te rate pour te faire plaisir...

AA est très bien par exemple (je ne parle pas de la propagande & co, je parle du jeux brute). La 2.1 qui vient de sortir a encore rendu plus realiste le moteur physique et ca commence a devenir vraiment trop facile de se faire buter. Comme quoi le realisme peu etre très rigolo. Moi (AMHA) je vois pas l'interet de courrir partout et vider 45 roquettes pour shooter quelqu'un.

> on oublie linux-ppc, on oublie *bsd (quoique avec l'emulation Linux) etc etc,

Je joue a ET 5/8 FPS plus vite sous FreeBSD que sous linux...
Enfin c'est vraiment l'argument à la con autrement, si tu as un linux-ppc tu achetes pas de jeux et voila. Je vois pas en quoi une console c'est mieux pas ce que le jeux tourne pas sur XX ! C'est comme dire que le PC c'est mieux pas ce que ton jeux game cube tourne pas sur PS2... Le problème n'a rien avoir avec la solution !

> J'imagine bien que ca pose quelques pb, sinon ca devrait etre fait aujourd'hui...

C'est déjà fait aujourd'hui, je pense que tu as vu au moins les deux implémentations que je t'ai montré. Il y a deux problèmes principaux cependant (en dehors des autres niveau sécurité).

SEGMEXEC casse l'espace d'addressage en 2 par defaut, si tu es en 3:1 il te reste 2 x 1.5 Go , si tu es en 2:2 il te reste 2 x 1 Go ca pose donc problème sur les machines blindées de RAM. La solution encore et toujours allez acheter un AMD64 ou n'importe quoi du style...

W^X explose tout les binaires existant, si c'est juste pour supporter le x86 je dirais que le jeux n'en vaut pas la chandelle étant donné que tout les concepteurs de proco ont l'air d'avoir compris le problème et avancent le fait que ca sera resolu dans les prochaines evolutions.

Si tu veux une comparaisons objective entre les deux ca va etre difficile etant donné la rivalité entre OpenBSD et PaX/Grsecurity et qu'ils ne savent que s'insulter. Tu as une comparaison là http://grsecurity.org/papers.php(...) par spender et sur misc@openbsd et bugtraq y'a quelques thread bien saignants.

> Moi je parlais de rassembler tout le code dans un coin de l'expace lineaire, toutes les données dans un autres, et que le segment de code n'inclue pas les données et reciproquement.

Problème des bibliothèques partagées mais en gros c'est ce que semble faire W^X. Ils ont changé la ld pour que l'on puisse regrouper dans un coin les données et de l'autre le code.

http://groups.google.com/groups?q=g:thl3632333067d&dq=&hl=e(...)

Ca fait en effet pas mal de changements (plus aucun binaire compilé avant ne fonctionne) ce n'est donc plus facilement faisable surtout pour du desktop ou on commence a voir plein de trucs precompilés partout.

Le jeux est de savoir si *maintenant* c'est la peine de tout casser pour une architecture qui va pas tarder à partir à la poubelle. Tout comme est ce la peine de s'ennerver à supporter les big iron en x86 alors que des archis 64 bits plus adaptées sont maintenant abordables...

[À propos du malin]
Je pense surtout que le problème c'est qu'UNIX à toujours préféré la pagination et que malheureusement c'est le mauvais proco qui a gagné des parts de marché :-)

La plupart des installateurs de jeux (ET, AA, SOF par exemple) te demandent où installer tout les fichiers donc oui c'est tres facile.

Il n'y au aucune dependance avec ce type d'appli c'est tout ce qu'il y a de plus proprio tout ce qu'il te faut c'est un OpenGL qui marche (même via mesa si tu veux constater le carnage :-). Bref du pas du tout integrer à l'esprit distribution.

Autrement fait attention en general ca decompresse dans le /tmp ce qui selon ta config peu poser problème (on a rarement un /tmp faisant 2Go...) il suffit de faire TMP_DIR=/decompresse_la ./installer

Heu ca doit être que comme partout les standards à eux seuls ne garantissent pas grand chose. Tu peux faire un truc qui valide mais monstreux. C'est comme tout langage de prog. c'est pas par ce que tu es ANSI-C et POSIX1.e que tu as ecris du bon code. Tu peux ecrire de la merde valide, illisible et tout et tout. La preuve en est l'IOCCC demande du code ANSI-C strict.

Bref le jugement validateur = 0 fautes => bien, validateur != 0 fause => pas bien c'est de la stupidité en boite.

Si le standard est bien fait (et donc qu'il y a un interet de le respecter) alors le problème s'explique sans passer par le fait que "bouh c'est pas standard caca" mais d'expliquer le problème par le problème lui même. Le fait que ce soit pas standard c'est assez secondaire après tout. Ne pas respecter un standard pour une raison valide je le fais tout les jours en C simplement par ce que je sais les conséquence de la chose et suis apte de juger si c'etait approprié.

Enfin bref ca devait etre dans cet esprit la....

> - Rapprochement de MacOS X vers le monde UNIX, pourquoi ? réactions ?

C'est pas très difficile à expliquer ca :-)

On parle de NX hard et mon commentaire ne faisait que montrer que certaines veilles architectures supportaient NX depuis des lustres et d'autres pas et par quel biais (segmentation ou pagination). Après je peux aussi me planter mais je ne pense pas.

Trouves moi la dedans ou c'est dispo.

http://e-www.motorola.com/files/32bit/doc/ref_manual/M68040UM.pdf(...)
http://e-www.motorola.com/files/32bit/doc/ref_manual/MC68040UM.pdf(...)

En même temps du côté blackhat la rumeur dit qu'il y a un ou deux exploit(s) qui trainent depuis la sortie d'exec shield mais bon :-)

"En production depuis redhat 9. "

Vous avez quoi a prouvez avec qui était le premier ? Y'avait aussi des solutions bien qu'avant exec shield pointe le bout de son nez enfin je vois pas l'apport au débat hormis le "moi je". C'est du niveau du thread de bugtraq que j'ai posté plus bas...

Autrement tu m'expliques comment la RH 9 est sortie fin Mars et execshield posté sur lkml debut mai (2003) ? Tu m'aurais dit FC1 ou REL 3 tu aurais été plus crédible à mes yeux.

> Si tu lis la page pour patcher, il precise bien qu'il faut avoir un CPU avec la feature d'ailleurs.

Oui car les solutions pour x86 existent déjà dont exec shield écrit par le même ingo molnar.

En recherchant un trhead que je n'ai pas retrouver je suis tomber sur ca :
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&thre(...)

Excellent thread sur bugtraq avec du Jedi/Sector one, du Theo de Raadt, du pageexec, du Solar Designer, du sauron, du Stealth qui parle comme des hommes qui mettent leur teub sur la table pour savoir qui a la plus grosse^W^W^Wfait un NX sur i386 en premier.

C'est rigolo à lire :-)

Bon autrement pour ce que tu proposes bien qu'etant pas specialiste de la chose il y a plusieur problème. Le problème est que les UNIX ont l'habitude de bosser avec un espace virtuel plat et a coup de pagination ca simplifie beaucoup les choses (cf les vieux threads sur lkml), la segmentation a totalement disparue de linux depuis le 2.2 il me semble et encore c'etait utilisé pour separer le mode noyau du mode utilisateur donc pas grand chose avoir avec le schmilbick.

ll y a des patchs qui se basent en effet sur la segmentation notament une des approches de PaX (http://66.102.9.104/search?q=cache:HYWR5K5BAXkJ:pax.grsecurity.net/(...) désole pour le google cache mais comme grsecurity est down ca aide pas pour avoir l'original) le principal problème c'est que tu coupes ton espace d'addressage en 2 à l'avance c'est pas top pour les machines "big iron".

Mes connaissances sont très limitées de ce coté mais commencer à faire mumuse avec plein de petits segments ca me semble pas etre la joie quand on est limité en nombre.

Au niveau hardware sur AMD64 il n'y a bien évidement qu'un drapeau :-)
De plus le drapeau n'est pas vérifié à chaque accès mémoire mais on moment du chargement dans le TLB.

http://www.watson.org/~arr/pdfs/hw/amd64_vol2_system_programming.pd(...)
5.4.1 p 169
5.6.2 p 173

> Tout a fait, pour avoir un semblant de protection sous x86 il faut passer par OpenBSD

Linux : PaX, ExecShield, OpenWall (et d'autres)
OpenBSD/NetBSD : R^W
FreeBSD: rien niveau noyau sniff
Je pense pas que Solaris x86 fournisse quelque chose

Autrement au pire patchage gcc.

Bien sur faire du hardware en software ca a un certain cout :-)

Au niveau des pages tu as au moins : AMD64, Sparc64, sparc, powerpc, alpha, sh5, hppa

Systèmes batards (gestion niveau segmentation plus ou moins réussi) : i386, powerpc

Qui ne gère rien :arm, m68k, mips, sparc, vax

(oui sparc et ppc apparaissent plusieurs fois :-)

http://citeseer.ist.psu.edu/jacob97memory.html(...)
http://citeseer.ist.psu.edu/34758.html(...)

"À ma connaissance Linux est le premier OS à implémenter cette technologie."

Heu pardon c'est serieux la ?

Bon y'a deux cas si y'a un support hardware ou non.

S'il y a support hardware cette chose existe depuis la nuit des temps. Sur les systèmes qui utilisent la segmentation ou sur des processeurs non moisis niveau pagination ceci a toujours existé aussi loin que la mémoire virtuelle remonte.

Pour pas remonter à la nuit des temps je sais que Solaris le supporte au moins depuis 1998. NetBSD le fait aussi sur toutes les architectures potables.
Autrement pour faire plus mal je dirais que les anneaux Multics basés sur des segments faisaient déjà cela... y'a un peu plus de 20 ans... (rha j'étais même pas né !)

Le problème est que quelques architectures bien merdiques on fait l'économie d'un ou deux bits par pte et qu'on est bien emmerder maintenant et qu'il faut des ruses de sioux au niveau noyau pour émuler ce que le processeur n'est pas capable de fournir. Au niveau du noyau même linux à en effet été l'un des premiers (c'est plus recent maintenant) notament avec PaX & co. Il existe un autre technique mais qui demande la recompilation des tout sur la machine les solutions noyaux ayant l'avantage d'etre transparente.

Le seul événement la dedans, même s'il est pas récent, c'est que la famille de proco la plus répendue va enfin être potable niveau VM. L'AMD 64 étant pas mal foutu si on excepte les 8 modes de compatibilités...

Bref les linuxiens sont en train de trop s'enfermer dans leur monde linux à mon gout :-)

T'inquiete pas ca risque pas de s'en aller ca fait plus d'un an que c'est comme ca...

heu pas très utile le for là :-)

dans le même genre tu as
cat file | grep xxxx

le man bash est une horreur

par contre http://www.tldp.org/LDP/abs/html/(...) c'est du bonheur

Le gros reproche que je fais a graphviz est le temps enorme qu'il faut pour faire un rendu.
J'ai fait un peu mumuse le mois dernier avec, mais sur certains trucs un peu consequent (genre 1000 noeuds) faire le rendu m'a pris dans les 6h CPU (PIV 2.6Ghz) et 2Go de RAM.

Et sur un truc amusant, diagramme de decision binaire pour ressoudre les N-reines avec n = 10, j'ai mis une babasse 14h dessus avec 10Go de RAM occupé mais j'ai du couper car on arrivait au petit matin et la babasse devait utilisable. La taille des PNG etait de l'ordre de 500ko à 5Mo...

Bref graphviz ca tue mais au niveau rendu ca tue surtout les machines :-)

http://euterpe.unice.fr/~mathieuc/bdd/(...)
(attention pour n > 6 ca fait tres mal aux fesses du navigateur)

$seq 1000

c'est juste un peu plus court :-)