CoinKoin a écrit 698 commentaires

Dans mon pays je n'ai nullement confiance dans cet ancien service [la poste] (lent et non sécurisé).

Tu as déjà entendu parler d'Echelon? Bien. Comment fais-tu pour envoyer un message à un collaborateur en déplacement, si tu as des raisons de craindre un espionnage d'Echelon (exemple : tu t'appelles Airbus)?

Réponse : Echelon peut intercepter toutes les communications du monde, tant celles qui transitent par internet que par un réseau téléphonique classique, sans fil ou même sans fil satellitaire... SAUF les communications postales, vis-à-vis desquelles il est totalement inadapté.

(Bon, en fait, je caricature, d'une part, la poste présente d'évidents problèmes de rapidité, d'autre part, il existe d'autres moyens (les signaux de fumée... Ou bien l'envoi de 5000 messages, tous avec des informations différentes, le collaborateur connaissant au départ le numéro du seul message qui ne sera pas de l'intoxe... Ca, ça agace profondément les espions), cela dit, la solidité de la poste face à l'espionage électronique est une réalité.)

Oui enfin juger une société sur une personne sur un point précis, ca me semble un peu limite.

On est d'accord.

Je rencontre également le problème mais lors de tag CVS sur de gros repositories (RH9 - LVM et ext3). Le rapport avec Bull ?

Ben, quelle que soit la distribution, ça ne doit pas se produire... A plus forte raison lorsque la société fournit à la fois le matériel et le logiciel! (Jamais entendu parler d'un problème de ce genre avec un serveur Sun ou IBM, ou même Bull AIX).

Pas trop d'accord avec cette affirmation pour avoir vu un client très content de clusters novascale Bull et du travail de peaufinage fait par Bull sur la dernière version basée sur la RHEL 3 et ce la semaine dernière.

Ben tant mieux qu'il y en ait, et j'avoue que je souhaite qu'ils soient tous satisfaits, mais, désolé, ce n'est pas encore le cas partout. Cela dit, tu as raison de rapporter cette expérience, il n'y a pas de raison que seules les impressions négatives soient présentées, j'espère juste que l'exception est chez nous et pas chez ton client...

On dirait que tu n'es pas propriétaire de la console... Comme si tu étais loggé à distance (par exemple par ssh). Maintenant, quant à savoir d'où vient le problème...

Ne me fais pas dire ce que je n'ai pas dit...

Je n'ai pas dit "Il faut interdire tout ce qui peut permettre de violer la loi", mais seulement : "Attention, c'est plus compliqué, il existe des cas où il faut interdire certaines choses qui permettent de la violer".

Ben oui, mais, en fait, non.
Parce que cette andouille de bidouilleur qui contourne le filtrage est fichu de créer et de distribuer un logiciel qui fait de lui-même toutes les reconfigurations nécessaires, et ce logiciel se diffusera tellement vite que toutes les mesures mises en place seront obsolètes dans les deux mois...

Le souci d'indépendance nationale, par exemple? C'est à ma connaissance le dernier constructeur d'ordinateur européen...

(Je parle bien de constructeur, pas d'assembleur, hein).

Autre point (qui illustre assez bien les problèmes liés aux logiciels propriétaires) : devine qui a conçu les logiciels aux sources jalousement gardés qui pilotent les centrales nucléaires françaises? Ben oui, Bull. Maintenant, dis-moi : comment l'état français peut-il se permettre de laisser couler Bull? Arf...

P.S. : Je ne le leur reproche pas, à l'époque, le libre n'existait guère, et laisser trainer les sources d'un code pareil serait évidemment une énorme menace sur le plan militaire (imaginons le terroriste programmeur qui découvre qu'il suffit de boucher la prise d'eau de la centrale une seconde sur deux pendant deux minutes pour déclencher l'arrêt d'urgence de tous les réacteurs, et dont le groupe décide de tenter cette manoeuvre sur dix centrales en même temps...), donc, si ça n'avait pas été Bull, ç'aurait été une autre boîte... Mais cela montre bien ce à quoi on peut être réduit quand on ne maîtrise pas son code source.

Et tu fixes où la frontière ? Parce qu'avec ce raisonnement, on pourrait interdire beaucoup de choses... je peux faire des actions illégales avec un couteau de cuisine, par exemple...
Ta comparaison avec les mitraillettes est un peu biaisée. Une mitraillette a été conçue pour tuer. Son utilisation pacifique comme tu décris est un détournement de ce pourquoi elle a été conçue.

Tout à fait d'accord. Mais ma phrase était là uniquement pour contester le caractère soi-disant aberrant de la décision, en prenant un cas volontairement extrême, de façon à montrer qu'interdire quelque chose sous prétexte qu'il permet des actions illégales n'a rien d'aberrant en soi.

Ensuite, tu as raison, il faut fixer une frontière. Ma mitraillette est nettement du mauvais côté de celle-ci, ton couteau de cuisine du bon côté, pas d'hésitation possible de ce côté-là, mais il faut arrêter de raconter qu'il faut tout mettre à la disposition de tout le monde et interdire seulement les actions illégales qui sont éventuellement faites avec, parce qu'avec des raisonnements pareils, on en arrive exactement à la situation du Texas, où la possession d'une arme à feu est autorisée, et c'est seulement son usage contre un autre etre humain qui est interdit.

Cela dit, je pense aussi que l'interdiction du peer-to-peer n'est pas une solution, ce que je conteste, c'est l'argument qu'emploie fleny68.

Par ailleurs interdire le p2p sous prétexte qu'il permet la contrefaçon, c'est la même chose qu'interdire la vente de photocopieuse, de scanner, et d'appareils photos. C'est une aberration.

Oui, enfin, d'un autre côté, on interdit bien la vente de mitraillettes (alors qu'on pourrait s'en servir pacifiquement pour fabriquer des passoires industrielles), donc je ne pense pas qu'interdire quelque chose sous prétexte qu'il permet des actions illégales soit une complète aberration :-).

Et chvt, il marche ou pas?

Hé ben, on est bien partis...

Evidemment, il est normal que le CEA, organisme français, choisisse Bull pour construire un supercalculateur. Le problème, c'est que Bull, spécialiste d'AIX, n'est pas du tout au point avec Linux.

Là où je travaille, on a récemment reçu un serveur Bull Itanium fonctionnant sous Linux. Les utilisateurs, actuellement, en sont tout à fait satisfaits : puissant, stable, etc...

Mais il y a pas mal de choses qu'ils ne savent pas à son sujet. Ma première surprise a été en discutant avec l'un des spécialistes : c'est moi qui lui ai appris qu'il fallait faire init 1, et non init s, pour passer en single-user mode (parce que c'est plus propre).

Bon, ça, ce n'est pas bien grave. Ce qui est plus gênant, c'est que la distribution Linux de Bull est une Redhat modifiée... mais pas assez modifiée. Par exemple, qui peut m'expliquer quelle est l'utilité de faire une "recherche de nouveaux périphériques" lors du boot d'un serveur?? Et pourquoi les touches magiques avaient été laissées activées, dont la touche "break" déclencheant le débogueur kernel, alors qu'il n'y a qu'un clavier usb et aucune prise pour clavier standard? (ça nous a valu un joli freeze+reboot, ça.)

En plus, avant de le rendre opérationnel, il y a eu tellement de problèmes (quand on compilait, les disques tombaient de temps à autre en Read-only... Et il ne s'agissait pas de Lustre, mais d'ext3!) qu'il a fallu réinstaller plusieurs fois le système!

Bref, sans chercher à médire de Bull, j'estime qu'il s'agit d'une entreprise qui n'est actuellement pas du tout au niveau concernant Linux, et je crains que le CEA ne s'expose à de belles surprises quand il aura sa machine.

ls -ld /proc/pid, suivi d'un coup de tr et de cut.

cela dit, ps -ef | grep ppp | grep -v grep marche aussi :

$ps -ef | grep ppp | grep -v grep | cut -f 1 -d ' '
coinkoin

Et voila!

Plutôt cat /dev/urandom, ça ira plus vite, et le fait que les infos écrites ne soient pas vraiment aléatoires n'est pas bien gênant.

Pour ce qui est de la destruction physique, je crois que l'acide sur le disque est assez efficace (un peu moins, d'accord, mais c'est autrement plus simple que d'installer une fonderie dans le bureau des secrétaires).

J'ai exactement le même problème que toi avec mon mot de passe root. Je parviens à le taper dans les consoles textes et les terminaux sous X (xterm, Konsole), mais pas dans la petite boite théoriquement prévue à cet effet lorsqu'on lance une appli graphique de reconfiguration de l'ordi.

C'est sans doute dû au fait que mon mot de passe root contient certains caractères spéciaux qui ne passent pas très bien. Moi, je m'en fiche, de toutes façons, je n'aime pas employer le centre de contrôle Mandrake, mais je reconnais que cela peut être gênant. Voici les solutions :

1) changer définitivement le mot de passe root, au profit d'un mot de passe qui marche mieux. Techniquement, c'est assez facile à faire (tu te logges en root dans une console texte, ou bien tu fais "su" dans un xterm, puis tu tapes "passwd"), mais c'est évidemment une solution assez déplaisante (Et pourquoi devrais-je n'employer que des mots de passe qui ne me plaisent pas?)

2) changer de mot de passe root à chaque fois que tu veux lancer une telle application, puis remettre ton mot de passe préféré dès que c'est fait. Bof, c'est assez lourd, et pas très élégant.

3) à chaque fois que tu veux reconfigurer ton ordi, prendre un xterm, faire "su -" dedans, puis lancer l'appli graphique que tu veux. Inconvénient : il faut connaître le nom de l'appli (mais je crois que "drakconf" permet de lancer toutes les autres en mode graphique); avantage : ça reste assez propre.

4) à chaque fois que tu veux reconfigurer ton ordi, prendre un xterm et faire "su -", ou bien te logger en root dans une console texte (ctrl-alt-F1, par exemple, pour revenir : ctrl-alt-F7), taper "echo startkde > ~/.xinitrc (ça, tu n'aura en fait qu'à le faire une seule fois, pas besoin de le refaire à chaque fois), puis faire xinit -- :1 &. Avantage : heu ça marche, et même assez bien, inconvénient : c'est très sale, de lancer KDE en root.

Perso, je recommande la solution 3.

A+!

A mon avis, c'est relativement facile à faire...

Pour la souris, man 4 mouse explique le fonctionnement de ce périphérique. Pour le clavier, ben, man 4 keyboard. Ils sont effectivement tous les deux dans /dev.

Ensuite, pour que cela marche sous X, il faut que tu lise le contenu de ces fichiers, puis que tu les rende à X. La solution, à mon avis, c'est d'ouvrir les fichiers de périphériques, de les unlinker, de créer des fifos à la place portant le même nom, de créer quatre threads (une par fifo et une par fichier d'origine), deux buffers de petite taille, puis de lire les fichiers d'origine avec les threads, d'en faire ce que tu veux, et de placer leurs données dans ces buffers, les deux autres threads se chargeant, lorsqu'elles sont réveillées, de lire le contenu des buffers et de l'ecrire dans leur fifo.

L'idée, c'est que si personne n'a ouvert tes fifos, les deux threads d'écriture resteront bloquées, et attendront patiemment que quelqu'un les ouvre pour écrire. Il est évidemment préférable que les données non lues sur-le-champ soient purement et simplement _perdues_ (ben oui, quoi, quand je démarre X, je n'aime pas qu'il reçoive tous les mouvements qu'a fait la souris depuis une heure...), donc tu peux y aller bourrin pour les buffers.


Bon, finalement, je me relis, et je me dis que ce n'est pas aussi simple que ça en avait l'air. Mais bon, tu vois, à mon avis, il n'y a absolument pas de raison de faire du code kernel pour réussir ton démon.

Bonne chance!

Bizarre... Tu n'as plus de clavier du tout, ou seulement dans l'écran de login et KDE? Essaie de taper ctrl-alt-F1, pour voir... (pour revenir, c'est ctrl-alt-F7).

Essaie aussi les touches magiques (alt-shift-system-K, par exemple), pour qu'on sache ce qui marche et ce qui ne marche pas.

La communauté Linux. Ah, pardon, on ne parlait pas de capacité d'investissement personnel?

Windows XP et SCO dans le même post... Pour un débutant, tu trolles suspectement bien.

Bon, ton FreeSCO (qui n'existe pas, hein, les deux notions s'opposent radicalement), c'est certainement un FreeBSD, qui n'est pas une distribution Linux mais un BSD, c'est-à-dire un ensemble noyau BSD + logiciels. Pour savoir comment elle marche, ma foi, pas trop mal... C'est un UNIX, mais de type BSD, ce qui déstabilise un peu les habitués des UNIX POSIX. Que dire de plus? Ha oui, comme les différents BSD profitent les uns des autres, sa sécurité au niveau réseau, qui a dû bénéficier de celle d'OpenBSD, doit être bonne.

Sinon, si tu veux en savoir plus, ma foi, cherche FreeBSD sur Google, ça ira plus vite.

Je pense qu'il y a un malentendu au niveau de la nature exacte de la source de revenu que constitue le caractère fermé d'un pilote. Aujourd'hui, le but du jeu, lorsqu'un constructeur ne publie pas ses sources, est pour lui, non de gagner de l'argent par le biais d'un quelconque support (je n'ai jamais vu Nvidia vendre un patch pour ses propres pilotes!), mais bien de forcer les clients à acheter plus de matériel, en mettant fin le plus rapidement possible à sa prise en charge.

Vous voulez faire tourner votre scanner sous votre linux-2.6 ? Mais, mon cher monsieur, ce périphérique date d'il y a 2 ans, son pilote n'est plus maintenu, achetez-en donc un nouveau... Quand bien même le client choisirait un scanner d'un concurrent, ça ne changerait rien, puisqu'il y aura bien un client de ce concurrent pour choisir l'un des leurs... Et tout le monde s'y retrouve (sauf le client, mais lui, personne ne lui demande son avis, voyons).

D'où la dangerosité des pilotes libres pour ce modèle économique : si le client peut attendre que son scanner casse avant d'en racheter un, parce que ce stupide pilote est maintenu à jour, et si le scanner casse dans 4 ans, eh bien, ça fait 50% de ventes en moins!

Ce qui explique pourquoi les constructeurs de périphériques n'ont strictement aucun intérêt à voir apparaître des pilotes libres.

En fait, la seule raison pour laquelle certains en font, c'est que les distributions Linux refusent généralement les pilotes propriétaires, par conséquent, dès qu'un concurrent à la traine décide, pour survivre, de collaborer à des pilotes libres, il risque de s'emparer d'un marché potentiellement très vaste, chose bien sûr inacceptable pour celui qui domine le marché propriétaire.

Cf. nVidia contre ATI...

Mmh... Il ne les supporte pas, ou seulement pas encore? Parce qu'il est encore en développement...

Leur condamnation, pour détournement de logo, a été cassée depuis.

Rectificatif : l'auteur me fait savoir que :
1) Le projet ne tourne pas au ralenti (sauf si on se réfère au site web);
2) s/seront/sera/g
3) Cela n'est plus un programme, mais une bibliothèque C++,
4) Ce n'est pas dynamique, mais statique :-( . Cela dit, connaissant l'auteur, je pensais bien qu'il ne fallait pas s'attendre à du dynamisme... (Il lit ça par-dessus mon épaule, il n'est pas content, mais tant pis pour lui, je poste!)

Va voir du côté de : http://www.magieeternelle.org/aldeia/(...) . Le projet tourne un peu au ralenti, mais, si tu les solicites, je pense qu'ils seront prêts à t'aider...

Bon, cela dit, ce n'est pas une bibliothèque, mais un programme complet.

Explication 1 : Tu es un bourrin qui utilise un ordinateur avec plus de 4Go de RAM, tu as changé de version de cc1plus, la nouvelle version est boguée et comporte une fuite mémoire.

Explication 2 : Ta version du noyau a changé, et la version actuelle est boguée, ou bien tu as fait trop d'uptime avec une version boguée.

Il y a quelque temps, quelqu'un ici avait posté un message à propos d'une fuite mémoire en 2.6.9 ... Comme le kernel est résident en mémoire, cela pourrait l'amener à tuer des processus pour récupérer leur RAM, alors même qu'il n'y a pas de problème pour leur allouer de l'espace de swap. Cela dit, il faudrait pour cela que le bogue affecte aussi la gestion de la mémoire virtuelle (parce que sinon, il devrait justement chasser ces processus sur le disque, à moins qu'il reste trop peu de place pour permettre le chargement d'une quantité minimale de code pour cc1plus?) .

Explication 3 : Tu as placé une limite de taille mémoire par processus, et cette limite est trop basse pour compiler ces programmes.

Explication 4 : Il existe une autre explication. Ca, malheureusement, ça arrive souvent :-( .

Et là, tu lui répondras, l'air désolé : "Mais voyons, fiston, ce système est devenu totalement introuvable depuis la faillite de son éditeur, il y a dix ans..."

D'ailleurs, parfois, on a :

CoinKoin@chezmoi:~$ cat "bouquin à la $$$" | grep interessant | wc -l
0
CoinKoin@chezmoi:~$