Par contre.. comment dire.. au niveau avancement.. si tu lis bien les
projets d'avancement de Gnome.. tu verras comment ils envient les
technologies microsoft et cherche à les reproduire..
[...]
Et je te parlerais même du pourquoi c'est si simple de faire des softs
sous Win alors que c'est un vrai cauchemard sous linux.. des notions
comme les technos ODBC par exemple.. ou COM ou maintenant les ADO
Provider (merci Mono de les implémenter..) ..
Et je parle pas de l'enfer du déploiement..
Par contre.. comment dire.. au niveau avancement.. si tu lis bien les
projets d'avancement de Gnome.. tu verras comment ils envient les
technologies microsoft et cherche à les reproduire..
[...]
Et je te parlerais même du pourquoi c'est si simple de faire des softs
sous Win alors que c'est un vrai cauchemard sous linux.. des notions
comme les technos ODBC par exemple.. ou COM ou maintenant les ADO
Provider (merci Mono de les implémenter..) ..
Et je parle pas de l'enfer du déploiement..
Par contre.. comment dire.. au niveau avancement.. si tu lis bien les
projets d'avancement de Gnome.. tu verras comment ils envient les
technologies microsoft et cherche à les reproduire..
[...]
Et je te parlerais même du pourquoi c'est si simple de faire des softs
sous Win alors que c'est un vrai cauchemard sous linux.. des notions
comme les technos ODBC par exemple.. ou COM ou maintenant les ADO
Provider (merci Mono de les implémenter..) ..
Et je parle pas de l'enfer du déploiement..
Mais non, c'est pas pareil. Tu fais tout à la main :
- déterminer la langue de l'utilisateur
une ligne au lancement de l'application
- charger la ressource qui correspond (et les ressources
indépendantes de la localisation)
une autre ligne au lancement de l'application (pour obtenir le Handle
- repérer les chaînes à traduire
Utiliser les outils pour ça.
- mettre à jour la traduction
idem que pour gettext.. les outils existent. Faut s'en servir.. y'a un
C'est un boulot tellement chiant qu'il y a quasiment aucune appli
localisée sous Windows alors que sous Linux ou Mac OS X, on en trouve
à la pelle. Simplement parce qu'ils ont un framework adapté.
Je peux te sortir une palanquée d'appli linux non ou très mal
Tout ce framework n'existe pas dans l'API Win32. Windows a des années
de retard sur ce terrain. Disons le :)
D'avance plutôt, vu que la méthode existait déjà avant la création
Gettext
On peut aussi appeler ressource un fichier texte avec les
correspondances et dire que ça existait déjà dans les années 60.
Entre nous, ca serait même encore mieux, parce que franchement, les
Sinon J'avais pas encore regarder pour Dot Net. A la création d'une
fenêtre, on determine si elle sera localisable. L'éditeur fait alors
de lui même les fichiers de ressources necessaires par langue. Le
form designer gère plusieurs langues à la volée et garde en plus la
possibilité d'éditer les ressources indépendament (genre envoyé le
source à des traducteurs externes..) Et le source.. c'est du xml,
donc facilement éditable dans n'importe quel environnement.
Et pour ce qui n'est pas de l'interface, quelles sont les facilitées ?
bin pareil.
L'interface graphique, c'est qu'une classe comme une autre..
Concrètement, j'ai un code avec "printf("Bonjour")", je localise
comment ?
bin comme le reste.
Mais non, c'est pas pareil. Tu fais tout à la main :
- déterminer la langue de l'utilisateur
une ligne au lancement de l'application
- charger la ressource qui correspond (et les ressources
indépendantes de la localisation)
une autre ligne au lancement de l'application (pour obtenir le Handle
- repérer les chaînes à traduire
Utiliser les outils pour ça.
- mettre à jour la traduction
idem que pour gettext.. les outils existent. Faut s'en servir.. y'a un
C'est un boulot tellement chiant qu'il y a quasiment aucune appli
localisée sous Windows alors que sous Linux ou Mac OS X, on en trouve
à la pelle. Simplement parce qu'ils ont un framework adapté.
Je peux te sortir une palanquée d'appli linux non ou très mal
Tout ce framework n'existe pas dans l'API Win32. Windows a des années
de retard sur ce terrain. Disons le :)
D'avance plutôt, vu que la méthode existait déjà avant la création
Gettext
On peut aussi appeler ressource un fichier texte avec les
correspondances et dire que ça existait déjà dans les années 60.
Entre nous, ca serait même encore mieux, parce que franchement, les
Sinon J'avais pas encore regarder pour Dot Net. A la création d'une
fenêtre, on determine si elle sera localisable. L'éditeur fait alors
de lui même les fichiers de ressources necessaires par langue. Le
form designer gère plusieurs langues à la volée et garde en plus la
possibilité d'éditer les ressources indépendament (genre envoyé le
source à des traducteurs externes..) Et le source.. c'est du xml,
donc facilement éditable dans n'importe quel environnement.
Et pour ce qui n'est pas de l'interface, quelles sont les facilitées ?
bin pareil.
L'interface graphique, c'est qu'une classe comme une autre..
Concrètement, j'ai un code avec "printf("Bonjour")", je localise
comment ?
bin comme le reste.
Mais non, c'est pas pareil. Tu fais tout à la main :
- déterminer la langue de l'utilisateur
une ligne au lancement de l'application
- charger la ressource qui correspond (et les ressources
indépendantes de la localisation)
une autre ligne au lancement de l'application (pour obtenir le Handle
- repérer les chaînes à traduire
Utiliser les outils pour ça.
- mettre à jour la traduction
idem que pour gettext.. les outils existent. Faut s'en servir.. y'a un
C'est un boulot tellement chiant qu'il y a quasiment aucune appli
localisée sous Windows alors que sous Linux ou Mac OS X, on en trouve
à la pelle. Simplement parce qu'ils ont un framework adapté.
Je peux te sortir une palanquée d'appli linux non ou très mal
Tout ce framework n'existe pas dans l'API Win32. Windows a des années
de retard sur ce terrain. Disons le :)
D'avance plutôt, vu que la méthode existait déjà avant la création
Gettext
On peut aussi appeler ressource un fichier texte avec les
correspondances et dire que ça existait déjà dans les années 60.
Entre nous, ca serait même encore mieux, parce que franchement, les
Sinon J'avais pas encore regarder pour Dot Net. A la création d'une
fenêtre, on determine si elle sera localisable. L'éditeur fait alors
de lui même les fichiers de ressources necessaires par langue. Le
form designer gère plusieurs langues à la volée et garde en plus la
possibilité d'éditer les ressources indépendament (genre envoyé le
source à des traducteurs externes..) Et le source.. c'est du xml,
donc facilement éditable dans n'importe quel environnement.
Et pour ce qui n'est pas de l'interface, quelles sont les facilitées ?
bin pareil.
L'interface graphique, c'est qu'une classe comme une autre..
Concrètement, j'ai un code avec "printf("Bonjour")", je localise
comment ?
bin comme le reste.
- repérer les chaînes à traduire
Utiliser les outils pour ça.
- mettre à jour la traduction
idem que pour gettext.. les outils existent. Faut s'en servir.. y'a
un
éditeur de ressources dans chaque environement digne de ce nom (du
moins sur tout ceux que j'ai utilisé, même le machin ignoble de
PCSoft..)
C'est un boulot tellement chiant qu'il y a quasiment aucune appli
localisée sous Windows alors que sous Linux ou Mac OS X, on en trouve
à la pelle. Simplement parce qu'ils ont un framework adapté.
Je peux te sortir une palanquée d'appli linux non ou très mal
localisée..
Et la seule appli non localisée que j'ai sur mon poste est un vieux
client FTP qui me convient bien et Real VNC.
Tous les autres sont dans la langue du système et la plupart peuvent
changer à la volée.
Concrètement, j'ai un code avec "printf("Bonjour")", je localise
comment ?
bin comme le reste.
"Bonjour", "Guten Tag", "Hello" sont sagement rangé dans leur ressource
respective
1) on repère la langue
2) on récupère la ressource.
je vois pas en quoi ca change.. c'est pas parce que il n'y a pas la
fenêtre que l'API n'est pas accessible. C'est pas un tool Kit graphique
comme les MFC ou la VCL,wxWidget ou GTK ..
- repérer les chaînes à traduire
Utiliser les outils pour ça.
- mettre à jour la traduction
idem que pour gettext.. les outils existent. Faut s'en servir.. y'a
un
éditeur de ressources dans chaque environement digne de ce nom (du
moins sur tout ceux que j'ai utilisé, même le machin ignoble de
PCSoft..)
C'est un boulot tellement chiant qu'il y a quasiment aucune appli
localisée sous Windows alors que sous Linux ou Mac OS X, on en trouve
à la pelle. Simplement parce qu'ils ont un framework adapté.
Je peux te sortir une palanquée d'appli linux non ou très mal
localisée..
Et la seule appli non localisée que j'ai sur mon poste est un vieux
client FTP qui me convient bien et Real VNC.
Tous les autres sont dans la langue du système et la plupart peuvent
changer à la volée.
Concrètement, j'ai un code avec "printf("Bonjour")", je localise
comment ?
bin comme le reste.
"Bonjour", "Guten Tag", "Hello" sont sagement rangé dans leur ressource
respective
1) on repère la langue
2) on récupère la ressource.
je vois pas en quoi ca change.. c'est pas parce que il n'y a pas la
fenêtre que l'API n'est pas accessible. C'est pas un tool Kit graphique
comme les MFC ou la VCL,wxWidget ou GTK ..
- repérer les chaînes à traduire
Utiliser les outils pour ça.
- mettre à jour la traduction
idem que pour gettext.. les outils existent. Faut s'en servir.. y'a
un
éditeur de ressources dans chaque environement digne de ce nom (du
moins sur tout ceux que j'ai utilisé, même le machin ignoble de
PCSoft..)
C'est un boulot tellement chiant qu'il y a quasiment aucune appli
localisée sous Windows alors que sous Linux ou Mac OS X, on en trouve
à la pelle. Simplement parce qu'ils ont un framework adapté.
Je peux te sortir une palanquée d'appli linux non ou très mal
localisée..
Et la seule appli non localisée que j'ai sur mon poste est un vieux
client FTP qui me convient bien et Real VNC.
Tous les autres sont dans la langue du système et la plupart peuvent
changer à la volée.
Concrètement, j'ai un code avec "printf("Bonjour")", je localise
comment ?
bin comme le reste.
"Bonjour", "Guten Tag", "Hello" sont sagement rangé dans leur ressource
respective
1) on repère la langue
2) on récupère la ressource.
je vois pas en quoi ca change.. c'est pas parce que il n'y a pas la
fenêtre que l'API n'est pas accessible. C'est pas un tool Kit graphique
comme les MFC ou la VCL,wxWidget ou GTK ..
Coucou !
Laurent BERNE écrivait:Par contre.. comment dire.. au niveau avancement.. si tu lis bien les
projets d'avancement de Gnome.. tu verras comment ils envient les
technologies microsoft et cherche à les reproduire..
Euh, qui a copié qui et quoi ? Vous êtes sûr de pouvoir répondre à cette
question ?
http://mail.gnome.org/archives/foundation-list/2004-April/msg00008.html
[...]
Et je te parlerais même du pourquoi c'est si simple de faire des softs sous
Win alors que c'est un vrai cauchemard sous linux.. des notions comme les
technos ODBC par exemple.. ou COM ou maintenant les ADO Provider (merci
Mono de les implémenter..) ..
Implémenter tous ces trucs avec l'API WIN32 est aisé, vous êtes sûr ?
Ou seulement si l'on a à sa disposition tout un tas d'outils et de
bibliothèques qui les encapsulent ?
Y'a pas besoin de lib particulière pour instancier un objet com et
Et je parle pas de l'enfer du déploiement..
Mmmmh ?
S'assurer que les bibliothèques et les fonctions du système que l'on
requiert, fonctionnent sous 95,98, NT et XP, ce n'est pas non plus très
évident.
Coucou !
Laurent BERNE écrivait:
Par contre.. comment dire.. au niveau avancement.. si tu lis bien les
projets d'avancement de Gnome.. tu verras comment ils envient les
technologies microsoft et cherche à les reproduire..
Euh, qui a copié qui et quoi ? Vous êtes sûr de pouvoir répondre à cette
question ?
http://mail.gnome.org/archives/foundation-list/2004-April/msg00008.html
[...]
Et je te parlerais même du pourquoi c'est si simple de faire des softs sous
Win alors que c'est un vrai cauchemard sous linux.. des notions comme les
technos ODBC par exemple.. ou COM ou maintenant les ADO Provider (merci
Mono de les implémenter..) ..
Implémenter tous ces trucs avec l'API WIN32 est aisé, vous êtes sûr ?
Ou seulement si l'on a à sa disposition tout un tas d'outils et de
bibliothèques qui les encapsulent ?
Y'a pas besoin de lib particulière pour instancier un objet com et
Et je parle pas de l'enfer du déploiement..
Mmmmh ?
S'assurer que les bibliothèques et les fonctions du système que l'on
requiert, fonctionnent sous 95,98, NT et XP, ce n'est pas non plus très
évident.
Coucou !
Laurent BERNE écrivait:Par contre.. comment dire.. au niveau avancement.. si tu lis bien les
projets d'avancement de Gnome.. tu verras comment ils envient les
technologies microsoft et cherche à les reproduire..
Euh, qui a copié qui et quoi ? Vous êtes sûr de pouvoir répondre à cette
question ?
http://mail.gnome.org/archives/foundation-list/2004-April/msg00008.html
[...]
Et je te parlerais même du pourquoi c'est si simple de faire des softs sous
Win alors que c'est un vrai cauchemard sous linux.. des notions comme les
technos ODBC par exemple.. ou COM ou maintenant les ADO Provider (merci
Mono de les implémenter..) ..
Implémenter tous ces trucs avec l'API WIN32 est aisé, vous êtes sûr ?
Ou seulement si l'on a à sa disposition tout un tas d'outils et de
bibliothèques qui les encapsulent ?
Y'a pas besoin de lib particulière pour instancier un objet com et
Et je parle pas de l'enfer du déploiement..
Mmmmh ?
S'assurer que les bibliothèques et les fonctions du système que l'on
requiert, fonctionnent sous 95,98, NT et XP, ce n'est pas non plus très
évident.
Le 23/08/2004, mykey a supposé :Laurent BERNE a saisi sur ce dernier post:
En s'en fout, c'est une insulte sans importance, je vous ai juste rendu la
monnaie de votre pièce. Car je vous ai trouvé très irespectueux...
Tiens donc... Si j'ai décidé de vous répondre, c'est parce que
l'ensemble de vos posts sont irrespectueux, notamment la remarque qui
met en cause un travailleur indépendant... Là ça a été la goutte d'eau.
Le T9, c'est le système de saisie rapide des SMS sur les téléphones
portables...
A tous ceux qui osent emettre une critique qui vous déplait,
systématiquement..
Effectivement.. la seule chose que je sais de vous vient du lien vers
votre site dans la signature..
Et google ne mentionne qu'une page à
DLFP qui renvoie vers le premier site cité
Le 23/08/2004, mykey a supposé :
Laurent BERNE a saisi sur ce dernier post:
En s'en fout, c'est une insulte sans importance, je vous ai juste rendu la
monnaie de votre pièce. Car je vous ai trouvé très irespectueux...
Tiens donc... Si j'ai décidé de vous répondre, c'est parce que
l'ensemble de vos posts sont irrespectueux, notamment la remarque qui
met en cause un travailleur indépendant... Là ça a été la goutte d'eau.
Le T9, c'est le système de saisie rapide des SMS sur les téléphones
portables...
A tous ceux qui osent emettre une critique qui vous déplait,
systématiquement..
Effectivement.. la seule chose que je sais de vous vient du lien vers
votre site dans la signature..
Et google ne mentionne qu'une page à
DLFP qui renvoie vers le premier site cité
Le 23/08/2004, mykey a supposé :Laurent BERNE a saisi sur ce dernier post:
En s'en fout, c'est une insulte sans importance, je vous ai juste rendu la
monnaie de votre pièce. Car je vous ai trouvé très irespectueux...
Tiens donc... Si j'ai décidé de vous répondre, c'est parce que
l'ensemble de vos posts sont irrespectueux, notamment la remarque qui
met en cause un travailleur indépendant... Là ça a été la goutte d'eau.
Le T9, c'est le système de saisie rapide des SMS sur les téléphones
portables...
A tous ceux qui osent emettre une critique qui vous déplait,
systématiquement..
Effectivement.. la seule chose que je sais de vous vient du lien vers
votre site dans la signature..
Et google ne mentionne qu'une page à
DLFP qui renvoie vers le premier site cité
Le 23/08/2004, mykey a supposé :Laurent BERNE a saisi sur ce dernier post:
En s'en fout, c'est une insulte sans importance, je vous ai juste rendu la
monnaie de votre pièce. Car je vous ai trouvé très irespectueux...
Tiens donc... Si j'ai décidé de vous répondre, c'est parce que
l'ensemble de vos posts sont irrespectueux, notamment la remarque qui
met en cause un travailleur indépendant... Là ça a été la goutte d'eau.
Le T9, c'est le système de saisie rapide des SMS sur les téléphones
portables...
A tous ceux qui osent emettre une critique qui vous déplait,
systématiquement..
Effectivement.. la seule chose que je sais de vous vient du lien vers
votre site dans la signature..
Et google ne mentionne qu'une page à
DLFP qui renvoie vers le premier site cité
Le 23/08/2004, mykey a supposé :
Laurent BERNE a saisi sur ce dernier post:
En s'en fout, c'est une insulte sans importance, je vous ai juste rendu la
monnaie de votre pièce. Car je vous ai trouvé très irespectueux...
Tiens donc... Si j'ai décidé de vous répondre, c'est parce que
l'ensemble de vos posts sont irrespectueux, notamment la remarque qui
met en cause un travailleur indépendant... Là ça a été la goutte d'eau.
Le T9, c'est le système de saisie rapide des SMS sur les téléphones
portables...
A tous ceux qui osent emettre une critique qui vous déplait,
systématiquement..
Effectivement.. la seule chose que je sais de vous vient du lien vers
votre site dans la signature..
Et google ne mentionne qu'une page à
DLFP qui renvoie vers le premier site cité
Le 23/08/2004, mykey a supposé :Laurent BERNE a saisi sur ce dernier post:
En s'en fout, c'est une insulte sans importance, je vous ai juste rendu la
monnaie de votre pièce. Car je vous ai trouvé très irespectueux...
Tiens donc... Si j'ai décidé de vous répondre, c'est parce que
l'ensemble de vos posts sont irrespectueux, notamment la remarque qui
met en cause un travailleur indépendant... Là ça a été la goutte d'eau.
Le T9, c'est le système de saisie rapide des SMS sur les téléphones
portables...
A tous ceux qui osent emettre une critique qui vous déplait,
systématiquement..
Effectivement.. la seule chose que je sais de vous vient du lien vers
votre site dans la signature..
Et google ne mentionne qu'une page à
DLFP qui renvoie vers le premier site cité
Au fait.. c'est quoi un informaticien ?
Une sale engeance, doublée d'une terrible calamité.
Au fait.. c'est quoi un informaticien ?
Une sale engeance, doublée d'une terrible calamité.
Au fait.. c'est quoi un informaticien ?
Une sale engeance, doublée d'une terrible calamité.
Au début DOS (comme CP/M) n'avait pas la notion de répertoire, donc
la question de la notation des chemins d'accès ne se posait pas.
Le slash a été utilisé pour annoncer les options par quelques programmes
sous CP/M (mais pas les commandes CP/M elles-mêmes). Ca a été repris
dans quelques programmes sous DOS, dont les compilateurs FORTRAN et cie.
Le / n'étant plus disponible, les chemins d'accès ont été notés par des .
Même problème pour la séparation des éléments de PATH, qui se fait par des
points-virgules, les deux-points étant déjà mobilisé pour séparer le nom
d'unité.
Au début DOS (comme CP/M) n'avait pas la notion de répertoire, donc
la question de la notation des chemins d'accès ne se posait pas.
Le slash a été utilisé pour annoncer les options par quelques programmes
sous CP/M (mais pas les commandes CP/M elles-mêmes). Ca a été repris
dans quelques programmes sous DOS, dont les compilateurs FORTRAN et cie.
Le / n'étant plus disponible, les chemins d'accès ont été notés par des .
Même problème pour la séparation des éléments de PATH, qui se fait par des
points-virgules, les deux-points étant déjà mobilisé pour séparer le nom
d'unité.
Au début DOS (comme CP/M) n'avait pas la notion de répertoire, donc
la question de la notation des chemins d'accès ne se posait pas.
Le slash a été utilisé pour annoncer les options par quelques programmes
sous CP/M (mais pas les commandes CP/M elles-mêmes). Ca a été repris
dans quelques programmes sous DOS, dont les compilateurs FORTRAN et cie.
Le / n'étant plus disponible, les chemins d'accès ont été notés par des .
Même problème pour la séparation des éléments de PATH, qui se fait par des
points-virgules, les deux-points étant déjà mobilisé pour séparer le nom
d'unité.
Au début DOS (comme CP/M) n'avait pas la notion de répertoire, donc
la question de la notation des chemins d'accès ne se posait pas.
Le slash a été utilisé pour annoncer les options par quelques programmes
sous CP/M (mais pas les commandes CP/M elles-mêmes). Ca a été repris
dans quelques programmes sous DOS, dont les compilateurs FORTRAN et cie.
Le / n'étant plus disponible, les chemins d'accès ont été notés par des .
Même problème pour la séparation des éléments de PATH, qui se fait par des
points-virgules, les deux-points étant déjà mobilisé pour séparer le nom
d'unité.
A ce sujet, il convient de rapeller que DOS 2.x (mais pas les versions
ultérieures) permettait de définir le caractère préféré pour introduire
les options, i.e. / (à la DOS) ou - (à la Unix) par la commande (et
l'appel système) SWITCHAR.
En définissant SWITCHAR à -, le / devenait utilisable indifféremment de
comme séparateur de répertoires.
M'enfin, c'est plus tout jeune, tout ça...
Au début DOS (comme CP/M) n'avait pas la notion de répertoire, donc
la question de la notation des chemins d'accès ne se posait pas.
Le slash a été utilisé pour annoncer les options par quelques programmes
sous CP/M (mais pas les commandes CP/M elles-mêmes). Ca a été repris
dans quelques programmes sous DOS, dont les compilateurs FORTRAN et cie.
Le / n'étant plus disponible, les chemins d'accès ont été notés par des .
Même problème pour la séparation des éléments de PATH, qui se fait par des
points-virgules, les deux-points étant déjà mobilisé pour séparer le nom
d'unité.
A ce sujet, il convient de rapeller que DOS 2.x (mais pas les versions
ultérieures) permettait de définir le caractère préféré pour introduire
les options, i.e. / (à la DOS) ou - (à la Unix) par la commande (et
l'appel système) SWITCHAR.
En définissant SWITCHAR à -, le / devenait utilisable indifféremment de
comme séparateur de répertoires.
M'enfin, c'est plus tout jeune, tout ça...
Au début DOS (comme CP/M) n'avait pas la notion de répertoire, donc
la question de la notation des chemins d'accès ne se posait pas.
Le slash a été utilisé pour annoncer les options par quelques programmes
sous CP/M (mais pas les commandes CP/M elles-mêmes). Ca a été repris
dans quelques programmes sous DOS, dont les compilateurs FORTRAN et cie.
Le / n'étant plus disponible, les chemins d'accès ont été notés par des .
Même problème pour la séparation des éléments de PATH, qui se fait par des
points-virgules, les deux-points étant déjà mobilisé pour séparer le nom
d'unité.
A ce sujet, il convient de rapeller que DOS 2.x (mais pas les versions
ultérieures) permettait de définir le caractère préféré pour introduire
les options, i.e. / (à la DOS) ou - (à la Unix) par la commande (et
l'appel système) SWITCHAR.
En définissant SWITCHAR à -, le / devenait utilisable indifféremment de
comme séparateur de répertoires.
M'enfin, c'est plus tout jeune, tout ça...
On Sun, 22 Aug 2004 11:56:01 +0200, Thierry wrote:La sécurité sous Linux est ausssi fragile que sous Windows,
franchement faut arrêter les mythos qui disent le contraire.
20 secondes de durée de vie sous Windows XP il parait ...
En comptant le temps de connexion sur un modem RTC, alors? Parce que
sous ADSL, cela peut aller beaucoup plus vite : au moins une attaque
toutes les 2 à 3 secondes...
On Sun, 22 Aug 2004 11:56:01 +0200, Thierry wrote:
La sécurité sous Linux est ausssi fragile que sous Windows,
franchement faut arrêter les mythos qui disent le contraire.
20 secondes de durée de vie sous Windows XP il parait ...
En comptant le temps de connexion sur un modem RTC, alors? Parce que
sous ADSL, cela peut aller beaucoup plus vite : au moins une attaque
toutes les 2 à 3 secondes...
On Sun, 22 Aug 2004 11:56:01 +0200, Thierry wrote:La sécurité sous Linux est ausssi fragile que sous Windows,
franchement faut arrêter les mythos qui disent le contraire.
20 secondes de durée de vie sous Windows XP il parait ...
En comptant le temps de connexion sur un modem RTC, alors? Parce que
sous ADSL, cela peut aller beaucoup plus vite : au moins une attaque
toutes les 2 à 3 secondes...
