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 aussi un petit ARM qui fonctionne avec une clé USB comme disque dur. Aucun besoin de -dev et de -doc là dessus,
Pipo. (pas pour les docs, mais les dev c'est 0.1% de la masse totale
de toute façon, compiler sur cette machine est beaucoup trop lent, et tuerais la flash.
Légende urbaine.
--
References:
Stephane TOUGARD
Patrice Karatchentzeff a perdu son temps a nous dire:
T'es vraiment bouché : on t'explique que la Debian est une *distribution* qui a un but *particulier* qui est un peu près la seule des distributions à avoir ce but et tu nous sors une généralisation à côté de la plaque pour soutenir le contraire...
Si la Debian avait uniquement ce but particulier, alors personne ne l'utiliserait.
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).
-- http://unices.over-blog.com/ Un Francais en Chine
Patrice Karatchentzeff a perdu son temps a nous dire:
T'es vraiment bouché : on t'explique que la Debian est une
*distribution* qui a un but *particulier* qui est un peu près la seule
des distributions à avoir ce but et tu nous sors une généralisation à
côté de la plaque pour soutenir le contraire...
Si la Debian avait uniquement ce but particulier, alors personne ne
l'utiliserait.
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).
--
http://unices.over-blog.com/ Un Francais en Chine
Patrice Karatchentzeff a perdu son temps a nous dire:
T'es vraiment bouché : on t'explique que la Debian est une *distribution* qui a un but *particulier* qui est un peu près la seule des distributions à avoir ce but et tu nous sors une généralisation à côté de la plaque pour soutenir le contraire...
Si la Debian avait uniquement ce but particulier, alors personne ne l'utiliserait.
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).
-- http://unices.over-blog.com/ Un Francais en Chine
yl
In article , Stephane TOUGARD writes:
Patrice Karatchentzeff a perdu son temps a nous dire:
C'est dire si même les dév d'Apache sont d'accord avec toi.
Je ne critique pas la qualite. Je critique le fait que c'est "invasif".
Il serait plus intelligent de faire une Debian version mini-disk pour le 0.1% de dino qui utilisent des disques durs de 200Mb et de faire une gestion normale de packages pour les 99.9% qui ont des disques de plus
s/normale/à la Tougard/
Non, "normale" comme tous les Unix depuis que les Unix existent.
Normal en utilisant des ports et/ou quand on a un patch local à appliquer ou pour optimiser le binaire à ton architecture ou pour tester une version de développement, oui. Autrement non, ce n'est pas vraiment une utillisation normale.
Ce n'est pas parce que tu travailles comme un goret que les autres sont obligés de faire de même.
Je suis sur que l'ensemble des gens qui travaillent sur des distributions plus classiques sont content de savoir que le grand Patrice K. pense qu'ils travaillent comme des gorets.
Alors si en plus tu parles explicitement de distribution que ce soit debian ou autres, ce n'est pas du tout l'utilisation normale.
--
References:
In article <d61417-5mu1.ln1@gulliver.unices.org>,
Stephane TOUGARD <jkb@unices.org> writes:
Patrice Karatchentzeff a perdu son temps a nous dire:
C'est dire si même les dév d'Apache sont d'accord avec toi.
Je ne critique pas la qualite. Je critique le fait que c'est "invasif".
Il serait plus intelligent de faire une Debian version mini-disk
pour le 0.1% de dino qui utilisent des disques durs de 200Mb et de
faire une gestion normale de packages pour les 99.9% qui ont des
disques de plus
s/normale/à la Tougard/
Non, "normale" comme tous les Unix depuis que les Unix existent.
Normal en utilisant des ports et/ou quand on a un
patch local à appliquer ou pour optimiser le binaire
à ton architecture ou pour tester une version de
développement, oui. Autrement non, ce n'est pas
vraiment une utillisation normale.
Ce n'est pas parce que tu travailles comme un goret que les autres
sont obligés de faire de même.
Je suis sur que l'ensemble des gens qui travaillent sur des
distributions plus classiques sont content de savoir que le grand
Patrice K. pense qu'ils travaillent comme des gorets.
Alors si en plus tu parles explicitement de distribution que ce soit
debian ou autres, ce n'est pas du tout l'utilisation normale.
Patrice Karatchentzeff a perdu son temps a nous dire:
C'est dire si même les dév d'Apache sont d'accord avec toi.
Je ne critique pas la qualite. Je critique le fait que c'est "invasif".
Il serait plus intelligent de faire une Debian version mini-disk pour le 0.1% de dino qui utilisent des disques durs de 200Mb et de faire une gestion normale de packages pour les 99.9% qui ont des disques de plus
s/normale/à la Tougard/
Non, "normale" comme tous les Unix depuis que les Unix existent.
Normal en utilisant des ports et/ou quand on a un patch local à appliquer ou pour optimiser le binaire à ton architecture ou pour tester une version de développement, oui. Autrement non, ce n'est pas vraiment une utillisation normale.
Ce n'est pas parce que tu travailles comme un goret que les autres sont obligés de faire de même.
Je suis sur que l'ensemble des gens qui travaillent sur des distributions plus classiques sont content de savoir que le grand Patrice K. pense qu'ils travaillent comme des gorets.
Alors si en plus tu parles explicitement de distribution que ce soit debian ou autres, ce n'est pas du tout l'utilisation normale.
--
References:
yl
In article , Patrice Karatchentzeff writes:
Un Unix est un OS de developpement philosophiquement parlant. Meme si on ne fait pas de developpement (je ne fais pas de C), on peut toujours faire des ./configure && make && make install parce qu'on a besoin d'un soft qui n'est pas package (ou pas comme il faut).
MDR. Sur un serveur de prod par exemple ?
Ou l'art et la manière d'ouvrir grandes ouvertes les portes de la machine au premier script kiddy venu.
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.
--
References:
In article <87fx6o1vax.fsf@belledonne.chartreuse.fr>,
Patrice Karatchentzeff <p.karatchentzeff@free.fr> writes:
Un Unix est un OS de developpement philosophiquement parlant. Meme
si on ne fait pas de developpement (je ne fais pas de C), on peut
toujours faire des ./configure && make && make install parce qu'on a
besoin d'un soft qui n'est pas package (ou pas comme il faut).
MDR. Sur un serveur de prod par exemple ?
Ou l'art et la manière d'ouvrir grandes ouvertes les portes de la
machine au premier script kiddy venu.
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.
Un Unix est un OS de developpement philosophiquement parlant. Meme si on ne fait pas de developpement (je ne fais pas de C), on peut toujours faire des ./configure && make && make install parce qu'on a besoin d'un soft qui n'est pas package (ou pas comme il faut).
MDR. Sur un serveur de prod par exemple ?
Ou l'art et la manière d'ouvrir grandes ouvertes les portes de la machine au premier script kiddy venu.
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.
il y a un curieux parallèle entre la compétence des admins et le choix des distributions.
Plus la distrib est mal fichue, plus l'admin acquiert de la compétence pour pallier aux manques de la distrib :)
--
References:
Stephane TOUGARD
Patrice Karatchentzeff a perdu son temps a nous dire:
Solaris,
N'existe plus en entreprise, sauf grand groupe et encore...
Ouah, t'as vraiment une vision super restreinte du monde.
Free/Net/OpenBSD
Tellement marginale que cela existe sans doute encore moins que Solaris...
Walnut Creek, Yahoo, Netcraft ... juste des entreprises mineures et sans importance.
Je passe sur les autres, non parce qu'elles n'existent pas en entreprise, mais simplement parce que tu n'es pas de bonne foi et que ca ne sert a rien d'argumenter. Une simple recherche sur le web t'en dira plus que je ne peux t'en dire.
MDR. Dit le gars qui administre deux serveurs dans son coin.
Que sais tu de ce que j'administre ? Et meme si je ne gere QUE 2 serveurs (ce qui n'est pas vrai), que sais-tu de ce qu'ils font ? a combien d'utilisateurs ils livrent un service ?
Je connais des serveurs qui necessitent des equipes pour fonctionner, un serveurs pour plusieurs administrateurs systemes. Bon, c'est pas des PC, c'est pas du Linux mais ca gere des trucs que t'as pas idee quand meme.
Maintenant, je connais aussi des admins qui font des scripts automatiques pour 3000 serveurs web dans des data-centers. Il y a pas de honte a aucun des deux metiers, mais je pense pas que le premier soit moins complique que le second.
Re-MDR. Dit le gars qui pense que seule sa façon de faire est la bonne.
Non et je te mets au defi de trouver un post ou je dis que tout le monde devrait travailler comme je le fais. Tu fais un proces d'intention, c'est tout.
-- http://unices.over-blog.com/ Un Francais en Chine
Patrice Karatchentzeff a perdu son temps a nous dire:
Solaris,
N'existe plus en entreprise, sauf grand groupe et encore...
Ouah, t'as vraiment une vision super restreinte du monde.
Free/Net/OpenBSD
Tellement marginale que cela existe sans doute encore moins que
Solaris...
Walnut Creek, Yahoo, Netcraft ... juste des entreprises mineures et sans
importance.
Je passe sur les autres, non parce qu'elles n'existent pas en
entreprise, mais simplement parce que tu n'es pas de bonne foi et que ca
ne sert a rien d'argumenter. Une simple recherche sur le web t'en dira
plus que je ne peux t'en dire.
MDR. Dit le gars qui administre deux serveurs dans son coin.
Que sais tu de ce que j'administre ? Et meme si je ne gere QUE 2
serveurs (ce qui n'est pas vrai), que sais-tu de ce qu'ils font ? a
combien d'utilisateurs ils livrent un service ?
Je connais des serveurs qui necessitent des equipes pour fonctionner, un
serveurs pour plusieurs administrateurs systemes. Bon, c'est pas des PC,
c'est pas du Linux mais ca gere des trucs que t'as pas idee quand meme.
Maintenant, je connais aussi des admins qui font des scripts
automatiques pour 3000 serveurs web dans des data-centers. Il y a pas de
honte a aucun des deux metiers, mais je pense pas que le premier soit
moins complique que le second.
Re-MDR. Dit le gars qui pense que seule sa façon de faire est la
bonne.
Non et je te mets au defi de trouver un post ou je dis que tout le monde
devrait travailler comme je le fais. Tu fais un proces d'intention,
c'est tout.
--
http://unices.over-blog.com/ Un Francais en Chine
Patrice Karatchentzeff a perdu son temps a nous dire:
Solaris,
N'existe plus en entreprise, sauf grand groupe et encore...
Ouah, t'as vraiment une vision super restreinte du monde.
Free/Net/OpenBSD
Tellement marginale que cela existe sans doute encore moins que Solaris...
Walnut Creek, Yahoo, Netcraft ... juste des entreprises mineures et sans importance.
Je passe sur les autres, non parce qu'elles n'existent pas en entreprise, mais simplement parce que tu n'es pas de bonne foi et que ca ne sert a rien d'argumenter. Une simple recherche sur le web t'en dira plus que je ne peux t'en dire.
MDR. Dit le gars qui administre deux serveurs dans son coin.
Que sais tu de ce que j'administre ? Et meme si je ne gere QUE 2 serveurs (ce qui n'est pas vrai), que sais-tu de ce qu'ils font ? a combien d'utilisateurs ils livrent un service ?
Je connais des serveurs qui necessitent des equipes pour fonctionner, un serveurs pour plusieurs administrateurs systemes. Bon, c'est pas des PC, c'est pas du Linux mais ca gere des trucs que t'as pas idee quand meme.
Maintenant, je connais aussi des admins qui font des scripts automatiques pour 3000 serveurs web dans des data-centers. Il y a pas de honte a aucun des deux metiers, mais je pense pas que le premier soit moins complique que le second.
Re-MDR. Dit le gars qui pense que seule sa façon de faire est la bonne.
Non et je te mets au defi de trouver un post ou je dis que tout le monde devrait travailler comme je le fais. Tu fais un proces d'intention, c'est tout.
-- http://unices.over-blog.com/ Un Francais en Chine
Stephane TOUGARD
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.
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.
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 :
-- http://unices.over-blog.com/ Un Francais en Chine
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.
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.
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 :
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.
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.
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 :
Couper le passage où je parle de datas de jeux te permet de dire ça. En remettant ce passage, ta réponse est juste à côté de la plaque.
Bien, sur un disque de 60Gb, tu n'as pas les 500Mb necessaires pour installer les *-dev et les *-doc qui vont bien.
Et je n'ai pas parlé de limitations dûes à l'espace disque sur l'ARM, juste de l'inutilité d'avoir ces données.
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.
Bien, sur ton clavier 105 touches, tu n'as pas celles pour taper :
aptitude installe MACHIN.dev ?
yl
In article , JKB writes:
Le 02-01-2010, ? propos de Re: KDE tuera Windows, Patrick Lamaizière ?crivait dans fr.comp.os.linux.debats :
Patrice Karatchentzeff :
Un Unix est un OS de developpement philosophiquement parlant. Meme si on ne fait pas de developpement (je ne fais pas de C), on peut toujours faire des ./configure && make && make install parce qu'on a besoin d'un soft qui n'est pas package (ou pas comme il faut).
MDR. Sur un serveur de prod par exemple ?
Ou l'art et la manière d'ouvrir grandes ouvertes les portes de la machine au premier script kiddy venu.
Sur les BSD il y a une chaine de compilation fonctionnelle dans la base et ça m'a pas l'air plus troué que Linux.
Euh... J'ai des FreeBSD et des NetBSD comme machines de test. Ta chaîne de compilation n'est utilisable que si tu vires les alertes de sécurités des ports (sinon, tu as toujours un ou deux trucs et je suis gentil qui refusent de s'installer parce que troués).
Ben ouais. C'est là qu'il faut voir s'il n'y a pas une version où le bug est corrigée et qui n'est pas dans les ports, et l'y faire entrer, (c'est complexe, mais faisable) ou alors voir coment on peut se passer du "truc" en question ou selon si l'alerte de sécurité est grave ou pas.
Par ailleurs, il est écrit noir sur blanc dans la doc des BSD que les équipes de développement ne sont pas responsables de la sécurité des logiciels dans les ports (comprendre de l'utilisation de l'outil et de ce qui peut se passer dans la phase de compilation). En d'autres termes, les ports, ce sont des logiciels fournis tels quels aux quelques scripts de compilation et de gestion des dépendances.
De l'autre côté, debian fournit des paquets bien plus suivis en terme de sécurité.
Rien n'empeche d'appliquer les patches debian au paquet, si patches debian il y a. Il y a une procédure pour appliquer des patches persos qui est bien documentée et facile sur NetBSD.
--
References:
In article <slrnhjut3q.big.knatschke@rayleigh.systella.fr>,
JKB <knatschke@koenigsberg.fr> writes:
Le 02-01-2010, ? propos de
Re: KDE tuera Windows,
Patrick Lamaizière ?crivait dans fr.comp.os.linux.debats :
Patrice Karatchentzeff :
Un Unix est un OS de developpement philosophiquement parlant. Meme
si on ne fait pas de developpement (je ne fais pas de C), on peut
toujours faire des ./configure && make && make install parce qu'on a
besoin d'un soft qui n'est pas package (ou pas comme il faut).
MDR. Sur un serveur de prod par exemple ?
Ou l'art et la manière d'ouvrir grandes ouvertes les portes de la
machine au premier script kiddy venu.
Sur les BSD il y a une chaine de compilation fonctionnelle dans la base
et ça m'a pas l'air plus troué que Linux.
Euh... J'ai des FreeBSD et des NetBSD comme machines de test. Ta
chaîne de compilation n'est utilisable que si tu vires les alertes
de sécurités des ports (sinon, tu as toujours un ou deux trucs et je
suis gentil qui refusent de s'installer parce que troués).
Ben ouais. C'est là qu'il faut voir s'il n'y a pas une version où le bug
est corrigée et qui n'est pas dans les ports, et l'y faire
entrer, (c'est complexe, mais faisable) ou alors voir coment on peut se
passer du "truc" en question ou selon si l'alerte de sécurité est grave
ou pas.
Par
ailleurs, il est écrit noir sur blanc dans la doc des BSD que les
équipes de développement ne sont pas responsables de la sécurité des
logiciels dans les ports (comprendre de l'utilisation de l'outil et
de ce qui peut se passer dans la phase de compilation). En d'autres
termes, les ports, ce sont des logiciels fournis tels quels aux
quelques scripts de compilation et de gestion des dépendances.
De l'autre côté, debian fournit des paquets bien plus suivis en
terme de sécurité.
Rien n'empeche d'appliquer les patches debian au paquet, si patches
debian il y a. Il y a une procédure pour appliquer des patches persos
qui est bien documentée et facile sur NetBSD.
Le 02-01-2010, ? propos de Re: KDE tuera Windows, Patrick Lamaizière ?crivait dans fr.comp.os.linux.debats :
Patrice Karatchentzeff :
Un Unix est un OS de developpement philosophiquement parlant. Meme si on ne fait pas de developpement (je ne fais pas de C), on peut toujours faire des ./configure && make && make install parce qu'on a besoin d'un soft qui n'est pas package (ou pas comme il faut).
MDR. Sur un serveur de prod par exemple ?
Ou l'art et la manière d'ouvrir grandes ouvertes les portes de la machine au premier script kiddy venu.
Sur les BSD il y a une chaine de compilation fonctionnelle dans la base et ça m'a pas l'air plus troué que Linux.
Euh... J'ai des FreeBSD et des NetBSD comme machines de test. Ta chaîne de compilation n'est utilisable que si tu vires les alertes de sécurités des ports (sinon, tu as toujours un ou deux trucs et je suis gentil qui refusent de s'installer parce que troués).
Ben ouais. C'est là qu'il faut voir s'il n'y a pas une version où le bug est corrigée et qui n'est pas dans les ports, et l'y faire entrer, (c'est complexe, mais faisable) ou alors voir coment on peut se passer du "truc" en question ou selon si l'alerte de sécurité est grave ou pas.
Par ailleurs, il est écrit noir sur blanc dans la doc des BSD que les équipes de développement ne sont pas responsables de la sécurité des logiciels dans les ports (comprendre de l'utilisation de l'outil et de ce qui peut se passer dans la phase de compilation). En d'autres termes, les ports, ce sont des logiciels fournis tels quels aux quelques scripts de compilation et de gestion des dépendances.
De l'autre côté, debian fournit des paquets bien plus suivis en terme de sécurité.
Rien n'empeche d'appliquer les patches debian au paquet, si patches debian il y a. Il y a une procédure pour appliquer des patches persos qui est bien documentée et facile sur NetBSD.
