Moby-Dik a écrit 2937 commentaires

Par contre, tout ce bordel est un faux prob : la potato sera encore maintenue, c'est juste un sondage.

Tsss, faut pas le dire, c'est un forum de compétition, ici ;-)

Ah, le retour de notre ami aux attaques persos :-)

C'est concrêt. Fait un nouvelle essai ! il y a 13 versions de plus avec la 2.0.43.

Pas le temps pour l'instant, surtout que je suis satisfait de la 1.3.x.... Mais je m'y mettrai un de ces quatre ;)

Normal, la plupart sont fermés puisque dus à Apache2 et non à PHP.
Du reste, ça ne compte pas les bugs présents lors de la sortie de la RH8 et corrigés depuis.

Tout ceci n'enlève pas non plus qu'Apache 2.0 est une branche quasi-morte au même titre que gcc3.1, tant en termes d'utilisation que de compatibilité prévisible.

Mais oui, le .deb est la solution à tous les problèmes... Faudrait dégonfler les chevilles et arrêter de monter sur ses grands chevaux de façon aussi ridicule.

Hors ces critiques sont arrivées lorsque RedHat a sorti la RH 8.0. Jamais avant.

C'est quoi ce procès d'intention à la mords-moi-le-noeud ? Je ne vois pas l'intérêt de discuter si c'est pour suspecter la guerre de religion à chaque post. Pour info, bien que n'ayant pas testé la RH 8.0, d'autres décisions de leur part (comme celle d'unifier l'apparence du desktop) me semblent totalement bienvenues ; je n'ai rien non plus contre gcc2.96 (avec lequel j'ai compilé plein de trucs sans aucun problème : apache, noyau linux, mysql...). Et je n'ai d'attachement sentimental à aucun OS particulier. Par contre j'ai déjà essayé de compiler PHP pour Apache 2 (me souviens plus laquelle, c'était aux alentours de 2.0.30), et j'ai abandonné.

Pour PHP, je répète : Rasmus Lerdorf s'est plaint publiquement, et à plusieurs reprises, sur la ML des dévs Apache. Bugs.php.net est rempli de bugs provoqués par Apache 2. Ca me semble suffisamment concret.

Du reste le fait que PHP ne supporte pas officiellement Apache2 me semble largement dissuasif quand tu as un serveur en production.


(PS : je n'ai rien de négatif sur mod_ssl, au contraire puisqu'il est désormais intégré à Apache, alors qu'avant il fallait patcher les sources avec la version qui va bien)

Trop fort. Samuel a trouvé un petit copain :-)))))))))))))

Pour info, si pour appréhender Emacs tu te limites à te ballader dans les menus, tu risques de ne voir que la partie émerger de l'iceberg. Un nombre conséquent de fonctions ne sont simplement pas accessibles via les menus.

C'est d'ailleurs sûrement par expérience poussée de cette interface ô-combien-géniale (où la majorité des fonctions ne sont pas accessibles via les menus, et où les raccourcis clavier sont totalement fantaisistes histoire ne pas sombrer dans un détestable conformisme) que tu as les compétences nécessaires pour dire que Visual Studio est "une merde finie".

Honnêtement si Microsoft fait un bon produit, c'est bien Visual Studio. Pas adapté à des petits projets certes, mais remarquablement complet et intégré (et stable qui plus est...).

http://www.redhat.com/apps/support/errata/(...)

plop

C'était pour montrer qu'il y a beaucoup de module avec Apache 2.0 . De quoi satisfaire plus de 95 % des utilisateur.

http://www.securityspace.com/s_survey/data/man.200209/apachemods.ht(...)

PHP est installé sur 39% des serveurs Apache, mod_perl sur 36%. IL est donc impossible que 95% des utilisateurs soient satisfaits d'Apache 2.0, qui pose beaucoup de problèmes avec PHP et mod_perl.

Ben tu ne m'as toujours pas mis un lien vers une page qui critique Apache 2.0.x (x >= 36).

On tourne en rond là. Lis bugs.php.net et la liste des développeurs Apache ;)

Tu ne devrais pas quand tu mets en cause un projet sur un site à large audiance considérer que tout le monde lit la mailing list Apache (je la lis pas comme beaucoup).

Sauf que j'ai donné explicitement le lien dans mon post précédent, et que j'ai dit que mes infos venaient de là. Du coup, si tu n'as pas envie de la lire, tu peux au moins faire confiance.

C'est censé nous apporter quoi, ce post ?

Je suis bien d'accord. C'est pour ça qu'au contraire des zélateurs de Debian ici présents, je ne considère pas une upgrade massive du système comme quelque chose qu'on fait à la légère ("avec Debian ça marche toujours").

Retranscrit pour Linux çà donne :
- "De toute façon les développeurs Linux sont tellement peu satisfaits de la branche actuelle qu'ils ont décidé de passer prochainement à la 2.5."

Ton argument ne tient pas. Le noyau 2.4 est largement déployé et n'a aucun problème de compatibilité avec les applications tierces.

Là on une branche (Apache 2.0) pour laquelle plein de modules courants ne sont pas supportés (tu connais la différence de popularité entre PHP et Subversion ?), vers laquelle pratiquement personne n'a effectué la migration (les dernières stats de Netcraft indiquaient quelques milliers de serveurs, par rapport aux millions en Apache 1.3), et qui pourtant va déjà être abandonnée.
Tout ça pour des améliorations profondes en interne, mais minimes pour la plupart des utilisateurs, car Apache 1.3 apporte à peu près tout ce qu'on veut actuellement.
Tu comprends la différence ?

Mais comme d'habitude, dans 6 mois tout le monde va faire comme RedHat.

Ben oui. Tout le monde va faire au bon moment ce que Redhat aura fait trop tôt. Pour l'instant, les autres distribs ont éventuellement Apache2 dans les paquets optionnels, mais mettent la 1.3 par défaut, ce qui est la bonne décision pour satisfaire les attentes de la majorité des utilisateurs.

Si tu lis les messages récents de la liste des dévs Apache (septembre & octobre), tu te rendras compte que même eux pensent que ce n'est pas une bonne idée de passer à la 2.0.x actuellement. A tel point que ça a fini par faire un gros foin en interne et qu'ils ont décidé de changer leur méthode de versionnage pour la suite (ils vont utiliser un système à la Linux/Perl, pair/impair pour distinguer les versions stables des versions de développement : voir les archives http-dev du mois d'octobre).

Si tu penses que c'est du "FUD sans arguments concrets", tu lis la ML Apache avant de dégainer comme un idiot, merci.

Avant c'était du DÉVELOPPEMENT (ceci était toujours rappelé sur le site d'Apache et tu dois le savoir)

Ben justement. Pourquoi Redhat prend-il une branche marquée développement dont ils savent très bien qu'elles n'apporte pas la compatibilité attendue par un bon nombre d'utilisateurs ?

Pour ton info l'archive apache 2.0.43 pèse 4.6 Mo et apache 1.3.27 "que" 2.2 Mo.

Quelle comparaison intéressante, surtout que l'architecture d'Apache2 est totalement différente. C'est toi qui parlais de "FUD sans arguments concrets" ? :-))

Un peu tout et n'importe quoi dans cette liste. Il y a :

- des interpréteurs Prolog écrits en Java (super)
- des outils de traduction C-vers-Java (très utile :-))
- des extensions de Java
...

Du reste, le problème c'est que Java n'a été *conçu* que pour un seul langage, ce qui veut dire que même si des passerelles sont programmées par des programmeurs tiers, ça risque fort d'être de la bidouille.

Tiens, toi aussi tu fais dans la mauvaise foi ?

"l'ASP.Net et C# sont bien plus simples pour des tanches en programmation que PHP, Perl ou meme Java"

-> ce à quoi je répondais parlait de langages de programmation

Moi aussi alors je cite un post plus bas :

"Tu te rappelles du passage de linuxfr en woody ? Des merdes qui avaient entrainé le passage vers une version plus ancienne apache et peut etre d'autre chose, je sais plus ?"

Je n'ai pas demandé "où", j'ai demandé "en quoi" ;)

Genre plein de projets développés sur une plate-forme devenant moribonde, ça serait quand même du gâchis. Et moi, le gâchis, je trouve pas ça très positif.

Certes ce serait un gros gâchis. Mais le gâchis est assez directement lié au fait d'avoir choisi un langage et des bibliothèques propriétaires. En gros, les gens qui ont utilisé Java pour des projets open-source ont construit leur propre cage.

Sinon, la JVM fait tourner du ByteCode. Rien n'empêche de développer un nouveau langage qui se compile en ByteCode,

S'il s'agit simplement de choisir un bytecode, il y a plein d'alternatives à Java. D'après Mono (qui ne sont peut-être pas très objectifs, mais bon), le bytecode .Net est plus performant car mieux adapté à la compilation JIT. Les auteurs de Parrot (la future VM de Perl) ont l'air assez enthousiastes vis-à-vis des performances qu'ils obtiennent. Etc.

Note : s'il y a plusieurs projets (Mono, dotGnu) qui s'occupent de recréer un environnement de développement et d'exécution .Net complet en opensource, alors qu'il n'y en a pas en Java, c'est peut-être qu'il y a une raison.

C'est pas parce que t'as fait du VB que tu vas pondre du code objet propre en VB.Net...

Non, mais pouvoir choisir le langage approprié pour une appli est important. On ne fait pas facilement des petits scripts en Java, ni du calcul scientifique.


Ah oui, et disclaimer : je suis loin d'être un fan de .Net et de ce genre de modes technologiques soudaines.

Ca ne fait qu'apporter de l'eau à mon moulin : si la potato était moins intéressante qu'une autre à installer il y a un an, pourquoi diable était-ce encore la version officielle ?

Ce qui m'amusait, c'est que la moindre critique de Debian suscite des tonnes de récriminations, tandis que les critiques de Windows, non seulement ne sont pas rejetées aussi violemment, mais ont même tendance à conférer à leur émetteur un certain prestige (même s'il ne dit que des conneries).

Ce n'était pas une critique de ton post en particulier. Ceci dit, j'aimerais bien savoir en quoi je dis des conneries sur Debian.

Sans vouloir couper les cheveux en quatre, la donnée importante n'est pas la date de sortir de la distrib, mais la date de sortie de la version suivante. Il y a six mois ou un an, en Debian tu installais la potato, tandis qu'en Redhat tu n'installais plus la 6.2 (mais plutôt la 7.2 ou 7.3).

Personne n'a jamais dit que la performance de l'équipe Debian n'était pas bonne, au contraire, mais le processus de lancement des versions "stables" a clairement un problème (primo parce qu'il frustre une partie des utilisateurs potentiels, deuzio parce que comme on le voit ça pose des problèmes au niveau du support de versions clairement obsolètes technologiquement, mais récemment "stables").

Mais, s'il te plaît, arrête de balancer des conneries sur un projet que tu connais très peu, voire même pas du tout

Franchement, quand on voit le nombre de conneries qui sont sorties régulièrement sur Windows sans que ce soit dénoncé avec une telle véhémence, cette me phrase me fait plutôt rigoler ;)

Maintenant j'aimerais vraiments avoir combien d'autre distributions GNU/Linux assurent des mises à jour de sécurité pour des logiciels aussi anciens.

http://www.redhat.com/apps/support/errata/(...)

La 6.2 est encore supportée, alors qu'il y a eu 5 versions "stables" depuis.

Tu devrais te renseigner. Regarde le nombre de bugs sur bugs.php.net liés au support Apache2. Lis la liste des développeurs Apache (http://httpd.apache.org/mail/dev(...)), les coups de gueule de Rasmus Lerdorf (co-dév de PHP) parce que les changements réguliers de l'API des modules Apache2 empêchent de maintenir correctement le support PHP pour Apache2. Il y a mod_perl, aussi, et on ne parlera même pas de tous les "petits" modules tiers ne disposant pas des ressources de la communauté PHP.

De toute façon les développeurs Apache sont tellement peu satisfaits de la branche actuelle qu'ils ont décidé de passer prochainement à la 2.1, histoire de faire les modifs profondes dont ils ont envie (notamment la restructuration des modules d'authentification livrés avec Apache). Du coup la branche 2.0, peu supportée, sujette par le passé à de nombreuses évolutions d'API brisant la compatibilité, et déjà sur le point de se transformer en branche morte, n'est vraiment pas attirante du point de vue des auteurs de modules.

Donc livrer Apache2 par défaut était une grosse erreur.

GNU/Dos, GNU/Linux, GNU/BSD, GNU/Hurd.

Un peu d'exactitude que diable.