Sytoka Modon a écrit 4551 commentaires

J'aime pas le design, cette grosse fenêtre qui n'arrête pas de changer en haut, c'est très pénible. La barre du haut est trop grande...

Et puis, je n'aime pas l'idée de fond. La différence entre les distribution Linux et Windows est que les choix sont fait en local. Je n'aime pas du tout cette idée de centralisé ce que j'installe, cela fait très big-brother.

Bref, je n'aime pas du tout les objectifs et je pense que toutes cette énergie pourrait être mise sur synaptic ou aptitude-gtk.

Il est tout a fait possible de faire des clients lourd jolie... Cet n'est pas le web qui a inventé la séparation du contenu et de la forme. C'est déjà dans MOTIF avec les Properties ! On pouvait alors modifier tout objet. Malheureusement, Qt et GTK par simplicité n'ont pas repris ce système et sont partis sur la voie des thèmes. MOTIF était absolument génial et un peu de l'énergie mis dans les navigateurs auraient mis été dans MOTIF que nous aurions un MOTIF qui déchire de nos jours.

Bref, votre truc me fait penser aux réseau sociaux. Comment mixer réseau social et installation de programme, avec vue central à la big brother. Peut être n'ai je pas tout compris mais tout cela me laisse un gout très amer.

Question : vis à vis de SPICE (Red-Hat), les deux se positionnent comment l'un de l'autre ?

Question subsidiaire : Google va-t'il pousser à l'intégration dans Xorg et dans ssh.

Autre question : NX peut faire proxy VNC ou RDP. C'est très pratique pour atteindre une machine à l'intérieur de son parc mais je ne sais pas faire "simplement" avec du proxy NX ! En gros, il est plus facile depuis chez soi en ADSL d'atteindre via un serveur ssh ou il y a NX son poste de boulot Windows (RDP) que son poste Linux (X) !

C'est pas aussi bien. ssh -CX avce l'ADSL se traine bien plus !

OK, merci. Si tu met les personnes dans un groupe, cela ne suffit pas ?

J'ai d'ailleurs l'impression que la gestion des droits sur un groupe merdoit dans la dernière version.

Tu as réussit a faire marche le freebusy avec davical, chez moi, cela ne marche pas ou je n'ai rien compris de comment le faire marcher...

X est le diminutif mais j'ai toujours entendus parlé de X-Window (qui dérive de Window qui dérive de View (V->W->X->Y), Y-Window projet de remplaçant pour X mais qui doit être mort à l'heure actuelle).

A noter que les versions des PDF est aussi marqué dans le document. Donc ce n'est pas n'importe quel PDF qui est valide. Après, il y a des subtilités norvégiennes dans le texte que je ne comprends pas ;-)

> ne prenez surtout pas les propos de zenitram pour la véritée

Tout a fait d'accord. Toutes les grosses distrib modifient le code des applications, donc dès qu'il y a modif, il y a risque. Il n'y a que ceux qui ne font rien qui ne casse rien.

On a déjà parlé de ce bogue ici, on va pas refaire encore une fois de l'anti-debian primaire... Je rappelle juste que Red-Hat et Novell se sont bien abstenus de tout commentaire négatif à l'époque.

Mon propos avait juste pour objectif d'aider Victor dans sa recherche du hasard.

> des personnes connaissant (très) bien les générateurs de nombres aléatoires... ce qui
> est très rare.

C'est une problématique bien connu dans les labo de recherche. On travaille sur des domaines pointus et donc l'audit n'est pas facile. On tourne assez rapidement sur toujours les mêmes personnes.

Sinon, je ne connais pas du tout OpenSSL sauf en tant que simple utilisateur lambda. Je vois juste que c'est un composant fondamental et qu'il y a régulièrement des bogues. En fait, je trouve dommage qu'OpenSSL et que GnuTLS ne soit pas plus interchangeable.

Enfin, j'ai essayé de faire une liste de type checklist des bonnes pratiques pour ce genre de composant. Cette checklist est bien sur à améliorer.

Concernant plus spécifiquement le code du bogue debian, je crois me souvenir que la ligne capitale qui a été retirée n'étais pas spécialement commentée et surtout, qu'il y avait un certain nombre d'appel du "même" type. C'est en ce sens la qu'il y a peut-être une amélioration à voir.

Ce qui prouve au moins une chose, que malgré la bourde du mainteneur debian, introduire un bogue dans ce genre de programme peut être très difficile à déceler. Il faut donc que ce genre de programme lié à la sécurité valide les critères suivants :

- toujours faire auditer le code par des personnes extérieures

- passer tous les tests des compilateurs (et équivalent : valgrind...) sans aucun warning

- avoir un code très propre et bien documenté aux passages critiques

- avoir une API simple et claire

- avoir une batterie de test la plus large possible

Malgré cela, on n'est pas à l'abris d'un bogue subtile. Pour revenir au cas d'openssl, le développeur debian a fait une bourde mais je le projet openssl ne passe pas non plus le genre de critère que je viens d'énoncer.

Dans le cas de debian, le problème était sur le PID... Pour détecter cela, il faudrait lancer des tests sur n machines virtuelles vierges que l'on démarre puis lance le test dessus.

Sur la version de debian, si tu lançais 10 générateurs, tu ne voyait pas le problème...

Bref, il faut lancer dans ces cas là des tests sur un cluster (virtuel ou physique).

OK, refaire la même liste est très pratique mais il y a plein de cas ou on s'en fou. Par exemple pour marquer les paquets TCP/IP.

Pourquoi ne pas introduire tous les x pas de temps, x aléatoire, la température du CPU dans la formule ? Cela rajouterais un aléa quasi imprévisible et éviterait même au "propriétaire" de rejouer la séquence.

> tout le monde s'en fout!

Non, on ne s'en fout pas mais tu ne peux pas vivre en pensant 24h sur 24 à toute la misère dans le monde. Certaines personnes le peuvent mais pas toutes.

Donc on y pense souvent mais notre cerveau a besoin aussi de rigoler, de plaisanter... C'est pas incompatible, au contraire. Cela signifie que malgré la misère, l'homme est capable de construire des îlots de bonheur.

Bref, soutenir la cause tibétaine et ne pas y penser en permanence ne me semble pas incompatible avec l'envie de construire pour ses enfants un monde correct.

> Chirac quand quelques kanaks ont eu des velléités d'autonomie ? Il a tiré dans le tas.
> Depuis black-out total, ou presque, circulez, y a rien à voir

Depuis, il y a eu Rocard qui est passé par là et qui a réglé le problème de manière posé et a mis les partis en présence d'accord sur une période transitoire et le conflit s'est dégonflé.

Il ne faut donc pas tout mélanger...

-3- C'est une machine à registre

-4- C'est un projet communautaire

-5- Elle est très jeune mais déjà plus de 60% de perl6 tourne dedans.

Bref, elle entre dans sa phase finale comme perl6... Normalement, d'ici 1 an, les bogues majeurs empêchant son utilisation dans des projets majeurs devraient être corrigés. Le but de l'année qui vient est donc qu'un maximum de projet ambitieux (comme perl, python, ruby...) porte leur langage sous parrot pour la corriger.

Enfin, moi, c'est free qui refuse les courriels qui viennent des serveurs de chez Amen... J'ai demandé a Amen de faire quelque chose mais c'est comme si je ne demandais rien. Ils sont polis mais rien ne se passe. Vive l'herbergement mutualisé !

Je viens d'aider un copain qui avait un problème sur pam_mount suite a un upgrade du système. Et bien le format XML de ce truc est une horreur (erreur serait plutôt le mot). On se demande si les mecs qui ont pondu ce code sont administrateurs systèmes ou si ce ne sont que des développeurs qui 'pissent' du code au kilomètre !

Pour ceux qui ne voit pas de quoi je parle, sur une debian, le fichier en question est :


/etc/security/pam_mount.conf.xml

Merci.

Je me rappelle que Keith Packard annonçant après plusieurs mois de boulot qu'on ne pouvait pas améliorer la latence et le traffic d'X-Windows. Que tout ce que son équipe avait réussi en optimisant ici ou la le code était du même ordre de grandeur que la compression gzip réalisée par ssh avec l'opion -C. Bref, il concluait que le protocole X n'avait pas été conçu pour les faibles bandes passantes et qu'il n'y avait pas grand chose à y faire...

Puis, peu de temps après, No-Machine sortait NX qui permettait de faire du X sur des liaisons ADSL ! Personne n'y a cru mais on avait tous tords... NX marche super bien.

Bref, tout cela pour dire que bouffer du CPU pour compresser par gzip les fichiers XML tout cela parce qu'on pense que le XML ASCII, c'est génial et qu'on fera pas mieux, comme toi, je ne suis pas d'accord.

Il est bien plus rentable de passer des tableaux de nombres réels via HDF5 ou NetCDF qu'en XML ou il faut les écrire avec la quinzième décimale et ou cela prend un place folle et n'est pas du tout optimale pour le transfert.

Contrairement à NetCDF très orienté tableau, le format HDF5 permet de stocker une structure arborescente. C'est pour cela que j'ai parlé de lui. Ce serait intéressant d'avoir sur ce genre d'outil un portage de l'API XML, rien que pour voir.

Par rapport a NX, cela donne quoi ? Pourquoi ne pas avoir intégré NX dans Xorg ? NX est déjà libre et opérationnel même s'il est parfois casse pied à mettre en oeuvre car pas toujours bien intégré au reste.

Que ceux qui mon moissé explique leur position !

Le XML n'est qu'une manière d'écrire un arbre. Si sa principale utilisation est dans le dialogue inter-machine, autant avoir un format binaire NORMALISE. Ensuite, avec un petit utilitaire, tu peux transformer cet arbre binaire en arbre XML et réciproquement.

Bref, je ne vois pas ou l'idée d'avoir un XML binaire est une mauvaise idée. Au contraire. A partir du moment ou on manipule l'arbre XML via des API normalisé, il suffit d'utiliser les mêmes API sur le format binaire. En plus, avec un format binaire, on est obligé de passer par les API et c'en est finit du XML non valide (type XHTML).

Ce qui est dommage, c'est que quitte a faire un format pour la machine, autant faire un format binaire plus performant a tout les égards et qui ferait la même chose. HDF par exemple ou un équivalent.

Bref, on a mis des millions d'heure de travail humaine pour un truc qui finalement est surtout utilisable par la machine mais celle-ci travaille bien mieux en binaire qu'en ASCII... On aurait mis cette énergie sur HDF (ou équivalent) qu'on aurait des programmes bien plus performant de nos jours.

C'était fonctionnel avant ce soir ;-) Je travaille depuis 1996 a 95% sur du Linux (le restant étant lorsque je dépanne ;-)) et en 1996, il n'y avait pas encore de boite derrière. Linux était déjà parfaitement fonctionnel pour un tas de chose. Lorsque je vois les problèmes actuels sur ma lenny parce que ldap merdouille au démarrage (il y a une solution), les clefs USB merde à cause qu'udev et hal ne tienne pas compte de pam_group... Bref, on a compliqué la partie logiciel a parfois en perdre de la simplicité d'UNIX !

A l'époque, je préférais mon bureau fvwm à un Windows 95 !

Attention, ton script ne marche pas en interactif. En effet, les règles par défaut bloque la connexion... En script cela marche car la connexion est coupé mais avant que ssh coupe la connexion via un timeout et donc que le noyau tue ton script, celui-ci est finit.

Bref, je n'aime pas les scripts de firewall qui joue sur les timeout système pour leur mise en place. J'aime bien pouvoir faire un copier coller et que les choses ait exactement le même comportement. Dans mes scripts à moi, je comme TOUJOURS par les lignes suivantes :


# Policies
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT


Puis, j'accepte en entrée sortie (deux règles écrites explicitement) tout ce qui concerne la loopback (lo). Dans ton script à toi, il n'y en a qu'une car il y a une règle implicite sur la loopback. Je n'aime pas les règles implicites...

Enfin, je finit sur le bas du script par les règles par défaut définitive


iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP


En effet, j'écris aussi des règles explicites sur la chaîne OUTPUT. Je trouve plus clair d'écrire à coté des règles d'entrée INPUT le correspond pour la sortie OUTPUT que de laisser tout sortir.

Moi, la révélation, je l'ai eu avec le Forth car avec lui, tu reconstruis le langage lui même... A coté, le C, c'est pauvre ;-)

J'ai pas le souvenir de cette annonce par Intel. Lien ?

J'étais resté sur le rapprochement fait par intel entre le x86_64 et l'Itanium qui devrait partager le même socket l'an prochain afin de pouvoir avoir des cartes mères avec l'un ou l'autre des processeurs.

Aujourd'hui, on ne sais pas encore faire de machine SMP a 1024 coeurs x86_64 alors qu'avec l'Itanium oui.