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.
Le Sun, 03 Jan 2010 19:23:51 +0100, pipantal a écrit:
Cependant, quel est l'intérêt de ces architectures aujourd'hui avec la puissance des archi i386 !!
Ben justement... l'archi i386 est une horreur, elle n'est un peu compétitive que grâce à la puissance de R&D d'Intel. Au niveau basse conso, c'est à peu près sans espoir (ARM a toujours une carte à jouer).
-- Don't worry about people stealing your ideas. If it's original, you'll have to ram it down their throats. Howard Aiken, creator of the IBM/Harvard Mark 1 Computer
Le Sun, 03 Jan 2010 19:23:51 +0100, pipantal a écrit:
Cependant, quel est l'intérêt de ces architectures aujourd'hui avec la
puissance des archi i386 !!
Ben justement... l'archi i386 est une horreur, elle n'est un peu
compétitive que grâce à la puissance de R&D d'Intel. Au niveau basse
conso, c'est à peu près sans espoir (ARM a toujours une carte à jouer).
--
Don't worry about people stealing your ideas. If it's original, you'll
have to ram it down their throats.
Howard Aiken, creator of the IBM/Harvard Mark 1 Computer
Le Sun, 03 Jan 2010 19:23:51 +0100, pipantal a écrit:
Cependant, quel est l'intérêt de ces architectures aujourd'hui avec la puissance des archi i386 !!
Ben justement... l'archi i386 est une horreur, elle n'est un peu compétitive que grâce à la puissance de R&D d'Intel. Au niveau basse conso, c'est à peu près sans espoir (ARM a toujours une carte à jouer).
-- Don't worry about people stealing your ideas. If it's original, you'll have to ram it down their throats. Howard Aiken, creator of the IBM/Harvard Mark 1 Computer
yl
In article , Stephane TOUGARD writes:
Yves Lambert a perdu son temps a nous dire:
Si la nouvelle version du développeur corrige un/des bugs, c'est un bug du package. Son mainteneur est contactable à l'adresse debian AT invux DOT com. Si personne n'a signalé le bug ni directement au mainteneur ni via le dbts c'est un peu *gras* de considérerer ça comme un défaut de debian.
Ce n'est pas une question de bug. La nature meme du logiciel fait qu'il doit etre maintenue a la derniere version autant que faire se peut. C'est une question de support materiel.
C'est un bug je suis désolé. Tu confond bugs de programmes et bugs de pasage. Au passage j'avais mal lu la page de dcraw et j'ai dit une grosse connerie dans un autre message.
Si le mainteneur attend un bug pour upgrader, c'est qu'il n'a rien compris a son boulot de mainteneur (c'est bien ce que je lui reproche). En tous cas pour CE logiciel en particulier.
Peut-etre qu'il est en longues vacances, ou bien il a démissionné. Comment le savoir si personne ne soumet un bug ? Je ne vais pas le faire, je n'ai pas d'APN. ET vu que DC ne fait pas vraiment de changelog, c'est difficile de voir si la nouvelle version est plus fonctionnelle ou pas.
Tu es gené dans ton utilisation par un ou plusieurs des 42 bugs. Tu te prend par la main et tu signale le bug au maintenenur du package. Si personne ne le fait c'est sur que les packages ne vont pas bouger.
Merci pour le process, mais ca ne m'interesse pas. Je n'utilise pas la Debian et pour dcraw, j'ai un script qui fait ca tres bien tout seul :
Ben oui, c'est valable aussi si tu utilises debian ou macintosh. Bon il faut mettre des bibliothèques standards dans /opt/local/lib pour suivre pas à pas ta marche à suivre ;)
à coté de ça il suffit d'hijacker le site de DC pour avoir un accès à ta machine :))
-- http://mikeread.tripod.com/archive.htm
In article <3rf617-3rp1.ln1@gulliver.unices.org>,
Stephane TOUGARD <jkb@unices.org> writes:
Yves Lambert a perdu son temps a nous dire:
Si la nouvelle version du développeur corrige un/des bugs,
c'est un bug du package. Son mainteneur est contactable à
l'adresse debian AT invux DOT com. Si personne n'a signalé
le bug ni directement au mainteneur ni via le dbts c'est un
peu *gras* de considérerer ça comme un défaut de debian.
Ce n'est pas une question de bug. La nature meme du logiciel fait qu'il
doit etre maintenue a la derniere version autant que faire se peut.
C'est une question de support materiel.
C'est un bug je suis désolé. Tu confond bugs de programmes et bugs de
pasage. Au passage j'avais mal lu la page de dcraw et j'ai dit une
grosse connerie dans un autre message.
Si le mainteneur attend un bug pour upgrader, c'est qu'il n'a rien
compris a son boulot de mainteneur (c'est bien ce que je lui reproche).
En tous cas pour CE logiciel en particulier.
Peut-etre qu'il est en longues vacances, ou bien il a démissionné.
Comment le savoir si personne ne soumet un bug ? Je ne vais pas le
faire, je n'ai pas d'APN. ET vu que DC ne fait pas vraiment de
changelog, c'est difficile de voir si la nouvelle version est plus
fonctionnelle ou pas.
Tu es gené dans ton utilisation par un ou plusieurs des 42 bugs. Tu te
prend par la main et tu signale le bug au maintenenur du package. Si
personne ne le fait c'est sur que les packages ne vont pas bouger.
Merci pour le process, mais ca ne m'interesse pas. Je n'utilise pas la
Debian et pour dcraw, j'ai un script qui fait ca tres bien tout seul :
Ben oui, c'est valable aussi si tu utilises debian ou macintosh. Bon il
faut mettre des bibliothèques standards dans /opt/local/lib pour suivre pas à
pas ta marche à suivre ;)
à coté de ça il suffit d'hijacker le site de DC pour avoir un accès à ta
machine :))
Si la nouvelle version du développeur corrige un/des bugs, c'est un bug du package. Son mainteneur est contactable à l'adresse debian AT invux DOT com. Si personne n'a signalé le bug ni directement au mainteneur ni via le dbts c'est un peu *gras* de considérerer ça comme un défaut de debian.
Ce n'est pas une question de bug. La nature meme du logiciel fait qu'il doit etre maintenue a la derniere version autant que faire se peut. C'est une question de support materiel.
C'est un bug je suis désolé. Tu confond bugs de programmes et bugs de pasage. Au passage j'avais mal lu la page de dcraw et j'ai dit une grosse connerie dans un autre message.
Si le mainteneur attend un bug pour upgrader, c'est qu'il n'a rien compris a son boulot de mainteneur (c'est bien ce que je lui reproche). En tous cas pour CE logiciel en particulier.
Peut-etre qu'il est en longues vacances, ou bien il a démissionné. Comment le savoir si personne ne soumet un bug ? Je ne vais pas le faire, je n'ai pas d'APN. ET vu que DC ne fait pas vraiment de changelog, c'est difficile de voir si la nouvelle version est plus fonctionnelle ou pas.
Tu es gené dans ton utilisation par un ou plusieurs des 42 bugs. Tu te prend par la main et tu signale le bug au maintenenur du package. Si personne ne le fait c'est sur que les packages ne vont pas bouger.
Merci pour le process, mais ca ne m'interesse pas. Je n'utilise pas la Debian et pour dcraw, j'ai un script qui fait ca tres bien tout seul :
Ben oui, c'est valable aussi si tu utilises debian ou macintosh. Bon il faut mettre des bibliothèques standards dans /opt/local/lib pour suivre pas à pas ta marche à suivre ;)
à coté de ça il suffit d'hijacker le site de DC pour avoir un accès à ta machine :))
-- http://mikeread.tripod.com/archive.htm
JKB
Le 03-01-2010, ? propos de Re: KDE tuera Windows, pipantal ?crivait dans fr.comp.os.linux.debats :
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 sûr qu'en consommation brute et en chauffage d'appoint, c'est pas mal du tout. Mes sparcs à 32 voies consomment 2A/230V en pleine charge. Le jour où je trouve un i386 capable de faire ça, je reviendrai sur ma position.
C'est peut-être pas très "propre" mais c'est efficace.
C'est ni propre, ni efficace.
Des processeurs de dernière génération qui consomme peu d'energie, chauffe peu, etc.
Non. Les procs x86 consomment peu lorsqu'ils ne fichent rien. Dès qu'on met les pieds dedans, ils se transforment en grille-pain (il y a des raisons qui proviennent du design de la puce et d'autres qui viennent directement de la conception du langage d'assemblage).
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 !
Ouaips. L'alpha est mort, mais l'UltraSPARC VII/FX est là. De même que le POWER6 et quelques autres.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 03-01-2010, ? propos de
Re: KDE tuera Windows,
pipantal ?crivait dans fr.comp.os.linux.debats :
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 sûr qu'en consommation brute et en chauffage d'appoint, c'est
pas mal du tout. Mes sparcs à 32 voies consomment 2A/230V en pleine
charge. Le jour où je trouve un i386 capable de faire ça, je
reviendrai sur ma position.
C'est peut-être pas très "propre" mais c'est efficace.
C'est ni propre, ni efficace.
Des processeurs de dernière génération qui consomme peu d'energie,
chauffe peu, etc.
Non. Les procs x86 consomment peu lorsqu'ils ne fichent rien. Dès
qu'on met les pieds dedans, ils se transforment en grille-pain (il y
a des raisons qui proviennent du design de la puce et d'autres qui
viennent directement de la conception du langage d'assemblage).
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 !
Ouaips. L'alpha est mort, mais l'UltraSPARC VII/FX est là. De même
que le POWER6 et quelques autres.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 03-01-2010, ? propos de Re: KDE tuera Windows, pipantal ?crivait dans fr.comp.os.linux.debats :
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 sûr qu'en consommation brute et en chauffage d'appoint, c'est pas mal du tout. Mes sparcs à 32 voies consomment 2A/230V en pleine charge. Le jour où je trouve un i386 capable de faire ça, je reviendrai sur ma position.
C'est peut-être pas très "propre" mais c'est efficace.
C'est ni propre, ni efficace.
Des processeurs de dernière génération qui consomme peu d'energie, chauffe peu, etc.
Non. Les procs x86 consomment peu lorsqu'ils ne fichent rien. Dès qu'on met les pieds dedans, ils se transforment en grille-pain (il y a des raisons qui proviennent du design de la puce et d'autres qui viennent directement de la conception du langage d'assemblage).
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 !
Ouaips. L'alpha est mort, mais l'UltraSPARC VII/FX est là. De même que le POWER6 et quelques autres.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
yl
In article <hhpvgp$eog$, Patrick Lamaizière writes:
Pas une erreur, rien...
Y'a des gens qui arrivent à utiliser Eclipse 3.4.2 sous FreeBSD ?
Je veux bien essayer sur NetBSD, mais il va falloir que je remette la vache en production pour ça. Il me semble qu'Eclipse s'exécute mal en dehors de la VM Sun ou IBM. Il faudrait peut-etre partir de là, non ?
Je ne suis pas sur fcob je suis trop newbie et puis tu parles de free et open pas de net, alors :)
-- http://mikeread.tripod.com/archive.htm
In article <hhpvgp$eog$1@news.davenulle.org>,
Patrick Lamaizière <adresse@est.invalid> writes:
Pas une erreur, rien...
Y'a des gens qui arrivent à utiliser Eclipse 3.4.2 sous FreeBSD ?
Je veux bien essayer sur NetBSD, mais il va falloir que je remette la
vache en production pour ça. Il me semble qu'Eclipse s'exécute mal en
dehors de la VM Sun ou IBM. Il faudrait peut-etre partir de là, non ?
Je ne suis pas sur fcob je suis trop newbie et puis tu parles de free et
open pas de net, alors :)
In article <hhpvgp$eog$, Patrick Lamaizière writes:
Pas une erreur, rien...
Y'a des gens qui arrivent à utiliser Eclipse 3.4.2 sous FreeBSD ?
Je veux bien essayer sur NetBSD, mais il va falloir que je remette la vache en production pour ça. Il me semble qu'Eclipse s'exécute mal en dehors de la VM Sun ou IBM. Il faudrait peut-etre partir de là, non ?
Je ne suis pas sur fcob je suis trop newbie et puis tu parles de free et open pas de net, alors :)
-- http://mikeread.tripod.com/archive.htm
Nicolas George
Emmanuel Florac , dans le message <4b40e1e3$0$28462$, a écrit :
L'ennui c'est qu'on a un OOo dépassé et un firefox itou, non?
Ils marchaient bien quand ils sont sortis. Ils ne marchent pas moins bien aujourd'hui.
Emmanuel Florac , dans le message
<4b40e1e3$0$28462$426a34cc@news.free.fr>, a écrit :
L'ennui c'est qu'on a un OOo dépassé et un firefox itou, non?
Ils marchaient bien quand ils sont sortis. Ils ne marchent pas moins bien
aujourd'hui.
Emmanuel Florac , dans le message <4b40e1e3$0$28462$, a écrit :
L'ennui c'est qu'on a un OOo dépassé et un firefox itou, non?
Ils marchaient bien quand ils sont sortis. Ils ne marchent pas moins bien aujourd'hui.
Stéphane CARPENTIER
Yves Lambert wrote:
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.
C'est pour ça que j'ai précisé ce que je comprenais et pourquoi je le comprenais comme ça. Pour rester dans le cadre général, il doit bien y avoir des cas où un ./configure && make && make install est sain sur un serveur de prod, mais ça me gêne dans le cadre général.
Ce dont avait parlé Patrick dans un autre fil c'était l'installation d'Eclipse.
Installer Eclipse sur un serveur de prod ? Pourquoi faire ?
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 ;-)
Il y a plusieurs risques, le secret industriel n'étant pas le plus important en cas d'installation de quelque chose. Pour moi, si la machine du développeur plante suite à une installation foireuse, il est le seul a être bloqué. Si c'est le serveur de prod qui plante à cause d'une installation foireuse, les risques peuvent être importants.
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 ?
Ça dépend quoi. Ce n'est pas aux développeurs d'installer un nouveau serveur de prod. Par contre, si tu veux faire une mise à jour d'une application java, c'est le développeur qui sera capable de créer un .ear ou un .jar pour le mette sur le serveur.
Ensuite, déployer un ear ou un jar sur un serveur est très simple. Que ce soit le développeur, l'administrateur ou une autre personne (si je te dis le chef de projet, tu vas bondir) qui le déploie n'est pas très important. Ce qui est important, c'est que la procédure soit bien cadrée (manuel de déploiement, tests préalable, circuit de validation et autres procédures de retour arrière).
Si en même temps que le déploiement, il y a des modifs en base de données à apporter, ça peut être plus simple que le développeur fasse tout.
Je suis d'accord que le plus logique est que l'administrateur fasse le déploiement, mais ce n'est pas si important que ça.
Yves Lambert wrote:
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.
C'est pour ça que j'ai précisé ce que je comprenais et pourquoi je le
comprenais comme ça. Pour rester dans le cadre général, il doit bien y
avoir des cas où un ./configure && make && make install est sain sur un
serveur de prod, mais ça me gêne dans le cadre général.
Ce dont avait
parlé Patrick dans un autre fil c'était l'installation d'Eclipse.
Installer Eclipse sur un serveur de prod ? Pourquoi faire ?
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 ;-)
Il y a plusieurs risques, le secret industriel n'étant pas le plus
important en cas d'installation de quelque chose. Pour moi, si la
machine du développeur plante suite à une installation foireuse, il est
le seul a être bloqué. Si c'est le serveur de prod qui plante à cause
d'une installation foireuse, les risques peuvent être importants.
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 ?
Ça dépend quoi. Ce n'est pas aux développeurs d'installer un nouveau
serveur de prod. Par contre, si tu veux faire une mise à jour d'une
application java, c'est le développeur qui sera capable de créer un .ear
ou un .jar pour le mette sur le serveur.
Ensuite, déployer un ear ou un jar sur un serveur est très simple. Que
ce soit le développeur, l'administrateur ou une autre personne (si je te
dis le chef de projet, tu vas bondir) qui le déploie n'est pas très
important. Ce qui est important, c'est que la procédure soit bien cadrée
(manuel de déploiement, tests préalable, circuit de validation et autres
procédures de retour arrière).
Si en même temps que le déploiement, il y a des modifs en base de
données à apporter, ça peut être plus simple que le développeur fasse tout.
Je suis d'accord que le plus logique est que l'administrateur fasse le
déploiement, mais ce n'est pas si important que ça.
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.
C'est pour ça que j'ai précisé ce que je comprenais et pourquoi je le comprenais comme ça. Pour rester dans le cadre général, il doit bien y avoir des cas où un ./configure && make && make install est sain sur un serveur de prod, mais ça me gêne dans le cadre général.
Ce dont avait parlé Patrick dans un autre fil c'était l'installation d'Eclipse.
Installer Eclipse sur un serveur de prod ? Pourquoi faire ?
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 ;-)
Il y a plusieurs risques, le secret industriel n'étant pas le plus important en cas d'installation de quelque chose. Pour moi, si la machine du développeur plante suite à une installation foireuse, il est le seul a être bloqué. Si c'est le serveur de prod qui plante à cause d'une installation foireuse, les risques peuvent être importants.
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 ?
Ça dépend quoi. Ce n'est pas aux développeurs d'installer un nouveau serveur de prod. Par contre, si tu veux faire une mise à jour d'une application java, c'est le développeur qui sera capable de créer un .ear ou un .jar pour le mette sur le serveur.
Ensuite, déployer un ear ou un jar sur un serveur est très simple. Que ce soit le développeur, l'administrateur ou une autre personne (si je te dis le chef de projet, tu vas bondir) qui le déploie n'est pas très important. Ce qui est important, c'est que la procédure soit bien cadrée (manuel de déploiement, tests préalable, circuit de validation et autres procédures de retour arrière).
Si en même temps que le déploiement, il y a des modifs en base de données à apporter, ça peut être plus simple que le développeur fasse tout.
Je suis d'accord que le plus logique est que l'administrateur fasse le déploiement, mais ce n'est pas si important que ça.
pipantal
JKB a écrit :
C'est sûr qu'en consommation brute et en chauffage d'appoint, c'est pas mal du tout. Mes sparcs à 32 voies consomment 2A/230V en pleine charge. Le jour où je trouve un i386 capable de faire ça, je reviendrai sur ma position.
Certes, mais ça donne quoi vos sparcs en terme de puissance brut ! Il faut quel (et combien d'x86) pour en arriver au même résultat ?
Non. Les procs x86 consomment peu lorsqu'ils ne fichent rien. Dès qu'on met les pieds dedans, ils se transforment en grille-pain (il y a des raisons qui proviennent du design de la puce et d'autres qui viennent directement de la conception du langage d'assemblage).
à une époque bien lointaine ou je bricolais mon Amiga 2000 et son 68000, je trouvais que c'était d'une simplicité déconcertante, je n'ai jamais compris l'x86, et notamment l'adressage mémoire !
Ouaips. L'alpha est mort, mais l'UltraSPARC VII/FX est là. De même que le POWER6 et quelques autres.
Mais qui fait fabrique ces machines, quels périphériques utilise-t-il ?
Le développement d'OS alternatif très mature à ce jour, ne peut-il envisager une concurrence du point de vue de l'architecture des coeurs ?
Le SATA c'est bien ? le PCI express c'est bien ?
Parce qu'on ne peut pas révolutionner tout, tout de suite.
Et combien coutent les architectures alternatives ?
Moi je reverrai d'avoir un ordinateur personnel qui consomme rien et rapide et surtout peu cher ! ça existe ?
JKB a écrit :
C'est sûr qu'en consommation brute et en chauffage d'appoint, c'est
pas mal du tout. Mes sparcs à 32 voies consomment 2A/230V en pleine
charge. Le jour où je trouve un i386 capable de faire ça, je
reviendrai sur ma position.
Certes, mais ça donne quoi vos sparcs en terme de puissance brut !
Il faut quel (et combien d'x86) pour en arriver au même résultat ?
Non. Les procs x86 consomment peu lorsqu'ils ne fichent rien. Dès
qu'on met les pieds dedans, ils se transforment en grille-pain (il y
a des raisons qui proviennent du design de la puce et d'autres qui
viennent directement de la conception du langage d'assemblage).
à une époque bien lointaine ou je bricolais mon Amiga 2000 et son 68000,
je trouvais que c'était d'une simplicité déconcertante, je n'ai jamais
compris l'x86, et notamment l'adressage mémoire !
Ouaips. L'alpha est mort, mais l'UltraSPARC VII/FX est là. De même
que le POWER6 et quelques autres.
Mais qui fait fabrique ces machines, quels périphériques utilise-t-il ?
Le développement d'OS alternatif très mature à ce jour, ne peut-il
envisager une concurrence du point de vue de l'architecture des coeurs ?
Le SATA c'est bien ?
le PCI express c'est bien ?
Parce qu'on ne peut pas révolutionner tout, tout de suite.
Et combien coutent les architectures alternatives ?
Moi je reverrai d'avoir un ordinateur personnel qui consomme rien et
rapide et surtout peu cher ! ça existe ?
C'est sûr qu'en consommation brute et en chauffage d'appoint, c'est pas mal du tout. Mes sparcs à 32 voies consomment 2A/230V en pleine charge. Le jour où je trouve un i386 capable de faire ça, je reviendrai sur ma position.
Certes, mais ça donne quoi vos sparcs en terme de puissance brut ! Il faut quel (et combien d'x86) pour en arriver au même résultat ?
Non. Les procs x86 consomment peu lorsqu'ils ne fichent rien. Dès qu'on met les pieds dedans, ils se transforment en grille-pain (il y a des raisons qui proviennent du design de la puce et d'autres qui viennent directement de la conception du langage d'assemblage).
à une époque bien lointaine ou je bricolais mon Amiga 2000 et son 68000, je trouvais que c'était d'une simplicité déconcertante, je n'ai jamais compris l'x86, et notamment l'adressage mémoire !
Ouaips. L'alpha est mort, mais l'UltraSPARC VII/FX est là. De même que le POWER6 et quelques autres.
Mais qui fait fabrique ces machines, quels périphériques utilise-t-il ?
Le développement d'OS alternatif très mature à ce jour, ne peut-il envisager une concurrence du point de vue de l'architecture des coeurs ?
Le SATA c'est bien ? le PCI express c'est bien ?
Parce qu'on ne peut pas révolutionner tout, tout de suite.
Et combien coutent les architectures alternatives ?
Moi je reverrai d'avoir un ordinateur personnel qui consomme rien et rapide et surtout peu cher ! ça existe ?
Eric Masson
pipantal writes:
'Lut,
Le PC c'est pas bien ! mais en terme de performance y a-t-il mieux !
Au niveau des io, n'importe quel midrange met une taule aux archis à base pc. Et lorsque l'on est obligé pour des raisons commerciales de mettre en place un serveur x86 en lieu et place d'un véritable serveur pour une appli transactionnelle, les coûts sont supérieurs pour un résultat largement inférieur.
-- les fu2 c'est completement con car ceux qui savent ce que c'est, les enlevent et ceux qui ne savent pas s'enervent de ne pas voir leurs messages s'afficher et ils repostent leur réponse en dehors du thread -+- ELG in GNU: Surtout ne pas se demander à quoi ça sert -+-
pipantal <000pipantal@free.fr000> writes:
'Lut,
Le PC c'est pas bien ! mais en terme de performance y a-t-il mieux !
Au niveau des io, n'importe quel midrange met une taule aux archis à
base pc. Et lorsque l'on est obligé pour des raisons commerciales de
mettre en place un serveur x86 en lieu et place d'un véritable serveur
pour une appli transactionnelle, les coûts sont supérieurs pour un
résultat largement inférieur.
--
les fu2 c'est completement con car ceux qui savent ce que c'est, les
enlevent et ceux qui ne savent pas s'enervent de ne pas voir leurs
messages s'afficher et ils repostent leur réponse en dehors du thread
-+- ELG in GNU: Surtout ne pas se demander à quoi ça sert -+-
Le PC c'est pas bien ! mais en terme de performance y a-t-il mieux !
Au niveau des io, n'importe quel midrange met une taule aux archis à base pc. Et lorsque l'on est obligé pour des raisons commerciales de mettre en place un serveur x86 en lieu et place d'un véritable serveur pour une appli transactionnelle, les coûts sont supérieurs pour un résultat largement inférieur.
-- les fu2 c'est completement con car ceux qui savent ce que c'est, les enlevent et ceux qui ne savent pas s'enervent de ne pas voir leurs messages s'afficher et ils repostent leur réponse en dehors du thread -+- ELG in GNU: Surtout ne pas se demander à quoi ça sert -+-
Patrick Lamaizière
Yves Lambert :
Pas une erreur, rien...
Y'a des gens qui arrivent à utiliser Eclipse 3.4.2 sous FreeBSD ?
Je veux bien essayer sur NetBSD, mais il va falloir que je remette la vache en production pour ça.
Bah t'embêtes pas merci. J'ai mis une debian dans une virtual box et au pire j'utiliserais MacOS X pour ça.
Il me semble qu'Eclipse s'exécute mal en dehors de la VM Sun ou IBM. Il faudrait peut-etre partir de là, non ?
J'utilise la VM de Sun.
Yves Lambert :
Pas une erreur, rien...
Y'a des gens qui arrivent à utiliser Eclipse 3.4.2 sous FreeBSD ?
Je veux bien essayer sur NetBSD, mais il va falloir que je remette la
vache en production pour ça.
Bah t'embêtes pas merci. J'ai mis une debian dans une virtual box et au
pire j'utiliserais MacOS X pour ça.
Il me semble qu'Eclipse s'exécute mal en
dehors de la VM Sun ou IBM. Il faudrait peut-etre partir de là, non ?
Y'a des gens qui arrivent à utiliser Eclipse 3.4.2 sous FreeBSD ?
Je veux bien essayer sur NetBSD, mais il va falloir que je remette la vache en production pour ça.
Bah t'embêtes pas merci. J'ai mis une debian dans une virtual box et au pire j'utiliserais MacOS X pour ça.
Il me semble qu'Eclipse s'exécute mal en dehors de la VM Sun ou IBM. Il faudrait peut-etre partir de là, non ?
J'utilise la VM de Sun.
Dellara
Eric Masson a papoté sur Usenet le janvier 3, 2010 02:35 PM:
Au niveau des io, n'importe quel midrange met une taule aux archis à base pc. Et lorsque l'on est obligé pour des raisons commerciales de mettre en place un serveur x86 en lieu et place d'un véritable serveur pour une appli transactionnelle, les coûts sont supérieurs pour un résultat largement inférieur.
Mais la question est (et ce n'est pas un troll mais une vraie question): Comment se fait-il que les constructeurs restent sur cette architecture pourrie s'il y a mieux?
Eric Masson a papoté sur Usenet le janvier 3, 2010 02:35 PM:
Au niveau des io, n'importe quel midrange met une taule aux archis à
base pc. Et lorsque l'on est obligé pour des raisons commerciales de
mettre en place un serveur x86 en lieu et place d'un véritable serveur
pour une appli transactionnelle, les coûts sont supérieurs pour un
résultat largement inférieur.
Mais la question est (et ce n'est pas un troll mais une vraie question):
Comment se fait-il que les constructeurs restent sur cette architecture
pourrie s'il y a mieux?
Eric Masson a papoté sur Usenet le janvier 3, 2010 02:35 PM:
Au niveau des io, n'importe quel midrange met une taule aux archis à base pc. Et lorsque l'on est obligé pour des raisons commerciales de mettre en place un serveur x86 en lieu et place d'un véritable serveur pour une appli transactionnelle, les coûts sont supérieurs pour un résultat largement inférieur.
Mais la question est (et ce n'est pas un troll mais une vraie question): Comment se fait-il que les constructeurs restent sur cette architecture pourrie s'il y a mieux?
