raison de plus pour limiter le nombre de moteurs non ? Ça ficilite le boulot des webmasters.
Oui et non. Il est vrai que si il n'y a que trois ou quatres moteurs sur le web, tu peux envisager de faire des codes specifique pour chacun d'entre eux, ou te limiter au niveau des fonctions pour sortir une page qui passe partout. Mais ca demande du temps, pas mal de tests et une pletore de code javascript pour ne pas se planter. Meme si ca a l'air techniquement faisable, cela entrainne un enorme surcout de devellopement et penalise grandement les technologies annexes et les petits browser. De plus quand on travaille pour un type de client particulier ca rend le dev quasi impossible. (Un exemple personel est un site il y a trois ans qui devait passer sous Netscape 3.x,4.x,IE,lynx sous PC/Mac/Unix/DOS tout en restant lisible pour des aveugles qui n'ont qu'une plage braille pour lire le site)
A l'inverse si il y a un bon nombre de navigateurs differents bases sur des moteurs independant, il y aura obligation d'uniformisation. Cela donnera beaucoup plus de poid au W3C (et beaucoup plus de travail aussi) et la notion de "site optimise pour X" disparaitra. En d'autre termes apres une periode de remous, le HTML deviendra une norme "reelle" (au sens ou personne ne pourra se permettre d'en ignorer ne serait-ce qu'une partie). Et la le travail des webmasters sera grandement simplifie.
A l'heure actuelle la technologie la plus repandue sur le web pour visualiser des donnees n'est pas IE, c'est Flash (95 a 97% des browsers). Pourquoi ce succes ? Tout simplement parceque flash garantit un comportement. Tout le cote casse-tete de la multicompatibilite disparait des que l'on choisit Flash. Et ca a commence bien avant que Gecko ou KHTML ne soient des projets "grand public" gerer 3 navigateurs (IE3 sous PC, Netscape 3 sous PC/MAC) etait deja un calvaire suffisant pour faire gagner des points a Flash. Donc le petit nombre de moteur de rendus n'est pas une aide pour les webmasters (loin de la meme, vu que dans la lutte pour la suprematie ils font tout pour se rendre incompatible les uns avec les autres).
Concernant Gecko,KHTML et consors il est absolument vital que ces projets coexistent. Contrairement a ce que tu as l'air de penser deux groupes de devellopement qui travaillent en parallele sont nettement plus efficace qu'un seul groupe de taille double. C'est un probleme bien connu en info le probleme du macon (aussi connu sous le nom du theoreme du trou) : Si un macon peut faire un mur en 1 heure, alors 3600 macons peuvent faire un mur en 1 seconde.
Inutile de dire que ce theoreme est une blague et que c'est completement faux.
Quel interet y-a-t-il a voir a la fois Gecko et KHTML ? Et bien dans tout dev il y a un paquet de choix qui sont fait, le design objet, le choix de techno, les priorites de dev, les optimisation etc... Et il arrive sur un projet a long terme dont on ne maitrise pas l'ensemble des contraintes (et pour le web je pense que personne ne maitrise l'ensemble des contraintes) que l'on se retrouve bloque ou fortement ralenti par un choix qui a ete fait longtemps avant. A ce moment la avoir un autre projet a cote qui a deja reflechi au probleme, voir meme qui a deja resolu le probleme et teste la solution fait gagner un temps fou. On ne compte plus le nombre de projet qui reparte "from scratch" parceque ce serait trop dur d'adapter l'existant a telle ou telle fonctionalite. Donc oui avoir deux ou trois groupes qui bossent sur des projets quasi identiques est une chance, et au final neuf fois sur dix tout le monde y gagne. KDE et Gnome se sont retrouve en "concurrence" (au sens emulation du terme) et n'ont pas hesite a echanger des infos, des points de vues et des methodes de dev. Je ne pense pas qu'aucun des deux projets serait aussi avance aujourd'hui sans cette concurence.
PS : oui, il y a la fonctionnalité de "tab-browsing", la navigation par onglets.
Il y a surtout une nouvelle fonction qu'on attendait depuis un moment : l'icone x pour fermer les onglets sur chaque onglet. Bon faut faire un peu gaffe a pas cliquer dessus par megarde quand on veut juste changer de page, mais le fait de ne plus avoir a aller a l'autre bout de la fenetre pour fermer un onglet justifie, a mon sens, a lui seul le telechargement.
kha
pourrait interdire MISC et toute documentation sur le sujet (du style la conf de Elcomsoft sur l'e-book d'Adobe) ou encore les slides du projet X-Box Linux ?
Pour te donner un exemple, le DMCA interdit l'utilisation, la diffusion ou la possession de toute methode, protocole, algorithme ou outil qui permet de circonvenir une protection numerique.
Il est possible sur les CD audios "proteges" de passer outre le crash initial d'un PC en recouvrant la premiere piste avec un marqueur indelebile.(je ne pourrais en aucun cas etre tenu responsable si vous tentez le truc et que vous vous plantez...)
Moralite le feutre indelebile tombe sous le coup du DMCA. Drole non ?
Bon ben l'EUCD c'est un peu le meme principe. L'idee n'est pas de savoir ce qui est legal ou non, mais c'est de se rendre compte que si cette loi passe, les consortiums auront un pouvoir quasi illimite pour bloquer toute initiative concurrente.
AOL qui reproche a Microsoft de profiter de sa position monopolitque pour creer des situations d'incompatibilite....
Oracle qui en veut a Microsoft de profiter de son statut de standard de fait pour forcer la vente de licenses...
Je ne sais pas le gars, a mon avis il va pas falloir longtemps aux avocats de Microsoft pour monter une defense. La seule chose qu'une boite comme Oracle peut reprocher a Microsoft au niveau des pratiques commerciales c'est de tricher mieux qu'elle et a plus grande echelle. (Ce qui n'enleve rien au fait que les produits Oracle soient de bonne qualite).
Je ne souhaite qu'une chose c'est que cette plainte porte ses fruits, mais je trouve juste qu'ils y en a qui ne manquent pas de culot.
Kha
(bof que les loups se devorent entre eux)
C'est vrai qu'en theorie rien n'interdit a la blender association de se faire du ble sur le dos des donnateurs. Mais ce n'est pas pour ca qu'elle est en place.
Le code source de Blender est passe en GPL mais ca ne veut pas dire que l'ensemble de l'univers Blender est passe en GPL.
Les deux exemple les plus important sont le moteur temps reel, qui n'est pas libre, et le plugin web, qui n'est pas libre non plus.
NaN espere bien reussir a rebondir, ou du moins a gagner un peu d'argent avec ce passage en GPL. Bien que j'aurais d'un point de vue personel prefere avoir le plugin et le temps reel en GPL, je ne boude pas mon plaisir avec tout ce que l'on a deja.
La license non GPL de Blender est a mon avis une porte que NaN a voulu garder ouverte, de facon a pouvoir, a la demande de client, implementer un moteur temps reel ou mettre a jour le plug-in 3D sans pour autant devoir liberer les sources de ces deux extensions.
Je ne pense pas que NaN veuille s'acharner sur un split payant de Blender. Je pense plutot qu'il veulent pouvoir vendre leurs ameliorations (TR et Plugin) aux clients qui le leur demandent. Voir faire des adaptations sur mesure (les mecs de chez NaN ont encore une bien meilleure maitrise du code).
Si NaN a garde deux technos en proprietaire, c'est bien pour les exploiter, et il n'y a a mon sens rien de choquant a ce qu'ils preferent une license moins contraigante que la GPL pour faire cela. C'est pas le top au niveau communautaire, mais c'est parfaitement comprehensible d'un point de vue financier.
archi faux, tout depend de comment est architecture (sans le "r") ton micro-noyau
Ben oui. Ca depend. Il est parfaitement possible de faire du multitache preemptif dans un micro-noyau, et de faire de la planification stochastique des taches (ie d'exploser les fonctionalites linux). Cela ne change rien a ce que je disais, a part le cote programation "baleze" une architecture micro-noyau n'a que des avantages. Si Hurd gere de facon un peu brute les threads, c'est lie a l'implementation et non au choix d'une techno micro-noyeau.
Tres peu vendeur, la majorite de ce que tu dit la, peut etre dit sur certains "noyaux monolythiques"
Le mot clef que je n'ai peut-etre pas mis en valeur c'est "simultane"
on peut par exemple imaginer 40 personnes loguees sur un serveur en session terminal avec chacune un noyeau different, et un systeme de fichiers different (bien que donnant sur le meme disque dur). C'est vrai que certains noyaux monolythiques se rapprochent de ces fonctionalites, mais c'est le plus souvent par des methodes d'emulation et non par un comportement natif, donc au prix de la perf. De plus une fois l'emulateur en place, il bloque les ressources, et de fait interdit le lancement d'un autre emulateur un parallele, alors qu'un micro-noyau peut gerer autant de driver differents pour un meme peripherique que son implementation et le hardware le lui permettent.
Aux risques de me prendre un grand coup de lance flame en travers de la tronche, et aux risque de me faire traiter de trolleur a mon tour je me hasarderais a une question :
"en quoi est-ce un troll ?"
Les licenses BSD et MPL sont beaucoup plus souples que la GPL, ce qui est tout benef pour les entreprises qui ont a les meme droits que pour un projet GPL, mais pas le quart des devoirs. Bien que ce ne soit pas du tout conforme a l'esprit communautaire, il est plus interressant financierement et techniquement pour une boite de travailler sur un projet en BSD que sur un projet en GPL.
Le contre coup etant bien sur que les developpeurs qui ont envie de faire partie de la communeaute FSF vont developper de preference en GPL (justement pour eviter que des versions commerciales, avec des surcouches proprietaires ne sortent). Donc choisir un projet en BSD c'est se couper de l'appui potentiel d'un certains nombres de developpeurs (la reciproque n'etant pas completement vrai, assez peu de developpeur BSD/MPL sont anti GPL).
Verifier lorsque l'on est une petite boite de dev que le produit que l'on choisit dispose d'un bon support et d'un historique de deploiement significatif (quelque soit le type de license) me parait aussi quelque chose de tout a fait judicieux.
J'ai beau chercher je ne voit pas vraiment de troll, il y a plutot de l'enfoncage de portes ouvertes (BSD/MPL c'est moins contraignant donc c'est mieux, mais si il y a moins de developpeurs qui bossent dessus c'est moins bien, verifier que le projet n'est pas a l'agonie avant de choisir vos solutions), mais pas de troll
Et une fois de plus, 100 000 euros c'est pas un peu cher pour un truc pas tout complet et pas tout libre ?
Bon premierement vu le temps qu'il a fallu a la blender fondation pour amasser l'argent, on peut se dire que non 100 000 euros si pas si cher que ca. De plus ca permet d'avoir un logiciel de 3d professionnel libre, et ca c'est une exellente chose.
Blender est completement libre (pour etre exact il y a une version de Blender qui est completement libre). Mais les actionnaires de NAN n'aurait jamais accepte de liberer le code si ca avait ete au prix de se facher avec leur clients. C'est pourquoi il y a possibilite de se procurer une license non GPL, et c'est aussi vraissemblablement aussi pourquoi le moteur de rendu temps reel n'est pas compris dans le package(les technos ont probablement ete vendues).
On a a donc un Blender sans rendu temps reel qui est parfaitement libre et pleinement fonctionnel, de plus rien qui empeche qu'un moteur de rendu temps reel soit developpe par la suite.
Quand un troll a caractere officiel, generalement c'est un FUD. Mais bon vu que la il se situe de l'autre cote de la barriere c'est pas gagne non plus de lui donner cette apellation. C'est bete l'icone etait toute prete...
L'article est bien aussi. Vu q'aujourd'hui on peut construire une becanne de course pour moins de 1000 euros, c'est clair que le prix doit etre un bon facteur limitant.
Quand on sait en plus que la micro-informatique domestique est avec l'automobile un des secteurs qui s'est le mieux porte en 2002 (ie qui s'est pas retrouve a l'agonie du jour au lendemain) on rigole un peu.
Quand a en deduire que c'est a cause de la prise de position du SNEP sur le piratage c'est clair, c'est la raison majeure. Je connais personellement pleins de gens qui allaient acheter un ordinateur et qui ont renonces quand ils ont appris que recuperer gartuitement le dernier Britney Spear sur le net c'etait mal. Bientot des hordes d'anciens leechers se rendront compte qu'ils font quelquechose de pas bien du tout et arreteront de se connecter a internet pour defiler dans la rue en se flagellant au son des "Mea Culpa".
Il me semble que sous Postgres, ou peut coder un peu ce qu'on veut en procédural, non ? Que ce soit en pl/pgsql ou en C même...
C'est assez vrai, il y a un certain nombre de languages qui permettent d'ecrire des triggers qui sont supportes de base par PG. Mais il n'y a pas le meme niveau d'integration que dans Oracle (Par exemple la possibilite de suivre pas a pas une transaction ou un export de donnees). Oracle a encore de l'avance a ce niveau, meme si PG commence a talonner de pres.
L'intégrité de la base n'est-il pas un point fort de PostgreSQL (surtout par rapport à MySQL) ? Foreign keys, transactions, etc...
PG s'en sort pas mal au niveau des controles d'integrite c'est vrai. Mais il y a a peu pres le meme ecart entre MySQL et PG qu'entre PG et DB2. DB2 possede (entre autre) des systemes d'indexs variables entre les donees consolidees et celles qui ne le sont pas, un systemes de rollback multibase (capable de remettre en etat precedent une base de donnees fille quand un truc foire sur une autre) et un systeme de shadow data(copie conforme de la base a l'etat n-1) qui permet d'eviter un maximum d'annerie (surtout lors des imports et exports de donnees exterieures). A ce niveau la PG ne joue pas du tout dans la meme cour que DB2 (Oracle non plus d'ailleurs)
Tu parles de "vocation objet", ça implique quoi ? Pour moi Postgres est une BDD relationnelle en premier lieu. Peux-tu préciser ce que tu entends par "bien se servir de Postgres" (ou "mal") ? Je suis preneur de choses à éviter et de trucs à savoir. Par "ménage", tu parles de vacuum ou d'autre chose ?
Ben je suis un peu comme toi je tatonne. Je n'ai pas la pretention d'etre un maitre es PostgreSQL, mais je me suis rendu compte que les fonctionalites objets permetaient de faire pas mal de chose pour limiter les effets du vacuum.
Notemment sur un flux de donnees non consolide (infos clients non valides, warning de prod non confirmes, infos non verifies etc...). J'ai un systemes de logs d'evenements qui rentre les donnees dans une base PG. Prob 90% des evennements sont des consequences d'un autre probleme plus general (ie si un routeur tombe on se doute bien qu'il va y avoir 200 machines qui ne vont plus repondre au ping, et on s'en fiche pas mal(ceci est un exemple tout commentaire du type "cretin d'admin il avait doubler les routes " n'est pas le bienvenu) ). On se retrouve donc avec 201 incidents dont un seul qui nous interresse. Au final dans l'historique des evenements on ne gardera que celui qui nous interresse et on fichera les 200 autres a la poubelle. => 200 fantomes pour le vacuum, bon apetit.
Autre solution, on cree un type "incident1" un peu comme on creerait une table temporaire, on externalise ses donnees vers un fichier texte. Au moment de consolider la base, on detourne les incidents qui arrivent vers un type "incident2", on recupere le sinfos qui nous interresse dans le type "incident1", on detruit le type "incident1" (attention pas de betise l'artiste travaille sans filet) et on shoote les fichier texte. Et qund le vacuum passe il trouve des donnees qui ne veulent rien dire pour lui (donc qu'il n'aura aucun remors a supprimer) et qui sont tres limitees (ce ne sont que des pointeurs vers une ligne de texte).
Ca ecconomise pas mal de temps.
Par menage j'entend les deux choses : Consolidation + vacuum.
On les perd pourquoi ?
Ben je sais pas pour toi , mais moi j'aime pas que ma base soit modifiee a tire larigo sans que je sois au courant. PostgreSQL a donc sur ma machine son comilo C dedie, son TCL dedie, son interpreteur phyton a lui. (Bon je sais je suis un peu maniaque, mais dans un environement de production ca vaut mieux).
De plus je prefere mettre en place de base un certains nombre de regles (vis a vis des timestamp et des formats de date en general) avant de me lancer dans la creation de BD. Bon je ne te cache pas qu'avec mes manie sil me faut pas loin de 10 heures pour monter un serveur PG dont je sois content, mais je pense que trois heures pour etre propre c'est un minimum.
Bien que PostgreSQL prenne de plus en plus la voie d'un Oracle Killer, il n'en est pas encore la. Les deux gros points forts d'Oracle sont sa versatilite (j'ai un pote qui c'est amuse a coder un jeu d'echec en PL/SQL) et sa vitesse de traitement sur des bases importantes.
Oracle se fait encore fiche des pates memorables par deux bases de donnees sur deux points specifiques :
- Sybase pour tout ce qui est de la vitesse d'insertion et d'extraction de donnees dans une base fixe (ie pas de alter table ou de creation de tables temporaires). C'est pour ca que Sybase est utilise dans pas mal de projets temps reel (c'est aussi la base de reference du systeme boursier Reuters)
-DB2 pour tout ce qui est du suivi d'integrite de la base et la protection des donnees.
PostgreSQL reste cependant un tres bon systeme, nettement meilleur a bien des points de vue que les bases de donnes commerciales non industrielle (ie toutes sauf les trois monstres Sybase,DB2,ORACLE). Cependant il est vrai que Postgres est une base de donnee a voccation objet et que si on ne s'en sert pas bien il faut faire du menage sans arret (Ceci n'est pas un reproche pour les posts plus haut, il est tres difficile de bien se servir de PGSQL).
Independament de ca il est vrai que sur les grosses bases (3Go ou plus) indexes, faire une transaction puis faire un rollback prend un temps fou et necessite de faire un gros menage derriere.
Mais a part ce cas la, je ne crois pas qu'Oracle vaille encore le coup sur des machines standard (ie becanne a moins de 3000 euros). PostgreSQL s'en sort quasiment aussi bien. Par contre d'experience je dirais que les deux ou trois heures que l'on gagne a l'installation de postgreSQL sur Oracle, on les perd lors de la mise en place de la premiere base de donnees. Donc pas de veritables avantages sur ce point.
kha
Pour ceux que ca interresse , voici les avantages d'un micro-noyeau sur un noyeau monolithique (fut-il modulaire).
1- Un micro noyeau peut faire tout ce que fait un noyeau monolithique. Outre le fait que ca soit super chiant a coder (mais alors beaucoup) un micro noyeau n'a pas d'inconvennient.
2- Un micro noyeau agit pour les fonctions de base comme un noyeau (timing, semaphores, ressources etc..) par contre pour tout ce qui est drivers il est out. Ce qui veut dire non seulement que si un driver plante, vu que mon noyeau n'est pas plante je peux continuer a bosser, mais surtout que je peux choisir mes drivers a la volee en fonction de mes besoins, avec une granularite qui peut descendre jusqu'au thread.
En d'autre terme on peut tres bien imaginer une appli qui utilise un driver graphique pour 80% de ses fonctions mais qui fasse appel a un autre driver pour les operation OpenGL par exemple.
Bien sur on peut aussi imaginer un utilisateur root qui n'a pas les memes drivers de carte reseau que les autres (implementation de ETH0 par exemple).
De plus pour un systeme micro-noyeau un certains nombre de choses qui sont implementees par le kernel passe en drivers (Gestion memoire, filesystems etc..) toutes ces choses sont donc configurable et adaptable a un groupe, un utilisateur ou meme un processus.
Il est meme theoriquement de declarer un deuxieme micro noyeau comme driver et de se lancer a tire larigo dans du kernel hacking sans risquer une seule fois de planter sa machine. Ou de donner a chaque utilisateur un noyeau different.
Je pense pas que le probleme vienne de la. C'est vrai que ca va etre un coup dur pour le Mpeg4, mais ca sera la troisieme fois qu'il en prend plein les dents, il commence a avoir l'habitude.
Petit resume de la situation :
Chez Mpeg ce qu'ils voulaient c'est une norme qui marche bien chez tout le monde, un format federateur comme l'ont ete en leur temps le Mpeg video et le Mp3. Sauf que ca n'a pas marche.
Au tout depart il y a eu deux utilisation du format Mpeg4 :
ASF microsoft(Mpeg4 non iso avec systeme d'authentification) et Sorenson(Melange de Mpeg4 et de wavelets globalisees). Compatibilite de l'un avec l'autre : 0. Rate pour le format federateur.
Puis le divx 3.11 est arrive, hack complet du formet Mpeg4 proprio de Microsoft avec en moins les systemes d'authemtification, juste le codec a l'etat brut. Succes indeniable du format, mais comme il s'agit d'un hack personne ne gagne un centime. Je ne sais pas pourquoi personne n'a bouge et pourquoi Gej n'en a pas pris plein les dents, mais mon hypothese est que Microsoft n'avait pas envie de defendre un format qui n'etait pas a lui a proprement parle, et ainsi faire de la pub a ce qu'ils voyaient deja comme un concurrent, alors que chez mpeg, trop heureux de voir leur format remporter une certaines forme de succes, ils ont prefere attendre que ca devienne le standard avant de reclamer des sous...
Mais la reretournement de situation, une nouvelle generation de codecs "libre" fait son apparition (je met le libre entre guillemet parceque l'algo d'encodage utilise par ces codecs est sujet a royalties dans les pays qui reconnaissent les brevets logiciels). Projet Mayo d'abord, puis Xvid. Alors que parallelement des codecs non libres optimises font leur apparition (DivX4 puis 5, version quicktime pour ne citer que les plus connus).
A l'heure actuelle sur mon PC windows j'ai 5 codecs Mpeg4 differents qui couvrent une vingtaines de methodes d'encodage et de decodage (Windows Media video 7, Asf 7, sorenson, quicktime 6,Xvid, Divx5 ). Tous incompatibles les uns avec les autres. Federation du format : 0. Ouverture commerciale possible a grande echelle : 0(Aucun logiciel commercial ne voudra developper un support natif du Mpeg4 parcequ'il y a trop d'implementation differentes. De plus sur les deux grandes plateformes grand public (Mac & PC) il y aune foule de facon d'encoder et de decoder du mpeg4 vi plug-ins....)
Alors pourquoi Microsoft tuerait-il ce qui est deja mort ? Leur style c'est plutot de laisser l'adversaire en semi coma pour prouver au monde entier qu'ils n'ont pas vraiment un monopole. Non leur cible n'est definitevement pas le Mpeg4, je pense qu'il s'agit au contraire d'une demarche hyper logique dans la marche contre le libre. Je ne sais pas si vous avez jete un coup d'oeuil aux DLL des codecs de WMP9 mais c'est que du bonheur. Appels systeme a tire larigo, fonctionalites DirectShow exclusive (et pas les bons vieux codecs VFW qu'on peut faire marcher en un tour de main sous linux), transcodage de systeme de couleur via appels graphiques directs (ie fonctionnalites codees dans la carte graphique). Celui la pour le faire tourner sous linux on va clairement s'amuser. Et la je ne parle pas des sytemes d'authentifications ASX et des verifications de protection de copyright a gogo.
Ce que veux faire MS en baissant ses prix pour etendre son format (qui a deja la sympathie des majors grace a toutes les protections dont il s'entoure) c'est de priver les O.S libres d'un paquet de fonctionalites multimedias." Vous voulez mettre du linux dans votre PDA ? Ca c'est con vous pourrez jamais lire les wmv que tout le monde utilise...." Le but du jeu est d'empecher l'expension de linux et consors transversallement, ie empecher linux d'aller s'implanter sur les different embarques qui existent, voir au passage de taper aussi sur les pas libres bien sympa quand meme (QNX par exemple).Quand on voit comment un grand nombre de boites serieuses on reagit a l'annonce d'I2BP (format video qui sois disant presque pret qui sur le papier arrivait a un taux de compression supoerieur de 4 fois au maximum mathematique demontre), on peut attendre d'eux exactement la meme reaction quand MS fera une grande declaration sur son nouveau format (le 10eme). Et quand ils apprendront que ca ne marche que sous WinCE.....
Bien sur le but du jeu est aussi de limiter l'expension sur les machines persos. On s'est frappes pendant pres de deux ans sur l'ensemble des forums de la planete des hordes de trolls avec comme seul argument "C'est nul ton truc on peut meme pas lire de videos avec..." D'autant plus enrageant que meme si c'etait pas nul mon truc, c'etait vrai qu'on ne pouvait pas lire de video avec, et a l'epoque du multimedia roi ca craignait vachement. Le dvd venait de sortir, les codecs indeos etait au top, VFW (Video For Windows) progressait chaque jour, et sous linux pour lire une video (Mpeg quasi obligatoire) de facon correcte sur une becanne standard il fallait acheter un soft....
Aujourd'hui encore, lire un DVD ou un fichier avi "recent" n'est pas evident. Et on a comme un leger retard sur le firewire. Alors si en plus le format principal des videos rigolotes sur le net change pour un standard MS quasi impossible a transferer sous linux on est reparti pour un cycle de joie.
En fait le probleme est plus profond que ca, Il n'y a pas de drivers libre en 3D pour un certains nombre de raisons. Toutes peuvent se resumer a cela : Tout le monde triche.
A moins que vous ne vous payiez une station IRIX de chez SG au top niveau votre carte graphique n'est pas full openGL. Pas plus que sous windows il n'existe de carte full DirectX.
Ce qui se passe est assez simple, les applications sont tellement gourmandes de nos jours, les pipelines de rendus graphs tellement long (et la je parle meme pas des differents loop materiels et logiciels possibles) que tout le monde essaye de court-circuiter certaines etapes, voir carrement de tricher ouvertement.
On a vu des drivers a detection d'applis (quake3 a 100fps, puis si on renome l'executable en toto.exe il ne tourne plus qu'a 30fps)
On a vu des drivers rogner sur l'occusion culling (detection des faces caches avant rendus) pour limiter les polygones. Le seul cas de carte qui soit vraiment compatible completement avec un standard c'est la vidia XBOX qui est full DirectX 8. Mais bon vu les coupes faites par Crosoft dans directx c'est plus DirectX qui 100% compatible nvidia.
En ce qui concerne OpenGL c'est encore pire. Comme tout standard ouvert d'une part, et non dedie au rendu temps reel d'autre part (OpenGL est avant tout une librairie d'imagerie destinee a la generation d'etat graphiques) il y a encore dans OpenGL 1.2 un certains nombre de points qui ne sont accelere hardware par personne (toutes les fonctionalites render to render). Et on en est a OpenGL1.4. Si vous voyez une carte graphique avec dans sa pub ou sur sa boite marque en gros "full OpenGL compliant" vous pouvez eclater de rire.
Pour vous donner une idee, il y a en ce bas monde une norme qui s'apelle SQL92, tout le monde essaye de la respecter, mais personne ne peut se targuer de supporter pleinement le standard. Et les differentes boites de se balancer les arguments a la gueule. MS SQLServer avec son indexage reccord sur les base modeste (Qui explose litterallement si vous faites mumuse avec des timestamp). Sybase qui gere l'insertion et la destruction de donnees a la vitesse de l'eclair (Par contre Alter table....). DB2 qui garantit une integrite absolu des donnes (tant que personne ne demande "C'est quoi shadow datas ?") et Oracle qui supporte des bases de donnees monstrueuses a des vitesses etonnantes (mais n'allez pas regarder de trop pres comment il gere les BLOBs)
En d'autres termes tous ces trucs ont leurs avantages et leurs defauts et il est tres facile a n'importe lequel d'entre eux de creer une base de donnees qui va tourner du feu de dieux chez eux, et qui va crasher, ou du moins salement ralentir l'adversaire. Et de temps en temps ils le font. Generalement c'est suivi d'un tolle general. Qui met en avant la mauvaise fois de l'initiateur de la comparaison. Mais bon avant que la supercherie ne soit decouverte, qu'une equipe se monte, lance une batterie de tests et prouve le prob il s'ecoule souvent un moment.
Ben pour les cartes graphiques c'est pareil : on a eu une premiere guerre orchestree par Quake3 sur le fond TL ou pas TL, Full screen Antialiasing. Ensuite il y a eu bataille sur le theme de la supression des surfaces caches avant traitement. Etc..
Dans le cadre de projets on peut penser que tout ce qui interresse les devellopeurs c'est que ca marche et que ca arrive a suivre la demande. En fonction de ca ils font leur choix. Mais un joueur qui va foutre plus de 400 euros dans une carte graphique il veut ce qui a de mieux.
Le rapport avec les drivers ? Ben si les drivers sont relaches en Opensource, tout le monde peut voir comment sont mappes les instructions Opengl. Tout le monde peut voir comment va etre traite tel ou tel instruction ou suite d'instructions.
Et la le concurrent il a qu'a ceuillir toutes les bonnes idees (et ca c'est bien parceque l'OpenSource c'est un peu la pour ca) et a faire une demo qui demontre que la carte du concurrent elle triche en traitant de facon un peu legere certains cas hyper specifique.
Mais bon que va penser un consomateur en voyant une demo qui tourne a peu pres bien sur n'importe quelle carte graphique et qui, sur une carte specifique, ressemble a de la pate pour chat ? Ben il va en acheter une autre.
Pour l'instant, a l'heure ou la guerre ecco fait rage entre les fabriquants il faut bien admettre que soit ils relachent tous des drivers OS en meme temps. Soit le mec qui se jette a l'eau le premier se tire une balle dans le pied. Les gars vous pensez quand meme pas que les drivers d'une carte graphique changent tous les deux mois avec a chaque fois un gain de perf de 10-20% simplement parceque les mecs programment de mieux en mieux ?
Si on en juge d'après le procès Kitetoa//Tati il est parfaitement admis de découvrir une faille sur un site de voir jusqu'ou elle va (dans la limite d'utilisation d'outils conventionels comme un navigateur quand on est sur un site web) et de prevenir les admins.
Par contre il est vachement moins bien toléré d'exploiter ces failles, de prévenir qui que ce soit d'autre que l'admin, ou de revenir voir sur le site de temps en temps si la faille est toujours présente.
Par contre si vous vous faites pincer par l'admin (il y en a encore certains qui lisent leur logs) en train de visionner des données privées, là vous risquez gros. Vous prenez dans la gueule un procès pour intrusion à coup sur, et vous en risquez un autre pour "tentative de destruction de données privées" (pas sur des termes) ce qui est passible des mêmes peines que la destruction effectives des données. Et là je vous souhaite clairement bonne chance pour prouver vos bonnes intentions au départ.
OPEN BSD
bon ca a un peu moins d'impact maintenant, mais ca marche bien quand même.
-1 parcequ'on arrète pas un troll en en lançant un autre
Kha
---
on aurait pu dire
MILLENIUM BUG
aussi
Le plus drole reste quand même que :
1°) tu ne peux plus lire ton cd avec ton ordi (ben non c'est un système de protection)
2°) tu ne peux plus lire ton dvd avec ton ordi (pas la bonne zone monsieur)
3°) tu ne peux plus passer ton dvd sur ta télé (Macrovision faut désactiver l'écran pour pouvoir passer en mode télé monsieur et encore)
4°) tu ne peux pas connecter le son de ton PC à ta chaine ou à ton minidisc avec le cable optique (on ne sait jamais monsieur, qu'est ce qui me prouve que c'est bien l'anniversaire de votre petit neuveu sur ce minidisc ??)
Bref de façon générale on ne peut plus rien copier vers rien, et dans la plupart des cas on ne peut même pas lire. Mais bon on va quand même goinfrer 20 euros sur les disques durs au cas ou.
Moi j'utilise des bandes de 15 terra octets pour des recoupements de données boursières, alors l'annonce d'une redevance à la proportionelle ca me fait hurler de rire.
La bande vaut dans les 10 000 et il y aura a peu près 6850 de "redevance" dessus. Content là. Heureux.
-1 parceque je ne suis pas le plus à plaindre loin de là...
Kha
---
Contre toute attente Vivendi va refaire des benefs beaucoup plus vite que prévu....
Bon manifestement c'est corrigé alors je me lache.
Il y avait moyen de récupérer l'intégralité des infos sur la base. Il suffisait de s'y connaitre un peu en SQL et en Cold Fusion.
Pour un questionnaire sur la sécurité des données personelles c'est assez fort je trouve....
(NB: c'est pas très grave car il y avait aussi moyen d'effacer toute la base)
-1 pour cause de risques de retombées néfastes
Kha
---
A votre avis que doit on faire pour la sécurité des données ?
[] Embaucher des gens compétents pour le développement
[] Passer au moins dix minutes en test du site
[] Se renseigner au moins une fois tous les dix ans sur les exploits courants
Je ne pense pas que ma traduction soit fausse ou biaisée. Et de plus il est vrai qu'aucun patch n'est prévu. Une nouvelle version n'est pas un patch.
la version originale dit bien :
An (as yet) undisclosed bug exists in OpenSSH which a patch is not forthcoming for yet -- no patch exists yet!
Il est plus que probable que la nouvelle version risque d'entrainer des reconfigs, et peut être même un réaudit complet pour les systèmes "sensibles". Rien à voir avec l'installation d'un patch ou l'on sait que le mode de fonctionnment n'a pas bougé et que l'on peut garder les mêmes fichiers de configs et la même architecture de sécurité.
Tout a fait d'accord pour le bug Appache. Mais Apache ne fait pas partie de la base install d'OpenBSD, donc rien à dire. Bon c'est du pinaillage d'accord, mais il y a un paquet de package OpneBSD qui ont des failles. OpenBSD ne s'engage que sur l'install de base point.
Traduction :
Un bug non (encore) rendu public existe dans OpenSSH pour lequel aucun patch n'est prévu -- aucun pacth n'existe pour l'instant!
Néamoins une mise à jour vers OpenSSH 3.3 avec l'option UsePrivilegeSeparation activée permet de bloquer cette faille.
Il est conseillé à tous les utilisatuers de mettre à jour immédiatement, et de garder un oeuil sur la sortie de OpenSSH 3.4 qui aura lieu lundi et qui contiendra une vrai correction de cette faille.
Trois mondes s'effondrent :
1°) Il va falloir mettre à jour des BSD, comme dans "c'est obligatoire", "ca vaut mieux", "on prend des risques sinon"
2°) J'ignore si la faille existe dans le SSH propriétaire, mais si ce n'est pas le cas ca risque d'avoir des conséquences désastreuses sur certains newsgroups et forums.
3°) OpenBSD est fourni de base avec OpenSSH, donc les versions "anciennes" avaient ce trou de sécurité. Donc il y a un trou de sécurité dans l'installation par défaut d'OpenBSD, on a juste mis 5 ans à le trouver.
Ceci étant c'est le deuxième exploit d'OpenSSH en un mois (un autre impliquait l'utilisation d'YP avec Netgroup dans la base des mots de passes). C'est pas bon pour ma paranoia ca :).
Quoi quand vius recevez du spam vous ne vous désinscrivez pas ?
C'est un tort, moi dès que je recoit du spam, je me désinscrit, pleins de fois encore :)
C'est vrai que si on reçoit un spam une fois, on peut laisser de coté. Mais si on se reprend le même mail tous les jours il y a des moyens de se défendre
Exemple si je recoit un spam à toto@tutu.com
Je désinscrit immédiatement un bon milier d'emails tous plus faux les uns que les autres.
Une centaine de prénoms, de noms de famille et de domaines et hop on désinscrit en boucle via un script Perl. Avantage : ca rend la base de données des spammeurs inutilisable. Il y avait moyen de mettre en place un système similaire sur le web (des pages remplies de fausses adresses emails pour les robots) mais je ne retrouve plus le lien.
Une autre technique qui marche très bien contre le spam c'est la technique du catch all. Par exemple faire un catch all sur toto.com, puis s'inscrire sur le site grospam avec l'adresse email nospam.grospam@toto.com.
Si cette adresse se prend du spam:
1°-on sait d'ou ca vient
2°-on sort l'email du catch all pour la mettre en disable et hop la paix.
En effet il serait bon de créer une installation facile et fexible (Soit une distribution Linux ou BSD, soit un système d'interface HTML/Java) pour faciliter le passage au libre.
Mais un tel travail demande du temps. Y a-t-il déjà en France des groupes qui se sont attelés à la tache ? Un produit "out of the box" serait clairement un gros plus dans le combat contre l'uniformisation microsoftienne.
Bof tu sais il existe déjà un certains nombre de réseaux de "DNS pirates" qui te permettent en théorie de suivre à le trace des sites qui changent d'IP 15 fois par jour.
De toute façon le seul truc que va réussir à faire le tribunal c'est de convaincre de plus en plus de gens de ne pas enregistrer leur nom de domaine en France. Moi personellement ca ne me dérange pas de déposer mes noms de domaine chez un registar russe ou hollandais.
Kha
---
Connections : .........Loguées
Hebergeur : ...........Sous controle
Nom de domaine : ......Redirigé
Vous êtes maintenant connectés à internet
Bonjour monsieur Jean Dupond, 26 rue des mimosas.
[^] # Re: Les statistique Google reconnaissent les navigateurs basés sur Gecko
Posté par Jerome Herman . En réponse à la dépêche Les statistiques Google reconnaissent les navigateurs basés sur Gecko. Évalué à 9.
Oui et non. Il est vrai que si il n'y a que trois ou quatres moteurs sur le web, tu peux envisager de faire des codes specifique pour chacun d'entre eux, ou te limiter au niveau des fonctions pour sortir une page qui passe partout. Mais ca demande du temps, pas mal de tests et une pletore de code javascript pour ne pas se planter. Meme si ca a l'air techniquement faisable, cela entrainne un enorme surcout de devellopement et penalise grandement les technologies annexes et les petits browser. De plus quand on travaille pour un type de client particulier ca rend le dev quasi impossible. (Un exemple personel est un site il y a trois ans qui devait passer sous Netscape 3.x,4.x,IE,lynx sous PC/Mac/Unix/DOS tout en restant lisible pour des aveugles qui n'ont qu'une plage braille pour lire le site)
A l'inverse si il y a un bon nombre de navigateurs differents bases sur des moteurs independant, il y aura obligation d'uniformisation. Cela donnera beaucoup plus de poid au W3C (et beaucoup plus de travail aussi) et la notion de "site optimise pour X" disparaitra. En d'autre termes apres une periode de remous, le HTML deviendra une norme "reelle" (au sens ou personne ne pourra se permettre d'en ignorer ne serait-ce qu'une partie). Et la le travail des webmasters sera grandement simplifie.
A l'heure actuelle la technologie la plus repandue sur le web pour visualiser des donnees n'est pas IE, c'est Flash (95 a 97% des browsers). Pourquoi ce succes ? Tout simplement parceque flash garantit un comportement. Tout le cote casse-tete de la multicompatibilite disparait des que l'on choisit Flash. Et ca a commence bien avant que Gecko ou KHTML ne soient des projets "grand public" gerer 3 navigateurs (IE3 sous PC, Netscape 3 sous PC/MAC) etait deja un calvaire suffisant pour faire gagner des points a Flash. Donc le petit nombre de moteur de rendus n'est pas une aide pour les webmasters (loin de la meme, vu que dans la lutte pour la suprematie ils font tout pour se rendre incompatible les uns avec les autres).
Concernant Gecko,KHTML et consors il est absolument vital que ces projets coexistent. Contrairement a ce que tu as l'air de penser deux groupes de devellopement qui travaillent en parallele sont nettement plus efficace qu'un seul groupe de taille double. C'est un probleme bien connu en info le probleme du macon (aussi connu sous le nom du theoreme du trou) : Si un macon peut faire un mur en 1 heure, alors 3600 macons peuvent faire un mur en 1 seconde.
Inutile de dire que ce theoreme est une blague et que c'est completement faux.
Quel interet y-a-t-il a voir a la fois Gecko et KHTML ? Et bien dans tout dev il y a un paquet de choix qui sont fait, le design objet, le choix de techno, les priorites de dev, les optimisation etc... Et il arrive sur un projet a long terme dont on ne maitrise pas l'ensemble des contraintes (et pour le web je pense que personne ne maitrise l'ensemble des contraintes) que l'on se retrouve bloque ou fortement ralenti par un choix qui a ete fait longtemps avant. A ce moment la avoir un autre projet a cote qui a deja reflechi au probleme, voir meme qui a deja resolu le probleme et teste la solution fait gagner un temps fou. On ne compte plus le nombre de projet qui reparte "from scratch" parceque ce serait trop dur d'adapter l'existant a telle ou telle fonctionalite. Donc oui avoir deux ou trois groupes qui bossent sur des projets quasi identiques est une chance, et au final neuf fois sur dix tout le monde y gagne. KDE et Gnome se sont retrouve en "concurrence" (au sens emulation du terme) et n'ont pas hesite a echanger des infos, des points de vues et des methodes de dev. Je ne pense pas qu'aucun des deux projets serait aussi avance aujourd'hui sans cette concurence.
Kha
# Re: Mozilla : on agrandit la famille !
Posté par Jerome Herman . En réponse à la dépêche Mozilla : on agrandit la famille !. Évalué à -10.
[^] # Re: EUCD : Entrevue avec Loïc Dachary
Posté par Jerome Herman . En réponse à la dépêche EUCD : Entrevue avec Loïc Dachary. Évalué à 2.
Pour te donner un exemple, le DMCA interdit l'utilisation, la diffusion ou la possession de toute methode, protocole, algorithme ou outil qui permet de circonvenir une protection numerique.
Il est possible sur les CD audios "proteges" de passer outre le crash initial d'un PC en recouvrant la premiere piste avec un marqueur indelebile.(je ne pourrais en aucun cas etre tenu responsable si vous tentez le truc et que vous vous plantez...)
Moralite le feutre indelebile tombe sous le coup du DMCA. Drole non ?
Bon ben l'EUCD c'est un peu le meme principe. L'idee n'est pas de savoir ce qui est legal ou non, mais c'est de se rendre compte que si cette loi passe, les consortiums auront un pouvoir quasi illimite pour bloquer toute initiative concurrente.
Un petit exemple presque comique pour voir jusqu'ou ca peut aller :
http://www.ubersoft.net/d/20020823.html(...)
kha
# Osons !!
Posté par Jerome Herman . En réponse à la dépêche La CCIA dépose une plainte contre Microsoft auprès de l'UE. Évalué à 10.
[^] # Re: Double licence: et le risque de fork ?
Posté par Jerome Herman . En réponse à la dépêche Sortie de la première version Open Source de Blender. Évalué à 1.
Le code source de Blender est passe en GPL mais ca ne veut pas dire que l'ensemble de l'univers Blender est passe en GPL.
Les deux exemple les plus important sont le moteur temps reel, qui n'est pas libre, et le plugin web, qui n'est pas libre non plus.
NaN espere bien reussir a rebondir, ou du moins a gagner un peu d'argent avec ce passage en GPL. Bien que j'aurais d'un point de vue personel prefere avoir le plugin et le temps reel en GPL, je ne boude pas mon plaisir avec tout ce que l'on a deja.
La license non GPL de Blender est a mon avis une porte que NaN a voulu garder ouverte, de facon a pouvoir, a la demande de client, implementer un moteur temps reel ou mettre a jour le plug-in 3D sans pour autant devoir liberer les sources de ces deux extensions.
Je ne pense pas que NaN veuille s'acharner sur un split payant de Blender. Je pense plutot qu'il veulent pouvoir vendre leurs ameliorations (TR et Plugin) aux clients qui le leur demandent. Voir faire des adaptations sur mesure (les mecs de chez NaN ont encore une bien meilleure maitrise du code).
Si NaN a garde deux technos en proprietaire, c'est bien pour les exploiter, et il n'y a a mon sens rien de choquant a ce qu'ils preferent une license moins contraigante que la GPL pour faire cela. C'est pas le top au niveau communautaire, mais c'est parfaitement comprehensible d'un point de vue financier.
Kha
[^] # Re: Linux,
Posté par Jerome Herman . En réponse à la dépêche Linux, "successeur logique de AIX", selon IBM. Évalué à 1.
Ben oui. Ca depend. Il est parfaitement possible de faire du multitache preemptif dans un micro-noyau, et de faire de la planification stochastique des taches (ie d'exploser les fonctionalites linux). Cela ne change rien a ce que je disais, a part le cote programation "baleze" une architecture micro-noyau n'a que des avantages. Si Hurd gere de facon un peu brute les threads, c'est lie a l'implementation et non au choix d'une techno micro-noyeau.
Tres peu vendeur, la majorite de ce que tu dit la, peut etre dit sur certains "noyaux monolythiques"
Le mot clef que je n'ai peut-etre pas mis en valeur c'est "simultane"
on peut par exemple imaginer 40 personnes loguees sur un serveur en session terminal avec chacune un noyeau different, et un systeme de fichiers different (bien que donnant sur le meme disque dur). C'est vrai que certains noyaux monolythiques se rapprochent de ces fonctionalites, mais c'est le plus souvent par des methodes d'emulation et non par un comportement natif, donc au prix de la perf. De plus une fois l'emulateur en place, il bloque les ressources, et de fait interdit le lancement d'un autre emulateur un parallele, alors qu'un micro-noyau peut gerer autant de driver differents pour un meme peripherique que son implementation et le hardware le lui permettent.
kha
[^] # Re: Des trolls de competition dans l'article
Posté par Jerome Herman . En réponse à la dépêche Dossier Logiciels Libres sur Indexel.net. Évalué à 6.
"en quoi est-ce un troll ?"
Les licenses BSD et MPL sont beaucoup plus souples que la GPL, ce qui est tout benef pour les entreprises qui ont a les meme droits que pour un projet GPL, mais pas le quart des devoirs. Bien que ce ne soit pas du tout conforme a l'esprit communautaire, il est plus interressant financierement et techniquement pour une boite de travailler sur un projet en BSD que sur un projet en GPL.
Le contre coup etant bien sur que les developpeurs qui ont envie de faire partie de la communeaute FSF vont developper de preference en GPL (justement pour eviter que des versions commerciales, avec des surcouches proprietaires ne sortent). Donc choisir un projet en BSD c'est se couper de l'appui potentiel d'un certains nombres de developpeurs (la reciproque n'etant pas completement vrai, assez peu de developpeur BSD/MPL sont anti GPL).
Verifier lorsque l'on est une petite boite de dev que le produit que l'on choisit dispose d'un bon support et d'un historique de deploiement significatif (quelque soit le type de license) me parait aussi quelque chose de tout a fait judicieux.
J'ai beau chercher je ne voit pas vraiment de troll, il y a plutot de l'enfoncage de portes ouvertes (BSD/MPL c'est moins contraignant donc c'est mieux, mais si il y a moins de developpeurs qui bossent dessus c'est moins bien, verifier que le projet n'est pas a l'agonie avant de choisir vos solutions), mais pas de troll
Kha
[^] # Re: Sortie de la première version Open Source de Blender
Posté par Jerome Herman . En réponse à la dépêche Sortie de la première version Open Source de Blender. Évalué à 10.
Bon premierement vu le temps qu'il a fallu a la blender fondation pour amasser l'argent, on peut se dire que non 100 000 euros si pas si cher que ca. De plus ca permet d'avoir un logiciel de 3d professionnel libre, et ca c'est une exellente chose.
Blender est completement libre (pour etre exact il y a une version de Blender qui est completement libre). Mais les actionnaires de NAN n'aurait jamais accepte de liberer le code si ca avait ete au prix de se facher avec leur clients. C'est pourquoi il y a possibilite de se procurer une license non GPL, et c'est aussi vraissemblablement aussi pourquoi le moteur de rendu temps reel n'est pas compris dans le package(les technos ont probablement ete vendues).
On a a donc un Blender sans rendu temps reel qui est parfaitement libre et pleinement fonctionnel, de plus rien qui empeche qu'un moteur de rendu temps reel soit developpe par la suite.
Kha
(qui va essayer ca de suite aussi)
[^] # Re: France : les plaintes du SNEP provoquent le marasme Internet
Posté par Jerome Herman . En réponse à la dépêche France : les plaintes du SNEP provoquent le marasme Internet. Évalué à 1.
L'article est bien aussi. Vu q'aujourd'hui on peut construire une becanne de course pour moins de 1000 euros, c'est clair que le prix doit etre un bon facteur limitant.
Quand on sait en plus que la micro-informatique domestique est avec l'automobile un des secteurs qui s'est le mieux porte en 2002 (ie qui s'est pas retrouve a l'agonie du jour au lendemain) on rigole un peu.
Quand a en deduire que c'est a cause de la prise de position du SNEP sur le piratage c'est clair, c'est la raison majeure. Je connais personellement pleins de gens qui allaient acheter un ordinateur et qui ont renonces quand ils ont appris que recuperer gartuitement le dernier Britney Spear sur le net c'etait mal. Bientot des hordes d'anciens leechers se rendront compte qu'ils font quelquechose de pas bien du tout et arreteront de se connecter a internet pour defiler dans la rue en se flagellant au son des "Mea Culpa".
Kha
[^] # Re: linuxfr.org dans une base postgresql ?
Posté par Jerome Herman . En réponse à la dépêche linuxfr.org dans une base postgresql ?. Évalué à 3.
C'est assez vrai, il y a un certain nombre de languages qui permettent d'ecrire des triggers qui sont supportes de base par PG. Mais il n'y a pas le meme niveau d'integration que dans Oracle (Par exemple la possibilite de suivre pas a pas une transaction ou un export de donnees). Oracle a encore de l'avance a ce niveau, meme si PG commence a talonner de pres.
L'intégrité de la base n'est-il pas un point fort de PostgreSQL (surtout par rapport à MySQL) ? Foreign keys, transactions, etc...
PG s'en sort pas mal au niveau des controles d'integrite c'est vrai. Mais il y a a peu pres le meme ecart entre MySQL et PG qu'entre PG et DB2. DB2 possede (entre autre) des systemes d'indexs variables entre les donees consolidees et celles qui ne le sont pas, un systemes de rollback multibase (capable de remettre en etat precedent une base de donnees fille quand un truc foire sur une autre) et un systeme de shadow data(copie conforme de la base a l'etat n-1) qui permet d'eviter un maximum d'annerie (surtout lors des imports et exports de donnees exterieures). A ce niveau la PG ne joue pas du tout dans la meme cour que DB2 (Oracle non plus d'ailleurs)
Tu parles de "vocation objet", ça implique quoi ? Pour moi Postgres est une BDD relationnelle en premier lieu. Peux-tu préciser ce que tu entends par "bien se servir de Postgres" (ou "mal") ? Je suis preneur de choses à éviter et de trucs à savoir. Par "ménage", tu parles de vacuum ou d'autre chose ?
Ben je suis un peu comme toi je tatonne. Je n'ai pas la pretention d'etre un maitre es PostgreSQL, mais je me suis rendu compte que les fonctionalites objets permetaient de faire pas mal de chose pour limiter les effets du vacuum.
Notemment sur un flux de donnees non consolide (infos clients non valides, warning de prod non confirmes, infos non verifies etc...). J'ai un systemes de logs d'evenements qui rentre les donnees dans une base PG. Prob 90% des evennements sont des consequences d'un autre probleme plus general (ie si un routeur tombe on se doute bien qu'il va y avoir 200 machines qui ne vont plus repondre au ping, et on s'en fiche pas mal(ceci est un exemple tout commentaire du type "cretin d'admin il avait doubler les routes " n'est pas le bienvenu) ). On se retrouve donc avec 201 incidents dont un seul qui nous interresse. Au final dans l'historique des evenements on ne gardera que celui qui nous interresse et on fichera les 200 autres a la poubelle. => 200 fantomes pour le vacuum, bon apetit.
Autre solution, on cree un type "incident1" un peu comme on creerait une table temporaire, on externalise ses donnees vers un fichier texte. Au moment de consolider la base, on detourne les incidents qui arrivent vers un type "incident2", on recupere le sinfos qui nous interresse dans le type "incident1", on detruit le type "incident1" (attention pas de betise l'artiste travaille sans filet) et on shoote les fichier texte. Et qund le vacuum passe il trouve des donnees qui ne veulent rien dire pour lui (donc qu'il n'aura aucun remors a supprimer) et qui sont tres limitees (ce ne sont que des pointeurs vers une ligne de texte).
Ca ecconomise pas mal de temps.
Par menage j'entend les deux choses : Consolidation + vacuum.
On les perd pourquoi ?
Ben je sais pas pour toi , mais moi j'aime pas que ma base soit modifiee a tire larigo sans que je sois au courant. PostgreSQL a donc sur ma machine son comilo C dedie, son TCL dedie, son interpreteur phyton a lui. (Bon je sais je suis un peu maniaque, mais dans un environement de production ca vaut mieux).
De plus je prefere mettre en place de base un certains nombre de regles (vis a vis des timestamp et des formats de date en general) avant de me lancer dans la creation de BD. Bon je ne te cache pas qu'avec mes manie sil me faut pas loin de 10 heures pour monter un serveur PG dont je sois content, mais je pense que trois heures pour etre propre c'est un minimum.
Kha
[^] # Re: linuxfr.org dans une base postgresql ?
Posté par Jerome Herman . En réponse à la dépêche linuxfr.org dans une base postgresql ?. Évalué à 2.
[^] # Re: Linux,
Posté par Jerome Herman . En réponse à la dépêche Linux, "successeur logique de AIX", selon IBM. Évalué à 10.
1- Un micro noyeau peut faire tout ce que fait un noyeau monolithique. Outre le fait que ca soit super chiant a coder (mais alors beaucoup) un micro noyeau n'a pas d'inconvennient.
2- Un micro noyeau agit pour les fonctions de base comme un noyeau (timing, semaphores, ressources etc..) par contre pour tout ce qui est drivers il est out. Ce qui veut dire non seulement que si un driver plante, vu que mon noyeau n'est pas plante je peux continuer a bosser, mais surtout que je peux choisir mes drivers a la volee en fonction de mes besoins, avec une granularite qui peut descendre jusqu'au thread.
En d'autre terme on peut tres bien imaginer une appli qui utilise un driver graphique pour 80% de ses fonctions mais qui fasse appel a un autre driver pour les operation OpenGL par exemple.
Bien sur on peut aussi imaginer un utilisateur root qui n'a pas les memes drivers de carte reseau que les autres (implementation de ETH0 par exemple).
De plus pour un systeme micro-noyeau un certains nombre de choses qui sont implementees par le kernel passe en drivers (Gestion memoire, filesystems etc..) toutes ces choses sont donc configurable et adaptable a un groupe, un utilisateur ou meme un processus.
Il est meme theoriquement de declarer un deuxieme micro noyeau comme driver et de se lancer a tire larigo dans du kernel hacking sans risquer une seule fois de planter sa machine. Ou de donner a chaque utilisateur un noyeau different.
Kha
# Re: Microsoft tente de déstabiliser le MPEG-4
Posté par Jerome Herman . En réponse à la dépêche Microsoft tente de déstabiliser le MPEG-4. Évalué à 2.
Petit resume de la situation :
Chez Mpeg ce qu'ils voulaient c'est une norme qui marche bien chez tout le monde, un format federateur comme l'ont ete en leur temps le Mpeg video et le Mp3. Sauf que ca n'a pas marche.
Au tout depart il y a eu deux utilisation du format Mpeg4 :
ASF microsoft(Mpeg4 non iso avec systeme d'authentification) et Sorenson(Melange de Mpeg4 et de wavelets globalisees). Compatibilite de l'un avec l'autre : 0. Rate pour le format federateur.
Puis le divx 3.11 est arrive, hack complet du formet Mpeg4 proprio de Microsoft avec en moins les systemes d'authemtification, juste le codec a l'etat brut. Succes indeniable du format, mais comme il s'agit d'un hack personne ne gagne un centime. Je ne sais pas pourquoi personne n'a bouge et pourquoi Gej n'en a pas pris plein les dents, mais mon hypothese est que Microsoft n'avait pas envie de defendre un format qui n'etait pas a lui a proprement parle, et ainsi faire de la pub a ce qu'ils voyaient deja comme un concurrent, alors que chez mpeg, trop heureux de voir leur format remporter une certaines forme de succes, ils ont prefere attendre que ca devienne le standard avant de reclamer des sous...
Mais la reretournement de situation, une nouvelle generation de codecs "libre" fait son apparition (je met le libre entre guillemet parceque l'algo d'encodage utilise par ces codecs est sujet a royalties dans les pays qui reconnaissent les brevets logiciels). Projet Mayo d'abord, puis Xvid. Alors que parallelement des codecs non libres optimises font leur apparition (DivX4 puis 5, version quicktime pour ne citer que les plus connus).
A l'heure actuelle sur mon PC windows j'ai 5 codecs Mpeg4 differents qui couvrent une vingtaines de methodes d'encodage et de decodage (Windows Media video 7, Asf 7, sorenson, quicktime 6,Xvid, Divx5 ). Tous incompatibles les uns avec les autres. Federation du format : 0. Ouverture commerciale possible a grande echelle : 0(Aucun logiciel commercial ne voudra developper un support natif du Mpeg4 parcequ'il y a trop d'implementation differentes. De plus sur les deux grandes plateformes grand public (Mac & PC) il y aune foule de facon d'encoder et de decoder du mpeg4 vi plug-ins....)
Alors pourquoi Microsoft tuerait-il ce qui est deja mort ? Leur style c'est plutot de laisser l'adversaire en semi coma pour prouver au monde entier qu'ils n'ont pas vraiment un monopole. Non leur cible n'est definitevement pas le Mpeg4, je pense qu'il s'agit au contraire d'une demarche hyper logique dans la marche contre le libre. Je ne sais pas si vous avez jete un coup d'oeuil aux DLL des codecs de WMP9 mais c'est que du bonheur. Appels systeme a tire larigo, fonctionalites DirectShow exclusive (et pas les bons vieux codecs VFW qu'on peut faire marcher en un tour de main sous linux), transcodage de systeme de couleur via appels graphiques directs (ie fonctionnalites codees dans la carte graphique). Celui la pour le faire tourner sous linux on va clairement s'amuser. Et la je ne parle pas des sytemes d'authentifications ASX et des verifications de protection de copyright a gogo.
Ce que veux faire MS en baissant ses prix pour etendre son format (qui a deja la sympathie des majors grace a toutes les protections dont il s'entoure) c'est de priver les O.S libres d'un paquet de fonctionalites multimedias." Vous voulez mettre du linux dans votre PDA ? Ca c'est con vous pourrez jamais lire les wmv que tout le monde utilise...." Le but du jeu est d'empecher l'expension de linux et consors transversallement, ie empecher linux d'aller s'implanter sur les different embarques qui existent, voir au passage de taper aussi sur les pas libres bien sympa quand meme (QNX par exemple).Quand on voit comment un grand nombre de boites serieuses on reagit a l'annonce d'I2BP (format video qui sois disant presque pret qui sur le papier arrivait a un taux de compression supoerieur de 4 fois au maximum mathematique demontre), on peut attendre d'eux exactement la meme reaction quand MS fera une grande declaration sur son nouveau format (le 10eme). Et quand ils apprendront que ca ne marche que sous WinCE.....
Bien sur le but du jeu est aussi de limiter l'expension sur les machines persos. On s'est frappes pendant pres de deux ans sur l'ensemble des forums de la planete des hordes de trolls avec comme seul argument "C'est nul ton truc on peut meme pas lire de videos avec..." D'autant plus enrageant que meme si c'etait pas nul mon truc, c'etait vrai qu'on ne pouvait pas lire de video avec, et a l'epoque du multimedia roi ca craignait vachement. Le dvd venait de sortir, les codecs indeos etait au top, VFW (Video For Windows) progressait chaque jour, et sous linux pour lire une video (Mpeg quasi obligatoire) de facon correcte sur une becanne standard il fallait acheter un soft....
Aujourd'hui encore, lire un DVD ou un fichier avi "recent" n'est pas evident. Et on a comme un leger retard sur le firewire. Alors si en plus le format principal des videos rigolotes sur le net change pour un standard MS quasi impossible a transferer sous linux on est reparti pour un cycle de joie.
Kha
[^] # Re: Que les constructeurs developpent les drivers eux-memes
Posté par Jerome Herman . En réponse à la dépêche Free Drivers Petition. Évalué à 5.
A moins que vous ne vous payiez une station IRIX de chez SG au top niveau votre carte graphique n'est pas full openGL. Pas plus que sous windows il n'existe de carte full DirectX.
Ce qui se passe est assez simple, les applications sont tellement gourmandes de nos jours, les pipelines de rendus graphs tellement long (et la je parle meme pas des differents loop materiels et logiciels possibles) que tout le monde essaye de court-circuiter certaines etapes, voir carrement de tricher ouvertement.
On a vu des drivers a detection d'applis (quake3 a 100fps, puis si on renome l'executable en toto.exe il ne tourne plus qu'a 30fps)
On a vu des drivers rogner sur l'occusion culling (detection des faces caches avant rendus) pour limiter les polygones. Le seul cas de carte qui soit vraiment compatible completement avec un standard c'est la vidia XBOX qui est full DirectX 8. Mais bon vu les coupes faites par Crosoft dans directx c'est plus DirectX qui 100% compatible nvidia.
En ce qui concerne OpenGL c'est encore pire. Comme tout standard ouvert d'une part, et non dedie au rendu temps reel d'autre part (OpenGL est avant tout une librairie d'imagerie destinee a la generation d'etat graphiques) il y a encore dans OpenGL 1.2 un certains nombre de points qui ne sont accelere hardware par personne (toutes les fonctionalites render to render). Et on en est a OpenGL1.4. Si vous voyez une carte graphique avec dans sa pub ou sur sa boite marque en gros "full OpenGL compliant" vous pouvez eclater de rire.
Pour vous donner une idee, il y a en ce bas monde une norme qui s'apelle SQL92, tout le monde essaye de la respecter, mais personne ne peut se targuer de supporter pleinement le standard. Et les differentes boites de se balancer les arguments a la gueule. MS SQLServer avec son indexage reccord sur les base modeste (Qui explose litterallement si vous faites mumuse avec des timestamp). Sybase qui gere l'insertion et la destruction de donnees a la vitesse de l'eclair (Par contre Alter table....). DB2 qui garantit une integrite absolu des donnes (tant que personne ne demande "C'est quoi shadow datas ?") et Oracle qui supporte des bases de donnees monstrueuses a des vitesses etonnantes (mais n'allez pas regarder de trop pres comment il gere les BLOBs)
En d'autres termes tous ces trucs ont leurs avantages et leurs defauts et il est tres facile a n'importe lequel d'entre eux de creer une base de donnees qui va tourner du feu de dieux chez eux, et qui va crasher, ou du moins salement ralentir l'adversaire. Et de temps en temps ils le font. Generalement c'est suivi d'un tolle general. Qui met en avant la mauvaise fois de l'initiateur de la comparaison. Mais bon avant que la supercherie ne soit decouverte, qu'une equipe se monte, lance une batterie de tests et prouve le prob il s'ecoule souvent un moment.
Ben pour les cartes graphiques c'est pareil : on a eu une premiere guerre orchestree par Quake3 sur le fond TL ou pas TL, Full screen Antialiasing. Ensuite il y a eu bataille sur le theme de la supression des surfaces caches avant traitement. Etc..
Dans le cadre de projets on peut penser que tout ce qui interresse les devellopeurs c'est que ca marche et que ca arrive a suivre la demande. En fonction de ca ils font leur choix. Mais un joueur qui va foutre plus de 400 euros dans une carte graphique il veut ce qui a de mieux.
Le rapport avec les drivers ? Ben si les drivers sont relaches en Opensource, tout le monde peut voir comment sont mappes les instructions Opengl. Tout le monde peut voir comment va etre traite tel ou tel instruction ou suite d'instructions.
Et la le concurrent il a qu'a ceuillir toutes les bonnes idees (et ca c'est bien parceque l'OpenSource c'est un peu la pour ca) et a faire une demo qui demontre que la carte du concurrent elle triche en traitant de facon un peu legere certains cas hyper specifique.
Mais bon que va penser un consomateur en voyant une demo qui tourne a peu pres bien sur n'importe quelle carte graphique et qui, sur une carte specifique, ressemble a de la pate pour chat ? Ben il va en acheter une autre.
Pour l'instant, a l'heure ou la guerre ecco fait rage entre les fabriquants il faut bien admettre que soit ils relachent tous des drivers OS en meme temps. Soit le mec qui se jette a l'eau le premier se tire une balle dans le pied. Les gars vous pensez quand meme pas que les drivers d'une carte graphique changent tous les deux mois avec a chaque fois un gain de perf de 10-20% simplement parceque les mecs programment de mieux en mieux ?
Kha
[^] # Re: Attention à la législation française
Posté par Jerome Herman . En réponse à la dépêche compte-rendu d'un pot de miel avec OpenBSD 3.0. Évalué à 10.
Par contre il est vachement moins bien toléré d'exploiter ces failles, de prévenir qui que ce soit d'autre que l'admin, ou de revenir voir sur le site de temps en temps si la faille est toujours présente.
Par contre si vous vous faites pincer par l'admin (il y en a encore certains qui lisent leur logs) en train de visionner des données privées, là vous risquez gros. Vous prenez dans la gueule un procès pour intrusion à coup sur, et vous en risquez un autre pour "tentative de destruction de données privées" (pas sur des termes) ce qui est passible des mêmes peines que la destruction effectives des données. Et là je vous souhaite clairement bonne chance pour prouver vos bonnes intentions au départ.
kha
# Une seule chose à dire
Posté par Jerome Herman . En réponse à la dépêche Une étude met dos-à-dos logiciels libres et propriétaires. Évalué à -5.
[^] # Re: Pas pour moi
Posté par Jerome Herman . En réponse à la dépêche Les disques durs bientôt taxés ?. Évalué à 10.
# Mort de rire
Posté par Jerome Herman . En réponse à la dépêche La Commission Européenne vous sonde. Évalué à 10.
Il y avait moyen de récupérer l'intégralité des infos sur la base. Il suffisait de s'y connaitre un peu en SQL et en Cold Fusion.
Pour un questionnaire sur la sécurité des données personelles c'est assez fort je trouve....
(NB: c'est pas très grave car il y avait aussi moyen d'effacer toute la base)
-1 pour cause de risques de retombées néfastes
Kha
---
A votre avis que doit on faire pour la sécurité des données ?
[] Embaucher des gens compétents pour le développement
[] Passer au moins dix minutes en test du site
[] Se renseigner au moins une fois tous les dix ans sur les exploits courants
[^] # Re: Euh, y a un trou là...
Posté par Jerome Herman . En réponse à la dépêche Vulnérabilité OpenSSH. Évalué à 4.
la version originale dit bien :
An (as yet) undisclosed bug exists in OpenSSH which a patch is not forthcoming for yet -- no patch exists yet!
Il est plus que probable que la nouvelle version risque d'entrainer des reconfigs, et peut être même un réaudit complet pour les systèmes "sensibles". Rien à voir avec l'installation d'un patch ou l'on sait que le mode de fonctionnment n'a pas bougé et que l'on peut garder les mêmes fichiers de configs et la même architecture de sécurité.
Kha
---
Un brin pinailleur aujourd'hui
[^] # Re: Euh, y a un trou là...
Posté par Jerome Herman . En réponse à la dépêche Vulnérabilité OpenSSH. Évalué à 8.
Kha
---
Paranoia Complex.
# Euh, y a un trou là...
Posté par Jerome Herman . En réponse à la dépêche Vulnérabilité OpenSSH. Évalué à 10.
http://www.openbsd.org/errata.html(...)
Traduction :
Un bug non (encore) rendu public existe dans OpenSSH pour lequel aucun patch n'est prévu -- aucun pacth n'existe pour l'instant!
Néamoins une mise à jour vers OpenSSH 3.3 avec l'option UsePrivilegeSeparation activée permet de bloquer cette faille.
Il est conseillé à tous les utilisatuers de mettre à jour immédiatement, et de garder un oeuil sur la sortie de OpenSSH 3.4 qui aura lieu lundi et qui contiendra une vrai correction de cette faille.
Trois mondes s'effondrent :
1°) Il va falloir mettre à jour des BSD, comme dans "c'est obligatoire", "ca vaut mieux", "on prend des risques sinon"
2°) J'ignore si la faille existe dans le SSH propriétaire, mais si ce n'est pas le cas ca risque d'avoir des conséquences désastreuses sur certains newsgroups et forums.
3°) OpenBSD est fourni de base avec OpenSSH, donc les versions "anciennes" avaient ce trou de sécurité. Donc il y a un trou de sécurité dans l'installation par défaut d'OpenBSD, on a juste mis 5 ans à le trouver.
Ceci étant c'est le deuxième exploit d'OpenSSH en un mois (un autre impliquait l'utilisation d'YP avec Netgroup dans la base des mots de passes). C'est pas bon pour ma paranoia ca :).
Kha
---
OpenBSD Power quand même na!
[^] # Re: Eliza et ChatBot
Posté par Jerome Herman . En réponse à la dépêche Bloquer le SPAM avec Postfix. Évalué à 2.
C'est un tort, moi dès que je recoit du spam, je me désinscrit, pleins de fois encore :)
C'est vrai que si on reçoit un spam une fois, on peut laisser de coté. Mais si on se reprend le même mail tous les jours il y a des moyens de se défendre
Exemple si je recoit un spam à toto@tutu.com
Je désinscrit immédiatement un bon milier d'emails tous plus faux les uns que les autres.
Une centaine de prénoms, de noms de famille et de domaines et hop on désinscrit en boucle via un script Perl. Avantage : ca rend la base de données des spammeurs inutilisable. Il y avait moyen de mettre en place un système similaire sur le web (des pages remplies de fausses adresses emails pour les robots) mais je ne retrouve plus le lien.
Une autre technique qui marche très bien contre le spam c'est la technique du catch all. Par exemple faire un catch all sur toto.com, puis s'inscrire sur le site grospam avec l'adresse email nospam.grospam@toto.com.
Si cette adresse se prend du spam:
1°-on sait d'ou ca vient
2°-on sort l'email du catch all pour la mettre en disable et hop la paix.
N'oubliez pas de réviser vos classiques
http://www.euro.cauce.org/(...)
Kha
---
This post was implicitly sollicited
[^] # Re: Excellent, mais ...
Posté par Jerome Herman . En réponse à la dépêche Un collectif d'enseignants lance une campagne d'information sur les logiciels libres. Évalué à 10.
Mais un tel travail demande du temps. Y a-t-il déjà en France des groupes qui se sont attelés à la tache ? Un produit "out of the box" serait clairement un gros plus dans le combat contre l'uniformisation microsoftienne.
Kha
---
# Le rève de toute une vie de Kook
Posté par Jerome Herman . En réponse à la dépêche Certains osent critiquer Mozilla. Évalué à 0.
Une mode qui va faire des émules je le sens.
Kha
---
<plonk> (01 was succesfully added to your killfile)
[^] # Re: Changé de nom de domaine ?
Posté par Jerome Herman . En réponse à la dépêche Gandi sollicité pour interdire l'accès d'un site. Évalué à 10.
De toute façon le seul truc que va réussir à faire le tribunal c'est de convaincre de plus en plus de gens de ne pas enregistrer leur nom de domaine en France. Moi personellement ca ne me dérange pas de déposer mes noms de domaine chez un registar russe ou hollandais.
Kha
---
Connections : .........Loguées
Hebergeur : ...........Sous controle
Nom de domaine : ......Redirigé
Vous êtes maintenant connectés à internet
Bonjour monsieur Jean Dupond, 26 rue des mimosas.