Quand le bureau KDE et toutes ses applications seront portés sur Windows
(on s'en rapproche pour ceux qui suivent, les applications deviennent de
plus en plus stables), celui-ci envahira Windows car, contrairement à
Linux qui possède des dizaines de bureaux, il sera l'unique alternative
au bureau Windows : KDE apporterait un souffle nouveau à Windows, en
tous cas plus que le bureau de Seven.
Du coup, l'utilisateur lambda (qui est l'utilisateur très largement
majoritaire) ne verra plus la différence entre un Windows et un linux
(ou un OpenSolaris ou un BSD) qui tournera derrière et au bout du
compte, il préférera naturellement se tourner vers l'OS qui lui coûte le
moins cher.
Je n'ai pas entendu causer de ça. Qu'est-ce que c'est ?
Tu as passé la dernière décennie au fond d'une grotte d'Afghanistan et tu viens d'être libéré ?
Il faut croire :) Mais juste depuis le 13/5/8. On peut reparler aussi du backdoor dans openBSD ? C'est plus sérieux. Bon c'est pas une bourde de développeur, mais du vandalisme délibéré mais quand meme :)
thx. En fait j'en avais entendu parler sans avoir capté que le problème n'était que dans debian. Je croyais que c'était dans openssl qu'il résidait.
-- http://mikeread.tripod.com/archive.htm
In article <slrnhk1b7q.b3p.hugolino@deborah.rock-n-roll.org>,
Hugolino <hugolino@free.fr> writes:
Je n'ai pas entendu causer de ça. Qu'est-ce que c'est ?
Tu as passé la dernière décennie au fond d'une grotte d'Afghanistan et
tu viens d'être libéré ?
Il faut croire :) Mais juste depuis le 13/5/8.
On peut reparler aussi du backdoor dans openBSD ?
C'est plus sérieux. Bon c'est pas une bourde de développeur, mais
du vandalisme délibéré mais quand meme :)
Je n'ai pas entendu causer de ça. Qu'est-ce que c'est ?
Tu as passé la dernière décennie au fond d'une grotte d'Afghanistan et tu viens d'être libéré ?
Il faut croire :) Mais juste depuis le 13/5/8. On peut reparler aussi du backdoor dans openBSD ? C'est plus sérieux. Bon c'est pas une bourde de développeur, mais du vandalisme délibéré mais quand meme :)
thx. En fait j'en avais entendu parler sans avoir capté que le problème n'était que dans debian. Je croyais que c'était dans openssl qu'il résidait.
-- http://mikeread.tripod.com/archive.htm
yl
In article <4b40b3ef$0$4970$, Stéphane CARPENTIER writes:
Il y a une différence entre développer un soft pour qu'il réponde à un besoin et le faire tourner dans un environnement. Les développeurs de debian ne se croient pas plus malins que les développeurs des softs originaux pour ce qui est de son fonctionnement normal. Par contre, ils ont presque toujours raison pour son intégration dans l'environnement debian.
Je suis d'accord.
Ce n'est pas insultant pour les développeurs originaux, c'est reconnaître qu'ils ne font pas le même métier.
Je suis d'accord aussi. Je rajouterai qu'il ne faut pas les opposer non plus.
-- http://mikeread.tripod.com/archive.htm
In article <4b40b3ef$0$4970$426a34cc@news.free.fr>,
Stéphane CARPENTIER <stef.carpentier@gratuit.fr.invalid> writes:
Il y a une différence entre développer un soft pour qu'il réponde à un
besoin et le faire tourner dans un environnement. Les développeurs de
debian ne se croient pas plus malins que les développeurs des softs
originaux pour ce qui est de son fonctionnement normal. Par contre, ils
ont presque toujours raison pour son intégration dans l'environnement
debian.
Je suis d'accord.
Ce n'est pas insultant pour les développeurs originaux, c'est
reconnaître qu'ils ne font pas le même métier.
Je suis d'accord aussi. Je rajouterai qu'il ne faut pas
les opposer non plus.
In article <4b40b3ef$0$4970$, Stéphane CARPENTIER writes:
Il y a une différence entre développer un soft pour qu'il réponde à un besoin et le faire tourner dans un environnement. Les développeurs de debian ne se croient pas plus malins que les développeurs des softs originaux pour ce qui est de son fonctionnement normal. Par contre, ils ont presque toujours raison pour son intégration dans l'environnement debian.
Je suis d'accord.
Ce n'est pas insultant pour les développeurs originaux, c'est reconnaître qu'ils ne font pas le même métier.
Je suis d'accord aussi. Je rajouterai qu'il ne faut pas les opposer non plus.
-- http://mikeread.tripod.com/archive.htm
yl
In article <hhq0np$asm$, (Michel Talon) writes:
Cette assertion est parfaitement ridicule, du même tonneau que celle qui consiste à dire qu'un prof de math de lycée est plus compétent qu'un grand mathématicien pour exposer au mieux un sujet.
Ah oui c'est faux. Et du meme tonneau, un journaliste spécialiste de l'art de la table est mieux placé qu'un grand cuisinier pour écrire un article de critique culinaire est aussi une assertion ridicule.
Je comprend.
-- http://mikeread.tripod.com/archive.htm
In article <hhq0np$asm$1@asmodee.lpthe.jussieu.fr>,
talon@lpthe.jussieu.fr (Michel Talon) writes:
Cette assertion est parfaitement ridicule, du même tonneau que celle
qui consiste à dire qu'un prof de math de lycée est plus compétent
qu'un grand mathématicien pour exposer au mieux un sujet.
Ah oui c'est faux. Et du meme tonneau, un journaliste spécialiste de
l'art de la table est mieux placé qu'un grand cuisinier pour écrire un
article de critique culinaire est aussi une assertion ridicule.
Cette assertion est parfaitement ridicule, du même tonneau que celle qui consiste à dire qu'un prof de math de lycée est plus compétent qu'un grand mathématicien pour exposer au mieux un sujet.
Ah oui c'est faux. Et du meme tonneau, un journaliste spécialiste de l'art de la table est mieux placé qu'un grand cuisinier pour écrire un article de critique culinaire est aussi une assertion ridicule.
Je comprend.
-- http://mikeread.tripod.com/archive.htm
yl
In article <4b40a0d9$0$22184$, Stéphane CARPENTIER writes:
Je vois pas en quoi la signature d'un mainteneur de package protègerait plus que celle d'un développeur de logiciel de ce genre de mésaventure. Explique.
Le développeur de logiciel, c'est un illustre inconnu. Si c'était un employé de la boîte, il l'aurait packagé comme c'est décrit dans la procédure interne. C'est pour ça que je suppose qu'il parle d'un soft trouvé sur internet et pas d'un développement spécifique. Il me semble préférable de faire confiance à la signature du mainteneur de package qu'à celle d'un inconnu.
Oui mais non ce n'est pas le cadre que j'avais compris. Ce dont avait parlé Patrick dans un autre fil c'était l'installation d'Eclipse. Déjà je ne sais pas si on peut écrire un rootkit en java qui ne laisse pas de grosses traces de boues derrière lui et devrait donc etre tout de meme assez facile a dégager, bon c'est sur qu'il vaut mieux éviter ce risque là aussi... en plus la machine virtuelle java constitue un rootkjail duquel il est tout de meme très difficile de s'évader mais c'est un détail. Le développeur d'eclipse a pignon sur rue, eclipse.org possède des certificats solides et confirmés, tu vas cherché le tarball chez eux, tu vérifie s'il a bien la bonne signature, tout est OK.
Mais ce qui me gêne, c'est de faire un ./configure && make && make install sur un serveur de prod, sans avoir peur du script kiddy.
Je suis d'accord. Je comprend mieux le souçal et j'apprends.
Le faire sur un serveur de test, bien le tester, bien le packager, déployer le package sur un serveur de préprod, bien le tester et enfin déployer le package sur le serveur de prod me parait plus sérieux.
Oui. La machine la plus vulnérable est tout de meme celle du développeur en cas de secret industriel ;-)
Je ne sais pas exactement comment travaillent les admins systèmes de ma boîte, mais faudrait pas qu'un développeur fasse un déploiement à la sauvage sur un serveur de prod.
Il y a un bug dans cette phrase. à chacun son métier, non ? Ce n'est pas aux développeurs de faire du déploiement que ce soit proprement ou salement, si ?
-- http://mikeread.tripod.com/archive.htm
In article <4b40a0d9$0$22184$426a74cc@news.free.fr>,
Stéphane CARPENTIER <stef.carpentier@gratuit.fr.invalid> writes:
Je vois pas en quoi la signature d'un mainteneur de package protègerait
plus que celle d'un développeur de logiciel de ce genre de mésaventure.
Explique.
Le développeur de logiciel, c'est un illustre inconnu. Si c'était un
employé de la boîte, il l'aurait packagé comme c'est décrit dans la
procédure interne. C'est pour ça que je suppose qu'il parle d'un soft
trouvé sur internet et pas d'un développement spécifique. Il me semble
préférable de faire confiance à la signature du mainteneur de package
qu'à celle d'un inconnu.
Oui mais non ce n'est pas le cadre que j'avais compris. Ce dont avait
parlé Patrick dans un autre fil c'était l'installation d'Eclipse. Déjà
je ne sais pas si on peut écrire un rootkit en java qui ne laisse pas
de grosses traces de boues derrière lui et devrait donc etre tout
de meme assez facile a dégager, bon c'est sur qu'il vaut mieux éviter ce
risque là aussi... en plus la machine virtuelle java constitue un rootkjail
duquel il est tout de meme très difficile de s'évader mais c'est un
détail. Le développeur d'eclipse a pignon sur rue, eclipse.org possède
des certificats solides et confirmés, tu vas cherché le tarball chez
eux, tu vérifie s'il a bien la bonne signature, tout est OK.
Mais ce qui me gêne, c'est de faire un ./configure && make && make
install sur un serveur de prod, sans avoir peur du script kiddy.
Je suis d'accord. Je comprend mieux le souçal et j'apprends.
Le faire sur un serveur de test, bien le tester, bien le packager,
déployer le package sur un serveur de préprod, bien le tester et enfin
déployer le package sur le serveur de prod me parait plus sérieux.
Oui. La machine la plus vulnérable est tout de meme celle du
développeur en cas de secret industriel ;-)
Je ne sais pas exactement comment travaillent les admins systèmes de ma
boîte, mais faudrait pas qu'un développeur fasse un déploiement à la
sauvage sur un serveur de prod.
Il y a un bug dans cette phrase. à chacun son métier, non ? Ce n'est pas
aux développeurs de faire du déploiement que ce soit proprement ou salement,
si ?
In article <4b40a0d9$0$22184$, Stéphane CARPENTIER writes:
Je vois pas en quoi la signature d'un mainteneur de package protègerait plus que celle d'un développeur de logiciel de ce genre de mésaventure. Explique.
Le développeur de logiciel, c'est un illustre inconnu. Si c'était un employé de la boîte, il l'aurait packagé comme c'est décrit dans la procédure interne. C'est pour ça que je suppose qu'il parle d'un soft trouvé sur internet et pas d'un développement spécifique. Il me semble préférable de faire confiance à la signature du mainteneur de package qu'à celle d'un inconnu.
Oui mais non ce n'est pas le cadre que j'avais compris. Ce dont avait parlé Patrick dans un autre fil c'était l'installation d'Eclipse. Déjà je ne sais pas si on peut écrire un rootkit en java qui ne laisse pas de grosses traces de boues derrière lui et devrait donc etre tout de meme assez facile a dégager, bon c'est sur qu'il vaut mieux éviter ce risque là aussi... en plus la machine virtuelle java constitue un rootkjail duquel il est tout de meme très difficile de s'évader mais c'est un détail. Le développeur d'eclipse a pignon sur rue, eclipse.org possède des certificats solides et confirmés, tu vas cherché le tarball chez eux, tu vérifie s'il a bien la bonne signature, tout est OK.
Mais ce qui me gêne, c'est de faire un ./configure && make && make install sur un serveur de prod, sans avoir peur du script kiddy.
Je suis d'accord. Je comprend mieux le souçal et j'apprends.
Le faire sur un serveur de test, bien le tester, bien le packager, déployer le package sur un serveur de préprod, bien le tester et enfin déployer le package sur le serveur de prod me parait plus sérieux.
Oui. La machine la plus vulnérable est tout de meme celle du développeur en cas de secret industriel ;-)
Je ne sais pas exactement comment travaillent les admins systèmes de ma boîte, mais faudrait pas qu'un développeur fasse un déploiement à la sauvage sur un serveur de prod.
Il y a un bug dans cette phrase. à chacun son métier, non ? Ce n'est pas aux développeurs de faire du déploiement que ce soit proprement ou salement, si ?
-- http://mikeread.tripod.com/archive.htm
yl
In article , Stephane TOUGARD writes:
Nicolas George a perdu son temps a nous dire:
Voyons voir, peut etre parce que le D70 n'est plus au catalogue de Nikon.
Quel rapport ?
Que tu ne peux rien utiliser de plus recent avec les versions de dcraw ou d'ufraw de la Debian.
www.dcraw.org
Arrete. le point de vue de David Coffin est que les APN récents produisent du JPEG et que son programme n'a d'usage que pour les APN anciens. Il ne fait pas de changelog et pour cause aussi on peut se fier qu'à sa page de garde et j'ai bien changements de versions depuis 2008 sont cosmétiques. Le plaisir d'avoir une versio finale (en virant au passage quelques formats prprio, résultat le code utilisé par debian marche avec plus d'APN que le dernier. As tu eu la curiosoité de faire un diff ?
www.ufraw.org
Je vais pas me pencher là dessus. Quel APN récent ennvoie du RAW encore et pourquoi un des deux ripper ne suffirait pas ?
-- http://mikeread.tripod.com/archive.htm
In article <2d1617-h7j2.ln1@gulliver.unices.org>,
Stephane TOUGARD <jkb@unices.org> writes:
Nicolas George a perdu son temps a nous dire:
Voyons voir, peut etre parce que le D70 n'est plus au catalogue de
Nikon.
Quel rapport ?
Que tu ne peux rien utiliser de plus recent avec les versions de dcraw
ou d'ufraw de la Debian.
www.dcraw.org
Arrete.
le point de vue de David Coffin est que les APN récents
produisent du JPEG et que son programme n'a d'usage que pour les APN
anciens. Il ne fait pas de changelog et pour cause aussi on peut se fier
qu'à sa page de garde et j'ai bien changements de versions depuis 2008
sont cosmétiques. Le plaisir d'avoir une versio finale (en virant au
passage quelques formats prprio, résultat le code utilisé par debian
marche avec plus d'APN que le dernier. As tu eu la curiosoité de faire
un diff ?
www.ufraw.org
Je vais pas me pencher là dessus. Quel APN récent ennvoie du RAW encore
et pourquoi un des deux ripper ne suffirait pas ?
Voyons voir, peut etre parce que le D70 n'est plus au catalogue de Nikon.
Quel rapport ?
Que tu ne peux rien utiliser de plus recent avec les versions de dcraw ou d'ufraw de la Debian.
www.dcraw.org
Arrete. le point de vue de David Coffin est que les APN récents produisent du JPEG et que son programme n'a d'usage que pour les APN anciens. Il ne fait pas de changelog et pour cause aussi on peut se fier qu'à sa page de garde et j'ai bien changements de versions depuis 2008 sont cosmétiques. Le plaisir d'avoir une versio finale (en virant au passage quelques formats prprio, résultat le code utilisé par debian marche avec plus d'APN que le dernier. As tu eu la curiosoité de faire un diff ?
www.ufraw.org
Je vais pas me pencher là dessus. Quel APN récent ennvoie du RAW encore et pourquoi un des deux ripper ne suffirait pas ?
-- http://mikeread.tripod.com/archive.htm
Doug713705
Dans fr.comp.os.linux.debats Yves Lambert nous expliquait:
Ce n'est pas le cas, donc elle n'a aucun but particulier que n'a n'importe quel autre distribution (je ne suis pas sur qu'il y ai pas plus de distrib basees sur la SLS que sur la Debian).
*toutes* les distributions sont basée sur la slack. Par définition.
??
Ce qui fait une distribution GNU/Linux c'est pour beaucoup son gestionnaire de paquets, ses outils spécifiques et éventuellement ses patches.
Il ne me semble pas que Debian ou RedHat proposent quoique ce soit qui soit en rapport de près ou de loin avec ce que Slackware propose et qui se veut très minimaliste (pas de gestion de dépendances, patchage au minimum syndical, respect maximum de l'emplacement des fichiers propres aux applications, etc).
Maintenant si c'est pour dire que Slackware est une distribution proche de l'esprit des développeurs des applications qu'elle propose, alors oui c'est vrai mais c'est loin d'être le cas de Debian ou RedHat qui adaptent bien souvent les applications qu'elles proposent à leur "philosophie".
C'est bien la raison pour laquelle, indépendamment de leur qualité, je n'aime finalement ni RedHat ni Debian.
-- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) [ Plus ou moins avec une chance de peut-être ]
Dans fr.comp.os.linux.debats Yves Lambert nous expliquait:
Ce n'est pas le cas, donc elle n'a aucun but particulier que n'a
n'importe quel autre distribution (je ne suis pas sur qu'il y ai pas
plus de distrib basees sur la SLS que sur la Debian).
*toutes* les distributions sont basée sur la slack. Par définition.
??
Ce qui fait une distribution GNU/Linux c'est pour beaucoup son
gestionnaire de paquets, ses outils spécifiques et éventuellement ses
patches.
Il ne me semble pas que Debian ou RedHat proposent quoique ce soit qui
soit en rapport de près ou de loin avec ce que Slackware propose et qui
se veut très minimaliste (pas de gestion de dépendances, patchage au
minimum syndical, respect maximum de l'emplacement des fichiers
propres aux applications, etc).
Maintenant si c'est pour dire que Slackware est une distribution proche
de l'esprit des développeurs des applications qu'elle propose, alors oui
c'est vrai mais c'est loin d'être le cas de Debian ou RedHat qui
adaptent bien souvent les applications qu'elles proposent à leur
"philosophie".
C'est bien la raison pour laquelle, indépendamment de leur qualité, je
n'aime finalement ni RedHat ni Debian.
--
@+
Doug - Linux user #307925 - Slackware64 roulaize ;-)
[ Plus ou moins avec une chance de peut-être ]
Dans fr.comp.os.linux.debats Yves Lambert nous expliquait:
Ce n'est pas le cas, donc elle n'a aucun but particulier que n'a n'importe quel autre distribution (je ne suis pas sur qu'il y ai pas plus de distrib basees sur la SLS que sur la Debian).
*toutes* les distributions sont basée sur la slack. Par définition.
??
Ce qui fait une distribution GNU/Linux c'est pour beaucoup son gestionnaire de paquets, ses outils spécifiques et éventuellement ses patches.
Il ne me semble pas que Debian ou RedHat proposent quoique ce soit qui soit en rapport de près ou de loin avec ce que Slackware propose et qui se veut très minimaliste (pas de gestion de dépendances, patchage au minimum syndical, respect maximum de l'emplacement des fichiers propres aux applications, etc).
Maintenant si c'est pour dire que Slackware est une distribution proche de l'esprit des développeurs des applications qu'elle propose, alors oui c'est vrai mais c'est loin d'être le cas de Debian ou RedHat qui adaptent bien souvent les applications qu'elles proposent à leur "philosophie".
C'est bien la raison pour laquelle, indépendamment de leur qualité, je n'aime finalement ni RedHat ni Debian.
-- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) [ Plus ou moins avec une chance de peut-être ]
yl
In article , Stephane TOUGARD writes:
Bref, tu dis quelque chose qui n'a strictement rien à voir pour essayer de cacher le fait que tu as dit une connerie deux messages plus tôt.
Comme d'habitude.
Non, ce post n'est tout simplement pas de moi.
C'est qui, Janville.org ?
Tu ne veux pas etre irréprochable de ce coté là, histoire de clarifier ?
-- http://mikeread.tripod.com/archive.htm
In article <th1617-h7j2.ln1@gulliver.unices.org>,
Stephane TOUGARD <jkb@unices.org> writes:
Bref, tu dis quelque chose qui n'a strictement rien à voir pour essayer de
cacher le fait que tu as dit une connerie deux messages plus tôt.
Comme d'habitude.
Non, ce post n'est tout simplement pas de moi.
C'est qui, Janville.org ?
<jkb@unices.org>
Tu ne veux pas etre irréprochable de ce coté là, histoire de clarifier ?
Bref, tu dis quelque chose qui n'a strictement rien à voir pour essayer de cacher le fait que tu as dit une connerie deux messages plus tôt.
Comme d'habitude.
Non, ce post n'est tout simplement pas de moi.
C'est qui, Janville.org ?
Tu ne veux pas etre irréprochable de ce coté là, histoire de clarifier ?
-- http://mikeread.tripod.com/archive.htm
pipantal
JKB a écrit :
Linux, c'est un nivellement par le bas, c'est le PPCM de l'informatique. C'est mieux que l'OS majoritaire sur un PC, ça peut être moins bien sur d'autres architectures. En particulier, c'est largement moins bien qu'OpenVMS sur des IA64 parce que Linux ne sait pas gérer correctement le matériel (changement de processeur à chaud...). Sur les sparc64, on choisira Linux ou Solaris, ou *BSD en fonction de ce qu'on veut faire parce que les possibilités des différents OS ne sont pas les mêmes. Pour du raid51 soft avec iSCSI et des fonctions de serveur de boot sur une machine frontale sur internet (donc avec firewall), on prendra du Linux. Pour un serveur de calcul sparc qui est caché derrière cette machine, on prendra plutôt du Solaris (on ne sera pas contraint à patcher la passoire en interrompant le service régulirèment).
Je suis toujours émerveillé par le nombre d'architecture alternative à l'i386.
Cependant, quel est l'intérêt de ces architectures aujourd'hui avec la puissance des archi i386 !!
C'est peut-être pas très "propre" mais c'est efficace.
Des processeurs de dernière génération qui consomme peu d'energie, chauffe peu, etc.
Je ne lance ni troll, je ne suis pas connaisseur, mais j'aimerai bien avoir un point de vu là dessus.
Le PC c'est pas bien ! mais en terme de performance y a-t-il mieux !
JKB a écrit :
Linux, c'est un nivellement par le bas, c'est le PPCM de
l'informatique. C'est mieux que l'OS majoritaire sur un PC, ça peut
être moins bien sur d'autres architectures. En particulier, c'est
largement moins bien qu'OpenVMS sur des IA64 parce que Linux ne sait
pas gérer correctement le matériel (changement de processeur à
chaud...). Sur les sparc64, on choisira Linux ou Solaris, ou *BSD en
fonction de ce qu'on veut faire parce que les possibilités des
différents OS ne sont pas les mêmes. Pour du raid51 soft avec iSCSI
et des fonctions de serveur de boot sur une machine frontale sur
internet (donc avec firewall), on prendra du Linux. Pour un serveur
de calcul sparc qui est caché derrière cette machine, on prendra
plutôt du Solaris (on ne sera pas contraint à patcher la passoire en
interrompant le service régulirèment).
Je suis toujours émerveillé par le nombre d'architecture alternative à
l'i386.
Cependant, quel est l'intérêt de ces architectures aujourd'hui avec la
puissance des archi i386 !!
C'est peut-être pas très "propre" mais c'est efficace.
Des processeurs de dernière génération qui consomme peu d'energie,
chauffe peu, etc.
Je ne lance ni troll, je ne suis pas connaisseur, mais j'aimerai bien
avoir un point de vu là dessus.
Le PC c'est pas bien ! mais en terme de performance y a-t-il mieux !
Linux, c'est un nivellement par le bas, c'est le PPCM de l'informatique. C'est mieux que l'OS majoritaire sur un PC, ça peut être moins bien sur d'autres architectures. En particulier, c'est largement moins bien qu'OpenVMS sur des IA64 parce que Linux ne sait pas gérer correctement le matériel (changement de processeur à chaud...). Sur les sparc64, on choisira Linux ou Solaris, ou *BSD en fonction de ce qu'on veut faire parce que les possibilités des différents OS ne sont pas les mêmes. Pour du raid51 soft avec iSCSI et des fonctions de serveur de boot sur une machine frontale sur internet (donc avec firewall), on prendra du Linux. Pour un serveur de calcul sparc qui est caché derrière cette machine, on prendra plutôt du Solaris (on ne sera pas contraint à patcher la passoire en interrompant le service régulirèment).
Je suis toujours émerveillé par le nombre d'architecture alternative à l'i386.
Cependant, quel est l'intérêt de ces architectures aujourd'hui avec la puissance des archi i386 !!
C'est peut-être pas très "propre" mais c'est efficace.
Des processeurs de dernière génération qui consomme peu d'energie, chauffe peu, etc.
Je ne lance ni troll, je ne suis pas connaisseur, mais j'aimerai bien avoir un point de vu là dessus.
Le PC c'est pas bien ! mais en terme de performance y a-t-il mieux !
Emmanuel Florac
Le Sun, 03 Jan 2010 16:16:58 +0000, Nicolas George a écrit:
Ou stable. Il n'y a pas besoin d'autre chose pour faire tourner GMail ou OpenOffice sur une machine vieille de deux ans.
L'ennui c'est qu'on a un OOo dépassé et un firefox itou, non? Les dernières versions sont quand même nettement mieux...
-- The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time. Tom Cargill
Le Sun, 03 Jan 2010 16:16:58 +0000, Nicolas George a écrit:
Ou stable. Il n'y a pas besoin d'autre chose pour faire tourner GMail ou
OpenOffice sur une machine vieille de deux ans.
L'ennui c'est qu'on a un OOo dépassé et un firefox itou, non? Les
dernières versions sont quand même nettement mieux...
--
The first 90% of the code accounts for the first 90% of the development
time. The remaining 10% of the code accounts for the other 90% of the
development time.
Tom Cargill
Le Sun, 03 Jan 2010 16:16:58 +0000, Nicolas George a écrit:
Ou stable. Il n'y a pas besoin d'autre chose pour faire tourner GMail ou OpenOffice sur une machine vieille de deux ans.
L'ennui c'est qu'on a un OOo dépassé et un firefox itou, non? Les dernières versions sont quand même nettement mieux...
-- The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time. Tom Cargill
Stéphane CARPENTIER
Yves Lambert wrote:
In article <4b40b3ef$0$4970$, Stéphane CARPENTIER writes:
Ce n'est pas insultant pour les développeurs originaux, c'est reconnaître qu'ils ne font pas le même métier.
Je suis d'accord aussi. Je rajouterai qu'il ne faut pas les opposer non plus.
Ouais, ben c'est un forum de troll aussi. Ça fait parti du jeu de dire un truc vrai qui peut avoir des interprétations fausses.
Yves Lambert wrote:
In article <4b40b3ef$0$4970$426a34cc@news.free.fr>,
Stéphane CARPENTIER <stef.carpentier@gratuit.fr.invalid> writes:
Ce n'est pas insultant pour les développeurs originaux, c'est
reconnaître qu'ils ne font pas le même métier.
Je suis d'accord aussi. Je rajouterai qu'il ne faut pas
les opposer non plus.
Ouais, ben c'est un forum de troll aussi. Ça fait parti du jeu de dire
un truc vrai qui peut avoir des interprétations fausses.
