Articles précédents : Articles
- [22] Des PC livrés sans OS
- [33] Article sur les positions des partis politiques sur les brevets logiciels
- [9] I2PB suite... et fin!
- [20] OpenSSH dépasse SSH ... en nombre
- [10] Procès Kitetoa : Epilogue
- [38] 110 Ghz : qui dit mieux !
- [29] Violation de GNU GPL : la FSF intervient lors d'un procès
- [16] A la découverte de Bochs
- [38] Le raquet des opérateurs de téléphonie mobile
- [44] Le logiciel libre en entreprise
Liens connexes
- redhat.com (605 hits)
- l'article sur news.com (478 hits)
- current, un serveur libre pour up2date (533 hits)
- annonce de la beta (413 hits)
- télécharger la beta (489 hits)
Dépêche modérée par
Articles : Red Hat s'éloigne de plus en plus du libre
Posté par gc (page perso, ). Modéré le 28 février 2002.Un article de news.com souligne que cette distribution ne sera, en version finale, pas disponible en téléchargement. Red Hat, comme tous les distributeurs commerciaux de Linux, espère probablement lutter ainsi contre le déséquilibre de ses finances, même si cela doit se faire au prix d'entorses de plus en plus sévères à la philosophie d'ouverture qui sied traditionnellement au logiciel libre.
Par exemple, leur programme d'installation graphique, Anaconda, est développé sous CVS mais celui-ci n'est pas public : on ne peut obtenir les sources que dans Rawhide (leur distrib instable) et celles-ci ne sont pas mises à jour sur une base régulière. Plus grave, au moment de lancer l'infrastructure "up2date", on se souvient que Red Hat avait décidé de ne pas publier le programme serveur nécessaire (d'où par exemple la naissance du projet Current qui propose un serveur up2date libre).
Les limites de la conciliation entre le libre et le commercial chez un éditeur logiciel ?
redhat.com (605 hits)
l'article sur news.com (478 hits)
current, un serveur libre pour up2date (533 hits)
annonce de la beta (413 hits)
télécharger la beta (489 hits)
> Lire la dépêche (143 commentaires, moyenne: 2,3).
RedHat, ça SuSE
elle était facile, mais c'est le premier truc qui me vient à l'esprit...
-
[^]Re: RedHat, ça SuSE
Posté par Pierre Jarillon (page perso, ) le 28/02/2002 à 02:09. (lien). Évalué à 11.Elle était facile, mais elle est bonne.
Corel : exit
Caldera : pas clean
SuSE et RedHat à la dérive...
Il nous reste Mandrake et Debian. Joli duo que je trouve très complémentaire.
Pourvu que cette dualité persiste très, très longtemps...-
[^]Re: RedHat, ça SuSE
Posté par Boa Treize (page perso, ) le 28/02/2002 à 04:49. (lien). Évalué à 14.Mandrake, Debian et Slackware. Non mais...
-1 bien sûr, ça commence à troller-
[^]et Conectiva...
Posté par richard bonichon (page perso, ) le 28/02/2002 à 07:37. (lien). Évalué à 4.que je n'utilise pas (mais à laquelle participe l'actuel mainteneur des noyaux 2.4 Marcelo Tosatti) et plein d'autres que j'oublie et qui permettent d'avoir le choix...un avantage du libre :-)
(De toutes façons, jamais utilisé du Chapeau Rouge moi)-
[+] [^]Re: et Conectiva...
Posté par Benjamin François (page perso, ) le 28/02/2002 à 12:15. (lien). Évalué à -1.Marcello Tosatti, il ferait mieux de ne s'occuper *que* de la branche 2.4 du kernel. Parce que je voudrais pas dire, mais ça fait désordre, pour une branche stable.
Quand à Red Hat, ils ont Alan Cox. C'est quand même pas la même catégorie.-
[^]Re: et Conectiva...
Posté par matiasf () le 28/02/2002 à 12:29. (lien). Évalué à 8.Tu te prends prend pour de la merde toi.
1- il donne des ordres a Marcello Tosatti.
2- il porte un jugement sur des developpeurs de haut niveau en estimant que Marcello n'est pas dans la meme categorie qu'Alan alors qu'il a ete designe par Linus (en consertation avec Cox, etc...).
Chapeau...
Tu devrais maintenir ta propre branche 2.4 si t'es si fort.-
[+] [^]Re: et Conectiva...
Posté par Benjamin François (page perso, ) le 28/02/2002 à 17:17. (lien). Évalué à -4.C'est bieeeeeeeeeen, il est mignon.
1) Tu as vu où que je donnais des ordres à Tosatti ? C'était une constatation, et une bête remarque.
2) Et donc, selon toi, si on est pas aussi bourrin en prog que le monsieur il est strictement interdit de considèrer que les kernels 2.4.11 et autres 2.4.15 sont des trucs qui n'ont rien à foutre dans une branche stable ? Bieeeen. J'en déduis donc que si on est pas réalisateur de films on a pas le droit de trouver "Les visiteurs en Amérique" mauvais. Que si on est pas chanteur on a pas le droit de dire que "L5" et "Star Academy", c'est de la daube. Bravoooooo.
Et le pire, c'est qu'il y a eu des abrutis pour voter + à son commentaire. Mon Dieu ®©(tm)-
[^]Re: et Conectiva...
Posté par matiasf () le 28/02/2002 à 18:06. (lien). Évalué à 4.> il est mignon.
Merci.
> 1) Tu as vu où que je donnais des ordres à Tosatti ? C'était une constatation
D'accord mais comment tu peux dire "il ferait mieux de ne s'occuper *que* de la branche 2.4".
- Tu connais son emploi du temps ?
- Tu as remarqué que dans les mailing-list kernel des gens se plaignent qu'il ne fesait pas son boulot correctement ?
- Tu croix qu'il a un salaire énorme pour s'occuper de la branche stable ?
Ben non, il fait çà gratuitement (ou presque) pour "la beauté du geste" et le bien de la "communauté". J'espère que tu comprends que je trouve le "il ferait mieux de ..." un peu hard.
> et une bête remarque.
Si c'est de l'humour/dérision alors je l'ai mal interprété.
> J'en déduis donc que si on est pas réalisateur de films on a pas le droit de trouver "Les visiteurs en Amérique" mauvais.
T'as raison et t'as tord car il y a une différence ENORME.
"Les visiteurs en Amérique" tu l'as vu et tu l'as pas aimé. Par contre, les patchs réalisés par Marcelo je ne les ai pas lu. Au mieux je peux apprécier les noms des variables, l'indentation, etc... Mais dire que j'aime ou que j'aime pas, je ne peut pas. Et à forciori sont travail et la pertinence de ces chois.
"Les visiteurs en Amérique" est pour un publique large (dont toi et moi) et ne demande pas de compétences particuliaires. Il est fait pour "divertir". Pour l'apprecier, il fait appèle à notre subjectif. J'aime ou je n'aime pas.
Et remarque qu'il y a certain film que je trouve très bien réalisé que je n'aime pas ...
Si on prend un documentaire scientifique sur la logique flou et bien je ne donnerai pas mon avis (surtout qu'il y a de forte chance que je m'endorme...).
-
[^]Re: et Conectiva...
Posté par Sylvain Rampacek (Jabber id, page perso, ) le 28/02/2002 à 18:18. (lien). Évalué à 4.Heu, je voudrais pas jeter le trouble, mais au moment du 2.4.11 et 2.4.15, ce n'était pas Marcello Tosatti qui maintenait cette branche...
Il a prit la main au moment du fork vers le 2.5... (donc 2.4.15+)...
-
-
[^]Re: et Conectiva...
Posté par Gaël Le Mignot (page perso, ) le 01/03/2002 à 08:49. (lien). Évalué à 0.Euh, j'aimerais bien t'y voir à maintenir une branche du noyau Linux. Tu crois que c'est facile ? Tu as une petite idée de la masse de boulot que ça représente ? Alors avant de porter un jugement sur Marcelo Tosatti, essaie de te renseigner.
Marcelo s'occupe du noyau 2.4 depuis la sortie du 2.4.15, il a donc releasé le 2.4.16, 2.4.17 et 2.4.18. Il a commis une bourde récemment en oubliant un "morceau" du 2.4.18-rc4, mais les erreurs ça arrive à tout le monde non ? Alors évite de critiquer une personne qui fait un boulot immense juste parce qu'un jour il a fait une petite bétise.
-
-
-
-
[^]Re: RedHat, ça SuSE
Posté par David Pradier (page perso, ) le 28/02/2002 à 13:23. (lien). Évalué à 2.Et Sorcerer, que j'aime de plus en plus (en dual boot avec une mandrake encore pour l'instant)
-
-
[^]Re: RedHat, ça SuSE
Posté par Rossel Olivier () le 28/02/2002 à 09:09. (lien). Évalué à 2.Je reste quand meme persuade que Mandrake doit beaucoup a Red Hat, meme actuellement.
Je ne sais pas comment la situation evoluerait si Red Hat abandonnait tout simplement l'idee de laisser libre le format .rpm ou leurs outils de detection du materiel ou les integrations de drivers proprietaires.-
[^]Re: RedHat, ça SuSE
Posté par Ano () le 28/02/2002 à 09:57. (lien). Évalué à 9.Je ne sais pas comment la situation evoluerait si Red Hat abandonnait tout simplement l'idee de laisser libre le format .rpm ou leurs outils de detection du materiel ou les integrations de drivers proprietaires.
Ben comme c'est sorti sous GPL, les versions actuelles resteraient libres quoi qu'il arrive. Ça ferait un fork auquel RH n'a aucun interêt puisque la majorité des distro utilisent ce format. Ils passeraient de chef de file de la majorité à tous seuls. IBM a déjà essayé avec le bus MCA, cette tactique ne vaut rien. Les outils de detection du materiel, même si sndconfig (par exemple) est encore dans la mdk, il ne sert plus guère...
Quand à l'integration des drivers propriétaires, ça fait longtemps que chaqun fais sa cuisine dans son coin.
En temps qu'utilisateur MDK, l'avenir de RH m'est indifférent. A un détail près...
Maintenant dans la tribune faut dire "La RedHat, ça SuSE, c'est pas libre" ;o)-
[^]Dans mon post précédent, rayez la dernière ligne...
Posté par Ano () le 28/02/2002 à 10:34. (lien). Évalué à 1.Comme un con je me suis laissé emporte par le troll ambiant. Et pBpG a repositionné les choses clairement....
Bref, la prochaine fois, je lis ATTENTIVEMENT la news et COMPLÊTEMENT l'enfilade avant de poster des conneries...
Mea culpa... Et -1 pour le compte.
-
-
-
[^]Re: RedHat, ça SuSE
Posté par Philippe SOHM (page perso, ) le 28/02/2002 à 10:18. (lien). Évalué à 7.N'oublions pas FreeBSD
Les systèmes BSD sont tout de même non négligeables en ce qui concerne les serveurs web et dns (microsoft l'utilise d'ailleurs pour hotmail :p)
-
-
[^]Re: RedHat, ça SuSE
Posté par lolopino () le 01/03/2002 à 07:33. (lien). Évalué à 1.Les distrib. RH, Suse, etc. c'est bien mais, se construire son propre système, c'est mieux!
Passez sous LFS ou BYO : vous comprendrez bien des subtilités de Linux, vous aurez un système performant et vous ne dépendrez plus que de la vraie communauté libre.
Vive les src.tar.gz !
[+] Debian Rulez
Une raison de plu de passer à Debian pour les soltions pros.
-
[^]Solutions pro
Posté par Anonyme () le 28/02/2002 à 02:15. (lien). Évalué à 16.En parlant de solutions pro, y a un DBA qui m'a dit aujourd'hui un truc que j'ignorais : depuis que RedHat a lancé son truc avec PostgreSQL, Oracle ne supporte plus sa base de données sur RedHat, mais uniquement sur... accrochez-vous... SuSE :((((
Note: J'avais tenté une install sur une Debian il y a un peu plus d'un an, ça marchait pas du tout :(-
[^]la bonne blague
Posté par B. franck () le 28/02/2002 à 07:51. (lien). Évalué à 11.Le problème d'Oracle c'est que redh*t ou plus précisément PostgreSQL, met en exergue
la nullité du sgbd Oracle.
Sa lourdeur, son coût (achat+long terme+serveur hébergeur)
font que pgsql est THE sgbd libre du siècle.
(pour les "pro" mysql, pardonnez moi mais je peux plus encaisser le xbase)
Oracle haha la bonne blague, ça te couche un hppa rien qu'en démarrant.-
[+] [^]La bonne blague : Oracle moins bien que PostgresSQL !
Posté par Stephane JUTIN () le 28/02/2002 à 10:48. (lien). Évalué à -2.Tu sais je pense que pouvoir comparer deux SGDB, il faut déja pas mal d'expérience en SQL (seul moyen pour découvir les limites respectives des deux outils).
<MODE IRONIQUE>
J'en déduis donc d'après ton assurance et ton ton catégorique (nullité du SGDB Oracle), que tu pratique le SQL depuis 4-5 ans, que tu as déja utilisé les BLOBS, des tables de plus de 2 millions de lignes, et que tu fais régulièrement des import/exports.
C'est étonnant d'ailleurs, moi qui aurais cru que LinuxFr n'était fréquenté que par des étudiants en première année d'info, qui venait de découvrir le SELECT il y a deux semaines ...
</MODE IRONIQUE>
Perso, je ne suis pas un expert et non plus (j'étais encore étudiant en Septembre 2001 alors je me mets dans le même sac), mais s'il y a pas mal à exposer ses connaissances même si elles sont limitées, ça m'énerve toujours de voir des "grandes gueules" (désolé pour le terme, mais c'est un peu ça quand même) prendre des positions tranchées sur des sujets qu'ils maitrisent mal.-
[^]Oracle moins bien que PostgresSQL (suite)
Posté par Stephane JUTIN () le 28/02/2002 à 11:34. (lien). Évalué à 4.Après avoir critiqué ton message pour cause de manque d'argumentation, je m'y colle et fait le récit de mon expérience certe limitée mais réelle d'Oracle :
1)Les blobs
J'ai fait mon stage dans une boite vraiment pro-linux (tout les développeurs travaillaient avec), au début ils utilisaient un SGDB libre (Postgres je crois).
Un jour, ils ont eu besoin d'utiliser des BLOBS dans une de leur table et ce jour là, ils ont été obligés de migrer vers Oracle.
2)Les tables de plus de 1 million de rangées
Au boulot, j'ai une appli qui fait une réquête (sur Oracle) avec jointure entre deux tables , l'une faisant 1,5 millions de lignes, l'autre plus petite 150000 lignes.
Comme la requète est compliqué, on ne peut pas utiliser l'index, il faut donc parcourir toute la table, ça prends plus de 4 minutes.
Certes c'est long mais faut voir le boulot qu'on lui demande à Oracle, et ça prouve qu'Oracle est VRAIMENT capable de gérer des tables de cette taille et en plus pour toutes les autres requêtes qui peuvent utiliser un index, ça reste rapide.
Je ne suis pas convaincu que Postgress ou MySQL possède un tel niveau de "scalabilité", et j'attends le jour ou LinuxFr aura 150.000 utilisateurs et 1,6 millions de commentaires à gérer pour voir si les SGDB libres sont capable de tenir aussi bien la charge.
3)Les imports/exports
Pour certaines personnes c'est vital, chez nous en fait plusieurs par semaine...
4)Oracle est lourd est lent par rappor à Postgres
Ouais, mais si comme si tu comparais le noyau Linux avec ses 3 millions de lignes à Minix.
Evidemment, c'est plus gros donc ça prends plus de mémoire et ça met un peu plus de temps à démarrer, mais ça fait vachement plus de truc aussi !
Conclusion
Donc en terme de fonctionalité Oracle explose les SGDB libres, même si pour beaucoup d'utilisateurs un SGDB libre suffit à couvrir leur besoins.-
[^]Re: Oracle moins bien que PostgresSQL (suite)
Posté par Gloo () le 28/02/2002 à 12:23. (lien). Évalué à 7.Je ne prends pas la defense du gars au dessus cependant:
1) le fait d'utiliser des blobs n'implique pas de passser à oracle. Pour le cas de postgresql, c'est que l'import/export est un peu plus embetant a gerer. Il fut un temps ou la taille des LO etaient limitées ce n'est plus le cas. Perso, je trouve que mettre des LO dans une BDD est une mauvaise chose... Mais bon... c'est pratique.
2) si tu veux faire un test de comparaison, tu peux faire un export d'oracle et un import dans postgresql de ce dont tu parles. Il faut savoir que la requette utilisée pour oracle devra peut etre reecrite pour postgresql. En effet chacun des optimizers (celui d'oracle et celui de postgresql) ont leurs caprices. Il est probable que la requete d'oracle a deja été reecrite.
Pour le nombre de tuples, postgresql n'a pas a rougir. Tu peux consulter http://www.pgsql.com/user_gallery(...) ou encore les archives de postgresql (par ex: fevrier "Who's Using Postgres") et enfin geocrawler est une application live. 110 milions de pages vues par mois.
3) import/export. C'est faisable sous postgres, dans les limites indiquées plus bas. Je ne vais pas me repeter.
4) lourdeur. Je suis d'accord.
Note: une requete n'a pas besoin d'etre compliquée pour nécessité un accès sequentiel ( sans index ). D'ailleurs ce sont les requetes les plus simples qui n'utilisent pas d'index.-
[+] [^]Re: Oracle moins bien que PostgresSQL (suite)
Posté par Stephane JUTIN () le 28/02/2002 à 13:32. (lien). Évalué à -2.1)Ah bon !
Enfin, ce qui m'étonne quand même, c'est que si Oracle ne fait pas mieux que Postgres (au niveau du support des Blobs) alors ça ne m'explique pas pourquoi ils ne sont pas revenus en arrière juste après leur migration.
D'autant plus que c'était vraiment une boite pro-opensource ... en fait je crois qu'Oracle était la seule appli non libre utilisée dans toute la boite.
Même si la dernière version en date de Postgres (sortie depuis) commencer à supporter correctement les blobs, ça doit faire un sacré bail qu'Oracle fait la même chose.
Au passage, tu sais si Postgres gère les "ALTER TABLE DROP COLUMN", sous Oracle il faut attendre la 8.1 pour que ça marche. C'est chiant d'avoir à
copier une table juste pour virer une colonne.
2) tu sais pour faire un import/export entre deux version d'Oracle différentes sur une base de 75 Mo c'est dèja long à cause de la conversion, alors pour une base de cette taille, surtout si tu dis que Postgress rame au niveau des import, il faudrait peut-être un week-end.
D'ailleurs, au niveau hardware ça n'aurait pas de sens d'héberger une telle base sur un PC sous Redhat Linux avec disque IDE, je doutes que les perfs en IO soutiennent la comparaison avec une SUN, son bus à commutation de paquet et les disques SCSI qui vont avec.
En plus, tu n'a pas l'air de savoir que le SQL n'est pas vraiment portable (un peu comme pour les compilo C, va compiler le kernel sous Visual) : tout les SGDB ont des parties de la norme qu'ils n'implémentent pas ou mal et c'est rarement les mêmes.
3) Mais est-ce que c'est vraiment viable en pratique, pour des gens qui font des dumps souvent ?
Si le fichier est beaucoup plus gros (car il contient des requètes en + des données) et si la restauration est significativement plus longue, ça peut être prohibitif à l'usage
4) Enfin, je pense aussi que pour les petits projets, Postgres (ou MySQL) doit largement suffire. D'ailleurs, on trouve même pas mal de base sous Access dans les PME (hé oui il y a un moteur SQL).
Notes :
1) Optimisation spécifique Oracle : tout SGDB qui se respecte à un optimiseur intégré, donc l'ordre dans lequel tu écris les clauses ne devrait pas influencer les perfs.
Par contre, on peut utiliser des "binding variable" pour qu'il puisse cacher la version compilée (et réordonnée) de la requète.
2) Index : Si la table est petite, ça va plus vite en balayant la table.
Par requète "compliquée", j'entendait au niveau des conditions de jointure : si elle porte sur une seule colonne c'est facile de l'indexer, par contre si il y en a beaucoup, créer un index sur des colonnes multiples (et nombreuses de surcroit) peut ne pas servir à grand chose (enfin c'est ce que j'ai compris).
3) "Les blobs c'est sale" : c'est vrai mais quand tu en as besoin, tu peux pas faire autrement-
[^]Re: Oracle moins bien que PostgresSQL (suite)
Posté par Gloo () le 28/02/2002 à 14:27. (lien). Évalué à 6."pourquoi ils ne sont pas revenus en arrière juste après leur migration"
Demande leurs.
"ca doit faire un sacré bail qu'Oracle fait la même chose"</i>"
Et alors ? Oracle8i max 4gigas. Postgres illimité.
"ALTER TABLE DROP COLUMN"
non. Mais j'imagine que tu me poses cette question en connaissant deja la reponse.
C'est pas sorcier non plus. On fait comme faisait les admins oracles.
Par contre postgresql permet de renomer une colonne ce qu'oracle 8i ne permet pas, si tu veux rentrer dans ce genre de troll idot...
"surtout si tu dis que Postgres rame au niveau des imports"
Jamais dis ça. Relis.
"[Hardware]"
Postgresql est compilable sous sun... renseigne toi.
"tu n'as pas l'air de savoir que SQL n'est pas vraiment portable"
Là tu commences à devenir penible. ( Ouverure parenthèse : Contrairement à toi, je ne sors pas tout juste de l'école. Fermeture parenthèse ).
Bref SQL a une _syntaxe_, si il y a des petites differences entre les implementations c'est à coup de grep que ca se règle.
Je te proposais simplement de faire le test par toi même. Ce qui est possible.
"Enfin, je pense aussi que pour les petits projets, Postgres [...]doit largement suffire"
Tu penses tout seul là. Postgresql est DEJA utiliser pour de gros projets.
1) Va donner tes lumières au dev d'oracle et de postgres.
2) En fait pour les index B-Tree c'est une histoire de sous ensemble par la gauche. style tu as un index sur [A,B,C] si ta requete utilise soit B soit B,C soit C ton index ne sert à rien.
Je ne dis pas contrairement au gars au dessus que postgresql explose oracle. Je dis que beaucoup de gens utilisent oracle parceque mal informés.
Suis le conseil que tu lui donnes, et ne prend pas des grands airs si tu ne maitrises pas le sujet.-
[^]Re: Oracle moins bien que PostgresSQL (suite)
Posté par Stephane JUTIN () le 28/02/2002 à 15:51. (lien). Évalué à 0.Demande leurs.
Tu sais la boite a coulé depuis 6 mois, donc c'est plus vraiment possible.
Mais si tu réfléchit un peu, il n'y a que deux solutions possibles : soit ils sont subitement devenus fous (la license Oracle c'est cher, et ils ont eu le temps de tester la BD avant de payer) ou ça marchait mieux qu'avant. Personellement, je pense que la deuxième solution est plus probable, libre à toi de te raccrocher à la première.
Et là encore, ce n'était pas un problème d'ignorance vis à vis du libre, tout les gens de la boite était des "pro-linux", sauf un gars qui préferait développer sous FreeBSD (pour te situer un peu le profil, il contribuait au système du fichier du noyau pendant son temps libre).
Je me souviens aussi, qu'une fois ils ont découvert (et corrigé eux-même) un petit bug du noyau en prod.
Oracle8i max 4gigas
Tu parle de la taille des blobs je suppose, mais est-ce que c'est vraiment utilisé en pratique par des "vrais utilisateurs dans le monde réel" des blobs de plus de 4 Go ?
Dans l'exemple en question c'était pour stocker des pages Webs donc la limite des 4 Go n'était pas un problème pratique.
Hardware .. Postgres compilable sur Unix proprio
bien sûr, je sais bien qu'on a les sources.
"ALTER TABLE DROP COLUMN" pas supporté ... tu me poses cette question en connaissant deja la reponse
tu t'énerve tout seul, là !
Non je ne connaissais par la réponse car je n'ai jamais utilisé Postgres jusqu'à maintenant (mais je compte le faire un jour).
Par contre j'ai été confronté au problème en pratique avec Oracle 8.0 (c'est ok avec 8.1), et quand tu dois recopier une liste de 59 colonnes pour supprimer la 60ème c'est pas pratique.
Et pour le renommage de colonne, ce n'est pas un "troll" comme tu dis - ce mot commence à se vider de son sens à force de l'employer à tort et à travers - c'est vraiment utile lorsque tu en as besoin.
Postgresql est DEJA utiliser pour de gros projets
Je vais te surprendre : Oracle aussi
1) Va donner tes lumières au dev d'oracle et de postgres.
Tu t'énerve tout seul !
Tout SGDB comprends un optimiseur qui doit ecrire un plan d'éxécution pour ta requète.
N'étant pas DBA, je ne connais pas son fonctionnement interne, mais il me paraissait vraissemblable que celui-ci prenne en compte la taille des tables pour ordonner les clauses WHERE.
Une rapide recherche sur le net (http://wwwsi.supelec.fr/~yb/poly_bd/node23.html(...)) semble d'ailleurs le confimer.
Suis le conseil que tu lui donnes, et ne prend pas des grands airs si tu ne maitrises pas le sujet.
C'est toi qui t'excite tout seul ici.
tu n'as pas l'air de savoir que SQL n'est pas vraiment portable ... c'est à coup de grep que ca se règle.
Sérieusement, tu as déjà porté une grosse BD avec plus de 100 tables "à coup de grep" en 5 minutes ou bien tu es juste en train de faire travailler ton imagination ?
Et les requêtes qui font appel à des fonctions Oracle genre "decode()", et les triggers en PL/SQL à convertir en P/SQL, les problème lié au partie de la norme SQL non supportée par l'un ou l'autre, le portage du code C des OCI vers la libpostgres, les types de données des colonnes qui changent, tout ça pour toi ça se "règle à coup de grep" en un quart d'heure... je suis sceptique.-
[^]Re: Oracle moins bien que PostgresSQL (suite)
Posté par Gloo () le 28/02/2002 à 16:46. (lien). Évalué à 4."Tu sais la boite a coulé depuis 6 mois"
Sans blague ? en utilisant oracle ?
"donc c'est plus vraiment possible"
et les employés se sont tous suicidés ?
(mauvaise) blague à part, certainement il y avait une raison d'utiliser oracle, mais une fois le projet a maturité, la licence payée ( la boite coulée ? ) pourquoi revenir en arrière ?
"je n'ai jamais utilisé Postgres jusqu'à maintenant (mais je compte le faire un jour)"
C'est l'occasion.
"tu as déjà porté une grosse BD avec plus de 100 tables à coup de grep"""
Evidemment Non. Tu parlais de 2 tables à ton boulot. 1,5 millions et 150000 milles lignes et d'une requete: excuse moi donc si je n'imaginais pas que ta requete etait un truc super compliqué avec des procedures stockées dans tous les coins sur des types à la mord moi le noeud.
De toute façon rien que l'export ne durera pas 5 minutes Idem pour l'import, idem pour l'install de postgresql, idem pour le tuning si necessaire.
Il s'agit de prendre le temps de faire un test. J'invite les gens à prendre le temps de generer leurs données et à a faire ce genre de test... Du SQL92, ca s'importe n'importe où...
"Une rapide recherche sur le net"
Il y a des statistiques sur les tables, c'est pas par hasard...
"je suis sceptique"
Tu sais, utiliser des types à la con, des blobs alors que pas necessaires, ne pas utiliser du SQL92, et bien... ca coule une boite...-
[^]Re: Oracle moins bien que PostgresSQL (suite)
-
[^]Re: Oracle moins bien que PostgresSQL (suite)
Posté par Stephane JUTIN () le 01/03/2002 à 11:15. (lien). Évalué à 1."tu sais la boite a coulé depuis 6 mois... sans blague ? en utilisant oracle ?"
Vous autre linuxien vous avez de bon cotés mais dès fois vous êtes vraiment têtu (pire que moi :) )
C'est vrai c'est rigolo (au second degrès) le coup de la boite qui a coulé après avoir acheté une license Oracle ... mais enfin faut vraiment être de mauvaise foi pour sortir un argument aussi ridicule pour défendre Postgres. Une license Oracle c'est jamais qu'un grain de sable dans le budget d'une boite (sauf si elle est miniscule).
Enfin, pour info, j'ai un peu simplifié la vérité, l'exemple dont je te parle est donc un mélange de plusieurs boites ... et toutes les boites dans laquelles j'ai travaillé existent toujours.
"Tu parlais de 2 tables à ton boulot. 1,5 millions et 150000 milles lignes et d'une requete"
Mais enfin ,tu aurais dû te douter que si les tables était aussi grosses c'est que c'était une grosse appli (pour info : il y en a plusieurs centaines des tables).
"Il y a des statistiques sur les tables, c'est pas par hasard..."
C'est aussi ce que je pensais mais je suis pas DBA Oracle, alors tu m'as fait douter quand tu as dis que "l'ordre des clauses" jouait (d'ailleurs si j'en crois le post plus bas, l'optimiseur avait ses faiblesses pour les vielles version d'Oracle).
je n'ai jamais utilisé Postgres jusqu'à maintenant (mais je compte le faire un jour)
j'ai oublié de te précise que ça sera seulement pour logger mes visiteurs en PHP sur ma page perso, d'ailleurs je pense que pour le PHP MySQL est peut-être plus adapté. Mais je prendrais pas le risque de migrer un serveur Oracle sur SUN Enterprise vers Postgres même si j'en avais le pouvoir.
Du SQL92, ca s'importe n'importe où...
Tu parle beaucoup, mais tu as déja écris une grosse appli métier (pas un petit site web avec 3-4 tables) comprenant des centaines de tables, des millions de ligne de code sans te heurter à un seul problème de portabilité ? Sincérement, je pense que c'est plus ton ignorance qui est en cause ici que l'imcompétence des centaines de développeurs qui ont déja été confrontés au problème.
A propos des normes comme SQL 92
En tant que débutant SQL je ne connais pas bien le niveau de support de la norme mais pour le C, écrire du C standard, ça ne suffit pas car tout les compilateurs ont des bugs et sur des gros programme le portage de code standard vers un autre compilo demande habituellement plusieurs mois de travail, il n'y a que les progs de TP d'info de 20 lignes qui compile du premier coup : j'imagine que pour SQL c'est pareil.
YAKA coder SQL 92
C'est bien gentil de jouer les donneurs de leçons, mais prenons un exemple concret d'un gros projet de plusieurs millions lignes de code: le noyau Linux.
Outre le fait que le code utilise des extensions GCC (donc qu'il n'est absolumment pas conforme au standard C), il m'est arrivé de voir (en lisant kernel traffic) que la compilation de tel noyau n'était garantie que pour telle version de gcc. Comme disait Alan Cox : "le noyau fonctionne grâce aux bugs de GCC", c'était une formule pour faire comprendre que leur code n'avait été testé qu'avec un compilo et donc que si t'en change (par exemple que t'utilise un gcc 2.95 au lieu du 2.7 )tout pète.
C'est bizarre je n'ai jamais entendu personne ici traiter les développeurs de noyau de bande d'imcompétents qui ne savent pas ce qu'est que le standard C. Et les spécialiste du "yaka respecter les standards", on les entends jamais soutenir que l'idée du siècle ça serait de passer deux mois pour virer les extensions GCC, même si après :
- ça diminue de 10 % les perfs du noyau
- le noyau n'est pas plus portable qu'avant vu qu'il n'y a pas une chance sur 10000 que ça compile du premier coup sur un autre compilo que celui utilisé par Linus depuis des années pour tester son code
Tu sais, utiliser des types à la con, des blobs alors que pas necessaires, ne pas utiliser du SQL92, et bien... ca coule une boite..
D'abord la boite n'a pas coulé, ensuite comme expliqué plus haut si tu disais vrai le noyau linux aurait coulé depuis longtemps.
Prends les fonctions de manipulation de date (genre conversion date->entier long, différence entre date), c'est pas absolumment pas portable comme truc, mais si tu en as besoin tu fait comment ?
Et les decode(), ça améliore les perfs, ça rends le code plus lisible : les extensions du C de GCC pour le noyau ne font rien de plus et ça suffit pour qu'ils s'en servent.
blobs alors que pas necessaires
Tu ne connais pas le contexte donc je vois par ce permet d'affirmer qu'ils étaient inutile.-
[^]Re: Oracle moins bien que PostgresSQL (suite)
Posté par Gloo () le 01/03/2002 à 16:33. (lien). Évalué à 2.Les gens qui reliront le thread et les commentaires plus bas jugeront.
2 tables qui passent à plusieurs centaines, une boite qui coule, mais en fait qui n'a pas coulée...
Tu sais, moi, je n'ai rien à prouver. Je connais visiblement Oracle mieux que toi, sans parler de postgresql.
L'application avec une centaine de tables tu l'as peut etre vu, mais tu etais spectateur. Ce genre d'application, s'il n'y a pas eu d'analyse, de conception, de schemas, de documentation et bien, ca n'aboutit pas. ( cf ton post plus bas )
Tu viens grossir le rang des arrogants à qui ont a mis (où va mettre) entre les pates un oracle, un reseau giga ethernet, et des sun hors de prix et qui pensent que c'est la seule solution technique serieuse, sans jamais se remettre en question. La plupart des "ignorants" qui ont trimés sur de l'ip dynamique, avec du 28.8, et leur pauvre pentium en se demandant quelles techniques utiliser pour que le portage se fasse (presque) sans douleur, eux, en savent beaucoup plus que toi et on l'esprit bien plus ouvert.-
[^]Re: Oracle moins bien que PostgresSQL (suite)
Posté par Stephane JUTIN () le 04/03/2002 à 11:04. (lien). Évalué à 1.une boite qui coule, mais en fait qui n'a pas coulée...
Tu sais j'ai toujours peur qu'on me repproche de dévoiler des infos sur les boites dans lesquelles j'ai travaillé, c'est pourquoi j'essaye de m'abstenir de donner des détails voir des fois j'altère un peu la vérité ... enfin la je pense être suffisament flou pour que cela ne soit pas
<i>2 tables qui passent à plusieurs centaines<i>
He bien oui, c'est comme tu reporte un bug pour gcc (ça m'est arrivé d'ailleurs), ton code peut faire 8000 lignes, tu ne parle que des 5 lignes qui font planter le compilo !
Mais comme je te l'ai déja dit, comme les tables étaient bien remplies tu aurait pu te douter que c'était un grosse appli.
L'application avec une centaine de tables tu l'as peut etre vu, mais tu etais spectateur
Je ne dis pas le contraire, mais c'est déja mieux d'être spectateur que rien du tout car ça te permet de relativiser tes propres besoins.
Tu viens grossir le rang des arrogants à qui ont a mis (où va mettre) entre les pates un oracle, un reseau giga ethernet, et des sun hors de prix et qui pensent que c'est la seule solution technique serieuse
La encore tu généralise à d'autres tes contraintes à toi : les etudiants (ou les particuliers, je ne dis pas ça pour toi) ont très peu d'argent et enormément de temps, pour d'autres personnes c'est parfois l'inverse.
Pour certaines personnne, un mois de retard sur le projet ou la difficulté de recruter des DBA compétents sur le logiciel, c'est bien plus embétant que de payer 50KF pour une license oracle.
Parenthèse : Le réseau Gigabits ne sert pas à grand chose pour faire des requètes SQL, c'est plus sensible à la latence qu'au débit.
-
-
-
-
-
-
[^]Re: Oracle moins bien que PostgresSQL (suite)
Posté par PLuG () le 28/02/2002 à 14:43. (lien). Évalué à 5.<aparté>
Tiens, pour une fois frecilia je suis plutot de ton avis !
</aparté>
par contre, dans tes Notes, je voudrais causer du <1>:
l'optimiseur Oracle (comme ses concurrents) a ses préferences. Du coup un type habitué a Oracle sait écrire les requetes dans le "bon ordre" pour que Oracle soit performant. C'est de moins en moins vrai (surtout depuis la v8) mais avant je te promet que changer l'ordre d'une clause pouvait avoir des répercussions assez fantastiques.
et puis du <2>: l'index a un cout lors des ecritures. Avoir des index sur plusieurs colonnes de plusieurs tables c'est cher, surtout si c'est pour optimiser une requete qui ne sert qu'une seule fois et encore pour un batch (j'exagere). C'est le probleme de toute optimisation: est-elle necessaire ?
enfin a propos du "drop column", ca me parait assez bidouille ton truc. Normalement on prevoit le schema de la base avant de la créer. Ensuite on developpe sur un serveur de ... developpement. Quand je m'y interessais, on avait des scritps pour re-creéer la base avec des données bidon que l'on pouvait relancer a volonté puisque pas en prod (je faisais des bench de requetes en oracle 8.0.5). Bref le "drop column" ca doit etre bien bas dans la liste des developpements necessaires sur postgresql, ce qu'il faut améliorer c'est plutot l'import/export et la réplication en live
(a mon avis mais je le partage avec vous :-))-
[^]Re: Oracle moins bien que PostgresSQL (suite)
Posté par Stephane JUTIN () le 28/02/2002 à 16:05. (lien). Évalué à 2.Normalement on prevoit le schema de la base avant de la créer.
Normalement, on commente le code
Normalement, on documente les API
Normalement, on fait une conception (par exemple UML) avant de coder
Normalement, le code devrait être propre, portable, générique
Normalement, une appli ne devrait jamais planter quoi que l'utilisateur fasse
...
-
-
-
-
[^]comparaisons
Posté par B. franck () le 28/02/2002 à 17:45. (lien). Évalué à 5.Bon, j'ai beaucoup hésité à répondre à une telle débauche de mots...
je vais faire court:
1-les blobs: plus un problème depuis.
2- Les tables de plus de 1 million de rangées
euh vous avez mis le moniteur dans le mauvais sens ? :\
trève de plaisanterie, je ne comprends pas l'intérêt
d'une telle table et ne connais pas les limitations de pgsql
(65000 ?)
(de plus je comprends pas comment on peux en arriver là?)
3- pour les imports, no problemo, au choix:
C / C++ / delphi / perl / bash ;) etc...
je ne comprends encore pas où est la difficulté que tu as rencontré
avec les imports (pas de clickodrôme?)
4- lourdeur: et bein ouais! un oracle qui démarre c'est une horreur
même sur un hp9000 bourré de processeurs et de ram!
Pour comparer les fonctionnalités souvent inutiles dans la major partie des cas,
je ne suis pas trop à même de le faire ne connaissant pas à fond ces fameuses fonctionnalités
chères à Oracle,
cependant, je puis dire que pgsql fait ce qu'il faut et bien et que db2 fait mieux
peut-être, mais je m'en tape, j'ai réussi à imposer un produit qui ne va pas me demander
6 mois d'installation (avec Oracle appli), 3 semaines de formation, une tonne de livres
tous souvent plus inutiles que les autres!, ou des patches à appliquer toutes les 3 semaines
pour colmater les innombrables problèmes qui sont apparus lorsque certaines concessions
ont été faites pour fournir une nouvelle version dans les temps...
Le principal grief que j'ai et garderais à l'encontre d'oracle est
que c'est peut-être le plus répandu, le plus gros, le plus cher (?) à l'achat
et à l'administration (une horreur)
mais, répandu ne veut pas dire fiable et efficace tout le temps
et encore moins meilleur.
Nous avons testé postgresql 7.1.3 pendant 2 mois à coup de tables
à +10millions d'enregistrements avec multiples connexions
concurrentes abusives, sous linux et Freebsd sur une machine
de base en IDE, peu de ram et mono-processeur de milieu de gamme
avant de faire ce choix:
Postgresql est un SGBDR-Objet qui tient la route
et nous a permis de mettre plus d'argent dans le matos
plutôt que dans les licenses.
Le serveur a encore plus de "patate", c'est très appréciable.
(conclusion secondaire: freebsd "dépote" bien une fois optimisé...)
En conclusion, ce qu'oracle apporte de plus que PostgreSQL
ne justifie pas les lourdeurs pécunières et administratives
que celà engendre.
Avec pgsql, j'ai plus de choix qui n'engendre pas de surcoût:
le matériel/l'atchitecture, l'OS (facilement et quand je veux),
la mise à jour ou non (sans perdre le support pour cause de patch non appliqué),
et les interfaces, bien sûr.
(à un problème, une multitude de solutions).
libre enfin!
ps: Y a-t'il quelqu'un qui travaille chez oracle dans ce "thread" ?
pps: il doit y avoir une malédiction sur oracle, mon ancienne boîte a rendu l'âme elle aussi, juste après avoir fait ce choix surdimensionné... ;)
ppps: enfin, non il n'y a pas que des étudiants qui consultent ce site...-
[^]Re: comparaisons
-
-
[^]Re: Oracle moins bien que PostgresSQL (suite)
Posté par jeanmarc () le 28/02/2002 à 18:10. (lien). Évalué à 5.Frecilla, tu dis à l'autre de fermer sa grande gueule parce qu'il parle de ce qu'il ne connais pas alors que tu fais une comparaison entre oracle et postgres sans connaitre postgres.
Tu le traites d'étudiant de 1ére année neuneu alors que tu ne travailles pas depuis plus de 6 mois!
Bel exemple de mauvaise foie!
-
-
-
[^]Re: la bonne blague
Posté par zap2076 () le 28/02/2002 à 13:01. (lien). Évalué à 2.Oracle est tellement mauvais que les lecteurs de Linux Journal l'ont élu comme meilleur RDBMS ...
http://www.linuxjournal.com/article.php?sid=5599(...)
C'est tout.-
[^]linux journal award 2000
Posté par B. franck () le 28/02/2002 à 18:22. (lien). Évalué à 3.The PostgreSQL Global Development Group is proud to announce
that we have received the 2000 Linux Journal Editor's Choice Award
for Best Database!
http://postgresql.org/images/database.jpg(...)
Et c'était l'année dernière... avant la v 7.2 ;)
-
-
[^]Re: Oracle : solide mais archaïque
Posté par Pierre Jarillon (page perso, ) le 28/02/2002 à 19:46. (lien). Évalué à 7.J'utilise Oracle à titre professionnel depuis plus de 10 ans. Je reconnais que c'est béton. Pas un problème en 10 ans.
Toutefois, j'ai quelques reproches à faire à ce SGBD : il a été conçu à une époque où les systèmes de fichiers étaient encore très sommaires. Rien à voir avec Reiserfs !
En effet, il est nécessaire de réserver la taille des fichiers et la taille de leurs extensions. Quand il y a trop "d'extends", les performances diminuent et l'administrateur du SGBD doit intervenir pour recréer la base de données avec de nouveaux espaces. Un travail lourd mais complètement anachronique. Comme les DSI ont bien souvent de 5 à 10 ans de retard sur notre époque, ils croient que c'est un travail normal et obligatoire.
Avec un file system moderne, ces opérations souvent très lourdes sont prises en compte par le FS. La charge de travail induite par Oracle est un véritable anachronisme.
Un autre reproche : pour exporter les données d'Oracle, il faut acheter des licences complémentaires ou écrire du code. Rien de tout ça avec Postgresql qui possède avec "pg_dump" et "copy" des utilitaires remarquables. L'un est lent mais universel, l'autre est plus spartiate mais très rapide. Actuellement, si je devais recréer une nouvelle (et énorme) application, j'utiliserais Postgresql plutôt qu'Oracle, et ce n'est pas pour le prix des licences!-
[^]Oracle archaïque
-
-
-
[^]Re: Solutions pro
Posté par Gloo () le 28/02/2002 à 07:55. (lien). Évalué à 15.Oracle sur Debian marche bien depuis plus d'un an. Il y a eu l'affaire du work around de la glibc.
le patch chez oracle s'appelle glibc-2.13-stubs.tar.gz Ce patch n'est pas valable uniquement pour Debian.
Enfin, cette histoire montre qu'oracle a peur de postgresql et pour cause.
Tout ceux qui utilisent oracle et qui n'ont pas besoin:
- de la replication
- du hot bakcup
- de la distribution
- des namespaces
et ils sont nombreux, ont été mal conseillés et gaspillent beaucoup d'argent pour rien.
Postgresql aurait fait largement l'affaire.-
[^]Re: Solutions pro
Posté par MagicNinja (page perso, ) le 28/02/2002 à 08:29. (lien). Évalué à 3.Y'a pas de hot backup sur pgsql ? (j'avais cru voir quelque chose de semblable utilisant les transactions pourtant)
-
[^]Re: Solutions pro
Posté par Gloo () le 28/02/2002 à 09:00. (lien). Évalué à 6.oui et non. (en fonction de l'application) voir les limitations:
http://www.postgresql.org/idocs/index.php?backup.html(...)
et
http://www.postgresql.org/idocs/index.php?backup-file.html(...)
pg_dump te sort les instructions que tu vas rejouer lors d'une restauration. C'est beaucoup plus lourd et long qu'un fichier binaire ou tu fais un "cp" ( en gros ).
Si tu preferes, le problème c'est pas le hot backup directement, c'est la restauration.
Comme tu dois le savoir, tout le monde se fout de savoir si tu fait des bakcup, mais si tu es capable de restaurer ;)
-
-
[^]Re: Solutions pro
Posté par vrm (page perso, ) le 28/02/2002 à 08:48. (lien). Évalué à 4.je pense que pgsql supporte le backup à chaud (contrairement a mysql 3)
au fait on peux ajouter firebird.sourceforge.net (fork d'interbase)
et sapDB (jammais testé)-
[^]Re: Solutions pro
Posté par Gloo () le 28/02/2002 à 09:14. (lien). Évalué à 2."je pense que pgsql supporte le backup à chaud"
oui et non, en fonction de l'application (cf plus haut) en l'occurence le problème des Large Objects et des references circulaires.
Bref, en attendant, c'est base-down et file-system. C'est ce que fait d'ailleurs je ne sais plus quel gros site d'archive. (geocrawler ?)
Donc je dirai que postgresql supporte le hot backup quand cela deviendra "quel que soit l'application".
-
-
[^]Re: Solutions pro
Posté par philip () le 28/02/2002 à 08:59. (lien). Évalué à 2.le hot backup c'est bien mais le archive log c'est mieux ! :)
mais y a pas non plus sur postgresql (meme si c'est prévu pour plus tard)-
[+] [^]HS
Posté par MagicNinja (page perso, ) le 28/02/2002 à 09:19. (lien). Évalué à -1.Tu sembles au courant de ce qui va sortir... sais tu de quand va-t-il etre possible (si c est prevu) de retourner un curseur sur des donnes avec une procedure stockee ?
-
-
[^]Re: Solutions pro - pour infos
-
-
[^]Re: Solutions pro
-
-
[^]Re: Debian Rulez
Posté par a_jr () le 28/02/2002 à 08:37. (lien). Évalué à 10.Pour les solutions pros, tu prends non pas une distrib, mais un support technique. C'est le support qui choisit la distrib a ta place.
Pour les distribs commerciales, c'est l'editeur qui te fournit le support (redhat supporte redhat, mandrakesoft support mandrake etc: logique!). Et y'a aussi des boites qui supportent une distrib sans pour autant la faire. C'est le cas par exemple d'ibm qui supporte redhat. Et de nombreuses SSII ont aussi fait leur choix. Par exemple, ma boite, CMG, a un partenariat avec Mandrakesoft.
Quant a debian, bah y'a aussi des supporters. Le plus gros est HP, mais je ne sais pas ou ils en sont de leur support.
Le bonjour chez vous,
Yves-
[^]Re: Debian Rulez
Posté par Silence (page perso, ) le 28/02/2002 à 08:54. (lien). Évalué à 3.Bah tu peux te brosser martine... En fait c'est RedHat only (6.2 et >=7.1), pour le support interne, qui s'occupe aussi du support des 'bon' clients, donc a priori...
Normalement ya Mandrake, mais la, personne en etend parler, ou plutot si on en a juste entendu parler.
Normalement ils doivent mettre MDK en OEM, mais g encore rien vu sur nos serveur d'installation (la ou y a des pseudos images ghost que l'on plaquent sur les pcs, avant de les vendres).
Alors Debian... arf, tu as le temps de voir pousser les arbres !--
^d^c
-
[+] On vous avait prevenu
Hello,
Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian.
On n'arret pas de vous le dire, comment voulez vous qu'une societe commerciale ne soit pas tente et meme le fasse comme dans le cas de Redhat de spolier et/ou voler/pervertir la licence GPL, le mode de devellopement de GNU/Linux ?
C'est quasiment impossible, surtout apres la bulle speculative qui a fait que beaucoup d'investissement ont etre faits (rachat de boites, etc) et qu'il faut donc un retour sur investissement RAPIDE et FORT.
La situation de MDK n'est pas toute a fait pareil dans le sens ou la deuxieme levee s'est faite apres la bulle (sont cons ou quoi =) speculative mais il faut faire attention quand meme.
Concernant la Suse, le probleme est presque le meme : pourquoi recommander une distribution qui a un programme (YAST) d'admin simplifie on va dire, alors que ce programme n'est pas lui meme soumis a la GPL ?
Donc, je ne conseille jamais Suse autour de moi et s'il creve, ils l'auront cherché.
Un dernier mot :
Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian, Debian.
J'ai exagere la sur debian ? Ok, je s...
[+] DEBIAN ???????? SLACKWARE OUI !!!!!!
Vous avez fumé quoi ????
La slack 8.x ça c est une bonne distrib !!!!
@++ Code34
-
[+] [^]Re: DEBIAN ???????? SLACKWARE OUI !!!!!!
Posté par Annah C. Hue (page perso, ) le 28/02/2002 à 08:22. (lien). Évalué à -21.Peut être que slackware est une bonne distrib, pour les débutants, mais dès qu'on commence à savoir taper ls et cd, on passe à un vrai système et on utilise debian.
Pour savoir si une entreprise maîtrise linux, un bon indicateur est de regarder la distrib qu'ils installent sur les serveurs de leurs clients. Si c'est pas debian, c'est vraiment pas des pros.-
[^]Re: DEBIAN ???????? SLACKWARE OUI !!!!!!
Posté par mcjyc (page perso, ) le 28/02/2002 à 08:45. (lien). Évalué à 17.c'est la pire des conneries que j'ai jamais lue...
et en plus, c'est une sacree discrimination que tu fais la...
je ne te dis pas bravo.
depuis quand la distrib est un indicateur du talent et de l'experience d'un admin ?
c'est pas parce que tu connais le man de apt-get par coeur que ca fait de toi un dieu...
faut arreter les chevilles qui enflent...-
[+] [^]Re: DEBIAN ???????? SLACKWARE OUI !!!!!!
Posté par vrm (page perso, ) le 28/02/2002 à 08:52. (lien). Évalué à -13.ouais c'est presenté comme un gros troll mais dans le fond il a rasion
en prod chez un client debian c'est vraiment le pied, mettre une distro RPM basé c'est uin debut de preuve d'incompétence...
m'enfin on va encore se faire traiter de gros elitiste de merde.. alirs -1-
[^]Re: DEBIAN ???????? SLACKWARE OUI !!!!!!
Posté par Silence (page perso, ) le 28/02/2002 à 09:02. (lien). Évalué à 10.tiens c'est marrant, je vais mettre plus de 350 machine en prod sur un RedHat 6.2 (oui je sais on dirait de SAMforMS) => je suis donc un incompetent ?
Arf, tu me fais penser a un supporter de foot: y a 22 joueur bien place autour du ballon, et 25000 qui "savent" ce qu'il faut faire... mdr, credibilite zero => tu n'a pas a faire d'un avis personnel, LA solution a tous.
Les Distribs, y en a plein, tu prend celle que tu connait bien, tu l'oublie que c'est ta prefere(a cause des icones de Helene), et tu repart a zero en ECOUTANT tes clients, et en lui proposant les meilleurs solutions. Evidement le libre c'est cool, mais d'autre distrib, plus ancienne, sont tous autant libre, a voir au cas par cas, peuvent parfaitement convenir.--
^d^c-
[^]Re: DEBIAN ???????? SLACKWARE OUI !!!!!!
Posté par Rossel Olivier () le 28/02/2002 à 09:23. (lien). Évalué à 1.350 machines a upgrader sur un systeme a base de RPM. Bon courage quand meme.
Les distrib s a base de RPM sont inbattables en terme d'install. Les distrib a base de DEB sont inbattables en terme de mise a jour.
Choisis ton camp, camarade.
PS: ceci est dit pas pour polemiquer, mais pour te prevenir que les mises a jour, ca compte aussi.-
[^]Re: DEBIAN ???????? SLACKWARE OUI !!!!!!
Posté par Silence (page perso, ) le 28/02/2002 à 10:04. (lien). Évalué à 6.Y a des utils qui existe, et g fait un script perl qui rappatrie les mise a jour, en fonction du type de machine, de sa fonction (car evidement les 350 n'ont pas forcement la meme tache dans l'usine.) Bref encore une fois un epu de systeme D et tu obtient un p'tit systeme qui marche est qui est parfaitement adapte.
En plus es mise a jour en production doivent passer par des phases de test, donc il faut avoir son propre serveur de mise a jour eunmae -r
tc... Je ne connais pas le package debian, et visiblement ca a l'air bien, je mis interreserai prochainement, mais partir d'un etats de faits sans reflechier au contrainte du client, c'est tout sauf du conseil, ca tend meme vers de la plublicite.
Comme toujours, il y a pas forcement de solution toutes prete, mais ca visiblement pas mal de monde n'y pense pas.
Et quand a choisir son camp, y a rien de plus debile, quand tu vends du service, tu essayes simplement de rassembler ce qui se fait de mieux pour ton client.
A bon entendeur--
^d^c-
[+] [^]Re: DEBIAN ???????? SLACKWARE OUI !!!!!!
Posté par jeanmarc () le 28/02/2002 à 19:20. (lien). Évalué à -3.>Je ne connais pas le package debian, et visiblement ca a l'air bien, je mis interreserai prochainement, mais partir d'un etats de faits sans reflechier au contrainte du client, c'est tout sauf du conseil, ca tend meme vers de la plublicite.
>Comme toujours, il y a pas forcement de solution toutes prete, mais ca visiblement pas mal de monde n'y pense pas.
>Et quand a choisir son camp, y a rien de plus debile, quand tu vends du service, tu essayes simplement de rassembler ce qui se fait de mieux pour ton client.
Encore un bel exemple de mauvaise fois! Comment peux-tu prétendre corespondre à l'image que tu donnes du mec impartial et respectueux du client alors que tu ne connais pas la Debian (avant que quelqu'un ne s'appuie sur la distrib pour rabaisser mon post, je précise qu'on peut remplacer par n'importe qu'elle autre distrib. Ici, je cite seulement la distrib que silence ne connait pas)?
Tu voudrais nous faire croire que c'est ton client qui t'a dis "installes moi 5000 redhat 6.2".
Pour ton information, tu décris un cas qui convient parfaitement à ine installation de debian. Tu peux utiliser ta machine de test des nouveaux packages comme proxy avec atp-proxy pour les autres machines à mettre à jour sur lesquelles tu auras pris le soin de mettre une tache cron.
Tu as bien argumenté le fait que c'est le choix du client qui importe mais toi même, tu ne lui offre pas un service de qualité puisque tu ignores toutes les solutions!
-
-
[^]Re: DEBIAN ???????? SLACKWARE OUI !!!!!!
Posté par anonyme512 () le 28/02/2002 à 10:05. (lien). Évalué à 6.alors ça, c'est n'importe quoi.
pour la MAJ des distribs RPM on a:
1- autoupdate: http://www.mat.univie.ac.at/~gerald/ftp/autoupdate/(...)
2- apt-rpm: http://apt-rpm.tuxfamily.org/(...)
3- tous les trucs filés par les distros, genre MandrakeUpdate (urpmi) , up2date, etc.
ces trucs là combinés à une distro en RPM 4, c pas fondamentalement plus mauvais qu'une debian avec .deb/apt-
[+] [^]DEBIAN, pour les hommes, les vrais !
Posté par Annah C. Hue (page perso, ) le 28/02/2002 à 10:20. (lien). Évalué à -12.Encore des surcouches à ajouter à un système déjà bien encombré. Ça ressemble vraiment à windows et à tous les sharewares qu'on y ajoute pour en faire un système à peu pret utilisable.
Optez pour un système propre, sans trucs à ajouter pour que ça marchotte, optez pour D E B I A N !-
[^]Re: DEBIAN, pour les hommes, les vrais !
Posté par anonyme512 () le 28/02/2002 à 10:28. (lien). Évalué à 8.<troll>
laquelle de debian ? la stable, la unstable, la test ? de toutes façons, faut toujours aller modifier le source-list d'apt.. pouah, ça craint, on dirait windows !
moi aussi je peux dire des trucs à la con sur ta distro préférée, mais ça fera pas avancer le débat.
</troll>
en bref, soyons pragmatiques, tant que ça reste du (GNU/)Linux, et que ça marche, et que ça répond au besoin exprimé, et que ça s'administre bien, peu importe comment ça a été construit exactement.
en plus rien ne t'empêche de faire un CD de RH modifié pour inclure les dernières MAJ ainsi qu'autoupodate par exemple. Je l'ai déjà fait d'ailleurs.-
[^]Re: DEBIAN, pour les hommes, les vrais !
-
-
[^]Re: DEBIAN, pour les hommes, les vrais !
Posté par PasChauve PasOunet () le 01/03/2002 à 14:41. (lien). Évalué à 1.En gros tu dis n importequoi et t as pas vraiment l air de connaitre la debian.
Tu parles de surcouche , tres bien , alors qu est apt si c est n est pas une surcouche a dpkg ?
De meme que urpmi est une surcouche a rpm
l un s occupe d installer physiquement (dpkg , rpm , ou en passsant par une lib ) et l autre (apt , urpmi )de gerer source , dependance ....
-
-
-
-
[+] [^]Re: DEBIAN ???????? SLACKWARE OUI !!!!!!
Posté par pas_moi () le 28/02/2002 à 09:52. (lien). Évalué à -2.je suis donc un incompetent ?
Non, un inconscient... Il n'a jamais été dit qu'il était impossible d'utiliser Red Hat dans un cadre professionel, mais franchement c'est de la perte de temps que de gérer un parc de serveurs/stations sur une distrib à base de RPM (ou de tgz à la slack).
C'est pas parce que je sais utiliser un marteau que je m'en sers quand il faut placer une vis dans le mur... C'est pas parce que quelqu'un ne connaît que Red Hat qu'il s'agit forcément de la meilleur solution; c'est comme quand les utilisateurs de MS-Word disent que Word c'est vachement mieux que Latex tout ça parce qu'ils ne connaissent que Word.-
[^]Re: DEBIAN ???????? SLACKWARE OUI !!!!!!
Posté par Silence (page perso, ) le 28/02/2002 à 10:17. (lien). Évalué à 4.Comment peut tu juger de ma situation, et des solutions que j'ai contribue (mais je ne suis pas le seul) a proposer au client ?
Tu etais la quand on a pris connaissances des donnees du client. de ses moyens (et pas forcement financier) ? de ses application ?
Non, alors ne soit pas trop prompt a donner des lecons.
Pour ta gouverne je n'ai aucune affection particuliere pour Red-Hat, je ne l'utilise pas personnellement (bref je suis tous sauf un pro Red-Hat ou un neu2 qui sait installer que celle la). Et j'ai plus de respect pour Debian que pour Red-Hat, meme pour des solutions professionnel.
J'ai pris note (et je savais deja) que les package de Debian sont tous bien foutu. je sais aussi que le maintient et les mise a jour d'un parc informatique est primordiale, surtout en production.
D'autant qu'avec des solution libre, il y a plein de solution facile et fiable.
Mais pour conclure (et me repeter) trancher avant d'ecouter un client (ou un copain) et de connaitre les contrainte d'un projet, c'est malsain.
Vos discours sont un peu trop " .deb, et reflechir apres" AMHA.
Je trouve ca dommage.--
^d^c-
[+] [^]OUINNN, narf il est méchant avec moi et il me parle sans même me connaîte
Posté par pas_moi () le 28/02/2002 à 11:22. (lien). Évalué à -4.Comment peut tu juger de ma situation
Oulaa, encore un qui se prend la tête...
Tu nous dis que tu as 350 machines de prod à installer et tu nous dis que Red Hat a été choisi... Si tu oublies de préciser certains impératifs, ne vient pas pleurer si certains critiquent la décision prise.
Quand il faut que j'installe des serveurs Solaris, je mets du Solaris; quand un client veut du Red Hat, il a du Red Hat; mais quand un client veut un serveur web/de fichier/mail/etc. il a bien souvent du Debian parce que dans ce cas c'est moi qui gère le système et parce que bibi ne veut pas administrer je ne sais quel système cheulou (noyaux patchés, paquets mal gérés...).
Vos discours sont un peu trop " .deb, et reflechir apres" AMHA.
Ben, disons que j'ai tendance à baser mes solutions sur des produits pratiques et simples à administrer... donc, oui, je commence bien souvent par regarder du côté de chez Debian quand on ne m'impose le système. Je ne vois pas où est le problème, mais tu peux peut-être m'éclairer sur ce point.-
[^]Re: OUINNN, narf il est méchant avec moi et il me parle sans même me connaîte
Posté par Nelis (page perso, ) le 28/02/2002 à 12:00. (lien). Évalué à 1.mais t'es con ou t'es con ??
Oulaa, encore un qui se prend la tête...
Pkoi est ce qu'il se prend la tete ? Parce qu'il te fait remarquer que tu ne saurais pas proposer une solution adaptée sans connaitre le problème ? Tu as la science infuse ?
Si tu oublies de préciser certains impératifs, ne vient pas pleurer si certains critiquent la décision prise.
Pkoi est-ce qu'il devrait t'expliquer les impératifs ?? Tu fais partie de sa boite ? Le client t'a demandé qqchose ? Non ! Il n'a absolument rien à expliquer ni à justifier !!
Bref je ne sais pas pour qui tu te prends mais tu as réussi à m'enerver !! Allez répète après moi : "Humilité ! Je ne connais pas la solution à tout, ma parole n'est pas la Vérité(tm)".--
Vache qui rit, à moitié dans son lit-
[^]Re: OUINNN, narf il est méchant avec moi et il me parle sans même me connaîte
Posté par pas_moi () le 28/02/2002 à 14:09. (lien). Évalué à 2.mais t'es con ou t'es con
Là, c'est sûr, tu me prends pour un con... c'est bien, tu as mis moins de temps que la plupart des personnes que j'ai rencontré.
J'essaye d'expliquer que lorsque l'on donne un exemple, on le donne entièrement, on ne le donne pas, ou on la ferme quand certains font signaler que pour le problème, tel qu'il est décrit, la solution choisie n'est sûrement pas la meilleure. Je ne sais pas comment le dire plus poliment (mais j'admets que j'ai tendance à être grossier).
je ne sais pas pour qui tu te prends
Je me prends pour un simple développeur/administrateur mais en réalité je suis Batman...
Humilité ! Je ne connais pas la solution à tout, ma parole n'est pas la Vérité
Putain de bordel de merde, explique-moi où j'ai bien pu dire que mes solutions sont toujours meilleures que celles des autres.
Vu comment je m'exprime dans ce post, ça ne m'étonnerait pas qu'il soit effacé par les modérateurs, mais je vais quand même essayer de t'expliquer une chose: quand une personne A dit quelque chose qui contredit une autre personne B, ça ne veut pas dire qu'elle considère ce qu'à dit B comme un ramassi de --tuu--. On m'explique qu'il a été décidé d'installer 350 RH, je dis que vu le nombre de machines, en Debian ce serait vachement plus simple, et on en arrive à me traiter de con. Moi je dis merci, la discussion avance... J'aurais tant aimé que quelqu'un réponde par: regardez, si vous suivez la doc que l'on trouve ici [url], vous pouvez administrer un parc de RH aussi simplement qu'un parc de Debian... mais visiblement, c'est beaucoup plus simple d'insulter.
HAaaa, ça fait du bien de cracher sa haine sur troll qui passait par là...-
[^]Re: OUINNN, narf il est méchant avec moi et il me parle sans même me connaîte
Posté par Nelis (page perso, ) le 28/02/2002 à 14:27. (lien). Évalué à 1.Ce qui m'énerve, c'est la façon que tu avais de cassé ce pauvre Silence. Si il a choisi RedHat il a sans doute ses raisons, lui seul connait le problème auquel il est confronté. Je ne dis pas que Debian est mieux que RedHat qui est mieux que SuSe qui est mieux que ... Simplement fout lui la paix, je crois qu'il y a plus de paramètres que simplement le nombre de machines pour choisir un distrib. Debian est surement plus facile à administrer lorsque le parc est relativement grand, mais ce n'est pas pour ça que toute autre solution est la mauvaise ...
Voilà :-) C'est tout ce que je voulais dire ...
HAaaa, ça fait du bien de cracher sa haine sur troll qui passait par là...
Effectivement ça m'a défoulé, d'ailleurs tu vois, je suis bcp plus zen maintenant ;-)
Allez sans rancune !--
Vache qui rit, à moitié dans son lit-
[^]Re: OUINNN, narf il est méchant avec moi et il me parle sans même me connaîte
Posté par pas_moi () le 28/02/2002 à 14:48. (lien). Évalué à 3.je crois qu'il y a plus de paramètres que simplement le nombre de machines pour choisir un distrib
Je suis d'accord, sauf que quand le seul paramètre connu est le nombre de machines, on ne propose pas une RH (on ne propose rien, d'ailleurs, parce qu'un client qui ne sait pas ce qu'il veut n'est pas un bon client).
Il voulait que son exemple serve d'arguement à ce qu'il voulait dire... la prochaine fois il sera peut-être plus précis avec ses exemples.
Allez sans rancune !
Je préfère largement quand ça discute comme ça :-)
-
-
-
-
[+] [^]Re: OUINNN, narf il comprend rien, et pas vite
Posté par Silence (page perso, ) le 28/02/2002 à 12:18. (lien). Évalué à -1.pour completer Nelis (ca fait du bien de pas se sentir seul) .
Je n'ai rien contre Debian, rien contre toi (pour le moment), je repondais juste au p'tit 'vrm' qui traiter d'incompetent tous les types qui avait propose RedHat, sans tenir compte une seule seconde, qu'il y a peut etre d'autre raison et d'autre appli sur Linux que apt-get.
Apres que tu (ou je si ca peux te faire plaisir) vexe, soit. Admet juste que le discour de 'vrm' n'est pas plus argumenter qu'une pub pour le retour d'Amiga, et qu'il faut etre un sacrement culote pour traiter d'incompetent toute un clique d'admin !
Encore une fois (aussi) je ne crique pas les solution debian, nio slackware, etc, etc, juste le discour de 'vrm'--
^d^c-
[^]Re: OUINNN, narf il comprend que certains ont plus de mal que lui à comprendre
Posté par pas_moi () le 28/02/2002 à 14:36. (lien). Évalué à 3.je repondais juste au p'tit 'vrm' qui traiter d'incompetent tous les types qui avait propose RedHat [...]
Hum, quand je relis le thread, je vois que tu réponds à vrm qui indique que proposer du RH c'est le début de la preuve de l'incompétence. Je ne vois pas où il dit qu'il n'y a aucune raison valable d'installer une RH.
il faut etre un sacrement culote pour traiter d'incompetent toute un clique d'admin
Heuuu, c'est bien ce que je dis, tu te prends la tête pour pas grand chose: tout ce qu'il veut dire (enfin, je suppose, sinon je suis d'accord avec toi sur le fait qu'il n'est pas malin), c'est que choisir RH comme distribution par défaut à proposer aux client est un très mauvais choix.-
[^]Re: OUINNN, narf il comprend que certains ont plus de mal que lui à comprendre
Posté par Silence (page perso, ) le 28/02/2002 à 14:44. (lien). Évalué à 0.Certe, disons que c'est comme Nelis et toi au dessus, je me suis lache. Ca m'enerve les lamerZ qui blaste a coup de 'Debian Rox', et qui n'on meme pas reflechi a ce qui viennent de dire. (C'est vrai que en mettant un truc pareil, il rsquie pas de se tromper de beaucoup, mais bon)
En plus du fait que j'en suis a mon 5eme cafe, qu'il crique Slackwar(e) et hop, le cochon est dans le mais...
(en plus c tjs un dizaine XP de pris 8^)--
^d^c
-
-
-
-
-
[^]Re: DEBIAN ???????? SLACKWARE OUI !!!!!!
Posté par Ronan BARZIC () le 28/02/2002 à 10:54. (lien). Évalué à 0.Dans mon domaine, beaucoup de softs du type CAO (micro-)electronique sont annonces pour des distribs RedHat.
Ca veut dire que tu prends un gros risque en partant sur une autre distrib.
Pas le risque de voir ton soft se vautrer, mais plutot le risque de voir la hot-line te racrocher au nez si tu dis que tu tournes sur une autre distrib.
Ronan
-
-
-
[^]FreeBSD power !!!
Posté par Philippe SOHM (page perso, ) le 28/02/2002 à 10:24. (lien). Évalué à 0.Ben dans ce cas je peux te dire que FreeBSD utilise des ports qui font la même chose que apt sauf que ca va plus loin puisque ca télécharge les sources et que ca te les compile auto
Bon tu me diras que ca te fera chier de recompiler KDE mais bon, freebsd est utilsié en tant que serveur la plupart du temps et non en tant que desktop d'où l'importance d'avoir tout recompilé
-
[^]N'importe quoi !
Posté par Julien Olivier () le 28/02/2002 à 12:25. (lien). Évalué à 3.Que des conneries...
Il n'y a AUCUNE différence entre un serveur Debian et un serveur Mandrake, Red Hat ou Suse.
Les deux serveurs vont reposer sur les mêmes logiciels. La configuration sera celle que l'admin aura faite. Quand au troll sur RPM, je ne vois vraiment pas en quoi le fait d'utiliser RPM plutôt qu'APT change quoi que ce soit. D'ailleurs APT est un outil linux, pas debian. Donc, tu peux installer apt sur Mandrake ou Suse et faire ton apt-get comme ça te plait.
Conclusion: ce n'est pas la distrib qui fait l'administrateur mais l'inverse.
-
-
[^]Re: DEBIAN ???????? SLACKWARE OUI !!!!!!
-
-
[+] [^]Re: DEBIAN ???????? SLACKWARE OUI !!!!!!
Posté par Silence (page perso, ) le 28/02/2002 à 08:49. (lien). Évalué à -3.Joli Troll, a ton niveau bien sur... 8^) Sur la tribune passerais p'tet (si on rien d'autre a faire) mais la, mazette, tu es cuit.
--
^d^c-
[+] [^]Re: DEBIAN ???????? SLACKWARE OUI !!!!!!
Posté par Annah C. Hue (page perso, ) le 28/02/2002 à 09:48. (lien). Évalué à -1.>Joli Troll
Ce n'est pas un troll, c'est la vérité :-)
C'est pour se rappeler le bon vieux temps d'avant (les) XP où les pires trolls se promenaient sans honte dans les commentaires... Ah quelle joie de voir les mandrakistes étriper les debianeurs qui se foutent de la gueule des slakeux qui se moquent des redhatistes...
M'enfin là encore ça va le débat vole encore assez haut, on aurait pu parler de macos ou de hurd, mais on préfère rester dans le domaine de l'informatique.
-
-


Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.