Guillaume Knispel a écrit 2474 commentaires

Oui, bon les warning dont tu parles, ils te disent juste que c'est codé un peu à l'arrache, pas que ton système est suceptible de freezer

Mais arretes de boire, des failles qui crash des démons, des OS, ce que tu veux, ca sort tous les jours, et pas forcement après la correction. Quand au fait que ca fasse dix lignes ou 400, c'est totalement irrelevant. Quand à mettre en péril des sté, vu que c un truc en accès local, soit la sté à des employés completement tarés, soit ya des vilains méchants haxor qui ont obtenus un shell, ce qui n'est en soit n'est pas une très bonne nouvelle. Et puisque que tu sembles etre si bon en programmation (avec ton splendide Ton indifférence est compréhensible, car tu n'as pas de connaissances suffisantes en matière de développement ou d'administration système .), tu aurais du te rendre compte par toi meme que le code employé est suceptible de ce retrouver non pas dans une proof of concept de crash test, mais bel est bien dans une appli réelle, et moi je t'avoues que je préfère savoir que ca bug plutot que de me dire pendant 3 semaines que je suis un couillon qui n'arrive pas à debugguer mon propre code ! Tampis pour la sté, merci pour mon confort de devel perso. Et puis tant mieu pour la sté si elle developpe des trucs suceptible de faire grosso modo la même chose, elle pourra éviter de crasher elle même ses propres serveurs ce qui est plus probable vu le bug que de ce les faire crasher par quelqu'un d'autre. Bon c'est vrai que pas grand monde ne lit l'asm x86 et le C posix courament, je pardonnes donc ta méconnaissance et te donnes mon absolution. Je te rappele que le noyau, comme tout code sous GPL, et fourni sans garantie dans l'extension permise par la loi. Si toi ou ta boite tu t'amuses à garantir tes installations, alors j'espere que tu es capable de regler toi même cette faille dans de bref délais sinon ta superbe garantie ne vaut pas un clou.

Clairement, c'est le match que j'ai le plus aimé de toute ma vie (du moins la partie que j'ai vue).

J'ai zappé sur le foot, je me suis dis "tient, ya un match ce soir", pis a ce moment la, pan, l'équipe francaise à gagnée, j'ai regardé la minute et j'ai capté que c'était fini, alors je me suis dit "cool, l'équipe francaise à gagné", et j'ai éteind la TV. J'adore le foot quand c'est en si petite dose :)

Jamais tu dirais dans la vraie vie : "vous pourriez pas vous taire, j'aime pas le foot, alors je ne veux pas que vous en parliez, ou alors sur le balcon, que je ne vous entende pas"

Moi j'en suis capable ;)
Mais bon faut dire que je suis un cas totalement désespéré...

J'ai pas compris le coup du "voir les explications en fin de CV" du titre.
Quelqu'un a une idée ?

Ouai ben SCO en attendant, c'est plus un repère d'avocat pas très doués, et franchement ca me fait ni chaud ni froid que des avocats pas très doués financés par microsoft se retrouvent au chomage.

Vu l'état actuel de l'économie et du droit, ils risquent fort de ne pas rester bien longtemps au chomage...

Quand on est dans une boite il faut en assumer solidairement les actes, ou partir, or les actes de SCO n'étant pas bien brillants dernièrement, que ceux qui ne sont pas partis et donc assument ses actes se retrouvent sans job ne me chagrinera pas, désolé !

Sans compter que quand on a lu le code source des logiciels de votes belges, qui avaient fait un peu de bruit à l'époque, et qui on été fort heureusement abandonnés depuis, on se met à avoir soudain TRES TRES peur du vote électronique. Entre les belles théories cryptographiques et la pratique, il y a un fossé de quelques années lumières. Pis les langages de programmation connus par une ou deux personnes au monde, ca aide pas pour verifier le bordel.

Bah en dernier recours, pourquoi pas :)
Par contre j'aurais plus tendance de faire ca a l'arret histoire de pas trop faire de head crash

Tu penses sérieusement que le vote électronique par le net pourrait être acceptable ?

Je ne pense pas : la confidentialité n'est plus du tout respectée sans isoloir...

Les symptomes étant clairement posés, je préconise le lance flamme ;P

Oulalala,
mais c'est un furax le gas !
je me demande ce que penseraient ses boss de lui en lisant ca...
Ptet qu'il passent leur journée à s'insulter et à parler de choses qu'ils ne connaissent pas dans la boite ?

En tout cas c'est toujours aussi affligeant de voir que la betise humaine n'a pas de limite...

et en plus c'est vrai par une boite de merde qui vire pleins de gens pour delocaliser là où c'est moins cher

> > D'ailleurs, vu l'allure du scroll dans konsole, j'ai l'impression que c'est comme ça qu'il procéde.
> Et koncole gère utf8 ?

je sais bien que pour traiter correctement de l'utf8 il faut eviter de lire 1 octet sur trois dans le flux, mais rien n'oblige de tous les afficher, donc je vois mal ce que vient faire l'argument d'utf8 lorsqu'on te décris une méthode simple pour éviter de laguer monstrueusement !


> Mais certains projets préfèrent ignorer les "klingons" pour une optimisation dont 98 % des gens se foutent complètement.

Une fois encore, tu crois qu'une opti détruit des fonctionnalité là où elle est seulement extrèmement logique (et extrèmement commune au point d'être connue par quiquonque ait fait un peu de prog d'affichage en mode texte)

Ben le frame buffer c'est un mapping de la mémoire de la CG dans l'espace d'adressage de l'utilisateur, en schématisant. C'est ultra simple et ultra limité, mais pour une GeexBox c'est vraiment parfait.

X c'est un énorme truc bourrin, qui dispose certe de qualités, mais qui sont de moins utiles aujourd'hui surtout fasse aux défauts qu'elles procurent (d'autant que windows & co est en train (dans une certaine mesure) de rattraper son manque de modularite graphique, sans pour autant que les trucs locaux en souffrent). X permet par exemple de déporter l'affichage avec une modularite extrème (une appli peut par exemple gerer l'interface utilisateur d'un soft, et une autre tournant sur une autre machine avec un autre archi peut très bien s'occuper de l'affichage d'un contenu quelquonque (mettons une image du ciel) dans l'IU de l'autre).

Malheureusement X est de trop bas niveau en ce qui concerne les primitives qui transitent par réseau, X est de trop haut niveau pour gerer des trucs videos ou 3D en local sans extension, et les extensions rajoutent une lourdeur supplementaire à X. En gros il faudrait faire une espèce de quadrature du cercle pour rendre tout ca parfait.

Les équations de maxwell te suffisent pas pour le démontrer ? ;)

Pour être certain d'avoir un truc qui tient la route, tu devrais acheter une petite machine de la taille d'un emplacement 5"1/4, un modem ADSL ethernet à la con, et te faire un vrai routeur sous nux sur lequel tu pourras foutre toutes les règles que tu veux (ou un BSD, je suis pas integriste :), et même du QoS si tu es courageux !

A mon goût les modems routeurs grand public supportent bien trop peu de fonctionnalités, alors si en plus y'en a pas un qui fonctionne correctement ca ne sert plus à rien (sauf peut-être si on a 2 machines qui font de l'http, et encore... pas trop violement !).

<ironique> A noter que d'après les petites images en bas, le site tourne surrement sur un cluster de machines utilisants Mandrake, Gentoo, ainsi que Slackware </ironique>

Flash utilise aussi un plugin avec une license tordue sous Windows...

zut j'ai cliqué sur poster au lieu de visualiser avant d'avoir tout corrigé.
Tant que j'en suis aux propositions qui font travailler les autres ;) :
qu'est ce que vous penseriez d'un bouton visualiser à coté du bouton poster du haut, cad celui juste en dessous de la prévisu ?

PaX n'a donc pas l'air de poser trop de problème si ce n'est la limitation coté espace d'adressage, mais bon on se rapproche de toute facon des limites inhérentes au 32 bits, et à ce niveau là c'est clair qu'il vaut mieux passer au 64 bits que blinder son 32 bits avec 4 Go de RAM, avec du NX qui la ne pose plus aucun problème de retro compatibilite ou autre.
Pour les pocesseurs de "vielles" machines sans NX, PaX ca à l'air bien, mangez en, on est jamais trop prudent coté sécurité !
Je vais d'ailleurs tester ce week end tellement j'aime utiliser intelligement mon materiel et ses protections naturelles :p

Bref tout ce thread pour dire que NX c'est bien beau, mais on savait deja faire avant à peu près pareil, et on pouvait deja techniquement depuis plus de 10 ans... (et me dites pas que j'aurais du m'y mettre et implementer ca moi même, j'etais trop petit ! :)

Quand à implementer quelque chose qui me semble naturel dès le début, à savoir une séparation code / donnée concrétisé par la segmentation correspondante et une chaine de compilation / chargement qui met tout là ou il faut, sans possibilité de passer outre, ce n'est bien evidemment plus possible puisqu'on est plus au début... Mais si quelqu'un dans l'assistance à envi de coder un OS je lui conseille vivement de le faire : à mon gout la sécurité est une priorité des plus grandes, et je ne pense pas que la sacrifier pour de petites simplifications soit une très bonne idée. D'autant que c'est ce mettre dans une situation ou il faudra peut être dans le futur faire des choses bien plus complexes pour corriger le tir !

Je parle pas de pleins de petits segments, je parle d'exactement le meme nombre qu'aujourdhui : un pour le code un pour les données.
J'imagine bien que ca pose quelques pb, sinon ca devrait etre fait aujourd'hui... Mais la question est : est-ce que ca pose plus de problème que ca n'en resoud ? Parce que le nombre d'exploit par buffer overflow est tout de meme impressionnant et aurait ete _tres_ reduit avec un tel systeme (je n'ose pas dire nul, j'ai peut etre oublie quelquechose...)

Update: le noyeau autorise a creer ses propres descripteur de segment dans la LDT et il faut donc desactiver cette possibilité (j'ai vu ca dans le post du dessous qui parle d'ailleur d'un patch qui fait precisement ce que je decris... et qui aparrement pose moins de problème que je l'imaginais)

Oui mais non, tu n'as pas le droit de creer un nouveau segment en mode protege, c'est une tache reservée au noyeau. Quand a mettre le segment de données dans CS, ce n'est pas très malin car le segment de données n'est pas executable.

Quand au retour en segmenté qui ferait faire des cauchemards, je ne vois vraiment pas ou est le problème : on est deja en mode segmenté : il y a un segment de code dans CS et un de données en DS, le truc c'est qu'ils ce recouvrent, et que le recouvrement rend donc inoperant une protection naturelle des x86. 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. Comme le segment de code est dans CS et est utilisé automatiquement par les jump, call, etc, ta pas besoin de préciser le segment. De meme pour les données : le segment de données est dans DS, et est utilisé automatiquement dans toutes les operations d'acces au données. Vu le modèle mémoire du C, il ne faudrait mieux pas separer le segment de données du segment de pile par contre (par contre en java on pourrait...), mais bon c'est pas essentiel de faire ca.

Bien evidemment faire ca aujourd'hui, meme si je pense que c'est possible, serait assez lourd : modification surrement toute la chaine de compilation et de chargement dynamique, du noyeau, puis recompilation. C'est pour ca que je disais que ca aurait du etre fait des le début. Reste que desactiver quasi volontairement une protection pour refaire la meme 10 ans apres a un autre niveau en plus compliqué, qui tourne sur peu de procs de la famille majoritaire x86 (alors que linus a developpé initialement sur x86), n'est pas tres (voir du tout) malin.

PS: evitez de me moinsser pendant 1 semaine, je viens de me recreer un compte et il m'est impossible de poster si j'ai trop peu de karma, encore un systeme de controle débile de merde, vu que j'ai voulu ecrire ca hier soir et que j'ai pas pu et que j'ai faillis refermer mon compte immédiatement sous la colere.

Je ne sais pas si c'est inenvisageable d'utiliser ca à cause de la structure des differents OS, mais ca fait TRES TRES TRES longtemps (depuis le i386 et même le 80286 en 16 bits) que les x86 possèdent une distinction segment de code / segment de donnees largement suffisante pour emepecher l'execution de code dans la pile ou le tas. Il aurait peut etre été plus malin d'utiliser ca dès le début plutôt que d'attendre que les fondeurs daignent rajouter un truc redondant au niveau des pages, en faisant par ailleurs le pire gruik illogique en attendant (supperposition on ne peut plus dangereuse (puisque qu'elle rend possible les exploitations des BOF) d'un segment de donnée pour rendre possible l'ecriture, et de code pour rendre possible l'execution).

Bref tout ca pour dire qu'avant de tripper sur des nouveautés loin d'être nouvelles, d'ailleurs, il faudrait ptet prendre le temps de matter l'existant et d'eviter de faire des choses absurdes au niveau design des OS (oui, la supperposition segment de code et segment de donnée est une chose ABSURDE, voir GRAVE si on prend en compte tous les exploit rendus possibles), et de venir se plaindre par apres du processeur sans même s'appercevoir de l'absurdite de sa plainte.

C'etait le coup de gueule du jour d'un psycopathe qui a les trois manuels d'Intel comme livre de chevet.