Plus je m'=E9loigne de Debian plus je vois ses "probl=E8mes".
Je r=E9sume.
1) Debian est une tr=E8s bonne distrib pour les serveurs, d'accord.
A mon avis, leur fa=E7on de geler les paquets requiert =E9norm=E9ment de
ressources, et cette fa=E7on de faire devrait =EAtre r=E9serv=E9e aux
entreprises. (Puisque une entreprise comme RH, on l'a paie en partie
pour les backports des probl=E8mes de s=E9curit=E9. Si RH utilisait les
derni=E8res versions upstream elle serait moins ch=E8re).
Bon, ils veulent le faire quand m=EAme, fort bien, mais pourquoi le
faire sur 25000 paquets ? Est-ce vraiment raisonnable ? C'est des
questions que j'aimerais qu'ils se posent.
2) Debian semble essayer de viser =E9galement les utilisateurs desktop.
Sauf que ni -testing, ni -unstable ne sont faits officiellement pour.
Hmm, peut être à cause de la dose de travail que celà imposerait ?
Non, c'est surtout qu'un nouvel ajout de fonctionnalités, ajoute très souvent au passage des bugs,
Donc un certain temps et un travail à fournir pour tester et le cas échéant corriger les bugs... je penses que le "Non" en début de phrase était de trop.
ou crée des changements qui peuvent poser problème.
Donc les nouvelles versions c'est bien, mais il y a aussi des gens qui utilisent leur machine pour de vrai et qui n'ont pas forcement envie de se demander chaque matin si leur machine va booter ou si ils vont devoir passer 1/2h à regler le problème.
La stable est là pour ça, je penses qu'on est d'accord sur le principe de na pas la faire évoluer sans réelle nécéssité (failles et bugs critiques).
Après pour les gens que ca ne gene pas, il y a des distribs adaptés, ou les versions de developement des distribs classiques.
nicolas vigier a écrit :
On 2008-10-20, Jonathan ROTH <jonathan@o462.fr> wrote:
Hmm, peut être à cause de la dose de travail que celà imposerait ?
Non, c'est surtout qu'un nouvel ajout de fonctionnalités, ajoute très
souvent au passage des bugs,
Donc un certain temps et un travail à fournir pour tester et le cas
échéant corriger les bugs... je penses que le "Non" en début de phrase
était de trop.
ou crée des changements qui peuvent poser
problème.
Donc les nouvelles versions c'est bien, mais il y a aussi
des gens qui utilisent leur machine pour de vrai et qui n'ont pas
forcement envie de se demander chaque matin si leur machine va booter
ou si ils vont devoir passer 1/2h à regler le problème.
La stable est là pour ça, je penses qu'on est d'accord sur le principe
de na pas la faire évoluer sans réelle nécéssité (failles et bugs
critiques).
Après pour les gens que ca ne gene pas, il y a des distribs adaptés, ou
les versions de developement des distribs classiques.
Hmm, peut être à cause de la dose de travail que celà imposerait ?
Non, c'est surtout qu'un nouvel ajout de fonctionnalités, ajoute très souvent au passage des bugs,
Donc un certain temps et un travail à fournir pour tester et le cas échéant corriger les bugs... je penses que le "Non" en début de phrase était de trop.
ou crée des changements qui peuvent poser problème.
Donc les nouvelles versions c'est bien, mais il y a aussi des gens qui utilisent leur machine pour de vrai et qui n'ont pas forcement envie de se demander chaque matin si leur machine va booter ou si ils vont devoir passer 1/2h à regler le problème.
La stable est là pour ça, je penses qu'on est d'accord sur le principe de na pas la faire évoluer sans réelle nécéssité (failles et bugs critiques).
Après pour les gens que ca ne gene pas, il y a des distribs adaptés, ou les versions de developement des distribs classiques.
ciol
On Oct 22, 6:37 pm, Jonathan ROTH wrote:
La stable est là pour ça, je penses qu'on est d'accord sur le princip e de na pas la faire évoluer sans réelle nécéssité (failles et bu gs critiques).
Il y a la manière de faire. La plupart des projets upstreams corrigent les failles. Seulement ils corrigent aussi des petits bugs en même temps. Debian n'aime pas ça, elle préfère se casser la tête à rétropor ter uniquement les corrections de sécu. En théorie c'est très bien... Mais parfois certaines corrections de bugs sont aussi potentiellement des corrections de faille de sécu, et Debian s'en fiche. cf le noyau, Linus lui même l'a dit. Bon, je pense que pour les gros projets comme Apache ou openssh, il n'y a pas de problème avec le modèle de Debian. Mais est-ce le cas par exemple avec toutes les applications php, ou tous les clients bitorrents ? Si on prend le cas d'Azureus, un gros truc en java. Je crois pas que RH le maintient dans ses branches stables. Donc Debian est la seule à le maintenir. Est-ce que tous les problèmes de sécurité sont rétroportés dans l e azureus de Debian ? (L'upstream n'indique pas toujours quand une correction concerne la sécurité). Est-ce que Debian fait un audit suffisant sur des versions qu'elle est la seule a supporter ? On peut en douter.
Si on prend Slackware, c'est plus logique. Quand une nouvelle version mineure de mysql sort, Slackware ne met pas à jour, seulement quand il y une maj de sécu, mais en tout cas il ne rétroportent pas. Ils utilisent la version de mysql upstream. Il n'y a pas de duplication inutile du travail.
Tant que certains admins se croiront en sécurité parce qu'en théorie le modèle de Debian fonctionne, ce modèle aura de l'avenir. Mais c'est fermer les yeux, ne pas se poser de question.
On Oct 22, 6:37 pm, Jonathan ROTH <jonat...@o462.fr> wrote:
La stable est là pour ça, je penses qu'on est d'accord sur le princip e
de na pas la faire évoluer sans réelle nécéssité (failles et bu gs
critiques).
Il y a la manière de faire.
La plupart des projets upstreams corrigent les failles.
Seulement ils corrigent aussi des petits bugs en même temps.
Debian n'aime pas ça, elle préfère se casser la tête à rétropor ter
uniquement les corrections de sécu.
En théorie c'est très bien...
Mais parfois certaines corrections de bugs sont aussi potentiellement
des corrections de faille de sécu, et Debian s'en fiche.
cf le noyau, Linus lui même l'a dit.
Bon, je pense que pour les gros projets comme Apache ou openssh, il
n'y a pas de problème avec le modèle de Debian.
Mais est-ce le cas par exemple avec toutes les applications php, ou
tous les clients bitorrents ?
Si on prend le cas d'Azureus, un gros truc en java.
Je crois pas que RH le maintient dans ses branches stables. Donc
Debian est la seule à le maintenir.
Est-ce que tous les problèmes de sécurité sont rétroportés dans l e
azureus de Debian ? (L'upstream n'indique pas toujours quand une
correction concerne la sécurité).
Est-ce que Debian fait un audit suffisant sur des versions qu'elle est
la seule a supporter ?
On peut en douter.
Si on prend Slackware, c'est plus logique.
Quand une nouvelle version mineure de mysql sort, Slackware ne met pas
à jour, seulement quand il y une maj de sécu, mais en tout cas il ne
rétroportent pas. Ils utilisent la version de mysql upstream. Il n'y a
pas de duplication inutile du travail.
Tant que certains admins se croiront en sécurité parce qu'en théorie
le modèle de Debian fonctionne, ce modèle aura de l'avenir.
Mais c'est fermer les yeux, ne pas se poser de question.
La stable est là pour ça, je penses qu'on est d'accord sur le princip e de na pas la faire évoluer sans réelle nécéssité (failles et bu gs critiques).
Il y a la manière de faire. La plupart des projets upstreams corrigent les failles. Seulement ils corrigent aussi des petits bugs en même temps. Debian n'aime pas ça, elle préfère se casser la tête à rétropor ter uniquement les corrections de sécu. En théorie c'est très bien... Mais parfois certaines corrections de bugs sont aussi potentiellement des corrections de faille de sécu, et Debian s'en fiche. cf le noyau, Linus lui même l'a dit. Bon, je pense que pour les gros projets comme Apache ou openssh, il n'y a pas de problème avec le modèle de Debian. Mais est-ce le cas par exemple avec toutes les applications php, ou tous les clients bitorrents ? Si on prend le cas d'Azureus, un gros truc en java. Je crois pas que RH le maintient dans ses branches stables. Donc Debian est la seule à le maintenir. Est-ce que tous les problèmes de sécurité sont rétroportés dans l e azureus de Debian ? (L'upstream n'indique pas toujours quand une correction concerne la sécurité). Est-ce que Debian fait un audit suffisant sur des versions qu'elle est la seule a supporter ? On peut en douter.
Si on prend Slackware, c'est plus logique. Quand une nouvelle version mineure de mysql sort, Slackware ne met pas à jour, seulement quand il y une maj de sécu, mais en tout cas il ne rétroportent pas. Ils utilisent la version de mysql upstream. Il n'y a pas de duplication inutile du travail.
Tant que certains admins se croiront en sécurité parce qu'en théorie le modèle de Debian fonctionne, ce modèle aura de l'avenir. Mais c'est fermer les yeux, ne pas se poser de question.
Hugolino
Le Wed, 22 Oct 2008 16:02:42 +0800, Stephane TOUGARD a écrit:
On Wed, 22 Oct 2008 06:17:47 +0000, JKB wrote:
> Je n'ai _jamais_ eu de problèmes avec apt-get update / apt-get > dist-upgrade et j'utilise le truc depuis la patate (de temps en > temps un truc vraiment pas grave sur la testing).
Ben t'as de la chance. Elle m'a fait le coup 2 fois du serveur qui repart par apres un update. Depuis, Debian est banni de mes serveurs.
s/update/upgrade/
En août 2005, sur une debian (testing crois-je me souvenir) un 'apt-get dist-upgrade' avait fait une mise à jour de X (ou du noyau) : tout pété le X...
Récemment, sur ma debian etch (stable) actuelle et qui marche très bien en 2.6.18-6-686, le paquet "linux-image-2.6.24-etchnhalf.1-686" a été installé --> reboot incapable de monter la racine. Je soupçonne fortement que c'est à cause de fstab qui référence les partitions par /dev/hdXY alors que etchnhalf doit attendre des champs UUID.
Je conçois que ce genre de blague puisse irriter l'admin confronté à des users chafoins...
Franchement, je vois meme pas l'interet de cette distrib en direct,
Quand on la connaît bien (et qu'on est un poil geek :), ça fait un truc sympa à bidouiller...
qu'elle serve de squelette a des trucs genre Ubuntu me parait logique.
Oui, mais comme Ubuntu, c'est déjà de la bidouille, tu peux pas la bidouiller comme tu veux. Je veux bien transformer un truc solide en chateau de carte tant que c'est *mon* chateau de carte, mais pas jouer avec un chateau de carte conçu par d'autres :))
--
J'ai besoin des caracteres []{}|/~ (Clavier >> Anglais-US). Mais je voudrais bien pouvoir mettre des accents dans mes courriels en francais
Il te faut donc trouver un clavier qui fait les 2. Prends l'azerty, car un clavier AZERTY en vaut 2.
Le Wed, 22 Oct 2008 16:02:42 +0800, Stephane TOUGARD a écrit:
On Wed, 22 Oct 2008 06:17:47 +0000, JKB wrote:
> Je n'ai _jamais_ eu de problèmes avec apt-get update / apt-get
> dist-upgrade et j'utilise le truc depuis la patate (de temps en
> temps un truc vraiment pas grave sur la testing).
Ben t'as de la chance. Elle m'a fait le coup 2 fois du serveur qui
repart par apres un update. Depuis, Debian est banni de mes serveurs.
s/update/upgrade/
En août 2005, sur une debian (testing crois-je me souvenir) un 'apt-get
dist-upgrade' avait fait une mise à jour de X (ou du noyau) : tout pété
le X...
Récemment, sur ma debian etch (stable) actuelle et qui marche très bien
en 2.6.18-6-686, le paquet "linux-image-2.6.24-etchnhalf.1-686" a été
installé --> reboot incapable de monter la racine. Je soupçonne
fortement que c'est à cause de fstab qui référence les partitions par
/dev/hdXY alors que etchnhalf doit attendre des champs UUID.
Je conçois que ce genre de blague puisse irriter l'admin confronté à des
users chafoins...
Franchement, je vois meme pas l'interet de cette distrib en direct,
Quand on la connaît bien (et qu'on est un poil geek :), ça fait un truc
sympa à bidouiller...
qu'elle serve de squelette a des trucs genre Ubuntu me parait logique.
Oui, mais comme Ubuntu, c'est déjà de la bidouille, tu peux pas la
bidouiller comme tu veux. Je veux bien transformer un truc solide en
chateau de carte tant que c'est *mon* chateau de carte, mais pas jouer
avec un chateau de carte conçu par d'autres :))
--
J'ai besoin des caracteres []{}|/~ (Clavier >> Anglais-US). Mais je
voudrais bien pouvoir mettre des accents dans mes courriels en francais
Il te faut donc trouver un clavier qui fait les 2. Prends l'azerty, car
un clavier AZERTY en vaut 2.
Le Wed, 22 Oct 2008 16:02:42 +0800, Stephane TOUGARD a écrit:
On Wed, 22 Oct 2008 06:17:47 +0000, JKB wrote:
> Je n'ai _jamais_ eu de problèmes avec apt-get update / apt-get > dist-upgrade et j'utilise le truc depuis la patate (de temps en > temps un truc vraiment pas grave sur la testing).
Ben t'as de la chance. Elle m'a fait le coup 2 fois du serveur qui repart par apres un update. Depuis, Debian est banni de mes serveurs.
s/update/upgrade/
En août 2005, sur une debian (testing crois-je me souvenir) un 'apt-get dist-upgrade' avait fait une mise à jour de X (ou du noyau) : tout pété le X...
Récemment, sur ma debian etch (stable) actuelle et qui marche très bien en 2.6.18-6-686, le paquet "linux-image-2.6.24-etchnhalf.1-686" a été installé --> reboot incapable de monter la racine. Je soupçonne fortement que c'est à cause de fstab qui référence les partitions par /dev/hdXY alors que etchnhalf doit attendre des champs UUID.
Je conçois que ce genre de blague puisse irriter l'admin confronté à des users chafoins...
Franchement, je vois meme pas l'interet de cette distrib en direct,
Quand on la connaît bien (et qu'on est un poil geek :), ça fait un truc sympa à bidouiller...
qu'elle serve de squelette a des trucs genre Ubuntu me parait logique.
Oui, mais comme Ubuntu, c'est déjà de la bidouille, tu peux pas la bidouiller comme tu veux. Je veux bien transformer un truc solide en chateau de carte tant que c'est *mon* chateau de carte, mais pas jouer avec un chateau de carte conçu par d'autres :))
--
J'ai besoin des caracteres []{}|/~ (Clavier >> Anglais-US). Mais je voudrais bien pouvoir mettre des accents dans mes courriels en francais
Il te faut donc trouver un clavier qui fait les 2. Prends l'azerty, car un clavier AZERTY en vaut 2.
Manuel Leclerc
ciol a écrit :
Mais parfois certaines corrections de bugs sont aussi potentiellement des corrections de faille de sécu, et Debian s'en fiche. cf le noyau, Linus lui même l'a dit.
S'il n'y a plus de mentions à la sécurité et aux CVE dans les changelogs du kernel, Linus est bien obligé d'inventer des arguments à la con.
Mais il paraît que les gens qui doivent savoir savent, donc tout va bien.
-- I refuse to have anything to even _do_ with organizations like vendor-sec that I think is a corrupt cluster-fuck of people who just want to cover their own ass. --Linus Torvalds
ciol a écrit :
Mais parfois certaines corrections de bugs sont aussi
potentiellement des corrections de faille de sécu, et
Debian s'en fiche.
cf le noyau, Linus lui même l'a dit.
S'il n'y a plus de mentions à la sécurité et aux CVE
dans les changelogs du kernel, Linus est bien obligé
d'inventer des arguments à la con.
Mais il paraît que les gens qui doivent savoir savent,
donc tout va bien.
--
I refuse to have anything to even _do_ with organizations like
vendor-sec that I think is a corrupt cluster-fuck of people who
just want to cover their own ass.
--Linus Torvalds
Mais parfois certaines corrections de bugs sont aussi potentiellement des corrections de faille de sécu, et Debian s'en fiche. cf le noyau, Linus lui même l'a dit.
S'il n'y a plus de mentions à la sécurité et aux CVE dans les changelogs du kernel, Linus est bien obligé d'inventer des arguments à la con.
Mais il paraît que les gens qui doivent savoir savent, donc tout va bien.
-- I refuse to have anything to even _do_ with organizations like vendor-sec that I think is a corrupt cluster-fuck of people who just want to cover their own ass. --Linus Torvalds
ciol
On Oct 22, 7:41 pm, Manuel Leclerc wrote:
S'il n'y a plus de mentions à la sécurité et aux CVE dans les changelogs du kernel, Linus est bien obligé d'inventer des arguments à la con.
Mais il paraît que les gens qui doivent savoir savent, donc tout va bien.
Il ne faut pas être un expert pour comprendre. Imaginons la situation suivante. Vous êtes le développeur d'un quelconque projet. Vous corrigez un bug, sans vous êtes rendu compte qu'il s'agissait d'un problème de sécurité (puisque cela peut se faire d'une manière indirecte, dans le cas du noyau Linux c'est loin d'être impossible). Et bien Debian aura un trou de sécurité.
C'est pour cela que je dis que le modèle de Debian n'est valable que si l'on vérifie *chaque* patch. Debian n'a pas les moyens pour ça, en tout cas, pas pour 25000 paquets.
On Oct 22, 7:41 pm, Manuel Leclerc <manuel.lecl...@alussinan.org>
wrote:
S'il n'y a plus de mentions à la sécurité et aux CVE
dans les changelogs du kernel, Linus est bien obligé
d'inventer des arguments à la con.
Mais il paraît que les gens qui doivent savoir savent,
donc tout va bien.
Il ne faut pas être un expert pour comprendre.
Imaginons la situation suivante.
Vous êtes le développeur d'un quelconque projet.
Vous corrigez un bug, sans vous êtes rendu compte qu'il s'agissait
d'un problème de sécurité (puisque cela peut se faire d'une manière
indirecte, dans le cas du noyau Linux c'est loin d'être impossible).
Et bien Debian aura un trou de sécurité.
C'est pour cela que je dis que le modèle de Debian n'est valable que
si l'on vérifie *chaque* patch.
Debian n'a pas les moyens pour ça, en tout cas, pas pour 25000
paquets.
S'il n'y a plus de mentions à la sécurité et aux CVE dans les changelogs du kernel, Linus est bien obligé d'inventer des arguments à la con.
Mais il paraît que les gens qui doivent savoir savent, donc tout va bien.
Il ne faut pas être un expert pour comprendre. Imaginons la situation suivante. Vous êtes le développeur d'un quelconque projet. Vous corrigez un bug, sans vous êtes rendu compte qu'il s'agissait d'un problème de sécurité (puisque cela peut se faire d'une manière indirecte, dans le cas du noyau Linux c'est loin d'être impossible). Et bien Debian aura un trou de sécurité.
C'est pour cela que je dis que le modèle de Debian n'est valable que si l'on vérifie *chaque* patch. Debian n'a pas les moyens pour ça, en tout cas, pas pour 25000 paquets.
Rakotomandimby (R12y) Mihamina
ciol wrote:
Mais est-ce le cas par exemple avec toutes les applications php, ou tous les clients bitorrents ?
Tant que certains admins se croiront en sécurité parce qu'en théorie le modèle de Debian fonctionne, ce modèle aura de l'avenir. Mais c'est fermer les yeux, ne pas se poser de question.
Les "admins" ont les yeux ouverts et ont le choix. 4 choix chez Debian en comptant "experimental". Et tant que je sache, il y a beacoup d'utilisateurs de chaque branche.
Il y aurait eu fermeture d'yeux si seule "stable" était utilisée.
Avant, j'étais tres "testing" puis tres "unstable".
Tant que certains admins se croiront en sécurité parce qu'en théorie
le modèle de Debian fonctionne, ce modèle aura de l'avenir.
Mais c'est fermer les yeux, ne pas se poser de question.
Les "admins" ont les yeux ouverts et ont le choix. 4 choix chez Debian
en comptant "experimental". Et tant que je sache, il y a beacoup
d'utilisateurs de chaque branche.
Il y aurait eu fermeture d'yeux si seule "stable" était utilisée.
Avant, j'étais tres "testing" puis tres "unstable".
Tant que certains admins se croiront en sécurité parce qu'en théorie le modèle de Debian fonctionne, ce modèle aura de l'avenir. Mais c'est fermer les yeux, ne pas se poser de question.
Les "admins" ont les yeux ouverts et ont le choix. 4 choix chez Debian en comptant "experimental". Et tant que je sache, il y a beacoup d'utilisateurs de chaque branche.
Il y aurait eu fermeture d'yeux si seule "stable" était utilisée.
Avant, j'étais tres "testing" puis tres "unstable".
Si on prend le cas d'Azureus, un gros truc en java. Je crois pas que RH le maintient dans ses branches stables. Donc Debian est la seule à le maintenir. Est-ce que tous les problèmes de sécurité sont rétroportés dans le azureus de Debian ?
Quelle idée d'utiliser Azureus quand rTorrent existe ? http://libtorrent.rakshasa.no/
-- « Quand je serai grand, je ferai des bug reports sur la LKML » -- Octane in fcolm * NNTP vaincra ! * Un bon site web se visite agréablement sans mise en forme et sans images. Sauvez un site web, mangez un webdesigner.
ciol écrivit :
Si on prend le cas d'Azureus, un gros truc en java.
Je crois pas que RH le maintient dans ses branches stables. Donc
Debian est la seule à le maintenir.
Est-ce que tous les problèmes de sécurité sont rétroportés dans le
azureus de Debian ?
Quelle idée d'utiliser Azureus quand rTorrent existe ?
http://libtorrent.rakshasa.no/
--
« Quand je serai grand, je ferai des bug reports sur la LKML »
-- Octane in fcolm * NNTP vaincra ! *
Un bon site web se visite agréablement sans mise en forme et
sans images. Sauvez un site web, mangez un webdesigner.
Si on prend le cas d'Azureus, un gros truc en java. Je crois pas que RH le maintient dans ses branches stables. Donc Debian est la seule à le maintenir. Est-ce que tous les problèmes de sécurité sont rétroportés dans le azureus de Debian ?
Quelle idée d'utiliser Azureus quand rTorrent existe ? http://libtorrent.rakshasa.no/
-- « Quand je serai grand, je ferai des bug reports sur la LKML » -- Octane in fcolm * NNTP vaincra ! * Un bon site web se visite agréablement sans mise en forme et sans images. Sauvez un site web, mangez un webdesigner.
Stephane TOUGARD
On Wed, 22 Oct 2008 10:18:13 -0700, ciol wrote:
Linus lui même l'a dit. Bon, je pense que pour les gros projets comme Apache ou openssh, il n'y a pas de problème avec le modèle de Debian.
Hum, faut pas trop parler de OpenSSH sur Debian quand meme. Cette distrib a perdu une grande partie de sa credibilite a cause de la facon pitoyable dont ce paquet a ete gere.
Tant que certains admins se croiront en sécurité parce qu'en théorie le modèle de Debian fonctionne, ce modèle aura de l'avenir. Mais c'est fermer les yeux, ne pas se poser de question.
Tout a fait d'accord.
On Wed, 22 Oct 2008 10:18:13 -0700, ciol wrote:
Linus lui même l'a dit. Bon, je pense que pour les gros projets comme
Apache ou openssh, il n'y a pas de problème avec le modèle de Debian.
Hum, faut pas trop parler de OpenSSH sur Debian quand meme. Cette distrib
a perdu une grande partie de sa credibilite a cause de la facon pitoyable
dont ce paquet a ete gere.
Tant que certains admins se croiront en sécurité parce qu'en théorie le
modèle de Debian fonctionne, ce modèle aura de l'avenir. Mais c'est
fermer les yeux, ne pas se poser de question.
Linus lui même l'a dit. Bon, je pense que pour les gros projets comme Apache ou openssh, il n'y a pas de problème avec le modèle de Debian.
Hum, faut pas trop parler de OpenSSH sur Debian quand meme. Cette distrib a perdu une grande partie de sa credibilite a cause de la facon pitoyable dont ce paquet a ete gere.
Tant que certains admins se croiront en sécurité parce qu'en théorie le modèle de Debian fonctionne, ce modèle aura de l'avenir. Mais c'est fermer les yeux, ne pas se poser de question.
Tout a fait d'accord.
Stephane TOUGARD
On Wed, 22 Oct 2008 22:44:08 +0300, Rakotomandimby (R12y) Mihamina wrote:
Mais est-ce le cas par exemple avec toutes les applications php, ou tous les clients bitorrents ?
Parlons d'applications sérieuses, plutot... non?
Non. On ne definit pas une application "serieuse", soit elle est geree de facon correcte, soit elle ne l'est pas.
On Wed, 22 Oct 2008 22:44:08 +0300, Rakotomandimby (R12y) Mihamina wrote:
Mais est-ce le cas par exemple avec toutes les applications php, ou
tous les clients bitorrents ?
Parlons d'applications sérieuses, plutot... non?
Non. On ne definit pas une application "serieuse", soit elle est geree de
facon correcte, soit elle ne l'est pas.
