Aller plus loin
- l'info (3 clics)
Un virus attaque les machines RedHat
18
jan.
2001
Un vers nommé Ramen s'attaque à l'heure actuelle aux serveurs Linux qui se trouvent sur son passage. Il semblerait que seules les distributions RedHat 6.2 et 7.0 soient victimes de ce vers. En effet, il exploite plusieurs trous de sécurité au niveau de rpc.statd et wu-ftpd pour s'implanter sur les machines et modifier les fichiers d'acceuil du serveur web (index.html)... (source mynews.free.fr)
# HOAX ?
Posté par Anonyme . Évalué à 0.
[^] # Re: HOAX ?
Posté par Anonyme . Évalué à 0.
# Attention danger !
Posté par Anonyme . Évalué à 0.
Vu les problèmes de sécurité de wu-ftpd, il vaut mieux le changer pour proftpd.
[^] # Re: Attention danger !
Posté par Ramón Perez (site web personnel) . Évalué à 1.
Et rpc.statd ca sert a quoi ?
[^] # Re: Attention danger !
Posté par bmc . Évalué à 1.
De plus, il a une syntaxe de configuration assez proche de celle d'Apache, ce qui peut accélerer sa mise en place et sa compréhension.
[^] # Re: Attention danger !
Posté par sylvain cresto (site web personnel) . Évalué à 1.
[^] # Re: Attention danger !
Posté par Yann Kerhervé (site web personnel) . Évalué à 1.
le plus sûr c'est certainement scp :)
[^] # Re: Attention danger !
Posté par Mathieu Dessus (site web personnel) . Évalué à 1.
http://freshmeat.net/projects/ftpd-bsd/?highlight=ftpd(...)
[^] # Re: Attention danger !
Posté par bmc . Évalué à 1.
Vu sur la page de Proftpd, http://www.proftpd.net(...)
[^] # Re: Attention danger !
Posté par bmc . Évalué à 1.
Pour proftpd, je n'ai entendu parler de problèmes que dans les version antérieures à 1.2.0pre9. Depuis, il n'y a pas eu d'alertes de sécurité (ça doit faire pas loin de 8 mois), et la version 1.2.0 a l'air très prometteuse.
[^] # Re: Attention danger !
Posté par j . Évalué à 1.
[^] # Re: Attention danger !
Posté par bmc . Évalué à 1.
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...
[^] # Re: Attention danger !
Posté par bmc . Évalué à 1.
[^] # Ca me fait bien rire
Posté par Anonyme . Évalué à 0.
[^] # Ca me fait bien rire aussi
Posté par Ano . Évalué à 1.
Ca éxploite un trou de sécurité connu. La distro n'a pas corrigé, tant pis pour eux. L'admin n'a pas corrigé, tant pis pour lui!
Sinon, toute personne censée aura corrigé ce trou!
Pour les mandrakiens, un ch'tit MandrakeUpdate et fini le ver!
Par contre, avec un trou connu dans un soft propriétaire, on peut toujours moisir en attendant le patch!
[^] # Re: Attention danger !
Posté par Anonyme . Évalué à -1.
Vu les problèmes de sécurité des distros Linusque il vaut mieux changer pour un BSD.
Si ce n'est pas possible, faire sa propre mouture basée sur LFS ou slack.
[^] # Re: Attention danger !
Posté par LynXX . Évalué à 1.
" [...] The worm may also successfully execute on Intel-processor based systems with a Linux compatibility layer such as FreeBSD or NetBSD. [...]"
[^] # Re: Attention danger !
Posté par Anonyme . Évalué à 0.
Est-ce bien sérieux ?
--
« C'est l'histoire d'un gars qui veut la machine la plus puissante du
monde sous Windows 95 en émulation sous Wine qui tourne sur une station
FreeBSD avec bibliotheque de compatibilité Linux. »
-+- ST in Guide du linuxien pervers : "A quoi sert Unix ?" -+-
# securityfocus
Posté par cornofulgur . Évalué à 1.
http://news.cnet.com/news/0-1003-200-4508359.html?tag=st.ne.1430735(...)
par contre, le site de redhat ne reference pas Ramen, a part dans ce document:
http://www.europe.redhat.com/documentation/HOWTO/User-Authenticatio(...)
Si vous ne corrigez pas les trous dans vos distro, c'est le ver qui le fera. Il s'empeche ainsi de contaminer plusieurs fois une meme machine, une strategie que n'avait pas adopte le ver de Morris. Le principal effet notable est une forte charge reseau, du aux scans que le ver tente pour detecter d'autres trous.
# linuxfr sous Redhat
Posté par oliv . Évalué à 1.
# ...
Posté par Anonyme . Évalué à 0.
(je précise que pour qu'il soit lancé par défaut sous RedHat, il faut préciser à l'installation qu'on désire avoir un serveur ftp)
[^] # Re: ...
Posté par Ramón Perez (site web personnel) . Évalué à 1.
[^] # Re: ...
Posté par Anonyme . Évalué à 0.
[surtout avec l'aide affichée à gauche]
# Pure-FTPd
Posté par j . Évalué à 1.
Tout petit ("no bloat"), extremement stable, très sécurisé (jamais le moindre trou découvert), simple à mettre en oeuvre...
Malheureusement l'auteur n'a plus le temps de vraiment s'y consacrer.
Je viens donc de prendre le relais, et le serveur se nomme désormais Pure-FTPd.
Vous le trouverez sur http://www.sourceforge.net/projects/pureftpd(...) ainsi que sur http://www.jedi.claranet.fr(...)
Jetez-y un coup d'oeil, surtout qu'il est réellement dédié à Linux.
-Jedi.
[^] # Re: Pure-FTPd
Posté par Ramón Perez (site web personnel) . Évalué à 1.
C'est peut être du en grande partie au fait que peu de personnes l'utilisent. (comme disait quelqu'un sur Slashdot, rien ne vaut comme firewall un VAX sous VMS, on ne trouve pas de scripts kiddies pour ça sur le net !)
Bon je vais jeter un oeil...
[^] # Re: Pure-FTPd
Posté par bmc . Évalué à 1.
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é) ?
[^] # Re: Pure-FTPd
Posté par Matthias Saou . Évalué à 1.
1) Avec openssh, il suffit de rajouter "sftp" ( http://www.xbill.org/sftp/(...) ou http://redhat.aldil.org/(...) pour un RPM RedHat 7.0) et le tour est joué!
2) Modifier la conf d'inetd ou xinetd et lui balancer un -HUP pour qu'il relise sa conf puis refaire la manip' inverse après.
Moi j'utilise plutôt le 1) ...
Matthias
[^] # Re: Pure-FTPd
Posté par j . Évalué à 1.
scp fichier1 fichier2 fichier3 login@machi.ne:/tmp
scp -r login@machi.ne:/usr/src/linux /var/import
scp login@machi.ne:/home/j/images/\*.jpg /tmp
Dans tous les cas, on passe par SSH ce qui permet d'une part de crypter les données, mais aussi d'utiliser les clefs RSA ou DSA pour ne jamais avoir à taper de mot de passe. 'scp' devient aussi simple que 'cp', et peut s'utiliser dans des scripts, par exemple pour automatiser la mise à jour de plusieurs machines distantes.
[^] # Re: Pure-FTPd
Posté par bmc . Évalué à 1.
[^] # Re: Pure-FTPd
Posté par j . Évalué à 1.
[^] # Re: Pure-FTPd
Posté par bmc . Évalué à 1.
Sinon, n'hésites pas, ça m'intéresse beaucoup ;)
[^] # Re: Pure-FTPd
Posté par j . Évalué à 1.
Le principe est très simple : prenons deux machines. (C) étant le client à partir duquel on souhaite lancer "ssh" (ou scp, hsftp, etc...) . (S) est le serveur sur lequel on souhaite se connecter à l'aide du compte "plop".
On installe une clef publique sur (S), dans le compte "plop". En fait, on installe cette clef publique sur toutes les machines où l'on souhaite se connecter sans mot de passe à partir de (C) .
Pour que l'authentification réusisse, il suffit de posséder sur (C) la clef privée correspondant à la clef publique déposée sur les serveurs. Simple, non ?
Voici comment créer le couple clef publique à exporter/clef privée à conserver sur (C) :
ssh-keygen -d
Et c'est tout. On obtient en retour dans le répertoire ~/.ssh deux fichiers : id_dsa (clef privée : ne pas donner l'acces en lecture aux autres !), et id_dsa.pub (clef publique) .
Le contenu de id_dsa.pub est à copier sur (S) dans le fichier ~plop/.ssh/authorized_hosts2 (le 2 n'est pas une faute de frappe, c'est pour le protocole SSH 2) .
Et... c'est tout ! Dans le fichier authorized_hosts2 vous pouvez évidemment mettre plusieurs clefs privées, une par ligne.
Pour résumer :
ssh-keygen -d
scp .ssh/id_dsa plop@nom.du.serveur:.ssh/authorized_hosts2
(scp demande le mot de passe)
Et voilà. Les "scp" et "ssh" suivants ne vous demanderont plus de passe.
Attention : dans les fichiers sshd_config et ssh_config (en principe dans /usr/local/etc) vous devez avoir la ligne suivante :
DSAAuthentication yes
Voilà !
[^] # Re: Pure-FTPd
Posté par bmc . Évalué à 1.
Mais c'est toujours plus clair de se le faire expliquer en bon Français par un exemple.
Merci.
[^] # Re: Pure-FTPd
Posté par Anonyme . Évalué à -1.
[^] # Re: Pure-FTPd
Posté par syntaxerror . Évalué à 1.
et si quelqu'un met la main dessus il pourra se faire passer
pour vous sur tous les serveurs où la clef publique a été copiée.
Il faut généralement protéger sa clef par une passphrase.
Et rentrer la passphrase à chaque utilisation de la clef.
C'est encore plus chiant qu'un mot de passe, direz-vous.
Oui (à ceci près que la clef permet d'accéder tous les serveurs
avec un même passphrase, quel que soit le mot de passe qui
serait utilisé à l'autre bout).
La solution est de démarrer ssh-agent en début de session (X ou login), ou plutôt de démarrer la session à travers ssh-agent, par exemple:
ssh-agent bash
ou bien ssh-agent startx
(Debian fait ça par défaut)
Ensuite on peut gérer les clefs connues de ssh-agent
par la commande ssh-add. La passphrase sera demandée une fois et c'est tout.
[^] # Re: Pure-FTPd
Posté par j . Évalué à 1.
tcpserver 0 ftp /usr/local/sbin/pure-ftpd &
Et voilà, ton serveur FTP tourne et il n'y a aucune différence avec un "standalone".
Les super-serveurs comme tcpserver, g2s et xinetd possèdent de quoi prendre correctement en charge les connexions, maintenir des fichiers d'historique, effectuer du filtrage IP, ... Bref, tout ce qui se passe entre le moment où un client demande une connexion et celui où la session commence réellement avec le serveur.
Tout les serveurs "standalone" doivent réimplémenter tout ça. Et la configuration de ces éléments redondants se fait pourtant chaque fois d'une façon totalement différente d'un logiciel à l'autre.
Pure-FTPd n'a actuellement pas de mode "standalone" pour cette raison : il doit rester simple, petit, et se concentrer sur le protocole FTP et non la négociations des connexions, que d'autres logiciels font très bien. Si je commence à y ajouter la gestion de bases de données CDB (pour le filtrage IP, comme TCPServer), on va obtenir un produit plus lourd. Et ceux qui n'utilisent pas le filtrage en subiraient quand meme les conséquences.
Et même au niveau sécurité, c'est intéressant de séparer chaque tâche. Ainsi, g2s/xinetd/tcpserver/rlinetd/etc... sont audités de leur coté, et les serveurs qu'ils lancent, d'un autre côté. Si un bug ou une faille de sécurité se produit, on ne perd pas de temps à la localiser ("zut, ça a planté... il y a un D.O.S... est-ce-qu'il vient des fonctions qui acceptent les connexions TCP et du filtrage IP ? Est-ce dans les fonctions qui demandent le login du client FTP ?" - Le problème ne se pose pas si ces parties sont séparées) .
D'autre part... Avoir un mode "standalone" pour des logiciels comme Apache et Proftpd est intéressant car ils possèdent un fichier de configuration avec une syntaxe complexe. Le déchiffrer prend du temps. S'il faut le déchiffrer à chaque fois qu'un client se connecte (en mode non-standalone), c'est forcément plus lent que si ces fichiers sont analysés une fois pour toutes.
Maintenant, dans le cas de Pure-FTPd, le démarrage est immédiat : les options sont en ligne de commande, le cache des uid/gid se construit dynamiquement, et les serveurs virtuels ne sont détectés que s'ils sont réellement utilisés. Donc lancer Pure-FTPd en standalone ou à partir d'un super-serveur revient sensiblement au même pour les performances.
Cela dit, il y aura peut-etre effectivement un mode standalone avant la version 1.0, mais uniquement pour avoir une architecture encore plus blindée niveau sécurité. En gros, il y aura un "serveur de bind" qui n'aura aucune capacité (au sens des "capabilities" du noyau Linux) si ce n'est celle d'ouvrir des connexions sur des ports privilégiés et de passer les descripteurs au réel serveur. Résultat : *aucune* partie du serveur ne tournera sous l'identité "root" (la cause de tous les soucis des autres logiciels) .
# Vive debian
Posté par Anonyme . Évalué à 0.
Lgtm http://www.phpmylinux.net/(...)
# Zont qu'à programmer en Java !
Posté par crusher . Évalué à 1.
On parle souvent de Java pour sa portabilité mais il ne faut pas oublier l'aspect sécurité.
L'attaque du buffer overflow est impossible en Java : pas de pointeur (ou plutot pas de manipulation directe d'adresse mémoire), pas de dépassement de la taille de tableau autorisé.
De même il est possible de définir des contraintes de sécurité pour toutes applications Java de manière très fine et indépendantes de l'appli. comme par exemple ne donner l'accès qu'à un seul répertoire ou un seul port.
Plus d'info sur http://java.sun.com/j2se/1.3/docs/guide/security/spec/security-spec(...)
PS.: Attention, ça ne veut pas dire qu'il n'y a pas de problèmes de sécurité dans une appli. Java:
une appli mal développée en langage X reste une appli mal développée en Java ! Mais en Java on évite des erreurs qui à notre époque me semble assez risibles (comme dépasser la taille d'une chaine de caractères qui plante l'appli dans le meilleur des cas). Un peu comme si sur un OS le plantage d'une appli. planterait tout le système :-)
PSS.: De même il arrive qu'il y ait des problèmes de sécurité dans l'implémentation d'une JVM mais dans ce cas là il est plus facile de corriger le problème que de sécuriser toutes les applis.
[^] # Re: Zont qu'à programmer en Java !
Posté par j . Évalué à 1.
Les exceptions systématiques et le securitymanager de Java sont effectivement très efficaces contre ce genre de bourdes. Mais ce ne sont que des barrières qui ne transforment pas miraculeusement un mauvais code en un code sûr et solide. Simplement, les conséquences d'un bogue sont différentes. Ca va davantage se traduire par un déni de service que par l'exécution de code arbitraire (porte joyeusement ouverte par un buffer overflow) .
Perl est aussi un bon choix pour placer des barrières autour d'un code pas forcément très sûr, en particulier grâce à l'excellent mode "taint".
[^] # Re: Zont qu'à programmer en Java !
Posté par bmc . Évalué à 1.
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.
[^] # Re: Zont qu'à programmer en Java !
Posté par j . Évalué à 1.
Quant à ton point de vue sur Perl... je le partage entierement. Ne serait-ce-que parce que tout ce qu'il est possible de faire en PHP est refaisable en Perl, alors que l'inverse n'est pas vrai (et Lingua::Romana::Perligata n'existe pas en PHP) . Le seul intéret que je trouve à PHP est la gestion des sessions. Mais bref, ne relançons pas ce genre de débat. Le meilleur langage est de toutes façons celui que l'on connait le mieux, quel qu'il soit !
[^] # Re: Zont qu'à programmer en Java !
Posté par bmc . Évalué à 1.
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 ...
[^] # Re: Zont qu'à programmer en Java !
Posté par j . Évalué à 1.
Il n'y a pas qu'Apache sous Linux...
- WN (http://www.wnserver.org(...)) est plus sécurisé (et possède des fonctionnalités intégrés intéressantes, comme un moteur de recherche)
- Roxen (http://www.roxen.com(...)) est très puissant, dispose d'une magnifique interface de configuration, se met à jour automatiquement par le net, et il existe de nombreux modules aussi originaux que pratiques, ainsi qu'un langage (RXML) simple et complet pour les pages dynamiques.
- WebFS (j'ai plus l'url en tete) et le serveur web du noyau Linux 2.4 (khttpd) sont parfaits pour les pages statiques.
- THttpd bat de loin tous ses concurrents... pour les trous de sécurité. Son principal argument concerne le throttling (limitation de bande passante pour chaque service) . Mais Roxen fait aussi ça à merveille, et propose meme d'affecter des priorités à tous les modules.
[^] # Re: Zont qu'à programmer en Java !
Posté par bmc . Évalué à 1.
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
[^] # Re: Zont qu'à programmer en Java !
Posté par bmc . Évalué à 1.
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
[^] # Re: Zont qu'à programmer en Java !
Posté par j . Évalué à 1.
"Courrier" est une très bonne alternative, et est sous license GPL. Par contre je n'ai pas du tout confiance en la façon dont ça a été programmé, les auteurs ne se sont visiblement pas du tout souciés de la sécurité de leur code dès le départ. "Maildrop" était à lui seul un nid de buffer overflows, et "Courrier" a les mêmes lacunes. Ils ne se sont décidés que très récemment à corriger quelques sprintf/strcat/strcpy.
Qmail est nickel. Aucun problème de sécurité, très fiable, rapide, et une architecture à base de petits composants plutôt qu'une usine à gaz. Quasiment aucune contribution n'a été intégrée à la distribution officielle, il faut donc se préparer à patcher le source d'origine dans tous les sens si on souhaite en bénéficier. Mais on n'a pas forcément besoin des contributions.
Postfix... hum.... non, je n'ai pas envie d'utiliser un soft dont l'auteur n'arrete pas de se vanter, de se moquer hypocritement des autres logiciels pour promouvoir le sien, et de répondre "va t'acheter unix pour les nuls, connard" lorsque, sur la mailing-list, quelqu'un pose une question un peu trop basique à son goût.
Il reste aussi Zmailer, réputé pour sa rapidité, et Exim, une usine à gaz qui a connu quelques failles de sécurité, mais qui est GPL et a déjà largement fait ses preuves.
Oublie par contre "postaci", encore buggué et sur lequel un important overflow a été découvert hier.
[^] # Re: Zont qu'à programmer en Java !
Posté par bmc . Évalué à 1.
Par contre, ça risque de renforcer la critique sur la syntaxe illisible de Perl :)
[^] # Re: Zont qu'à programmer en Java !
Posté par j . Évalué à 1.
[^] # Re: Zont qu'à programmer en Java !
Posté par bmc . Évalué à 1.
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)
[^] # Re: Zont qu'à programmer en Java !
Posté par j . Évalué à 1.
Hum, cela dit mes sources en Perl sont peut-être illisibles malgré tout, preuve en est l'entrée "dlister" au concours Obfuscated Perl Programming Contest de cette année ( www.tpj.com ) .
[^] # Ah oui, là...
Posté par bmc . Évalué à 1.
[^] # Re: Ah oui, là...
Posté par j . Évalué à 1.
On a envie de programmer "propre et structuré" ? On peut ! On veut du code bourrin ? On peut ! On aime la programmation objet ! On peut ! On déteste la programmation objet ? Pas grave !
Et pour ceux qui ne jurent que par Java, sachez qu'un compilateur Perl -> bytecode Java est en développement.
[^] # Oui, enfin option
Posté par reno . Évalué à 1.
Beurk!!
Je suis d'accord le point fort du Perl c'est sa souplesse, m'enfin ca a un prix assez lourd a payer.
Je fais pas mal de maintenance sur du Perl crade (certains diront que c'est un pleonasme)
==> la prochaine fois que je demarre un projet je me battrait "jusqu'a la mort" pour utiliser Python ou Ruby, mais pas Perl.
[^] # Re: Oui, enfin option
Posté par bmc . Évalué à 1.
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).
[^] # Re: Zont qu'à programmer en Java !
Posté par Christophe BAEGERT . Évalué à 1.
Mais evidemment le temps de lancement est important. Ce qui peut etre réglé par le mod_perl (bof) ou par le Fast CGI (génial).
Voila.
[^] # Re: Zont qu'à programmer en Java !
Posté par bmc . Évalué à 1.
Une question : que reproches-tu au mod_perl et FastCGI est-il vraiment avantageux en comparaison ?
# Pas forcément uniquement Red Hat
Posté par Frédéric Delanoy . Évalué à 1.
Les admins. n'avaient qu'à appliquer les patchs c'est tout !
# anti virus
Posté par christophe deze . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.