Pour ma part, en tant qu'utilisateur, je pencherais pour KDE car il contient beaucoup plus de fonctionnalité que GNOME. Voici quelques exemple qui concerne principalement le gestionnaire de fichier Nautilus, car le gestionnaire de fichier est, selon moi, une pièce maîtresse de base d'un bureau utilisateur :
- un truc tout bête qui me manque sous GNOME dans Nautilius : lancer un terminal dans le dossier courant. Il est vrai que je peux faire un "Nautilus script" qui effectue cela et c'est ce que j'ai fait, mais ce n'est pas une fonctionnalité standard, tandis que ça l'est sous KDE avec Konqueror ;
- si je veux créer un fichier dans le dossier courant de Nautilus, je dois là aussi faire un "Nautilus script" alors que sous Konqueror c'est déjà implémenté en standard ;
- la gestion des signets pour le système de fichier est plate dans Nautilus : impossible d'organiser mes signets en arborescence pour les classer ;
Ce sont des fonctionnalités basiques très simples, presque insignifiantes au premier abord, mais à l'utilisation, ça fait toute la différence pour moi. Et des exemple j'en ai encore d'autres (notament la gestion des types MIME et l'association des fichiers inintuitives de Nautilus).
Mais malgré tout cela, je fais avec et j'utilise GNOME. Pourquoi ? Pour une raison toute simple : toutes les applications quotidiennes que j'utilise son basées sur GTK+ ou sur les librairies GNOME et ma machine n'est pas assez puissante pour me permettre d'avoir les libraries GNOME et les librairies KDE chargées en même temps sans ralentissements énormes : GVim, Mozilla et Mozilla Mail (avec son excellent filtre anti-spam), GFtp, GNuméric et Abiword (il m'arrive d'utiliser OpenOffice quand les formats passent mal), Gaim, XChat, GThumb, XMMS, GXine, GTop, Visionneuse de journaux système, Prises en compte des touches Multimédia, ...
Si il existait des équivalents qui offrent exactement les même fonctionnalités sous KDE, j'utiliserais KDE. Si j'avais une machine plus puissante, j'utiliserais aussi KDE avec mes applications GNOME/GTK+ favorites. Mais ce n'est pas le cas.
> Et hop, un commentaire de plus qui prouve que certaines personnes sont completement a coté de la plaque. Oui, je comprend que ca peut etre considéré comme une insulte, mais c'est tellement vrai.
Excuse-moi d'exposer un fait que je constate, je suis désolé de te faire part de mon expérience qui est totalement différente de la tienne. Par ailleurs, je n'ai jamais prétendu que mon cas était une généralité, contrairement à toi. Bref, apprends à écouter les autres, même s'ils n'ont pas le même avis que toi.
Par ailleurs, personnellement si je voulais vraiment parler à une personne pour lui montrer ma belle voix et laisser tomber ma proie, j'utiliserais un téléphone, autant qu'il serve si le message est si important qu'il doit être vocal ... Mais bon, ça m'apporterait rien de plus que d'exprimer mon idée par un texte via la messagerie instantanée.
Et personnellement, si je voulais absolument qu'une personne m'admire absolument pour discuter, je préfèrerais la terrasse d'un café : je n'ai pas trop envie de m'abrutir derrière la froideur d'une webcam et d'un micro. À voir absolument mon interlocuteur pour faire passer mon message, je préfère largement la chaleur et la convivialité des contacts humains.
Bien que je n'ai pas voté pour ce commentaire, je pense l'argument de la voix et la vidéo est totalement inadapté pour dire que Jabber n'a pas l'utilisation qu'il mérite. En effet, l'utilisation de ces deux fonctionnalités pour communiquer est si marginale dans le monde de la messagerie instantannée que je doute que ce soit la raison qui pousse les utilisateurs à préfèrer MSN. De plus, cela nécessite d'avoir le matériel nécessaire, micro et webcam, ce qui n'est pas le cas de tout le monde.
D'ailleurs, dans mon entourage, je ne connais personne qui utilise cela, et pourtant certains sont très attachés à leur MSN messenger, et ils ignorent même qu'il est possible de joindre la voix et la vidéo à leur frasque textuelle. Pour couronner le tout, très peu disposent de webcam et de micro.
Ainsi, prétendre que tout client de messagerie instantanée qui se respecte doit inclure la voix et la vidéo et que c'est la raison qui fait que les clients Jabber sont théoriquement si peu utilisés est tout, sauf vraiment pertinent.
> qmail n'est pas GPL mais n'est pas non plus libre selon la définition des libertés essentielles de la FSF. Je pense qu'il reste sur ce site des personnes qui pensent que cette définition est la plus appropriée. Ces personnes là considéreront qmail comme proprietaire, et de ce fait l'éviteront.
Dois-je en déduire que tout ce qui n'est pas GPL n'est pas assez libre pour "mériter" que tu l'utilises ? Hum ...
> Exim n'a connu qu'un malheureux trou de sécu depuis 3 ou 4 ans que je l'utilise. Ça ne fait pas de lui une usine à trous de sécu comme sendmail.
Loin de moi de prétendre que Exim est aussi buggé que Sendmail, ça se saurait tellement se serait exceptionnel. D'ailleurs, je n'ai pas parlé de Exim ! Ceci dit, c'est une bonne chose qu'Exim n'a eu qu'une faille de sécurité en 3 ou 4 ans, mais Qmail n'en a eu aucune en 6 ans : je ne connais aucun autre serveur de messagerie qui peut se vanter de cela, aucun !
> La principale opinion qu'il défend c'est qu'il préfère publier sous une license propriétaire.
Il est libre de choisir la license qu'il veut pour son logiciel. Tout comme chacun d'entre nous est libre de choisir le logiciel qui lui convient le mieux selon ses propres critères - et non pas pour faire plaisir aux autres. Pour ma part, la license de Qmail n'est certe pas la GPL, mais elle est acceptable vis à vis des caractéristiques que Qmail offre : je me voyais mal expliquer à un de mes employeur que Qmail est ce qu'il nous faut mais que sa license n'est pas aussi libre que j'aurais pu éventuellement le souhaiter.
Je ne peux cependant pas m'empêcher de préciser que lorsque Netscape était le seul navigateur Web disponible pour Linux, personne ne l'a critiqué pour sa license qui n'était ni GPL, ni aussi libre que celle de Qmail. Donc c'est un faux débat que de prétendre qu'il ne faut pas utiliser Qmail en raison de sa license, qui est tout de même raisonnablement acceptable *pour moi*. Mais bon, c'est clair que je ne m'appelle pas Richard Stallman ...
> Avec tout ça t'as pas répondu à ma question : quelles sont les fonctionnalités (utiles) qui n'existent que dans qmail ?
Et pour cause, ce n'est pas à moi que tu la posais, et je ne faisais que répondre à ton jugement gratuit sur Qmail et son auteur ! Mais je vais quand même y répondre pour ma part.
Qmail est totalement modulaire : chaque programme qui compose la chaîne Qmail est chargé d'un tâche, et d'une seule : c'est exactement ce qu'on appelle philosophie Unix. C'est d'ailleurs ce qui est recommandé à tout développeur pour respecter les règles de l'art de la programmation, et c'est une règle rarement respectée pour que cela soit signalé. En changeant l'un des modules, disons le module d'authentification très populaire checkpassword, tu es libre d'implémenter ton propre système d'authentification comme utiliser une base mysql par exemple. Le tout sans rien changer d'autre dans toute la chaîne.
Du fait de sa modularité, aucun programme composant la chaîne Qmail n'est setuid root, pratique courante dans d'autre serveur de messagerie : seul deux programmes sont root et ne sont jamais utiliser depuis une demande réseau mais uniquement via les composants locaux de la chaîne Qmail.
Qmail n'accepte pas le relaying par défaut. Qmail supporte en natif le format Maildir qui très fiable. Qmail n'effectue pas de requête DNS pour éviter tout risque de répercussion d'une compromission du système DNS lors du remplissage des entêtes partiaux (contrairement à Exim) : à noter que cela est aussi un gage de performance dans la mesure où ces requêtes ne sont pas nécessaires (sauf cas très particuliers, mais est-ce alors un raison d'en faire une fonctionnalité générale pour quelques cas très rares ?).
Enfin, qmail a pour but d'être le plus sécurisé des serveurs de messageries (aucune faille découverte à ce jour) tout en gardant à l'esprit que les performances doivent aussi faire partie de l'objectif : l'auteur de Exim n'avait pas cet objectif de performance en tête, bien que exim soit quand même très performant (voir http://www.exim.org/exim-html-4.20/doc/html/FAQ_10.html#TOC257(...))
Bref, Qmail n'est pas GPL, certe, mais tu peux prendre les sources, les étudier, les installer comme tu veux tant que tu ne redistribues pas des binaires réalisés contrairement aux excellentes règles de rigueur de travail imposées par son auteur : et quand on voit que ça donne le serveur de messagerie le plus sécurisée à peine installé sans sacrifier les performances, on ne peut qu'être séduit, en tout cas, j'ai été séduit.
Sur la supposée mégalomanie de l'auteur de qmail, moi ce je vois, c'est qu'il a fait un serveur de messagerie très utilisé en milieu professionnel et qu'il s'est engagé à offire 500$ pour celui qui y trouverait une faille. À ce jour, le prime dort paisiblement dans son porte-feuille depuis 6 ans (http://cr.yp.to/qmail/guarantee.html(...)). Je ne sais pas toi, mais moi personnellement, si j'arrivais à lancer un défi que personne ne gagnerait, en tant que programmeur, je serais fier de mon travail, surtout si son utilisation se répand. Sans compter que c'est un signe de crédibilité et de qualité imparable qu'aucun autre serveur de messagerie n'a osé relevé, et surement pas l'historique et cryptique Sendmail (http://cr.yp.to/maildisasters/sendmail.html(...)) - mais qui en aurait douté - et encore moins postfix (http://cr.yp.to/maildisasters/postfix.html(...)) d'IBM.
Ah oui, il s'engage dans ses opinions qu'il défend et il rédige des textes techniques très pertinents, est-ce ça être mégalomane pour toi ?
Bref, à côté de cela, à part nous sortir deux lieux communs de la veille qui traînait au fin fond du frigo sous les huîtres de noël 1999, peux-tu nous expliquer ce que TOI tu as fait ? Parce que je ne veux pas dire, mais si on me demandait de choisir entre assumer une mégalomanie supposé doublée d'une extrême compétence et entre une médisance flagrante, mon choix serait vite fait.
À l'heure où les grandes marques de consommation tentent de réduire de plus en plus les emballages pour réduire la masse de déchets, on a les maisons de disque qui nous innondent les rues avec un nouveau déchet, le CD jettable qui, à l'image des journaux gratuits qui les accompagnent finiront à trainer sur les trottoirs. Si encore on pouvait ré-utiliser ces CDs par la suite, ç'aurait éviter de les jeter. Remarquez, ils pourront toujours diffuser de la musique Kleenex sur leurs CDs jetables, au moins elle y aurait sa place.
La documentation officieuse de qmail, mais officiellement la plus utilisé, est "Life With QMail" (http://www.lifewithqmail.org/lwq.html(...)) En plus de l'installation de netqmail-1.04, qui est une version de qmail-1.03 avec quelques correctifs nécessaires, cette documentation est plus complète, plus à jour et explique pas mal de points de configuration (comparé à la documentation livrée avec qmail-1.03).
Sinon, en ce qui concerne ton problème, ça m'a rappelé un passage précis lors de l'installation pas-à-pas de qmail. Je te le reporte texto ici, tiré directement du fichier INSTALL.alias de qmail-1.03 : " Under qmail, root never receives mail. Your system may generate mail messages to root every night; if you don't have an alias for root, those messages will bounce. (They'll end up double-bouncing to the postmaster). Set up an alias for root in ~alias/.qmail-root. .qmail files are similar to .forward files, but beware that they are strictly line-oriented---see dot-qmail.0 for details."
Posté par kapouik .
En réponse au journal Gaim 0.73.
Évalué à 2.
Il s'agit de GtkSpell qui permet de corriger le texte tapé comme dans un traitement de texte (mot mal orthographié mis en surbrillance). Essaie avec le RPM, il s'agit de GtkSpell pour Linux Mandrake 9.1 :
En effet, Slackware utilise le système de démarrage du style BSD. Cependant, elle supporte très bien les scripts de démarrage SysV : c'est le script /etc/rc.d/rc.sysvinit qui est chargé de cela et qui est appelé automatiquement par les scripts de démarrage standards. Pour plus de détails, lire les commentaires qui figurent au début de ce fichier.
Posté par kapouik .
En réponse au journal Now on TV.
Évalué à 8.
Puisque qu'on ne va plus avoir le droit de copie privée, puisque tous les supports seront cryptés et inviolables et que passer outre sera passible de la peine de mort, qu'ils commencent à nous virer les taxe de la SACEM sur les supports informatiques : j'en ai plus que marre d'enrichir Lorie et Alizée à chaque fois que j'achète des CDs vierges qui ne me servent que pour les sauvegardes ou pour les images ISOs.
Essaie de passer un document XML ainsi rédigé dans XSLTPROC, et tu verras que le problème n'est pas si simple. Bien évidemment, ta solution est la solution standard qui s'impose au premier abord, celle que j'ai moi même essayé la première fois que j'ai eu le problème, mais XLSTPROC voit ça d'un autre il ...
Tu peux utiliser un éditeur qui gère l'UTF-8, style GEdit qui permet d'enregistrer au formar UTF-8 et qui possède aussi la coloration de synthaxe pour le format XML : l'inconvénient est que changer d'éditeur n'est pas ce qu'il y a de plus agréable.
J'ai une deuxième solution plus ou moins gruik, mais qui me permet d'utiliser n'importe quel éditeur standard qui ne gère pas l'UTF-8 en natif : il s'agit d'utiliser iconv pour convertir les fichiers XML du format ISO-8859-1/ISO-8859-15 vers le format UTF-8. J'ai fait un petit script qui s'occupe de cela et que je l'exécute avant de générer mes documents DocBook :
[ ! -d utf8 ] && mkdir utf8
for file in *.xml ; do
cat $file | iconv -f ISO-8859-15 -t UTF-8 $tmpfile > utf8/$file
done
Il existe probablement une meilleure solution que cette dernière mais je ne la connais pas malgré mes nombreuses lectures des différentes documentations sur DocBook XML éparpillées ici et là sur le Web et qui sont plus où moins complète ...
Un des meilleurs guides sur DocBook XML (il suppose que le lecteur est familier avec DocBook SGML) que j'ai pu trouvé est le suivant :
Il explique notament comment générer les documents au format XHTML en y attachant une feuille de style CSS personnelle pour modifier le look final des documents généré.
Originellement, PC signifie Personal Computer et désigne un ensemble technique modeste destiné au grand public. Il s'agit d'ailleur à l'origine d'une marque déposée d'IBM "tombée" dans le langage populaire, comme un Kleenex, ou un Tupperware qui sont des marques déposées "tombées" dans le laguage populaire en raison ... de leur popularité justement :)
Bien qu'un serveur peut être basé sur une architecture de type PC, pour le monde professionel, quand on désigne un serveur, on parle de ordinateur qui techniquement est adapté à la fonction de serveur professionnel, et il existe des serveurs IBM justement qui n'ont rien à voir avec un PC. En fait, à mon avis, le terme serveur est utilisé ici pour les gros systèmes d'IBM par opposition aux ordinateurs grand public faisant parti de la micro-informatique.
> "In the first 150 days after the release of Windows 2000," he said, "there were 17 critical vulnerabilities. For Windows Server 2003, there were four. For Red Hat Linux 6, they were five to ten times higher."
Oui enfin, si Microsoft utilise ce genre d'argument, elle ne va pas aller bien loin ! Soit, Red Hat avait plus de bug que Windows Server 2003 mais une distribution Linux est livrée avec beaucoup plus de logiciels que Windows. Une fois réalisée une installation complète de Windows, il n'y a pratiquement aucune application, alors qu'une distribution Linux en possède des centaines voire des milliers selon les distributions.
D'autre part, comme le signale judicieusement l'article, les coûts liées au virus informatiques concernent les systèmes Windows, et non pas les systèmes Linux ou autres systèmes d'exploitation libres : cet été a été exemplaire à ce sujet ! Et concernant les failles des produits Microsoft, ce n'est pas encore terminé : http://news.google.fr/news?num=30&hl=fr&edition=fr&q=cl(...)
Par ailleurs, soyons honnête : la majorité des failles découvertes sur les systèmes Linux demandent des connaissances techniques assez poussées, ce qui les rend difficillement exploitables. À rapprocher aux bugs du navigateur IE dont il fut (est ?) possible de voler les cookies de l'utilisateurs (pour usurper l'identité d'un Internaute sur une site par exemple) ou d'exécuter du code malicieux à distance à cause de la gestion des types MIME défectueuses, et cela de manière assez simple.
Enfin, Microsoft a une certaine puissance de communication certe, mais si elle s'engage dans ce jeu là, elle va devoir être très persuasive car les professionels ne sont pas si dupes qu'elle veut bien le croire ! Dans tous les cas, après les fabulations divertissantes de SCO, Microsoft nous promet peut être là une nouvelle source de divertissement :)
> Cette documentation est soumise aux termes de la License Publique Générale GNU. Une copie de cette licence peut être trouvée à l' Annexe A. Linux est une marque déposée par Linus Torvalds. Slackware est une marque déposée par BSDi et Patrick Volkerding. Cette documentation a été traduite de l'anglais au français par Fish (coordinateur du projet), Jakob Wylleman et Idroxid.
Sans vouloir être mauvaise langue, il s'agit des premières lignes du SlackBook en français, et déjà il y a 7 fautes : ça promet ! D'autant qu'il me semble avoir lu ces fautes sur le forum il y a un mois ou deux, mais bon ...
> Aujourd'hui presque 70% des serveurs internet sont sous Linux:
Attention ! Le lien que tu donnes montre que presque 70% des serveurs Web tournent sous Apache. De manière implicte, on peut supposer que la majeure partie tourne probalement avec systèmes d'exploitation libres tels que Linux ou *BSD, mais ce n'est pas ce que dit le lien !!!
Avant d'aller gueuler à tout va, soit bien sûr et certains que tu ne t'es pas trompé lors de la commande. Si tu n'en as pas la certitude ou les preuves (copies), demande à reformuler ta commande avec un modem Ethernet. Si on te répond que ce n'est pas possible, sache que tu as 7 jours à partir de la réception pour annuler le contrat, et reformuler une demande d'abonnement avec le modem Ethernet :) Au dela de ces 7 jours, le contrat est considéré comme accepté par les 2 parties : dans ce cas, à moins que tu ais une preuve de ta bonne formulation d'abonnement, et donc d'une erreur de leur part , tu restes suspendu à leur bon vouloir.
Mais linux fait encore peur, pour mon patron, linux est un système pour rigolo bricoleur, ou presque ...
Sans vouloir juger gratuitement ton patron, s'il pense vraiment tout cela, c'est qu'il est très mal informé et/ou que les FUDs entrepris par des sociétés anti-Linux (www.wehavethewayout.com) fonctionne à merveille.
Je pense plutôt que ce qui fait que certaines sociétés sont réticentes à Linux, c'est l'introduction de nouvelles compétences au sein du service informatique. À première vue, cela paraît insignifiant, mais l'introduction d'un nouveau système et de nouvelles compétences pour une société est toujours vue d'un mauvais oeil, notament en raison des pratiques douteuses de nombreuses SSII (voir le passage à l'euro et à l'an 2000).
Pour finir, si ton patron est aussi compétent que cela pour donner son avis dans le domaine informatique alors qu'il est apparement mal informé, pourquoi a t-il besoin d'un service informatique ? Ne ferait-il pas confiance aux compétences des personnes du métier ? Personnellement, je n'hésiterais pas une seconde à lui poser la dernière question car je me sentirais grandement concerné en tant qu'utilisateur Linux ...
> tout le monde se félicite que ce backdoor ait été trouvé à temps, mais peut-on être sur qu'un autre bien discret ne se cache pas dans un recoin du kernel, de la libc, de ssh, ou de je ne sais quel autre service ?
Sûr, non. Mais ce qui est certain, c'est la disponibilité du code source pour les développeurs qui travaillent sur un logiciel rend difficile l'introduction de code douteux (mais théoriquement pas impossible). À noter que si de telles backdoors volontaires existaient déjà, elles seraient exploitées - c'est le but après tout - et il y a de forte chance que cela aurait été su.
> Donc ma question est : parmi tous les récents systèmes de sécurité qui ont vu le jour dans linux, y-en a t-il un qui permettrait de détecter des comportements étranges provenant d'un élément du système ? Même un truc bien fastidieux qui ne serait fait que par le développeur lui même mais qui permettrait d'être sur qu'il n'y a aucun problème ?
Comment veux-tu qu'un système puisse détecter un comportement étrange ? Cela supposerait l'analyse et la compréhension de la logique de chaque séquence de code, ce qui est d'une part énorme et d'autre part inexistant à ce jour. Pour couronner le tout, dans la série du chien qui se mord la queue, qu'est-ce qui assurerait que ce système est de digne de confiance ? :)
Par ailleurs, est-il besoin de tomber dans la paranoïa ? Non, il faut faire confiance par la communauté du Logiciel Llibre qui a prouvé sa compétence depuis des années déjà, et qui a déjouée les multiples sabotages dans ce style. Sinon, autant utiliser un système propriétaire, au moins on suppose qu'il y a qu'il y a des backdoors par avance et on dort tranquille le soir :)
> d'ailleurs j'hésite bien souvent à prendre des paquets non officiels de ma distrib s'ils ne viennent pas du mainteneur lui même à cause de ça
La plupart des projets dispose d'une clé GPG pour contrôler la signature des sources et s'assurer qu'elles proviennent bien des auteurs originaux : personnellement, je vérifie tout le temps cette signature, car c'est un gage de sécurité et une habitude à avoir quand on est soucieux de la sécurité (surtout en milieu professionnel).
De même, les mises à jour d'une distribution peuvent être contrôlées de manière sûre grâce à la clé GPG des mainteneurs, et cela, quelque soit le mirroir sur lequel se trouve la mise à jour. Par exemple, avant d'appliquer un paquet de mise à jour à mon système Slackware, je le vérifie vérifie avec GPG pour m'assurer que le paquet de mise à jour est sûre car il provient bien des mainteneurs. Cela suppose évidemment que les mainteneurs font de même lorsqu'ils téléchargent les sources d'un logiciel pour en faire un paquet, ce qui est le cas pour la plupart des distributions Linux.
Le problème n'est pas que les sources du noyau se trouvent dans /usr/src/linux ! Le problème existe si les dossiers /usr/incude/{linux,asm} sont des liens vers les dossier du noyau dans /usr/src/linux/include. Normalement, ces dossiers ne doivent pas être liés à /usr/src/linux/include : ils doivent contenir une copie des entêtes du noyau utilisés au moment de la compilation de la glib du système ! C'est ce que fait Linux Slackware qui a installe une copie des entêtes du noyau sans liens vers /usr/src/linux.
> Y'a-t-il dans l'assistance une moule (barbu(e) et chevelu(e) comme il se doit) qui pourrait éclairer ma lanterne ? Me remettre dans le droit chemin de l'obéissance stricte du dogme ?
Quand tu compiles ta glibc, elle utilise les entêtes de la version installé du noyau : les entêtes dans /usr/src/linux/include (sauf si tu as utilisé le paramètre "--with-headers" lors du "./configure") sont utilisés. Certaines distributions incluent donc un lien /usr/include/asm qui pointe vers /usr/src/linux/include/asm (et aussi un lien /usr/include/linux qui pointe vers /usr/src/linux/include/linux).
Or si tu installes un nouveau noyau dans /usr/src/linux, le nouveau contenu de /usr/src/linux/include/{asm,linux} ne correspond pas forcément à l'ancien contenu : des structures ont pu radicalement changer. Ainsi, si tu compiles un programme sur ton système, il utiliseras les nouvelles structures avec les appels systèmes de la libraries C qui s'attendent à recevoir l'ancienne version de la structure : évidemment, ce n'est pas correct.
La solution ? Normalement, une distribution bien faite doit copier les entêtes du noyau utilisés pour la compilation de la glibc dans /usr/include : ainsi, sur une architecture ix86, le lien /usr/include/asm doit être un dossier ou un lien qui pointe sur le dossier /usr/include/asm-i386 (dossier qui contient une copie des entêtes du noyau linux utilisé lors de la compilation de la glibc). De même pour /usr/include/linux qui doit être un dossier et non pas un lien vers /usr/src/include/linux.
Pour information, Linux Slackware (depuis la version 9.x au moins) n'est pas concernée par ce problème dans la mesure ou les entêtes utilisés pour la compilation de la glibc sont regroupés dans leur propres paquetage (kernel-headers) et ils sont installés dans /usr/include sans aucun lien symbolique avec /usr/src/linux/include.
# Re: La guerre des Desktops aura-t-elle lieu ?
Posté par kapouik . En réponse au journal La guerre des Desktops aura-t-elle lieu ?. Évalué à 1.
- un truc tout bête qui me manque sous GNOME dans Nautilius : lancer un terminal dans le dossier courant. Il est vrai que je peux faire un "Nautilus script" qui effectue cela et c'est ce que j'ai fait, mais ce n'est pas une fonctionnalité standard, tandis que ça l'est sous KDE avec Konqueror ;
- si je veux créer un fichier dans le dossier courant de Nautilus, je dois là aussi faire un "Nautilus script" alors que sous Konqueror c'est déjà implémenté en standard ;
- la gestion des signets pour le système de fichier est plate dans Nautilus : impossible d'organiser mes signets en arborescence pour les classer ;
Ce sont des fonctionnalités basiques très simples, presque insignifiantes au premier abord, mais à l'utilisation, ça fait toute la différence pour moi. Et des exemple j'en ai encore d'autres (notament la gestion des types MIME et l'association des fichiers inintuitives de Nautilus).
Mais malgré tout cela, je fais avec et j'utilise GNOME. Pourquoi ? Pour une raison toute simple : toutes les applications quotidiennes que j'utilise son basées sur GTK+ ou sur les librairies GNOME et ma machine n'est pas assez puissante pour me permettre d'avoir les libraries GNOME et les librairies KDE chargées en même temps sans ralentissements énormes : GVim, Mozilla et Mozilla Mail (avec son excellent filtre anti-spam), GFtp, GNuméric et Abiword (il m'arrive d'utiliser OpenOffice quand les formats passent mal), Gaim, XChat, GThumb, XMMS, GXine, GTop, Visionneuse de journaux système, Prises en compte des touches Multimédia, ...
Si il existait des équivalents qui offrent exactement les même fonctionnalités sous KDE, j'utiliserais KDE. Si j'avais une machine plus puissante, j'utiliserais aussi KDE avec mes applications GNOME/GTK+ favorites. Mais ce n'est pas le cas.
[^] # Re: Voila pourquoi ca ne viendra pas partout...
Posté par kapouik . En réponse à la dépêche Du nouveau de coté de Jabber. Évalué à 0.
Excuse-moi d'exposer un fait que je constate, je suis désolé de te faire part de mon expérience qui est totalement différente de la tienne. Par ailleurs, je n'ai jamais prétendu que mon cas était une généralité, contrairement à toi. Bref, apprends à écouter les autres, même s'ils n'ont pas le même avis que toi.
Par ailleurs, personnellement si je voulais vraiment parler à une personne pour lui montrer ma belle voix et laisser tomber ma proie, j'utiliserais un téléphone, autant qu'il serve si le message est si important qu'il doit être vocal ... Mais bon, ça m'apporterait rien de plus que d'exprimer mon idée par un texte via la messagerie instantanée.
Et personnellement, si je voulais absolument qu'une personne m'admire absolument pour discuter, je préfèrerais la terrasse d'un café : je n'ai pas trop envie de m'abrutir derrière la froideur d'une webcam et d'un micro. À voir absolument mon interlocuteur pour faire passer mon message, je préfère largement la chaleur et la convivialité des contacts humains.
[^] # Re: PUB Perso
Posté par kapouik . En réponse à la dépêche Du nouveau de coté de Jabber. Évalué à 4.
D'ailleurs, dans mon entourage, je ne connais personne qui utilise cela, et pourtant certains sont très attachés à leur MSN messenger, et ils ignorent même qu'il est possible de joindre la voix et la vidéo à leur frasque textuelle. Pour couronner le tout, très peu disposent de webcam et de micro.
Ainsi, prétendre que tout client de messagerie instantanée qui se respecte doit inclure la voix et la vidéo et que c'est la raison qui fait que les clients Jabber sont théoriquement si peu utilisés est tout, sauf vraiment pertinent.
[^] # Re: Cleanner les erreurs qmail ...
Posté par kapouik . En réponse au journal Cleanner les erreurs qmail .... Évalué à 0.
Dois-je en déduire que tout ce qui n'est pas GPL n'est pas assez libre pour "mériter" que tu l'utilises ? Hum ...
[^] # Re: Cleanner les erreurs qmail ...
Posté par kapouik . En réponse au journal Cleanner les erreurs qmail .... Évalué à 0.
Loin de moi de prétendre que Exim est aussi buggé que Sendmail, ça se saurait tellement se serait exceptionnel. D'ailleurs, je n'ai pas parlé de Exim ! Ceci dit, c'est une bonne chose qu'Exim n'a eu qu'une faille de sécurité en 3 ou 4 ans, mais Qmail n'en a eu aucune en 6 ans : je ne connais aucun autre serveur de messagerie qui peut se vanter de cela, aucun !
> La principale opinion qu'il défend c'est qu'il préfère publier sous une license propriétaire.
Il est libre de choisir la license qu'il veut pour son logiciel. Tout comme chacun d'entre nous est libre de choisir le logiciel qui lui convient le mieux selon ses propres critères - et non pas pour faire plaisir aux autres. Pour ma part, la license de Qmail n'est certe pas la GPL, mais elle est acceptable vis à vis des caractéristiques que Qmail offre : je me voyais mal expliquer à un de mes employeur que Qmail est ce qu'il nous faut mais que sa license n'est pas aussi libre que j'aurais pu éventuellement le souhaiter.
Je ne peux cependant pas m'empêcher de préciser que lorsque Netscape était le seul navigateur Web disponible pour Linux, personne ne l'a critiqué pour sa license qui n'était ni GPL, ni aussi libre que celle de Qmail. Donc c'est un faux débat que de prétendre qu'il ne faut pas utiliser Qmail en raison de sa license, qui est tout de même raisonnablement acceptable *pour moi*. Mais bon, c'est clair que je ne m'appelle pas Richard Stallman ...
Une note intéressante et pertinente sur la license de qmail et son auteur :
-> http://mla.libertine.org/tmda-workers/2002-04/msg00049.html(...)
> Avec tout ça t'as pas répondu à ma question : quelles sont les fonctionnalités (utiles) qui n'existent que dans qmail ?
Et pour cause, ce n'est pas à moi que tu la posais, et je ne faisais que répondre à ton jugement gratuit sur Qmail et son auteur ! Mais je vais quand même y répondre pour ma part.
Qmail est totalement modulaire : chaque programme qui compose la chaîne Qmail est chargé d'un tâche, et d'une seule : c'est exactement ce qu'on appelle philosophie Unix. C'est d'ailleurs ce qui est recommandé à tout développeur pour respecter les règles de l'art de la programmation, et c'est une règle rarement respectée pour que cela soit signalé. En changeant l'un des modules, disons le module d'authentification très populaire checkpassword, tu es libre d'implémenter ton propre système d'authentification comme utiliser une base mysql par exemple. Le tout sans rien changer d'autre dans toute la chaîne.
Du fait de sa modularité, aucun programme composant la chaîne Qmail n'est setuid root, pratique courante dans d'autre serveur de messagerie : seul deux programmes sont root et ne sont jamais utiliser depuis une demande réseau mais uniquement via les composants locaux de la chaîne Qmail.
Qmail n'accepte pas le relaying par défaut. Qmail supporte en natif le format Maildir qui très fiable. Qmail n'effectue pas de requête DNS pour éviter tout risque de répercussion d'une compromission du système DNS lors du remplissage des entêtes partiaux (contrairement à Exim) : à noter que cela est aussi un gage de performance dans la mesure où ces requêtes ne sont pas nécessaires (sauf cas très particuliers, mais est-ce alors un raison d'en faire une fonctionnalité générale pour quelques cas très rares ?).
Enfin, qmail a pour but d'être le plus sécurisé des serveurs de messageries (aucune faille découverte à ce jour) tout en gardant à l'esprit que les performances doivent aussi faire partie de l'objectif : l'auteur de Exim n'avait pas cet objectif de performance en tête, bien que exim soit quand même très performant (voir http://www.exim.org/exim-html-4.20/doc/html/FAQ_10.html#TOC257(...))
Bref, Qmail n'est pas GPL, certe, mais tu peux prendre les sources, les étudier, les installer comme tu veux tant que tu ne redistribues pas des binaires réalisés contrairement aux excellentes règles de rigueur de travail imposées par son auteur : et quand on voit que ça donne le serveur de messagerie le plus sécurisée à peine installé sans sacrifier les performances, on ne peut qu'être séduit, en tout cas, j'ai été séduit.
[^] # Re: Cleanner les erreurs qmail ...
Posté par kapouik . En réponse au journal Cleanner les erreurs qmail .... Évalué à 3.
Ah oui, il s'engage dans ses opinions qu'il défend et il rédige des textes techniques très pertinents, est-ce ça être mégalomane pour toi ?
Bref, à côté de cela, à part nous sortir deux lieux communs de la veille qui traînait au fin fond du frigo sous les huîtres de noël 1999, peux-tu nous expliquer ce que TOI tu as fait ? Parce que je ne veux pas dire, mais si on me demandait de choisir entre assumer une mégalomanie supposé doublée d'une extrême compétence et entre une médisance flagrante, mon choix serait vite fait.
# Re: La gestion des droits numériques de Microsoft c'est maintenant que ca comment ?
Posté par kapouik . En réponse au journal La gestion des droits numériques de Microsoft c'est maintenant que ca comment ?. Évalué à 6.
# Re: Cleanner les erreurs qmail ...
Posté par kapouik . En réponse au journal Cleanner les erreurs qmail .... Évalué à 2.
La documentation officieuse de qmail, mais officiellement la plus utilisé, est "Life With QMail" (http://www.lifewithqmail.org/lwq.html(...)) En plus de l'installation de netqmail-1.04, qui est une version de qmail-1.03 avec quelques correctifs nécessaires, cette documentation est plus complète, plus à jour et explique pas mal de points de configuration (comparé à la documentation livrée avec qmail-1.03).
Sinon, en ce qui concerne ton problème, ça m'a rappelé un passage précis lors de l'installation pas-à-pas de qmail. Je te le reporte texto ici, tiré directement du fichier INSTALL.alias de qmail-1.03 : " Under qmail, root never receives mail. Your system may generate mail messages to root every night; if you don't have an alias for root, those messages will bounce. (They'll end up double-bouncing to the postmaster). Set up an alias for root in ~alias/.qmail-root. .qmail files are similar to .forward files, but beware that they are strictly line-oriented---see dot-qmail.0 for details."
[^] # Re: Gaim 0.73
Posté par kapouik . En réponse au journal Gaim 0.73. Évalué à 2.
-> ftp://ftp.rediris.es/sites/carroll.cac.psu.edu/mandrake/9.1/i586/M(...)
[^] # Re: Sortie d'ALSA 1.0.0pre1
Posté par kapouik . En réponse à la dépêche Sortie d'ALSA 1.0.0pre1. Évalué à 1.
Ah ? Je serais intéressé par plus de détail au sujet de cette information sur le gain en sécurité gagné en ne compilant pas les modules ! Merci.
[^] # Re: Sortie d'ALSA 1.0.0pre1
Posté par kapouik . En réponse à la dépêche Sortie d'ALSA 1.0.0pre1. Évalué à 2.
En effet, Slackware utilise le système de démarrage du style BSD. Cependant, elle supporte très bien les scripts de démarrage SysV : c'est le script /etc/rc.d/rc.sysvinit qui est chargé de cela et qui est appelé automatiquement par les scripts de démarrage standards. Pour plus de détails, lire les commentaires qui figurent au début de ce fichier.
# Re: Now on TV
Posté par kapouik . En réponse au journal Now on TV. Évalué à 8.
[^] # Re: DocBook et les accents
Posté par kapouik . En réponse au journal DocBook et les accents. Évalué à 1.
# Re: DocBook et les accents
Posté par kapouik . En réponse au journal DocBook et les accents. Évalué à 4.
Tu peux utiliser un éditeur qui gère l'UTF-8, style GEdit qui permet d'enregistrer au formar UTF-8 et qui possède aussi la coloration de synthaxe pour le format XML : l'inconvénient est que changer d'éditeur n'est pas ce qu'il y a de plus agréable.
J'ai une deuxième solution plus ou moins gruik, mais qui me permet d'utiliser n'importe quel éditeur standard qui ne gère pas l'UTF-8 en natif : il s'agit d'utiliser iconv pour convertir les fichiers XML du format ISO-8859-1/ISO-8859-15 vers le format UTF-8. J'ai fait un petit script qui s'occupe de cela et que je l'exécute avant de générer mes documents DocBook :
[ ! -d utf8 ] && mkdir utf8
for file in *.xml ; do
cat $file | iconv -f ISO-8859-15 -t UTF-8 $tmpfile > utf8/$file
done
Il existe probablement une meilleure solution que cette dernière mais je ne la connais pas malgré mes nombreuses lectures des différentes documentations sur DocBook XML éparpillées ici et là sur le Web et qui sont plus où moins complète ...
Un des meilleurs guides sur DocBook XML (il suppose que le lecteur est familier avec DocBook SGML) que j'ai pu trouvé est le suivant :
http://www.sagehill.net/docbookxsl/index.html(...)
Il explique notament comment générer les documents au format XHTML en y attachant une feuille de style CSS personnelle pour modifier le look final des documents généré.
[^] # Re: IBM va promouvoir Linux sur les PC
Posté par kapouik . En réponse au journal IBM va promouvoir Linux sur les PC. Évalué à 6.
Bien qu'un serveur peut être basé sur une architecture de type PC, pour le monde professionel, quand on désigne un serveur, on parle de ordinateur qui techniquement est adapté à la fonction de serveur professionnel, et il existe des serveurs IBM justement qui n'ont rien à voir avec un PC. En fait, à mon avis, le terme serveur est utilisé ici pour les gros systèmes d'IBM par opposition aux ordinateurs grand public faisant parti de la micro-informatique.
# Re: Microsoft prépare son assaut
Posté par kapouik . En réponse au journal Microsoft prépare son assaut. Évalué à 3.
Oui enfin, si Microsoft utilise ce genre d'argument, elle ne va pas aller bien loin ! Soit, Red Hat avait plus de bug que Windows Server 2003 mais une distribution Linux est livrée avec beaucoup plus de logiciels que Windows. Une fois réalisée une installation complète de Windows, il n'y a pratiquement aucune application, alors qu'une distribution Linux en possède des centaines voire des milliers selon les distributions.
D'autre part, comme le signale judicieusement l'article, les coûts liées au virus informatiques concernent les systèmes Windows, et non pas les systèmes Linux ou autres systèmes d'exploitation libres : cet été a été exemplaire à ce sujet ! Et concernant les failles des produits Microsoft, ce n'est pas encore terminé : http://news.google.fr/news?num=30&hl=fr&edition=fr&q=cl(...)
Par ailleurs, soyons honnête : la majorité des failles découvertes sur les systèmes Linux demandent des connaissances techniques assez poussées, ce qui les rend difficillement exploitables. À rapprocher aux bugs du navigateur IE dont il fut (est ?) possible de voler les cookies de l'utilisateurs (pour usurper l'identité d'un Internaute sur une site par exemple) ou d'exécuter du code malicieux à distance à cause de la gestion des types MIME défectueuses, et cela de manière assez simple.
Enfin, Microsoft a une certaine puissance de communication certe, mais si elle s'engage dans ce jeu là, elle va devoir être très persuasive car les professionels ne sont pas si dupes qu'elle veut bien le croire ! Dans tous les cas, après les fabulations divertissantes de SCO, Microsoft nous promet peut être là une nouvelle source de divertissement :)
# Re: Slackware Francophone fait peau neuve.
Posté par kapouik . En réponse au journal Slackware Francophone fait peau neuve.. Évalué à 1.
Sans vouloir être mauvaise langue, il s'agit des premières lignes du SlackBook en français, et déjà il y a 7 fautes : ça promet ! D'autant qu'il me semble avoir lu ces fautes sur le forum il y a un mois ou deux, mais bon ...
[^] # Re: Linux contre Microsoft (1-0)
Posté par kapouik . En réponse à la dépêche "Est-ce que copier, c'est voler ?" la dernière émission de Rue des entrepreneurs. Évalué à 10.
Attention ! Le lien que tu donnes montre que presque 70% des serveurs Web tournent sous Apache. De manière implicte, on peut supposer que la majeure partie tourne probalement avec systèmes d'exploitation libres tels que Linux ou *BSD, mais ce n'est pas ce que dit le lien !!!
# Re: Free : ras le bol !
Posté par kapouik . En réponse au journal Free : ras le bol !. Évalué à 2.
# Re: Utilisation
Posté par kapouik . En réponse au journal Utilisation. Évalué à 2.
Sans vouloir juger gratuitement ton patron, s'il pense vraiment tout cela, c'est qu'il est très mal informé et/ou que les FUDs entrepris par des sociétés anti-Linux (www.wehavethewayout.com) fonctionne à merveille.
Je pense plutôt que ce qui fait que certaines sociétés sont réticentes à Linux, c'est l'introduction de nouvelles compétences au sein du service informatique. À première vue, cela paraît insignifiant, mais l'introduction d'un nouveau système et de nouvelles compétences pour une société est toujours vue d'un mauvais oeil, notament en raison des pratiques douteuses de nombreuses SSII (voir le passage à l'euro et à l'an 2000).
Pour finir, si ton patron est aussi compétent que cela pour donner son avis dans le domaine informatique alors qu'il est apparement mal informé, pourquoi a t-il besoin d'un service informatique ? Ne ferait-il pas confiance aux compétences des personnes du métier ? Personnellement, je n'hésiterais pas une seconde à lui poser la dernière question car je me sentirais grandement concerné en tant qu'utilisateur Linux ...
[^] # Re: Et si il y avait un backdoor non trouvé ?
Posté par kapouik . En réponse à la dépêche Tentative d'insertion d'une porte dérobée dans le noyau Linux. Évalué à 6.
Sûr, non. Mais ce qui est certain, c'est la disponibilité du code source pour les développeurs qui travaillent sur un logiciel rend difficile l'introduction de code douteux (mais théoriquement pas impossible). À noter que si de telles backdoors volontaires existaient déjà, elles seraient exploitées - c'est le but après tout - et il y a de forte chance que cela aurait été su.
> Donc ma question est : parmi tous les récents systèmes de sécurité qui ont vu le jour dans linux, y-en a t-il un qui permettrait de détecter des comportements étranges provenant d'un élément du système ? Même un truc bien fastidieux qui ne serait fait que par le développeur lui même mais qui permettrait d'être sur qu'il n'y a aucun problème ?
Comment veux-tu qu'un système puisse détecter un comportement étrange ? Cela supposerait l'analyse et la compréhension de la logique de chaque séquence de code, ce qui est d'une part énorme et d'autre part inexistant à ce jour. Pour couronner le tout, dans la série du chien qui se mord la queue, qu'est-ce qui assurerait que ce système est de digne de confiance ? :)
Par ailleurs, est-il besoin de tomber dans la paranoïa ? Non, il faut faire confiance par la communauté du Logiciel Llibre qui a prouvé sa compétence depuis des années déjà, et qui a déjouée les multiples sabotages dans ce style. Sinon, autant utiliser un système propriétaire, au moins on suppose qu'il y a qu'il y a des backdoors par avance et on dort tranquille le soir :)
> d'ailleurs j'hésite bien souvent à prendre des paquets non officiels de ma distrib s'ils ne viennent pas du mainteneur lui même à cause de ça
La plupart des projets dispose d'une clé GPG pour contrôler la signature des sources et s'assurer qu'elles proviennent bien des auteurs originaux : personnellement, je vérifie tout le temps cette signature, car c'est un gage de sécurité et une habitude à avoir quand on est soucieux de la sécurité (surtout en milieu professionnel).
De même, les mises à jour d'une distribution peuvent être contrôlées de manière sûre grâce à la clé GPG des mainteneurs, et cela, quelque soit le mirroir sur lequel se trouve la mise à jour. Par exemple, avant d'appliquer un paquet de mise à jour à mon système Slackware, je le vérifie vérifie avec GPG pour m'assurer que le paquet de mise à jour est sûre car il provient bien des mainteneurs. Cela suppose évidemment que les mainteneurs font de même lorsqu'ils téléchargent les sources d'un logiciel pour en faire un paquet, ce qui est le cas pour la plupart des distributions Linux.
# Re: e16.6 is out
Posté par kapouik . En réponse au journal e16.6 is out. Évalué à 2.
http://sourceforge.net/mailarchive/forum.php?thread_id=3414829&(...)
[^] # Re: Compiler son kernel dans /usr/src/linux, c'est mal ?
Posté par kapouik . En réponse au journal Compiler son kernel dans /usr/src/linux, c'est mal ?. Évalué à 3.
# Re: Compiler son kernel dans /usr/src/linux, c'est mal ?
Posté par kapouik . En réponse au journal Compiler son kernel dans /usr/src/linux, c'est mal ?. Évalué à 5.
Quand tu compiles ta glibc, elle utilise les entêtes de la version installé du noyau : les entêtes dans /usr/src/linux/include (sauf si tu as utilisé le paramètre "--with-headers" lors du "./configure") sont utilisés. Certaines distributions incluent donc un lien /usr/include/asm qui pointe vers /usr/src/linux/include/asm (et aussi un lien /usr/include/linux qui pointe vers /usr/src/linux/include/linux).
Or si tu installes un nouveau noyau dans /usr/src/linux, le nouveau contenu de /usr/src/linux/include/{asm,linux} ne correspond pas forcément à l'ancien contenu : des structures ont pu radicalement changer. Ainsi, si tu compiles un programme sur ton système, il utiliseras les nouvelles structures avec les appels systèmes de la libraries C qui s'attendent à recevoir l'ancienne version de la structure : évidemment, ce n'est pas correct.
La solution ? Normalement, une distribution bien faite doit copier les entêtes du noyau utilisés pour la compilation de la glibc dans /usr/include : ainsi, sur une architecture ix86, le lien /usr/include/asm doit être un dossier ou un lien qui pointe sur le dossier /usr/include/asm-i386 (dossier qui contient une copie des entêtes du noyau linux utilisé lors de la compilation de la glibc). De même pour /usr/include/linux qui doit être un dossier et non pas un lien vers /usr/src/include/linux.
Pour information, Linux Slackware (depuis la version 9.x au moins) n'est pas concernée par ce problème dans la mesure ou les entêtes utilisés pour la compilation de la glibc sont regroupés dans leur propres paquetage (kernel-headers) et ils sont installés dans /usr/include sans aucun lien symbolique avec /usr/src/linux/include.
# Re: Linuxfrien, Linuxfrienne, je vous dis bravo.
Posté par kapouik . En réponse au journal Linuxfrien, Linuxfrienne, je vous dis bravo.. Évalué à 1.
http://www.intermonde.net/bourgo/RolandB/Boileau.html(...)