Sytoka Modon a écrit 4551 commentaires

Je suis convaincu que l'azerty n'est pas idéal question position des lettres. Par contre, au niveau clavier droit ou penché, j'ai des doutes. La main droite sur un accordéon utilise un clavier penché et cela marche très bien. En fait, le clavier étant horizontal (pour la plupart, Microsoft en fait en deux parties), les doigts ne se déplacent pas verticalement mais en biais. Obligé les doigts au déplacement vertical oblige à caser le poignet.

Bref, c'est un sujet complexe qui mériterait une vraie recherche par les SHS.

J'ai eu des soucis avec la variable PATH. Dans le cron, elle est très restrictive. Donc bien mettre les chemins en dur dans ton script ou bien définir le PATH en début de script.

C'est à la fois de l'humour pour montrer que moi aussi, je sais en faire, mais aussi, le fait de passer en négatif montre que pas mal de personne sur ce site considèrent normal cette blague nulle de Linus et prennent mal mes remarques sur ce sujet. Donc je trouve que j'ai raison de me battre contre, pour le souvenirs des millions de personnes qui ont souffert et/ou ont été massacré par le nazisme.

Ceci dis, s'il y a d'autres personnes qui sont sur ma longueur d'onde, manifestez-vous lors de post dans ce genre. Je ne suis pas un spécialiste ni de l'histoire, ni de la mémoire.

Cela maintenant des mois que cette blague nulle traine ici... Ce n'est pas la première fois que je m'insurge contre (et qu'a chaque fois, je passe en négatif, comme quoi j'ai bien raison !).

Oui, cette tentative d'humour m'embête parce qu'elle est récurrente et qu'elle détourne complètement un sujet grave en banalisant ce mot. Une blague sur le sujet est acceptable si justement elle a un lien avec le sujet et qu'on ne la ressorte pas à chaque fois.

Sinon, je te rassure, je ne l'ai pas pris au premier degré, j'suis con mais pas a ce point là -)

> Oui, c'est pour ça qu'on se moque de lui.

Linus ne lit pas dlfp, donc tu ne te moques pas de lui, tu ne fait que dénaturer le nazisme, c'est donc exactement l'effet inverse qui se produit.

Pour la finlande, c'était la suède qui était neutre je crois. Désolé.

Je suis d'accord pour dire que Perl s'est endormis... Python a pris la cote et pourtant, je ne l'aime pas personnellement et ne lui trouve rien de vraiment sympa. Ruby est sympa mais ne prends pas tant que cela je trouve...

Mais cela pourrait changer. Parrot est maintenant là pour les développeurs, Perl6 arrive... La sauce va t'elle reprendre ?

C'est pas parce que Linux utilise très mal ce mot qu'il faut faire de même. Linus fait lui aussi des "conneries" et celle là en est une grosse.

Par ailleurs, Linus ne vit pas en Europe et il est né dans un pays qui était neutre il me semble... (même si il n'as toujours été clair, comme la Suisse...).

Bref, il y a 10000 autre manière de se moquer de Linus que de ressortir a chaque fois cette blague de très mauvais gout.

Voila ce qui est rattaché a ce mot

http://fr.wikipedia.org/wiki/Camps_de_concentration_nazis

merci de ne pas dénaturé ce mot par des blagues nulles.

S'il te plait, regardes un peu l'histoire du milieu du XXeme sciècle avant de parler de méthodes nazies. Ce n'est pas parce que des personnes travaillant aux USA en parlent en informatique qu'il nous faut nous le faire.

Il n'y a rien de nazie chez les développeurs et c'est une insulte que de sortir ce mot là sous dflp pour tout et n'importe quoi. A l'employer à tord et à travers, vous diminuez la valeur de ce mot, valeur qui en gros dis : "Plus jamais ca".

Ben si tu sais, pourquoi tu mets 4 points d'exclamation !

Il faut aussi remarquer que le XML n'a pas été fait pour l'Homme (mais par lui), c'est très très lourd comme langage. TeX s'adapte au contexte, le meilleur exemple est celui des formules mathématiques, mais on peut aussi parler des tableaux basiques. On peut aussi regarder du coté du format de bibtex... Bref, c'est clairement conçu pour être pratique dans un éditeur ligne à ligne.

En effet, cela ressemble a du cygwin et je n'ai jamais réussi a savoir comment on gère du cygwin facilement sur un parc en le déployant automatiquement et de manière silencieuse (avec mise a jour par la suite et tout et tout)...

Bref, c'est un truc de développeur qui sont admin de leur poste !

Pourquoi veux-tu imposer une règle aux autres que tu ne t'imposes pas à toi même...

Raz le bol d'obliger les personnes à vouloir prendre mandriva... Comme dis ci-dessus, il y a des procédures avec appel d'offre.

Je rappelle que debian est très bien ancré en europe et en france en particulier. Combien de développeurs debian en Europe et combien de développeurs mandriva ?

Et puis, il y a la Suse...

Bref, pour un ancien qui a bien connu les problèmes avec BULL et Thompson, tu nous gonfles un peu avec Mandriva à chaque fois !

T'as combien de serveur pour arriver à faire une migration en une seule semaine ?

> J'avoue être troublé que certains ne comprennent pas l'avantage de cette fonctionnalité.

Parce que tu es dans un stratégie mono-utilisateur avec une vision bureau graphique et click click click...

J'ai quatre utilisateurs, je fait une file globale ?

Mes programmes tournent et font des copies, ils attendent la file globable ?

Je veux un système multi-utilisateurs, multi-tâches. Le disque n'a pas à gratter, avec le sata, l'ordonencement des ordres, les caches... normalement, c'est à l'OS de se débrouiller pour faire cela. Ici, on veut amener une fonctionalité de l'OS sur le bureau... avec un démon encore de plus.

Si l'OS ou le système de fichier sont mal conçu, modifiont les plutôt que de passer de l'énergie sur un truc réducteur et qui met en évidence la mauvaise conception de l'OS ou des applications graphiques (comme dis dans un post, ionice, cela existe).

Cela me rappelle gnome-vfs et toute cette daube inutilisable en ligne de commande mais uniquement pour les applications du bureau considérer (gnome d'un coté, kde de l'autre avec kio). L'énergie aurait du dès le début se faire sur fuse ou équivalent et donc de faire quelque chose dans la couche base.

Exemple de daube graphique. Sur une debian (je ne sais pas pour les autres), les clefs USB ne se monte pas sur le bureau si l'utilisateur est sur un annuaire de type LDAP et qu'on lui donne le groupe plugdev au lancement de la session avec pam_group. Pourquoi ? parce que tout dépend d'un démon dbus qui est lancé avant l'ouverture de session... (je crois que c'est corrigé sur ubuntu). Bref, tout cela pour dire que ces machins globaux nous compliquent la vie et que le système des droits et ainsi de suite devient de plus en plus nébuleux.

> La suite logique serait de pouvoir définir des règles globales

Il faut aussi arrêter de vouloir transformer un OS multi-utilisateurs multi-tâche multi bureau en OS à variable globale mono-utilisateurs mono-bureau mono-tâche...

Les machines global avec les démons qui tournent de partout, tout cela pour que lorsque je change le paramètre epsilon, tout change d'un coup, je pense que c'est une voie très dangeureuse pour la sécurité du système.

UNIX est assez simple à la base et un des fondamentaux de la programmation est d'éviter les variables globales. Donc lorsque je lis une phrase comme celle ci-dessus, je dis danger, on est en train de partir dans une mauvaise direction et on va avoir des bureaux très sensibles aux virus si on continue dans cette direction.

C'est linux.com et non linux.org, donc c'est du contenu en .com. Le public visé ne me semble pas celui de linuxfr et cela ne me choque pas qu'on n'y aille pas souvent. C'est plus dédié décideur. Il faudrait en parallèle un linux.org (qui existe, je viens d'aller voir).

Il n'empêche que j'ai vu que SystemRescueCD avait sortie une nouvelle version. J'ai donc appris quelque chose d'intéressant en allant la bas.

C'est même limite illisible. J'ai passé plusieurs minutes à m'y retrouvé.

Un peu de formatage SVP si vous souhaitez plus de lecteurs. Merci.

Et toi, tu en bégaie ?

> Mais Debian passe son temps à ajouter des patches.

Je ne suis pas sur que Red-Hat (et Fedora) et Novell patchent moins... J'aimerais avoir des vrais statistiques que ce genre de phrase gratuite.

> Donc plusieurs heures pour installer cette douille

Il serait temps de remettre les travaux manuels aux collèges et aux lycées !

Moi je dis que s'il faut couper le courant pour changer une ampoule, c'est qu'il y a manifestement un problème de conception (sauf si ampoule cassée).

Une ampoule morte, on doit la prendre et en mettre une autre comme on branche un poste radio sur une prise, sans se poser de question.

Je n'ai jamais eu de soucis avec les baïonnettes alors que les ampoules à vis passent leur temps à se dévisser... Mettre une vis me semble aberrant même si c'est la norme par défaut d'aujourd'hui. Tu te vois visser la prise de ton poste radio dans le mur ? Alors pourquoi nous oblige t'on à faire cela percher sur une chaise les deux bras en l'air ?

A mon sens, un des soucis de ce genre de réseau (PGP/GPG ou SSH) est qu'il est basé sur des clefs ayant la plupart du temps une durée de vie infini. Donc on monte son réseau et puis un jour ... patatras, il y a un article qui dis que les clefs ne sont pas si géniale que cela à terme.

Au final, cela me donne comme pour SSH le sentiment d'un défaut de conception. Les clefs de chiffrement à usage pour le réseau devrait toujours avoir une durée de vie limitée (c'est souvent le cas des certificat X509 que le trouve pour les sites HTTPS, mais pas toujours). La durée de vie limité résout à terme le problème des failles inévitable (cf carte bleu).

La solution de la révocation n'est pas bonne car elle demande au client d'aller voir des listes centralisées, de se mettre à jour et que celui-ci ai effectivement implémenté ce mécanisme de révocation. Bref, c'est bien mais pas assez fiable pour se baser la dessus sur du long terme.

A partir du moment ou les clefs ont une durée de vie limité, il faut dès la conception penser à la mise à jour de ces clefs et assurer la période transitoire à deux clefs. C'est souvent mal fait, même sur les certificats X509. Le CNRS a d'ailleurs été confronté au passage aux certificats CNRS2 il n'y a pas longtemps et nous avons deux ans pour mettre à jour tous nos certificats dans les laboratoires. Malgré cela, pas mal d'applications n'aiment pas le changement de certificat. Par exemple, comment mettre à jour le certificat de mon serveur OCS qui me déploie mes logiciels sachant que celui-ci a soit le nouveau, soit l'ancien certificat mais ne peut pas avoir les deux ! Cela se mors la queue et je n'ai pas trouvé de bonne solution intégrée dans OCS...

Au final, je dirais qu'il y a du travail sur la planche pour que les développeurs de ces applications modifient leurs protocoles pour tenir compte de cet aspect temporel et que le protocole lui-même gère la phase de transition avec une mise à jour automatique des clients vers les nouvelles clefs et que les deux clefs soient équivalentes pour les clients. Pour le moment, un serveur web ou ssh ne peut avoir deux clefs !

Debian l'a bien compris puisque chaque distribution est lié a une et une seule clef. Lorsqu'elle sors une distribution, la clef de la future stable est déjà dans le paquetage keyring pour que la mise à jour de la stable vers la future stable (testing) puisse se faire sans hurlement de la part d'APT. C'est ce genre de mécanisme qui doit être pensé et généralisé, bien sur en s'adaptant à la problémtique !

J'ai motivé ma belle mère a prendre Ordissimo. Pourquoi ? Parce qu'elle débute l'informatique à 76 ans, qu'elle n'habite pas la même ville que moi et que je ne veux pas faire son support, je fais déjà cela toute la journée au boulot et même parfois le soir à la maison ou chez quelques potes ;-)

Donc Ordissimo m'a paru il y a 6 mois la meilleure solution et elle s'en sors pas si mal.

Il faut arrêter d'avoir peur de tout et de stresser sur le minitel 2 à la moindre annonce. Il y a des personnes qui n'y connaissent rien et qui souhaitent juste utiliser l'outil dans un cadre très simplifié. Ce genre de solution a plus de chance de leur convenir que nos distributions préférées. Tant mieux.

Je préfère voir ma belle mère profiter d'internet sur un poste adapté que de la voir bêtifier devant TF1 ;-)

Je pense que tu as parfaitement résumé la chose en une ligne. A l'époque, je me souviens, gcc ne bougeait pas et egcs apportait vraiment du plus a nos programmes. Heureusement, les personnes ont à l'époque réussit à rediscuter et à refusionner pour reformer gcc.

Cela n'a pas été le cas avec XFree ou Sodipodi qui sont toujours là malgré le fork mais ne doivent plus être très utilisé.

On verra avec cette libc. Je pense que la FSF suit cela de près et pour l'instant regarde avant de prendre une décision. Il faut voir si les personnes derrière la eglibc sont capable de faire vivre ce projet sur la durée.

Comme la eglibc a vocation a rester compatible API/ABI avec la glibc, je ne serais pas étonné qu'il y ai fusion à terme des deux projets si l'organisation de la eglibc fonctionne.

Au final, debian se simplifie la vie et remonte ainsi plus facilement ses bogues pour les partager (cf pb du bogue introduit par debian dans openssl). Par ailleurs, debian ne prends pas tant de risque que cela car le retour sur la glibc me semble toujours possible sans chambouller tout le projet.

Bref, cela a bien moins d'impact que lors du passage de la libc6 a la glibc2 qui avait foutu un bordel dans toutes les distributions. D'ailleurs, pour ceux qui se rappelle, lors de se passage à la glibc2, cela avait plusieurs fois chauffées entre la glibc et le noyau linux car linus refusait de faire des bidouilles dans le kernel dont le seul but était de contourner des bogues dans la glibc. Au final, la glibc a du corriger ses bogues...