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.
Je ne vois pas pourquoi Intel reussirais mieux que les autres sur le segment des stations de travail ultra haut de gamme.
Les performances d'un processeur dépendent de choses :
- le design
- le processus de fabrication qui lui-même dépends de l'usine
Les processeurs RISC ont un bon design (car ils ne se trainent pas la compatibilité x86) mais de mauvais processus de fabrication car les faibles volumes n'amortirait pas les investissement nécessaires.
Les x86 ont un mauvais design mais compensent avec du volume donc des processus de fab ultra high-tech.
Donc si l'IA64 avait été un design simplement moyen alors conjugué à la quantité d'argent qu'a Intel pour investir dans des usines performantes, la concurrence n'aurait pas pu lutter.
Le problème est que jusqu'ici Intel a été incapable de produire un design moyen voir médiocre : leur design est juste catastrophiquement nul.
un windowien se felicite que Microsoft est corrige un trou de securite vieux de 3 mois.
Ce qui prends 3 mois, c'est pas de corriger le trou mais de faire les tests de QA (assurance qualité) pour vérifier que quel que soit la configuration possible (DLL, version de windows) ça ne plantera pas à cause d'un conflit stupide (Unix a aussi ses problèmes de libc et de dépendance): c'est le revers du plug'n'play.
Un admin UNIX qui corrige lui-même un trou, acceptera si le programme plante, de chercher à cause de quoi il y a un conflit, de le résoudre voir de revenir en arrière sur sa modif.
En même temps, si tu as un grand nombre (disons plusieurs centaines) de serveurs à administrer, la solution du patch "plug'n'play" peut être la seule envisagable, en contrepartie elle a l'inconvénient d'introduire plus de délais dans la sortie du patch.
"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.
Je m'en prends a CERTAINS utilisateurs de Debian qui se la petent...
Tout à fait d'accord, d'autant plus que comme il faut beaucoup moins de compétence UNIX pour faire un apt-get que pour compiler un programme depuis les sources, c'est complétement injustifié.
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
...
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.
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.
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
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.
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.
Quantify et Purify existent aussi en version Unix, car un gros pourcentage des clients de Rational développe sous Solaris.
Donc, à priori ça devrait pas demander des efforts délirants d'en faire une version Linux.
Encore faut-il que les gens acceptent de l'utiliser car bcp de développeurs Linux en sont encore à tenir le discours : "un débugger ça sert à rien". (en plus c'est pas donné !)
tu dis que c'est du java, juste parce que c'est lent
oui parce que c'est lent et parce qu'il y a une option dans un menu nommée "show java console" qui te montre une console java style applet dans un navigateur.
En gros, d'après ce que j'ai compris l'idée derrière Tex/Latex est d'entrer son texte avec une sémantique décrivant l'organisation de son rapport/livre/article, et non pas des informations de présentation comme dans un traitement de texte classique.
Mais alors, pourquoi ne pas faire une DTD rapport de stage en XML, et utiliser une feuille de style XSL pour le rendu (en XSL-Fo convertit via FOP en PDF) ?
De plus, Latex continue de contenir des informations de présentation (j'en ai pas fait beaucoup mais je crois me souvenir des \it pour l'italique ou quelque chose de ce genre), ce qui est justement ce que l'on repproche au traitement de texte WISIWYG.
Donc, si tu veux un outil intuitif et utilisable par un non-informaticien tu utilise un traitement de texte WYSIWYG (au choix Word, Staroffice, Koffice, Wordperfect, AbiWord, OpenOffice ...), si tu veux un outil qui préserve la structure/sémantique du document et que tu as des connaissances basiques en programmation utilise plutôt XML que Tex/Latex, ça évitera de "polluer" ta sémantique avec des informations de présentation.
Tu utilises quel version de Notes, INotes ou le client classic?
Le about me dit "Lotus Notes R5.0.5 22 Sept 2000".
Enfin, j'ai un pas mal critiqué Notes, mais c'est pas si nul que ça, juste ça désarçonne un peu quand tu n'a pas l'habitude et puis tu sens les inconvénients du Java, l'avantage est que ça devrait être facile à porter sous Unix/Linux de ce point de vue là, d'ailleurs IBM a sans doutes voulu préserver ses plateformes sous AIX (et maintenant Linux) d'où le choix de Java.
Le defaut des produits microsofts outre leurs licenses inadmissibles ,
Question de point de vue, enfin au moins du point de vue de la viabilité du business model la preuve n'est plus à faire. c est leur faiblesse technique
Qu'est-ce que tu entends par là !
Tu veux dire qu'il sont lents et buggés.
Mais n'est-ce pas plutôt la conséquence d'un style de développement (niveau d'abstraction élévé, gigantisme des équipes de développements et des spécifications du logiciel) plutôt que quelque chose de lié à MS.
Les produits Netscape qui utilisent le même style de développement (plus de 160 développeurs au début du projet Mozilla, c'était vraiment du gigantisme !), ne souffrent-ils pas des même défauts ? qui se ressent pas des failles de securites enormes !
Disons plutôt que la culture d'un développeur spécialisé dans l'interface graphique n'implique pas en général, le degrès de sensibilisation aux problèmes de sécurité que l'on peut trouver chez un développeur ayant une culture de développeur réseau.
Et comme MS vient du monde de la bureautique pour aller vers celui des serveurs, ils font parfois des erreurs de conception que n'auraient pas fait un Sun ou un IBM.
Enfin, il ne faut pas non plus imaginer que c'est MS qui a inventé les problèmes de sécurité, on a découverts des centaines de buffer overflow dans des produits Unix avant-même que NT existe.
Et il y a aussi beaucoup de produits Unix/Linux réputées pour leurs failles de sécurité à répetition :
- WuFTP et les autres démons de l'université de Washington
- Bind de l'ISC
- Sendmail ...
D'ailleurs beaucoup de caractéristiques d'Unix rendent plus facile l'exploitation des failles sur cet OS.
La disponibilité des sources facilite l'écriture de rootkit (certain ont essayé d'écrire des rootkit NT au desassembleur mais c'est plus dur !).
Et il est plus facile de télécommander à distance un OS qui se commande via un shell, qu'un OS qui se commande via une interface graphique : on peut toujours écrire une backdoor avec un protocole style VNC mais c'est ça demande beaucoup plus de travail (intercepter les messages Windows de mouvement de la souris, transmettre efficacement donc avec compression des copies d'écran) que de juste "binder" un shell sur un port.
A propos d'outils de groupware, nous, au boulot on est sous Notes, et c'est pas terrible d'ailleurs !
Quand t'ouvre un mail il ouvre une nouvelle fenêtre MDI, ce qui fait que tu retrouve vite avec une dizaine de fenêtre ouverte, et ça c'est un peu énervant.
Par ailleurs, comme Notes est développé en Java (avec peut-être une compilation native derrière), c'est plutôt lent. Quant tu envois une pièce jointe, il te la compresse, et ça dure longtemps, longtemps (parfois plusieurs minutes chrono en main).C'est bien simple, la première fois que j'ai envoyé une grosse pièce jointe avec Notes, j'ai rebooté mon PC pensant qu'il avait planté parce qu'il ne réagissait plus depuis 10 minutes.
Enfin, bon je râle contre Notes, mais c'est pas si pourri que ça, faut juste avoir un peu l'habitude.
Et puis, bien que Notes ait beaucoup de défauts, il a moins le mérite de l'originalité dans son ergonomie, alors qu'Evolution (et dans moindre mesure Aethera) me rappelle vraiment Outlook avec sa barre d'icone à gauche sur fond gris foncé.
Comme quoi, on rale sur les produit MS, mais ils sont pas si pourris que ça (surtout au niveau interface utilisateur, la spécialité de MS). La preuve j'ai pas vu beaucoup de client mails copier l'ergonomie de Notes (vaut mieux d'ailleurs), alors qu'il y en déja deux qui copient Outlook.
VA Linux à changé d'orientation, va savoir pourquoi ?
- parce qu'ils perdaient du fric ?
- parce que les investisseurs en avaient marre que l'on jette leur argent par la fenêtre ?
- parce qu'ils allaient faire faillite sinon ?
Sinon, c'est dommage qu'ils fasse que du soft, des boites de soft il y en déja des dizaines et leur outil SourceForge n'a rien de miraculeux par rapport à ce qui existe déja en propriétaire (chez Rational par exemple).
Maintenant, faire du hard je veux bien, mais alors si la valeur ajouté est dans la machine pourquoi le vendre uniquement sous Linux et pas aussi sous Win 2K, ou Netware ?
Quand j'achéte un Pc chez un assembleur, on me vends pas un PC pour faire du Linux ou un PC pour faire du Windows, on me vends un PC c'est tout, et c'est moi qui décide quoi en faire derrière ! Alors pourquoi ça serait différent pour les serveurs en Rack ?
VA Linux aurait utilisé des processeurs ARM, ou MIPS (pour tirer parti du caractère portable de Linux), je dis pas, mais comme ils ont du penser que ça leur couterait plus cher (rapport aux carte mères sans doute), je vois plus la raison.
Je crois que WordPerfect et CorelDraw ne tournaient sous Linux que grâce à Wine.
Donc, si ils avaient recodé une application nouvelle en Qt, Gtk, Motif, Tk ou ce que tu veux d'autres comme toolkit Unix, celà aurait présenté un intérêt au niveau technique (mais peut-être pas niveau commercial).
Alors que là porter une appli sur un émulateur, c'est comme si une boite de jeux portait des jeux non pas sur PC mais sur Bleem. Je vois pas trop l'intérêt.
Vraiment toi, tu n'as que le mot "intégriste" à la bouche.
T'as raison je me repète un peu, mais bon il y a un fond de vérité aussi!
Et puis soyez un peu plus ouvert d'esprit comme ça je pourrais me taire ... ça devrait vous motiver :)
En plus, tu prends des exemples trés respectueux des sensibilités de chacun!
Si tu va pas la, c'est pas moi non plus qui ait commencé à sortir des exemples "sur les catholiques qui sont contre le fait de faire l'amour avant le mariage"
Je comprends que te retrouver parmis des gens qui pronnent le partage, le respect et la tolérance
- le partage : des sources, ouais, d'accord ! des connaissances assez souvent !
- le respect : là y a des progrès à faire !
Tu vois quand je vois des gens qui répondent à des commentaires défendant le logiciel proprio
sous le titre "Quel con !", je suis moyennement convaincu.
- la tolérance : LinuxFr a beaucoup de qualité mais la a mon avis c'est pas le point fort.
Et si Linus était simplement un étudiant qui voulait coder en ASM mode protégé sur son 386, qui avait voulu modifier Minix et qui avait été dégouté lorsque on lui avait rétorqué que la license de Tannembaum lui interdisait d'en modifier le code.
Et si encore échaudé par cette frustation, il avait voulu placer son propre code sous une license qui autorise ce genre de modif, et que là sur un newsgroup on lui avait parlé d'une license écrite par un type obscur nommé Stallman qui servirait plus ou moins ça. Linus aurait copié ça dans son entête de fichier source et aurait commencé à penser à autre chose de plus intéressant : son code.
En bref, Linus ça serait un gars qui s'en foutrait pas mal de la philosophie du libre, il voudrait juste s'amuser à coder des trucs marrant avec son 386, c'est tout.
Pourquoi alors venir l'emm... avec des histoires comme quoi "le logiciel propriétaire c'est le MAL, c'est mauvais pour l'humanité ..." ?
Il lui DEMANDE, il ne l'impose pas.
Et alors, si un jour je vais dans un pays musulman et que l'ihmam du coin me "demande" de faire le rahmadan alors qu'il sait parfaitement que je suis catholique (comme toi tu sais parfaitement que Linus n'est pas membre de la secte de RMS), je le traiterais quand même d'intégriste.
<i>l'install de CVS sous NT ca se fait pas en claquant des doigts<i>
Et puis, surtout avec CVS tu n'a pas de barre d'outil pour l'intégration avec Visual et ça c'est moins pratique à l'usage!
Je crois qu'il y a un projet open-source pour faire cela mais j'ai pas l'impression qu'il soit méga stable.
Je te cite mot pour mot :"Bah moi si. Sachant que Redhat a tendance à activer plein de trucs pas stables dans le noyau, et parfois à le compiler avec des trucs bizarres, les noyaux ne sont pas les mêmes."
Donc non seulement, tu as dit que les noyaux étaient différents (ce qui est indiscutable) mais en plus tu as dit que celui de RedHat était moins stable (sous-entendu ils contiendrait plus de trucs expérimentaux que la version de Linus) ce qui est manifestement une erreur, c'est même en fait exactement le contraire !
Comme quoi, il y a quand même une certaine tendance sur ce forum à dire du vouloir dire du mal à tout prix de tout ce qui est assimilé même de très loin (leur noyau à Redhat il est quand même GPL, non ?) à du propriétaire .
Je n'ai rien contre les gens qui disent du mal des éditeurs de logiciels proprio lorsque c'est justifié, car vois-tu je n'ai pas d'action chez MS, donc si tu veux critiquer vas-y, mais fait attention que celà soit basé sur quelque chose de solide derrière, ta crédibilité y gagnera.
La plupart des ressources de Mozilla sont bouffées par son interface.
A mon avis la plupart des ressources sont surtout bouffés par le fait qu'il y a plus d'un million de lignes de codes, que tout est linkés dynamiquement dans des .so et que au démarrage ça prends trois heures de faire la résolution des liens vu le nombre de fonctions.
Et dans la version embedded, t'as pratiquement la même quantité de code, car c'est pas le truc XUL qui doit prendre le plus de place dans le source.
Comme galeon utilise une interface beaucoup plus légère
Lis ma réponse plus haut, elle est pas plus légére car il y a à peu pratiquement autant de code, mais elle est plus réactive (raffraichit plus vite) car tu appelle les routines de dessins de widget gtk directement au lieu de passer par les couches XUL avant.
Quant à ton Opera chéri, je crois qu'il ne gère pas les signets paramétrés...
Et, les gestures dans un galeon c'est pas un peu une idée pompée dans Opéra 6.0 ?
Sachant que Redhat a tendance à activer plein de trucs pas stables dans le noyau
Dis-donc, tu serais pas un peu de mauvaise foi vis-à-vis de RedHat, lis-donc cette news "The kernel of pain", et tu verra que le kernel de RedHat cheche au contraire de ce que tu raconte à privilégier la stabilité sur la performance http://linuxtoday.com/news_story.php3?ltsn=2002-01-16-014-20-OP-KN(...)
D'ailleurs, je te signale que Linus a changé la VM en 2.4.10, et que RedHat utilise volontairement une 2.4.9 justement pour éviter d'utiliser une nouvelle VM pas stable. Après, ils ont du backporter quelques fix depuis les versions ultérieures pour améliorer encore la stabilité mais j'appelle pas ça "activer plein de trucs pas stables dans le noyau" !!!
ça te fait vraiment c...r qu'on occulte carrément et systématiquement microsoft
ça ne me fait pas spécialement chier, je trouve seulement que c'est une attitude ridicule, parfois infantile, en gros que c'est dommage.
Ici, quand on parle de gestionnaire de version, on n'a pas besoin de préciser que c'est pour faire du logiciel libre.
Je ne vois pas le rapport, la GPL n'est pas réservée pour les projets Linux (regarde SourceForge, c'est bourré de moteurs 3D libres sous Windows), et puis je n'ai vu nulle part que l'usage de la GPL interdisais l'usage d'outils propriétaires.
Je suppose que par exemple tu considère que Mozilla est un logiciel libre, pourtant il est développé sous CodeWarrior (pour la compilation Mac) et il me semble que la compilation Windows se fait avec Visual C++.
Tu n'a jamais regardé dans le CVS de Mozilla ?
Alors, évite tes notes bidons et arrête de juger la compréhension des utilisateurs de ce site STP. On n'a pas attendu ta venue pour savoir ce qu'était un troll.
Franchement, je suis contre l'usage du mot "troll", je me suis toujours dis que l'usage de ce mot appauvrissait la langue française pourtant riche d'expressions comme "ton post fait de la provocation mais n'apporte rien de substanciel".
D'ailleurs je ne suis pas persuadé que dire que "les logiciel M$ sont pourris et bourrés de bug" soit moins provocant, et plus informatif que d'indiquer que "Sourcesafe ait un outil de gestion de configuration destiné aux petites équipes" comme je l'ai fait dans mon post.
Donc ici, le "trolleur" c'est pas moi !
[^] # Re: Oracle moins bien que PostgresSQL (suite)
Posté par Stephane JUTIN . En réponse à la dépêche Red Hat s'éloigne de plus en plus du libre. Évalué à 1.
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.
[^] # Intel plus fort que tout le monde ?
Posté par Stephane JUTIN . En réponse à la dépêche AMD presente son ClawHammer avec Linux 64 bits. Évalué à 0.
Les performances d'un processeur dépendent de choses :
- le design
- le processus de fabrication qui lui-même dépends de l'usine
Les processeurs RISC ont un bon design (car ils ne se trainent pas la compatibilité x86) mais de mauvais processus de fabrication car les faibles volumes n'amortirait pas les investissement nécessaires.
Les x86 ont un mauvais design mais compensent avec du volume donc des processus de fab ultra high-tech.
Donc si l'IA64 avait été un design simplement moyen alors conjugué à la quantité d'argent qu'a Intel pour investir dans des usines performantes, la concurrence n'aurait pas pu lutter.
Le problème est que jusqu'ici Intel a été incapable de produire un design moyen voir médiocre : leur design est juste catastrophiquement nul.
[^] # Trou de sécurité
Posté par Stephane JUTIN . En réponse à la dépêche La crise des patchs du noyau. Évalué à 6.
Ce qui prends 3 mois, c'est pas de corriger le trou mais de faire les tests de QA (assurance qualité) pour vérifier que quel que soit la configuration possible (DLL, version de windows) ça ne plantera pas à cause d'un conflit stupide (Unix a aussi ses problèmes de libc et de dépendance): c'est le revers du plug'n'play.
Un admin UNIX qui corrige lui-même un trou, acceptera si le programme plante, de chercher à cause de quoi il y a un conflit, de le résoudre voir de revenir en arrière sur sa modif.
En même temps, si tu as un grand nombre (disons plusieurs centaines) de serveurs à administrer, la solution du patch "plug'n'play" peut être la seule envisagable, en contrepartie elle a l'inconvénient d'introduire plus de délais dans la sortie du patch.
[^] # Re: Oracle moins bien que PostgresSQL (suite)
Posté par Stephane JUTIN . En réponse à la dépêche Red Hat s'éloigne de plus en plus du libre. Évalué à 1.
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: DEBIAN ????????
Posté par Stephane JUTIN . En réponse à la dépêche Red Hat s'éloigne de plus en plus du libre. Évalué à 0.
Tout à fait d'accord, d'autant plus que comme il faut beaucoup moins de compétence UNIX pour faire un apt-get que pour compiler un programme depuis les sources, c'est complétement injustifié.
[^] # Re: Oracle moins bien que PostgresSQL (suite)
Posté par Stephane JUTIN . En réponse à la dépêche Red Hat s'éloigne de plus en plus du libre. Évalué à 2.
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
...
[^] # Re: Oracle moins bien que PostgresSQL (suite)
Posté par Stephane JUTIN . En réponse à la dépêche Red Hat s'éloigne de plus en plus du libre. Évalué à 0.
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 Stephane JUTIN . En réponse à la dépêche Red Hat s'éloigne de plus en plus du libre. Évalué à -2.
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
[^] # Oracle moins bien que PostgresSQL (suite)
Posté par Stephane JUTIN . En réponse à la dépêche Red Hat s'éloigne de plus en plus du libre. Évalué à 4.
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.
[^] # La bonne blague : Oracle moins bien que PostgresSQL !
Posté par Stephane JUTIN . En réponse à la dépêche Red Hat s'éloigne de plus en plus du libre. Évalué à -2.
<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.
[^] # Rational
Posté par Stephane JUTIN . En réponse à la dépêche Entrevue avec David FAURE. Évalué à 9.
Donc, à priori ça devrait pas demander des efforts délirants d'en faire une version Linux.
Encore faut-il que les gens acceptent de l'utiliser car bcp de développeurs Linux en sont encore à tenir le discours : "un débugger ça sert à rien". (en plus c'est pas donné !)
[^] # Notes et Java
Posté par Stephane JUTIN . En réponse à la dépêche Des tas de Betas. Évalué à -1.
[^] # Tex/Latex & outil de formatage
Posté par Stephane JUTIN . En réponse à la dépêche Open Office: pourquoi les utilisateurs Linux en ont-ils besoin?. Évalué à 9.
Mais alors, pourquoi ne pas faire une DTD rapport de stage en XML, et utiliser une feuille de style XSL pour le rendu (en XSL-Fo convertit via FOP en PDF) ?
De plus, Latex continue de contenir des informations de présentation (j'en ai pas fait beaucoup mais je crois me souvenir des \it pour l'italique ou quelque chose de ce genre), ce qui est justement ce que l'on repproche au traitement de texte WISIWYG.
Donc, si tu veux un outil intuitif et utilisable par un non-informaticien tu utilise un traitement de texte WYSIWYG (au choix Word, Staroffice, Koffice, Wordperfect, AbiWord, OpenOffice ...), si tu veux un outil qui préserve la structure/sémantique du document et que tu as des connaissances basiques en programmation utilise plutôt XML que Tex/Latex, ça évitera de "polluer" ta sémantique avec des informations de présentation.
[^] # Re: Aethera, Evolution et autres outils de mail/groupware
Posté par Stephane JUTIN . En réponse à la dépêche Des tas de Betas. Évalué à 2.
Le about me dit "Lotus Notes R5.0.5 22 Sept 2000".
Enfin, j'ai un pas mal critiqué Notes, mais c'est pas si nul que ça, juste ça désarçonne un peu quand tu n'a pas l'habitude et puis tu sens les inconvénients du Java, l'avantage est que ça devrait être facile à porter sous Unix/Linux de ce point de vue là, d'ailleurs IBM a sans doutes voulu préserver ses plateformes sous AIX (et maintenant Linux) d'où le choix de Java.
[^] # Re: Aethera, Evolution et autres outils de mail/groupware
Posté par Stephane JUTIN . En réponse à la dépêche Des tas de Betas. Évalué à 4.
Question de point de vue, enfin au moins du point de vue de la viabilité du business model la preuve n'est plus à faire.
c est leur faiblesse technique
Qu'est-ce que tu entends par là !
Tu veux dire qu'il sont lents et buggés.
Mais n'est-ce pas plutôt la conséquence d'un style de développement (niveau d'abstraction élévé, gigantisme des équipes de développements et des spécifications du logiciel) plutôt que quelque chose de lié à MS.
Les produits Netscape qui utilisent le même style de développement (plus de 160 développeurs au début du projet Mozilla, c'était vraiment du gigantisme !), ne souffrent-ils pas des même défauts ?
qui se ressent pas des failles de securites enormes !
Disons plutôt que la culture d'un développeur spécialisé dans l'interface graphique n'implique pas en général, le degrès de sensibilisation aux problèmes de sécurité que l'on peut trouver chez un développeur ayant une culture de développeur réseau.
Et comme MS vient du monde de la bureautique pour aller vers celui des serveurs, ils font parfois des erreurs de conception que n'auraient pas fait un Sun ou un IBM.
Enfin, il ne faut pas non plus imaginer que c'est MS qui a inventé les problèmes de sécurité, on a découverts des centaines de buffer overflow dans des produits Unix avant-même que NT existe.
Et il y a aussi beaucoup de produits Unix/Linux réputées pour leurs failles de sécurité à répetition :
- WuFTP et les autres démons de l'université de Washington
- Bind de l'ISC
- Sendmail ...
D'ailleurs beaucoup de caractéristiques d'Unix rendent plus facile l'exploitation des failles sur cet OS.
La disponibilité des sources facilite l'écriture de rootkit (certain ont essayé d'écrire des rootkit NT au desassembleur mais c'est plus dur !).
Et il est plus facile de télécommander à distance un OS qui se commande via un shell, qu'un OS qui se commande via une interface graphique : on peut toujours écrire une backdoor avec un protocole style VNC mais c'est ça demande beaucoup plus de travail (intercepter les messages Windows de mouvement de la souris, transmettre efficacement donc avec compression des copies d'écran) que de juste "binder" un shell sur un port.
[^] # Aethera, Evolution et autres outils de mail/groupware
Posté par Stephane JUTIN . En réponse à la dépêche Des tas de Betas. Évalué à 6.
Quand t'ouvre un mail il ouvre une nouvelle fenêtre MDI, ce qui fait que tu retrouve vite avec une dizaine de fenêtre ouverte, et ça c'est un peu énervant.
Par ailleurs, comme Notes est développé en Java (avec peut-être une compilation native derrière), c'est plutôt lent. Quant tu envois une pièce jointe, il te la compresse, et ça dure longtemps, longtemps (parfois plusieurs minutes chrono en main).C'est bien simple, la première fois que j'ai envoyé une grosse pièce jointe avec Notes, j'ai rebooté mon PC pensant qu'il avait planté parce qu'il ne réagissait plus depuis 10 minutes.
Enfin, bon je râle contre Notes, mais c'est pas si pourri que ça, faut juste avoir un peu l'habitude.
Et puis, bien que Notes ait beaucoup de défauts, il a moins le mérite de l'originalité dans son ergonomie, alors qu'Evolution (et dans moindre mesure Aethera) me rappelle vraiment Outlook avec sa barre d'icone à gauche sur fond gris foncé.
Comme quoi, on rale sur les produit MS, mais ils sont pas si pourris que ça (surtout au niveau interface utilisateur, la spécialité de MS). La preuve j'ai pas vu beaucoup de client mails copier l'ergonomie de Notes (vaut mieux d'ailleurs), alors qu'il y en déja deux qui copient Outlook.
[^] # VA Linux
Posté par Stephane JUTIN . En réponse à la dépêche Le site Opensource de Corel ferme!. Évalué à -2.
- parce qu'ils perdaient du fric ?
- parce que les investisseurs en avaient marre que l'on jette leur argent par la fenêtre ?
- parce qu'ils allaient faire faillite sinon ?
Sinon, c'est dommage qu'ils fasse que du soft, des boites de soft il y en déja des dizaines et leur outil SourceForge n'a rien de miraculeux par rapport à ce qui existe déja en propriétaire (chez Rational par exemple).
Maintenant, faire du hard je veux bien, mais alors si la valeur ajouté est dans la machine pourquoi le vendre uniquement sous Linux et pas aussi sous Win 2K, ou Netware ?
Quand j'achéte un Pc chez un assembleur, on me vends pas un PC pour faire du Linux ou un PC pour faire du Windows, on me vends un PC c'est tout, et c'est moi qui décide quoi en faire derrière ! Alors pourquoi ça serait différent pour les serveurs en Rack ?
VA Linux aurait utilisé des processeurs ARM, ou MIPS (pour tirer parti du caractère portable de Linux), je dis pas, mais comme ils ont du penser que ça leur couterait plus cher (rapport aux carte mères sans doute), je vois plus la raison.
[^] # c'est pas une si grosse perte que ça
Posté par Stephane JUTIN . En réponse à la dépêche Le site Opensource de Corel ferme!. Évalué à -3.
Donc, si ils avaient recodé une application nouvelle en Qt, Gtk, Motif, Tk ou ce que tu veux d'autres comme toolkit Unix, celà aurait présenté un intérêt au niveau technique (mais peut-être pas niveau commercial).
Alors que là porter une appli sur un émulateur, c'est comme si une boite de jeux portait des jeux non pas sur PC mais sur Bleem. Je vois pas trop l'intérêt.
[^] # Re: C'est beau la philosophie du libre
Posté par Stephane JUTIN . En réponse à la dépêche Le site Opensource de Corel ferme!. Évalué à -3.
Je crois qu'ils s'en foutent un peu des contributions maintenant qu'ils ont arrêté leur activité Linux.
[^] # Re: S'il vous plait arretez avec votre Open Source !
Posté par Stephane JUTIN . En réponse à la dépêche Linus passe un peu la main. Évalué à -2.
T'as raison je me repète un peu, mais bon il y a un fond de vérité aussi!
Et puis soyez un peu plus ouvert d'esprit comme ça je pourrais me taire ... ça devrait vous motiver :)
En plus, tu prends des exemples trés respectueux des sensibilités de chacun!
Si tu va pas la, c'est pas moi non plus qui ait commencé à sortir des exemples "sur les catholiques qui sont contre le fait de faire l'amour avant le mariage"
Je comprends que te retrouver parmis des gens qui pronnent le partage, le respect et la tolérance
- le partage : des sources, ouais, d'accord ! des connaissances assez souvent !
- le respect : là y a des progrès à faire !
Tu vois quand je vois des gens qui répondent à des commentaires défendant le logiciel proprio
sous le titre "Quel con !", je suis moyennement convaincu.
- la tolérance : LinuxFr a beaucoup de qualité mais la a mon avis c'est pas le point fort.
[^] # Re: S'il vous plait arretez avec votre Open Source !
Posté par Stephane JUTIN . En réponse à la dépêche Linus passe un peu la main. Évalué à -2.
Et si encore échaudé par cette frustation, il avait voulu placer son propre code sous une license qui autorise ce genre de modif, et que là sur un newsgroup on lui avait parlé d'une license écrite par un type obscur nommé Stallman qui servirait plus ou moins ça. Linus aurait copié ça dans son entête de fichier source et aurait commencé à penser à autre chose de plus intéressant : son code.
En bref, Linus ça serait un gars qui s'en foutrait pas mal de la philosophie du libre, il voudrait juste s'amuser à coder des trucs marrant avec son 386, c'est tout.
Pourquoi alors venir l'emm... avec des histoires comme quoi "le logiciel propriétaire c'est le MAL, c'est mauvais pour l'humanité ..." ?
Il lui DEMANDE, il ne l'impose pas.
Et alors, si un jour je vais dans un pays musulman et que l'ihmam du coin me "demande" de faire le rahmadan alors qu'il sait parfaitement que je suis catholique (comme toi tu sais parfaitement que Linus n'est pas membre de la secte de RMS), je le traiterais quand même d'intégriste.
[^] # Re: Il y aussi ClearCase
Posté par Stephane JUTIN . En réponse à la dépêche Linus passe un peu la main. Évalué à -2.
Et puis, surtout avec CVS tu n'a pas de barre d'outil pour l'intégration avec Visual et ça c'est moins pratique à l'usage!
Je crois qu'il y a un projet open-source pour faire cela mais j'ai pas l'impression qu'il soit méga stable.
[^] # Re: S'il vous plait arretez avec votre Open Source !
Posté par Stephane JUTIN . En réponse à la dépêche Linus passe un peu la main. Évalué à -1.
Donc non seulement, tu as dit que les noyaux étaient différents (ce qui est indiscutable) mais en plus tu as dit que celui de RedHat était moins stable (sous-entendu ils contiendrait plus de trucs expérimentaux que la version de Linus) ce qui est manifestement une erreur, c'est même en fait exactement le contraire !
Comme quoi, il y a quand même une certaine tendance sur ce forum à dire du vouloir dire du mal à tout prix de tout ce qui est assimilé même de très loin (leur noyau à Redhat il est quand même GPL, non ?) à du propriétaire .
Je n'ai rien contre les gens qui disent du mal des éditeurs de logiciels proprio lorsque c'est justifié, car vois-tu je n'ai pas d'action chez MS, donc si tu veux critiquer vas-y, mais fait attention que celà soit basé sur quelque chose de solide derrière, ta crédibilité y gagnera.
[^] # Re: S'il vous plait arretez avec votre Open Source !
Posté par Stephane JUTIN . En réponse à la dépêche Linus passe un peu la main. Évalué à -2.
A mon avis la plupart des ressources sont surtout bouffés par le fait qu'il y a plus d'un million de lignes de codes, que tout est linkés dynamiquement dans des .so et que au démarrage ça prends trois heures de faire la résolution des liens vu le nombre de fonctions.
Et dans la version embedded, t'as pratiquement la même quantité de code, car c'est pas le truc XUL qui doit prendre le plus de place dans le source.
Comme galeon utilise une interface beaucoup plus légère
Lis ma réponse plus haut, elle est pas plus légére car il y a à peu pratiquement autant de code, mais elle est plus réactive (raffraichit plus vite) car tu appelle les routines de dessins de widget gtk directement au lieu de passer par les couches XUL avant.
Quant à ton Opera chéri, je crois qu'il ne gère pas les signets paramétrés...
Et, les gestures dans un galeon c'est pas un peu une idée pompée dans Opéra 6.0 ?
Sachant que Redhat a tendance à activer plein de trucs pas stables dans le noyau
Dis-donc, tu serais pas un peu de mauvaise foi vis-à-vis de RedHat, lis-donc cette news "The kernel of pain", et tu verra que le kernel de RedHat cheche au contraire de ce que tu raconte à privilégier la stabilité sur la performance
http://linuxtoday.com/news_story.php3?ltsn=2002-01-16-014-20-OP-KN(...)
D'ailleurs, je te signale que Linus a changé la VM en 2.4.10, et que RedHat utilise volontairement une 2.4.9 justement pour éviter d'utiliser une nouvelle VM pas stable. Après, ils ont du backporter quelques fix depuis les versions ultérieures pour améliorer encore la stabilité mais j'appelle pas ça "activer plein de trucs pas stables dans le noyau" !!!
[^] # Re: Il y aussi ClearCase
Posté par Stephane JUTIN . En réponse à la dépêche Linus passe un peu la main. Évalué à -4.
ça ne me fait pas spécialement chier, je trouve seulement que c'est une attitude ridicule, parfois infantile, en gros que c'est dommage.
Ici, quand on parle de gestionnaire de version, on n'a pas besoin de préciser que c'est pour faire du logiciel libre.
Je ne vois pas le rapport, la GPL n'est pas réservée pour les projets Linux (regarde SourceForge, c'est bourré de moteurs 3D libres sous Windows), et puis je n'ai vu nulle part que l'usage de la GPL interdisais l'usage d'outils propriétaires.
Je suppose que par exemple tu considère que Mozilla est un logiciel libre, pourtant il est développé sous CodeWarrior (pour la compilation Mac) et il me semble que la compilation Windows se fait avec Visual C++.
Tu n'a jamais regardé dans le CVS de Mozilla ?
Alors, évite tes notes bidons et arrête de juger la compréhension des utilisateurs de ce site STP. On n'a pas attendu ta venue pour savoir ce qu'était un troll.
Franchement, je suis contre l'usage du mot "troll", je me suis toujours dis que l'usage de ce mot appauvrissait la langue française pourtant riche d'expressions comme "ton post fait de la provocation mais n'apporte rien de substanciel".
D'ailleurs je ne suis pas persuadé que dire que "les logiciel M$ sont pourris et bourrés de bug" soit moins provocant, et plus informatif que d'indiquer que "Sourcesafe ait un outil de gestion de configuration destiné aux petites équipes" comme je l'ai fait dans mon post.
Donc ici, le "trolleur" c'est pas moi !