bmc a écrit 1651 commentaires

Le pire, c'est bien PowerPoint. Parce qu'à ma connaissance, il n'y a aucun moyen de les relire sous Linux. Qqn sait comment faire ?
Les .doc => AbiWord
Les .xls => Gnumeric (excellent !)

Si Soldier Of Fortune est OpenGL, alors l'OpenGL marche sous kernel 2.4 avec les divers 0.96.
Donc c'est ta conf.

Je dirais même qu'il roule :)

C'est vrai, sous Linux j'attends également le disque. hdparm m'a bien accéléré, mais il y a toujours une grosse attente pour X.

Quelqu'un a-t-il testé Berlin ? Est-ce beaucoup plus rapide ?
(je sais qu'il n'y a pas le même genre d'applications).

Merci pour cette précision.
Une question : que reproches-tu au mod_perl et FastCGI est-il vraiment avantageux en comparaison ?

>> Je suis d'accord le point fort du Perl c'est sa souplesse, m'enfin ca a un prix assez lourd a payer.

Evidemment, les langages qui ne laissent pas trop le choix au programmeur (tu feras comme ça ou rien !) sont certainement plus facile à lire/débugguer, mais un codeur (Perl ou pas d'ailleurs) se doit de rendre son code lisible. Par exemple, la plupart des modules sur CPAN ont un code très propre.

D'ailleurs, je conseille à tout débutant (ou confirmé) de lire le guide de la programmation claire en Perl :http://www.perl.com/pub/doc/manual/html/pod/perlstyle.html(...)

Il est aussi facile de faire un code C illisible qu'un code Perl imbitable, alors qu'il est plus simple de débugguer du Perl (pour quelqu'un connaissant aussi bien les deux langages).

Bien sûr, je ne dis pas qu'il ne faut utiliser que du Perl, mais il faudrait abandonner ses idées préconcues sur sa soit-disant difficulté de programmation ou de lecture.
D'ailleurs, je m'intéresse beaucoup au Ruby, qui pourrait être un "Perl killer" selon certains (je ne connais pas personnellement le Ruby).

>> NVidia ne veut pas filer le code source de ses drivers car cela donnerait des infos sur ses cartes aux concurrents, c'est leur droit, ils ont debourse des millions de $ en recherche et ils ont pas forcement envie que la concurrence ait ca gratuitement.

Tout à fait d'accord. Mais...

>>D'autre part si tu crois que le developpeur a cote de chez toi est mieux arme que les dev de chez NVidia, qui ont les specs de A a Z et le concepteur du chip dans le bureau d'a cote, pour ecrire un driver pour un chip NVidia je crois que tu reves un peu.

Il arrive que même les meilleurs développeurs dans les meilleures conditions fassent une groooosssee bourde, et l'audit du code par une (et même plusieurs) source(s) extérieure(s) est extrèmement bénéfique.


>> Mis a part ca, j'ai une TNT2 sur un bi-proc a la maison et j'ai jamais eu de problemes, donc ca devait pas etre si grave que ca.

Les plantages de ma GeForce 256 sous Soldier Of Fortune ont disparu avec la version 0.9.6 des drivers. Il y avait bien qq problèmes

En effet, c'est, comment dirais-je...hmmm ... à gerber

Juste une question : pour quelles tâches courantes est-il vraiment utile de disposer d'un OS temps réel ? N'est-il pas suffisant pour le quidam de se contenter d'utiliser un kernel patché pour des bas temps de latence ? (low latency)

Pas mal ce Roxen, y'a même un module Perl !
Je vais m'y intéresser de près...

Sinon, puisque l'on est dans la section conseils, quel serveur de mail conseillerais-tu pour un serveur de mail ? qmail, Postfix ? Un autre ?
Y'en a-t-il en GPL qui te paraisse pouvoir convenir ?

Voilà voilà, merci.

NB : tout le monde peut me répondre, n'hésitez pas

Peut-être parce que c'est plus facile de mettre une barrette de RAM que de se faire chier à reconfigurer le truc...
C'est peut-être une solution provisoire, en attendant que djbdns soit en place ?

ps: tu es très actif sur le site en ce moment ;)

C'est possible, mais le pourcentage d'utilisation de ces serveurs doit être assez faible.
Sois sûr que dès que ces logiciels seront plus répandus, une solution en Perl sera déployée.

Sinon, merci pour l'info, je vais aller jeter un oeil sur Roxen

Là je suis plus tout à fait d'accord...

Le Latin est beaucoup plus lisible que des symboles, peut-être, tout dépend de ce que tu appelles lisible, mais on perd un des plus grands intérêts du Perl (à mon avis) : l'accès au sources. En effet, pour le nombre de personnes qui parlent Latin, on va pas faire des programmes très "accéssibles" au commun des mortels (moi, quoi :).
Si les symboles te hérissent, tu peux toujours utiliser une fonctionnalité de Perl, je ne sais plus comment elle s'appelle, mais en gros tu remplaces certaines variables (et opérateurs ?) par de l'Anglais, langue un peu plus répandue :)
C'est beaucoup moins poussé que Lingua::Romana::Perligata, mais c'est beaucoup plus facile à débugguer pour un tiers, et ça doit être bien plus rapide à interpréter.

Sinon, j'espère que tu bosses tout seul tes scripts, parce que ça doit être assez problématique à relire ;)



Un exemple pour les sceptiques :


#! /usr/bin/perl -w
use Lingua::Romana::Perligata;

adnota Illud Cribrum Eratothenis

maximum tum val inquementum tum biguttam tum stadium egresso scribe.
vestibulo perlegementum da meo maximo.
maximum tum novumversum egresso scribe.
da II tum maximum conscribementa meis listis.
dum damentum nexto listis decapitamentum fac sic
lista sic hoc tum nextum recidementum cis vannementa da listis.
next tum biguttam tum stadium tum nextum tum novumversum
scribe egresso.
cis.


(désolé pour l'indentation)

Eh bien merci pour tout, je te suis très reconnaissant de perdre du temps à expliquer des choses sur lesquelles il existe très certainement des HOWTOs et autres FAQ...
Mais c'est toujours plus clair de se le faire expliquer en bon Français par un exemple.

Merci.

Je viens d'aller voir ce que c'était Lingua::Romana::Perligata , c'est excellent !
Par contre, ça risque de renforcer la critique sur la syntaxe illisible de Perl :)

Si c'est le procédé pour éviter de taper son mot de passe à chaque fois, n'hésites pas, ça m'intéresse beaucoup.
Sinon, n'hésites pas, ça m'intéresse beaucoup ;)

Oui, c'était un petit troll. Mais de nombreuses personnes ne se mettent pas au Perl parce qu'elles le trouvent trop compliqué (en apparence). Il est très simple de faire un code Perl (crade) sans se prendre la tête en deux temps trois mouvements.
Après, je pense que ceux qui écrivent des expression régulières monstrueuses sont des cochons et j'essaye d'éviter d'avoir à relire leur code :p

>> Le meilleur langage est de toutes façons celui que l'on connait le mieux, quel qu'il soit !
Entièrement d'accord. Mais ce n'est pas une raison pour se fermer aux autres langages. Je me mets d'ailleurs moi-même au PHP (avec qq réticences c'est vrai :).
Mon but est d'attirer l'attention de ceux qui ne connaissent pas encore Perl sur ses immenses possibilités. On peut faire à peu près tout et n'importe quoi avec Perl, des scripts CGI (ou ModPerl) à l'administration système en passant comme tu l'as dit par l'agglomération de programmes en différents langages tout en sécurisant un peu le bazar.
De plus, Perl dispose d'un nombre de modules de bonne qualité réellement TRES impréssionnant qui permettent d'étendre les capacités de ses programmes en en écrivant le moins possible. Pour obtenir les modules Perl, voir http://search.cpan.org(...) , pour les télécharger/installer/configurer, le module CPAN est excellent.
Quelques modules que j'utilise personnellement : DBI, DBD::mysql, Mail::Sender, POSIX, Apache, et je ne parle que ceux que je connais.
Pour utiliser leurs capacités dans un script Perl, un use nom_du_module est suffisant (dans la plupart des cas), et hop ! le tour est joué.

J'en oublie sûrement, mais n'hésitez pas à aller sur http://www.perl.com(...) pour y trouver votre bonheur :)

>> Lingua::Romana::Perligata
Je ne le connaissais pas celui-là...


>> Le seul intéret que je trouve à PHP est la gestion des sessions
http://search.cpan.org/doc/JBAKER/Apache-Session-1.53/Session.pm(...)
C'est un module Perl pour gérer les sessions avec Apache et ModPerl/CGI.


Voilà, tout ça pour dire que Perl est AMHA un langage sur lequel tout un chacun devrait se pencher, il devient très vite indispensable.
A ce propos, j'ai même entendu parler d'un shell entièrement en Perl ...

OK, ça marche comme sur des roulettes, je vous le conseille, le gain de perfs (et de stabilité) est réel comme indiqué par Steph.

Merci, j'attendais que quelqu'un les essaye :)

OK, merci à toi et à Frank pour ces éclaircissements. Maintenant j'ai l'embarras du choix :)

J'arrêtes pas de leur dire que Perl est bien mieux que PHP ;)

Le problème dont on entend tout le temps parler avec Java, c'est sa lenteur. Est-ce un mythe ? Parce que si c'est effectivement lent, ça ne peut pas être utilisé sur des gros serveurs FTP par exemple.
Je pense que le problème est le même avec le Perl, de par son caractère 'interprété'.

J'ai également entendu parler de certaines librairies dans les langages courants (C, C++ ...) qui permettraient de réduire de façon drastique les risques de "buffer overflow". Qu'en est-il exactement ?

Evidemment, rien ne vaut un bon vieux code bien solide et bien clair, mais personne n'est à l'abri des erreurs.

Juste un petit inconvénient : on ne peut pas le lancer en mode "standalone". Or, c'est ce que je fais tout le temps. Par exemple, j'ai besoin d'envoyer un fichier sur une machine sur laquelle j'ai un accès ssh.
OK, je lance mon serveur ftp en standalone (proftpd), je me connecte en ssh sur la machine distante, puis je lance une session ftp, fais ce que j'ai à faire, ferme la session ssh, stoppes proftpd. Je n'utilise jamais inted ou des trucs de ce genre.

Donc, ma question : cette fonctionnalité est-elle prévue, ou y a-t-il quelque chose qui l'empêche (non sécurisé, manque de temps ou de personnes pour développer, ou choix délibéré) ?

Oups, je viens de voir ton post ci-dessous...

En effet, je viens d'aller voir sur securityfocus.org, et c'est pas joli joli...
Etrange, rien n'a filtré sur le site de proftpd (peut-être pas mis à jour très souvent).

Ce qui m'a refroidi, c'est surtout http://www.securityfocus.com/frames/?content=/templates/archive.pik(...)
, un post qui a pour titre "proftpd 1.2.0rc2 -- example of bad coding" !!
Bon, alors si Proftpd n'est pas sécurisé, si Wu-ftpd ne l'est pas non plus, que faudrait-il utiliser ? Parce que selon l'auteur du port de ftpd pour Linux, le code serait assez crade...

ProFTPD is not a hack based on any other server, it's an independent source tree from the ground up

Vu sur la page de Proftpd, http://www.proftpd.net(...)