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.
J'ai Kubuntu avec KDE, mais pas de MySQL en mémpoire ?!
Regarde les dépendances inverses de mysql* et celles des scripts *mysql* pour savoir quel composant de KDE a besoin de MySQL.
AhAhAhAh.
Stephane TOUGARD
Stéphane CARPENTIER a perdu son temps a nous dire:
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.
Comment pourraient-ils avoir tort sur ce point puisque Debian a ses propres regles pour definir son propre environnement ?
-- http://unices.over-blog.com/ Un Francais en Chine
Stéphane CARPENTIER a perdu son temps a nous dire:
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.
Comment pourraient-ils avoir tort sur ce point puisque Debian a ses
propres regles pour definir son propre environnement ?
--
http://unices.over-blog.com/ Un Francais en Chine
Stéphane CARPENTIER a perdu son temps a nous dire:
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.
Comment pourraient-ils avoir tort sur ce point puisque Debian a ses propres regles pour definir son propre environnement ?
-- http://unices.over-blog.com/ Un Francais en Chine
Stephane TOUGARD
Yves Lambert a perdu son temps a nous dire:
Je crois que tu n'as pas compris, mais en fait c'est hypothétique : c'est au cas ou tu as besoin des bibiothèques d'Apache pour un autre soft que tu risques de te retrouver avec des liens dynamiques un peu hasardeux.
Ca ne m'est jamais arrive dans ce sens la, mais c'est deja arrive dans le sens PHP -> Apache.
Ca fait partie du process que d'en tenir compte.
Je t'explique comment je vois les choses si tu utilises une ditribution (on va prendre debian parce qu'on connait tous les duex un peu).
Non, je connais peu Debian. Mes seules experiences avec cette distrib sont soit via la Ubuntu (Desktop) soit pour corriger les inepties de configuration par defaut sur des machines que je n'ai pas installe.
Tu installes la nouvelle version (packagée en binaire mais portée et
...
Desole, pas ma maniere de faire. Trop complique et ca n'apporte aucune plus value en soit. Qui plus est, c'est totalement impossible a realiser sur les services que je gere.
-- http://unices.over-blog.com/ Un Francais en Chine
Yves Lambert a perdu son temps a nous dire:
Je crois que tu n'as pas compris, mais en fait c'est hypothétique :
c'est au cas ou tu as besoin des bibiothèques d'Apache pour un autre
soft que tu risques de te retrouver avec des liens dynamiques un peu
hasardeux.
Ca ne m'est jamais arrive dans ce sens la, mais c'est deja arrive dans
le sens PHP -> Apache.
Ca fait partie du process que d'en tenir compte.
Je t'explique comment je vois les choses si tu utilises une ditribution
(on va prendre debian parce qu'on connait tous les duex un peu).
Non, je connais peu Debian. Mes seules experiences avec cette distrib
sont soit via la Ubuntu (Desktop) soit pour corriger les inepties de
configuration par defaut sur des machines que je n'ai pas installe.
Tu installes la nouvelle version (packagée en binaire mais portée et
...
Desole, pas ma maniere de faire. Trop complique et ca n'apporte aucune
plus value en soit. Qui plus est, c'est totalement impossible a realiser
sur les services que je gere.
--
http://unices.over-blog.com/ Un Francais en Chine
Je crois que tu n'as pas compris, mais en fait c'est hypothétique : c'est au cas ou tu as besoin des bibiothèques d'Apache pour un autre soft que tu risques de te retrouver avec des liens dynamiques un peu hasardeux.
Ca ne m'est jamais arrive dans ce sens la, mais c'est deja arrive dans le sens PHP -> Apache.
Ca fait partie du process que d'en tenir compte.
Je t'explique comment je vois les choses si tu utilises une ditribution (on va prendre debian parce qu'on connait tous les duex un peu).
Non, je connais peu Debian. Mes seules experiences avec cette distrib sont soit via la Ubuntu (Desktop) soit pour corriger les inepties de configuration par defaut sur des machines que je n'ai pas installe.
Tu installes la nouvelle version (packagée en binaire mais portée et
...
Desole, pas ma maniere de faire. Trop complique et ca n'apporte aucune plus value en soit. Qui plus est, c'est totalement impossible a realiser sur les services que je gere.
-- http://unices.over-blog.com/ Un Francais en Chine
Stephane TOUGARD
Riquer Vincent a perdu son temps a nous dire:
Oui bien sur, donc parce que tu as un ARM, il faut absolument que tous les packages de la Debian soient splites en petits bouts.
Non : parce que je ne doit pas être le seul.
Oui, 0.1% des cas.
-- http://unices.over-blog.com/ Un Francais en Chine
Riquer Vincent a perdu son temps a nous dire:
Oui bien sur, donc parce que tu as un ARM, il faut absolument que tous
les packages de la Debian soient splites en petits bouts.
Non : parce que je ne doit pas être le seul.
Oui, 0.1% des cas.
--
http://unices.over-blog.com/ Un Francais en Chine
Oui bien sur, donc parce que tu as un ARM, il faut absolument que tous les packages de la Debian soient splites en petits bouts.
Non : parce que je ne doit pas être le seul.
Oui, 0.1% des cas.
-- http://unices.over-blog.com/ Un Francais en Chine
Stephane TOUGARD
Stéphane CARPENTIER a perdu son temps a nous dire:
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.
Ca n'a rien de plus dangereux que de downloader un package binaire, l'installation se passe egalement en root et le package peut embarquer un script kiddy exactement de la meme facon.
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.
Je ne vois pas le rapport entre une procedure d'installation qui passe par une phase de compilation et un deploiment a la sauvage.
On peut faire apt-get install package a la sauvage et on peut faire ./configure && make && make install en suivant un process d'installation interne, apres etre passe par une serie de tests, avec une procedure de rollback et tout et tout.
-- http://unices.over-blog.com/ Un Francais en Chine
Stéphane CARPENTIER a perdu son temps a nous dire:
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.
Ca n'a rien de plus dangereux que de downloader un package binaire,
l'installation se passe egalement en root et le package peut embarquer
un script kiddy exactement de la meme facon.
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.
Je ne vois pas le rapport entre une procedure d'installation qui passe
par une phase de compilation et un deploiment a la sauvage.
On peut faire apt-get install package a la sauvage et on peut faire
./configure && make && make install en suivant un process d'installation
interne, apres etre passe par une serie de tests, avec une procedure de
rollback et tout et tout.
--
http://unices.over-blog.com/ Un Francais en Chine
Stéphane CARPENTIER a perdu son temps a nous dire:
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.
Ca n'a rien de plus dangereux que de downloader un package binaire, l'installation se passe egalement en root et le package peut embarquer un script kiddy exactement de la meme facon.
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.
Je ne vois pas le rapport entre une procedure d'installation qui passe par une phase de compilation et un deploiment a la sauvage.
On peut faire apt-get install package a la sauvage et on peut faire ./configure && make && make install en suivant un process d'installation interne, apres etre passe par une serie de tests, avec une procedure de rollback et tout et tout.
-- http://unices.over-blog.com/ Un Francais en Chine
Stephane TOUGARD
JKB a perdu son temps a nous dire:
Utiliser exim pour un serveur privé (comprendre une station de travail qui a besoin d'un serveur de mail pour que certains daemons puissent envoyer un courrier à l'administrateur en cas de problème), pourquoi pas. L'utiliser sur un vrai serveur de mail est une bêtise tant le truc est troué.
Oui on sait, comme Qmail, comme Postfix, comme ... en fait tout ce qui n'est pas sendmail (de preference sur OpenVMS).
-- http://unices.over-blog.com/ Un Francais en Chine
JKB a perdu son temps a nous dire:
Utiliser exim pour un serveur privé (comprendre une station de
travail qui a besoin d'un serveur de mail pour que certains daemons
puissent envoyer un courrier à l'administrateur en cas de problème),
pourquoi pas. L'utiliser sur un vrai serveur de mail est une bêtise
tant le truc est troué.
Oui on sait, comme Qmail, comme Postfix, comme ... en fait tout ce qui
n'est pas sendmail (de preference sur OpenVMS).
--
http://unices.over-blog.com/ Un Francais en Chine
Utiliser exim pour un serveur privé (comprendre une station de travail qui a besoin d'un serveur de mail pour que certains daemons puissent envoyer un courrier à l'administrateur en cas de problème), pourquoi pas. L'utiliser sur un vrai serveur de mail est une bêtise tant le truc est troué.
Oui on sait, comme Qmail, comme Postfix, comme ... en fait tout ce qui n'est pas sendmail (de preference sur OpenVMS).
-- http://unices.over-blog.com/ Un Francais en Chine
Stephane TOUGARD
Nicolas George a perdu son temps a nous dire:
Que tu ne peux rien utiliser de plus recent avec les versions de dcraw ou d'ufraw de la Debian.
Et tu ne peux pas utiliser non plus les trucs plus anciens ? Parce que c'est ça que tu sous-entends.
Non, j'utilise un D700 et je vais certainement essayer de trouver un D70 d'occas sous pretexte que c'est le Nikon le plus recent supporte par la Debian.
-- http://unices.over-blog.com/ Un Francais en Chine
Nicolas George a perdu son temps a nous dire:
Que tu ne peux rien utiliser de plus recent avec les versions de dcraw
ou d'ufraw de la Debian.
Et tu ne peux pas utiliser non plus les trucs plus anciens ? Parce que c'est
ça que tu sous-entends.
Non, j'utilise un D700 et je vais certainement essayer de trouver un D70
d'occas sous pretexte que c'est le Nikon le plus recent supporte par la
Debian.
--
http://unices.over-blog.com/ Un Francais en Chine
Que tu ne peux rien utiliser de plus recent avec les versions de dcraw ou d'ufraw de la Debian.
Et tu ne peux pas utiliser non plus les trucs plus anciens ? Parce que c'est ça que tu sous-entends.
Non, j'utilise un D700 et je vais certainement essayer de trouver un D70 d'occas sous pretexte que c'est le Nikon le plus recent supporte par la Debian.
-- http://unices.over-blog.com/ Un Francais en Chine
Stephane TOUGARD
Yves Lambert a perdu son temps a nous dire:
Ben oui, mais il n'est pas écrit dans la GPL que l'équipe d'un logiciel doit favoriser l'emergence de nouvelles branches. A ce compte là, le bonzai de Mozilla serait contraire à l'esprit des logiciels libres, or ce n'est pas le cas.
On s'en fiche en soit. Ce qui est marque, c'est du marketing. Les faits sont decides par des imperatifs techniques qui sont menes par un point de vue philosophiquement.
La Debian ne favorise pas plus techniquement les fork que n'importe quelle autre distribution ou n'importe quel LL.
Cetes, mais ce qui a été relevé, c'est qu'il est écrit en toute lettre dans la charte de debian que celle-ci peut servir de base à d'autres distributions. Il y a soit une nuance qui soit t'échappe, soit un point que tu éludes volontairement pour avoir raison contre vents et marées. Dans ce dernier cas tu as raison à 100%. Mais sur plus rien du tout.
Il y a rien qui m'echappe. Ce qui est ecrit en toute lettre est du bullshit, on peut marquer un million de choses dans une charte, ce sont les faits techniques qui decident.
Et la Debian n'a rien de plus quoi d'autre a ce niveau.
-- http://unices.over-blog.com/ Un Francais en Chine
Yves Lambert a perdu son temps a nous dire:
Ben oui, mais il n'est pas écrit dans la GPL que l'équipe d'un logiciel
doit favoriser l'emergence de nouvelles branches. A ce compte là, le
bonzai de Mozilla serait contraire à l'esprit des logiciels libres, or
ce n'est pas le cas.
On s'en fiche en soit. Ce qui est marque, c'est du marketing. Les faits
sont decides par des imperatifs techniques qui sont menes par un point
de vue philosophiquement.
La Debian ne favorise pas plus techniquement les fork que n'importe
quelle autre distribution ou n'importe quel LL.
Cetes, mais ce qui a été relevé, c'est qu'il est écrit en toute lettre
dans la charte de debian que celle-ci peut servir de base à d'autres
distributions. Il y a soit une nuance qui soit t'échappe, soit un point
que tu éludes volontairement pour avoir raison contre vents et marées.
Dans ce dernier cas tu as raison à 100%. Mais sur plus rien du tout.
Il y a rien qui m'echappe. Ce qui est ecrit en toute lettre est du
bullshit, on peut marquer un million de choses dans une charte, ce sont
les faits techniques qui decident.
Et la Debian n'a rien de plus quoi d'autre a ce niveau.
--
http://unices.over-blog.com/ Un Francais en Chine
Ben oui, mais il n'est pas écrit dans la GPL que l'équipe d'un logiciel doit favoriser l'emergence de nouvelles branches. A ce compte là, le bonzai de Mozilla serait contraire à l'esprit des logiciels libres, or ce n'est pas le cas.
On s'en fiche en soit. Ce qui est marque, c'est du marketing. Les faits sont decides par des imperatifs techniques qui sont menes par un point de vue philosophiquement.
La Debian ne favorise pas plus techniquement les fork que n'importe quelle autre distribution ou n'importe quel LL.
Cetes, mais ce qui a été relevé, c'est qu'il est écrit en toute lettre dans la charte de debian que celle-ci peut servir de base à d'autres distributions. Il y a soit une nuance qui soit t'échappe, soit un point que tu éludes volontairement pour avoir raison contre vents et marées. Dans ce dernier cas tu as raison à 100%. Mais sur plus rien du tout.
Il y a rien qui m'echappe. Ce qui est ecrit en toute lettre est du bullshit, on peut marquer un million de choses dans une charte, ce sont les faits techniques qui decident.
Et la Debian n'a rien de plus quoi d'autre a ce niveau.
-- http://unices.over-blog.com/ Un Francais en Chine
Stephane TOUGARD
Yves Lambert a perdu son temps a nous dire:
*toutes* les distributions sont basée sur la slack. Par définition.
Non, toutes les distrib sont basees sur la SLS (Slack incluse).
-- http://unices.over-blog.com/ Un Francais en Chine
Yves Lambert a perdu son temps a nous dire:
*toutes* les distributions sont basée sur la slack. Par définition.
Non, toutes les distrib sont basees sur la SLS (Slack incluse).
--
http://unices.over-blog.com/ Un Francais en Chine
*toutes* les distributions sont basée sur la slack. Par définition.
Non, toutes les distrib sont basees sur la SLS (Slack incluse).
-- http://unices.over-blog.com/ Un Francais en Chine
Stephane TOUGARD
Yves Lambert a perdu son temps a nous dire:
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 ?
J'ai suivi les upgrade de dcraw sur 2009, je peux te dire que chaque nouvelle version apporte le support pour des nouveaux boitiers et que je n'ai jamais vu de retrait de support de boitiers.
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 ?
Tous les DSLR envoient du RAW et c'est vraiment pas pres de changer. Je me vois pas payer un boitier 4kE et n'avoir QUE du JPG a la sortie. Ca serait un non sens (et aucun photographe amateur ne l'accepterait).
UFraw est une interface graphique qui s'appuye sur le code de dcraw (comme beaucoup de monde en fait).
-- http://unices.over-blog.com/ Un Francais en Chine
Yves Lambert a perdu son temps a nous dire:
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 ?
J'ai suivi les upgrade de dcraw sur 2009, je peux te dire que chaque
nouvelle version apporte le support pour des nouveaux boitiers et que je
n'ai jamais vu de retrait de support de boitiers.
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 ?
Tous les DSLR envoient du RAW et c'est vraiment pas pres de changer. Je
me vois pas payer un boitier 4kE et n'avoir QUE du JPG a la sortie. Ca
serait un non sens (et aucun photographe amateur ne l'accepterait).
UFraw est une interface graphique qui s'appuye sur le code de dcraw
(comme beaucoup de monde en fait).
--
http://unices.over-blog.com/ Un Francais en Chine
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 ?
J'ai suivi les upgrade de dcraw sur 2009, je peux te dire que chaque nouvelle version apporte le support pour des nouveaux boitiers et que je n'ai jamais vu de retrait de support de boitiers.
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 ?
Tous les DSLR envoient du RAW et c'est vraiment pas pres de changer. Je me vois pas payer un boitier 4kE et n'avoir QUE du JPG a la sortie. Ca serait un non sens (et aucun photographe amateur ne l'accepterait).
UFraw est une interface graphique qui s'appuye sur le code de dcraw (comme beaucoup de monde en fait).
-- http://unices.over-blog.com/ Un Francais en Chine
