P...n, tu m'étonnes après qu'on dit que le C est un langage de goret. Bon, je vois 3 fautes monumentales dans ces 5 pauvres lignes :
- Ta conversion de param en va_list n'est pas du tout portable, j'espère que tu n'auras pas à le tester sur d'autres archie. Sympa pour ceux qui vont maintenir ça après ...
- Utilise au moins vsnprintf, ça coute pas beaucoup plus cher, et tu éviteras un petit buffer overflow (surtout avec une taille de 100 octets). J'espère qu'il n'est pas trop critique ce code (pas d'accès public).
- Tes paramètres passés directement à sprintf, j'espère que tu es sûr de leur contenu, parce que c'est du pain bénit pour l'injection SQL, bref une faille de sécurité monumentale. Clairement, il ne vaut mieux pas qu'il soit public ton code.
La construction à la main d'un type va_list n'est pas du tout portable. Forcément sous Windows ça limite les choix, mais je parirai que le code qu'ils t'ont filé doit être hyper casse gueule. À ta place je reverrais légèrement ton "algo" :
#define MAX 1024
char buffer[MAX];
int usage = 0;
usage = sprintf(buffer, "%s", "UPDATE t_table set ");
if (bon1)
{
// Hum, hum, fait gaffe à l'SQL injection hein ....
usage += snprintf(buffer + usage, MAX - usage, " col1='%s',", param1);
}
if (bon2)
{
// Idem ici
usage += snprintf(buffer + usage, MAX - usage, " col2='%s',", param2);
}
/* .... */
C'est un poil plus complexe, parce qu'il y a vérification des débordements, mais si tu n'en a rien à foutre, tu pourras grandement simplifier le code ...
Sinon, je ne sais pas quel SGBD tu utilises, main en général dans l'API d'accès à la base, il y a des fonctions toutes prêtes pour gérer beaucoup plus proprement ce genre de problèmes (PostgreSQL et SQLite au moins).
Dans le même genre, quand tu es habitué à un certain éditeur de texte dont on taira le nom, Ctrl+W, c'est pour effacer un mot (le fameux ^W). Argh, combien de page de wiki j'ai pu fermer avec ça !!
P...n t'es lourd. Tu pourrais arrêter de pleurnicher parce que deux pauvres de tes commentaires n'ont pas les notes que tu penses qu'ils méritent dans les quinze nano-secondes après les avoir posté ? Parce que là, ça vole pas plus haut que le bac à sable des écoles primaires, alors pour ceux qui ont le QI le plus bas, tu devrais chercher un peu plus près de chez toi...
Bref, keep cool, éteint ta machine, sort et revient dans quelques jours, tu verras la vie est belle.
Tu peux utiliser des FastCGI aux lieux de simples CGI. Comme Google et co te donneront suffisament de doc et de choses à tester pour t'occuper les six prochains mois, je ne peux que te souhaiter bonne chance ....
En gros les FastCGI te permettront d'avoir des processus persistants et maintenir des sessions assez facilement avec un peu d'immagination, plutôt que te trimbaler des balises hidden de pages HTML en pages HTML. Mais bon, comme dit le commentaire au-dessus, mixer plusieurs langages ça risque d'être assez plantogène (tu as du remarquer que le débugage des CGI c'est pas très marrant, hein ?), surtout si tu débutes ...
Une dernière solution pourrait utiliser des buzzwords comme J2EE, Structs, Hibernate, Lead architect et Pierre Tramo, mais là il faut avoir quelques années devant soit ...
Posté par pierthi .
En réponse au message Perl html.
Évalué à 1.
À mon avis ton problème se résume simplement à un problème de chemin d'accès. Ton cgi doit s'exécuter dans /cgi-bin/ et tes fichiers (dont image.jpg) doivent se trouver dans /var/www/data ou un truc du genre. 2 solutions :
Ajoute style="background-image: url('/image.jpg')" à la balise body.
Ou rajoute <base href="/index.html" /> dans l'entête HTML.
Qu'est qu'il t'a fait ce Finder pour le détester comme ça ? Perso, je trouve plutôt pas mal avec ses 3 types de vues (icônes, listes/arbo, colonnes à la NextStep), accessibles en 1 clic de souris avec possibilité de switcher en mode spatial "à l'ancienne". Drag'n drop pas trop mal entre la plupart des applis. Bref rien de transcendatelement super différent de ce qui ce fait ailleurs.
Bon, ok, si tu cherches un gestionnaire de fichier à la rox-filer pour appliquer toutes sortes de filtres ou de commandes aux fichiers d'un répertoire, séléction par regex, ou un truc à la konqueror où tu peux éditer ton document koffice avec un panel ftp qui t'affiche la température de ta cafetière, tu as du remarquer que ce n'est pas trop dans la philosophie Mac (tu as quand même le montage +/- transparent des .iso, .dmg, site FTP, WebDAV et connexions SMB). De toute façon le terminal est là pour les trucs tordus.
Ce qui me gave principalement, c'est les problèmes de rafraichissement des fichiers créés autrement que par le finder (surtout avec SMB). Eh non il n'y a pas de commande "rafraichir le p...n de dossier" (la seule bidouille que j'ai trouvée, c'est de créer un dossier ou de faire un kill -9 sur le finder).
Donc, voilà, c'est juste un gestionnaire de fichier, ne cherches pas à faire du café avec, hein ...
(1) ne plus ménager de temps du tout pour leur activité Debian
Gniii ?!! Si ces gars étaient à l'origine bénévole, il y a mille et une autres raisons pour que cela arrive : manque d'intérêt, mariage, naissance de gamins, problèmes persos, etc ... Alors d'un coté on tape sur Canonical, mais pour les autres raisons j'ai comme l'impression qu'on aurait rien dit. Un poids, deux mesures ? Si Debian n'a pas prévu ça, c'est 100 % de leur faute. Si leurs travaux sont si critiques, à eux de faire en sorte qu'ils puissent se transmettre à un autre, donc documenter, toussa ... Pareil pour (4).
Concernant Ubuntu et le libre
Euh, t'es au courrant qu'il y en (beaucoup) pour qui l'informatique n'est qu'un moyen pas une fin ? Même rapporter un bug, corriger une doc, ça prends du temps. Ca me rappelle un phrase un peu dure, que j'ai lue dans un forum : "il n"y que les fous furieux de l'opensource gratuit pour croire que le temps ne coûte rien." Tout le monde n'est pas informaticien, et à encore moins envie de l'être. Mais bon tu connais le cercle vicieux : pas d'utilisateurs, pas de besoins, pas de besoins pas de logiciels, pas logiciels pas d'utilisateurs.
En tous les cas, ce n'est pas avec la part de marché de Linux, qu'on pourra un jour avoir des drivers libres et qu'on pourra se passer d'hacks immondes pour faire tourner certains. Là encore pas de drivers potables, pas d'utilisateurs, pas d'utilisateurs, aucun intérêt de libérer les drivers.
Franchement, utilisateur de Mandriva, je vois plus ça comme une guéguerre stérile qui va encore provoquer des scissions à la BSD, avec tous les gâchis et les pertes de temps que cela présuppose. Diviser pour régner, qu'ils disaient. P...n, c'est pas gagné.
Heu un format d'image bitmap libre quasi universel il y a le TIFF, hein. Très bon support sous Mac OS X, pas mal sous Linux et littéralement à chier sous Windows (en natif).
Pour remplacer le PDF/Postscript, il va falloir se lever tôt. Ça fait pratiquement 25 ans que le Postscript existe. Ces formats sont tellement répandus et éprouvés dans l'imprimerie, qu'ils sont pratiquement indéboulonables. Ce n'est pas qu'une question de quelques logiciels phares (où MS Office est d'ailleurs complètement marginal). Pratiquement tous les logiciels, des généralistes comme ceux d'Adobe, ou des trucs plus pointus (trapping, imposition, RIP, ...) savent utiliser ce format, et l'utilise pour dialoguer avec des applications complètement hétérogènes, sans parler des imprimantes.
Il faudra que MS arrive à convaincre un sacré paquet de monde avant de voir adopter leur format, surtout que le PDF/Postscript couvre déjà la plupart des besoins d'un imprimeur et je doute fortement que MS fasse beaucoup mieux. Quand je vois les emmerdes qu'il y a avec le format Word, je me dis que MS ne comprends strictement rien qux besoins des imprimeurs (besoin d'un format interopérable et durable avec un rendu stable).
Bah, euh, le coup de la preview, effectivement, certains logiciels (Photoshop et MacOS X le font depuis un bout de temps) utilise plusieurs images dans le même fichiers TIFF à des résolutions différentes.
Pour le taux de compression, ça dépend quand même un peu beaucoup des données que tu as en entrée. Du 1bit compressé en JPEG, doit donner des résultats misérablissime comparés à du Group4, sans parler des artéfacts. Pareil pour des images avec pas mal d'applats, la compression Flate/RLE donne d'excellent résultats, sans pertes. C'est clairement une des forces de ce format de pouvoir utiliser une compression adapté aux données de l'image. D'ailleur vu l'universalité et la légèreté de ce format, je me demande pourquoi il n'est pas aussi répandu que le JPEG ou le PNG.
Faut dire que si le support natif dans Windows n'était pas aussi pourri, ça aiderait sans doute un peu.
Ha, ha, ils sont au courrant que le TIFF sait faire ça et bien plus encore depuis, boaf, au moins 10 ans ? Y parait même qu'il y ait une lib opensource sous licence BSD qui implémente pratiquement toute la norme TIFF 6.0, avec une tétrachié de codec. Une rumeur à vérifier ....
Moui, mais le monsieur parlait à mon avis du programme en lui même et non de ses composants. De toute façon pour tout ces problèmes, il y a :
- Nada
- Poudre verte
- MultiDeskOS
C'est clair, il y en a marre de ces trolls baveux entre emacs et vi. D'autant qu'emacs est un système d'exploitation et vi, un éditeur de texte, je ne comprends pas comment on peut comparer deux choses différentes ...
Mouais, ça confirme l'impression que j'ai eue lorsque j'ai testé ce langage : c'est très fortement lié à Unix, aussi bien niveau développement, que des applications qu'il peut produire. Si on veut une appli a peu près bien intégrée sous Windows, voire Mac OS X, ç'est infiniment plus simple de faire ça en Java + SWL, ou en C++/wxWidgets, si on le compare avec C#/.net sous Windows uniquement, ça ne tient même pas la comparaison.
Mouais, sans doute que le C ou Java sont des langages préhistoriques, mais il y a un point où le Caml est encore plus préhistorique : c'est son framework et tout ce qui tourne autout. J'ai franchement l'impression de faire un bon de 15 ans en arrière. A mon avis ça doit expliquer pour une large part, pourquoi ce langage perce si peu.
Sérieux, c'est quoi l'intérêt d'un langage surdoué, quand le framework de base est à peine plus évolué que la libc ? Ok, c'est un langage Türing complete, tu peux tout faire avec, mais en combien de temps ? Si des langages comme C# ou Java ont un certains succès, c'est bien parce qu'ils proposent tout un framework utilisable et à peu près bien adapté aux besoins des entreprises d'aujourd'hui, pas d'il y a 15 ans. Parce que bon, on a franchement autre chose à faire que de recoder tout une tétrachié de wrappers pour des libs existantes (avec tous les emmerdes que ça présuppose : doc, tests, mise à jour, intégration plus ou moins bancale dans le langage, etc ...).
Tant qu'on y est, quid de l'intégration avec le système hôte ? Quid de l'intégration de Caml dans des IDEs un peu mieux foutu que vi ou emacs ? Quid d'un framework graphique qui fait autre chose que dessiner des droites et des rectangles ? Quid de la doc de tout ça (haha, je rigole d'avance à l'ampleur de la tâche) ? Quid des capacités cross-plateformes (dont les différences subtiles ont bien-sûr été documentées et à peu près testées) ? C'est l'exemple typique de sales boulots que personne ne veut faire.
Si on ajoute à ça que Caml n'est absolument pas en position de force, et que l'Inria n'a de toute façon pas les moyens de concurencer un Java ou un C#, ben faut pas s'étonner que ce langage se cantonne depuis des lustres aux cercles académiques ou à quelques niches ultra-pointues.
En tous les cas, l'approche utilisé par TOM me semble nettement plus pragmatique et réaliste.
Ouah, ça vole encore plus bas que l'autre ! Il a réussi à sortir tous les clichés possibles et immaginables sur Linux, en ayant l'air sérieux en plus. J'aime beaucoup cette perle (je résume) :
Les linuxiens sont des marxistes qui veulent piller la propriété intellectuelle de SCO.
Si il y a quelque chose qui s'est fait pillier dans cette histoire, ça doit être les neurones de ce gars ....
Et bien j'ai vite déchanté, déjà, il y a les repértoires qui n'ont pas le même nom dans le finder et dans le shell et des répertoires qu'ont ne voit pas du tout dans le finder...
Ouais, ça c'est l'héritage de OS 9. Pour les répertoires que tu ne vois pas dans le finder, je suppose que tu parles de /bin, /lib, /etc .... bah, franchement vouloir bidouiller la dedans avec une interface graphique, c'est pas plus mal qu'il sont cachés. Et si tu veux vraiment les afficher tu as la commande "open /bin", hein.
Donc, ouep, MacOSX, c'est un unix, mais faut pas regarder de trop près, hein... :/
Gni ? Sous prétexe qu'il n'utilise pas les mêmes fichiers de conf que Linux/BSD, ça ne ferait de Mac OS X qu'un sous-produit d'Unix ? Heu, je voudrais pas te décevoir, mais ce genre de système pourrait tout à fait s'appliquer à Linux, hein ...
Il y a quelques années, j'ai participé au portage d'une appli proprio ultra-bloat qui tournait sous divers Unix, et qui utilisait à fond tous les concepts (tout fichier, mémoire partagée, mmap() et co). À part quelques couches bas-niveaux et l'intégration dans OS X (icônes, install spécifique, HIG, ...), il y a eu relativement peu de problèmes purement techniques ...
> Je trouve consternant de voir ce commentaire lucide moinssé à -4.
Mouais, enfin de là à dire que Microsoft est gentille petite entreprise qui bosse pour le bien-être de ses clients, et qui se bat dur pour que ses logiciels soient les meilleurs du marché, grâce aux qualités visionnaires de son fondateur, ça serait un peu trop biaisé comme vision.
Ils ont quand même etouffés pas mal de concurents, sortis des logiciels pourris beaucoup trop tôt (windows 98 qui plante au milieu du show), distillés leurs technos aux compte goutte (au hasard, Samba), quand ce n'était pas buggé et mal documenté jusqu'à la moëlle, flingués la compatibilité de leur logiciels (MS Office, un classique) pour doper leurs ventes, et surtout vérrouiller le marché pour que leur système soit préinstallé et pas un autre (qui se souvient de BeOS ? Il avait 3 pourtant trains d'avance sur windows 9x).
Il a quand même fallu attendu Windows 2000 pour avoir un système qui ne plante pas trop, même si comme tu le soulignes, les bugs planqués sous le tapis (le coup du format WMF, pour le dernier en date) et la gestion de la mémoire (swapationite aigüe) sont franchement pas terribles.
Arf, excellent ! Tu parles du contrat de la Sacem ? Déjà si tu avais un lien, ça m'intéresserait effectivement (rien trouvé de trivial sur Google, , ni sur eucd, ni sur lestelechargements, ni sur sacem.fr ...). Et puis bon, si c'est pour se taper 24 pages de langue de bois juridique (genre ça : http://www.sesam.org/auteur/pdf/sacem.pdf ), quelqu'un se connaissant dans le domaine pour confirmer, je pensais que ce n'était pas trop demandé :-(
Plutot que de parler dans le vide, je te conseille de lire le sus-dit contrat.
Excellent, ce genre de phrase. Ca me fait penser aux abrutis qui envois chier les débutants Windows qui s'intéressent à Linux sous prétexe que leurs questions reflètent qu'ils n'ont pas lus toutes les man pages, les HOWTOs, la hiérarchie fr.comp.os.* depuis 1978, en plus d'Operating Systems: Design and Implementation de Tannenbaum.
Si Internet était le lieu où tout pouvait se savoir en moins d'une vie, ça se saurait, hein ...
[^] # Re: Tant qu'on en est à creuser dans les méandres de linuxfr
Posté par pierthi . En réponse au journal L'été est manchot, extrême manchot !. Évalué à 6.
Non, c'était "linuxfan" et effectivement ses journaux valent le détour !
C.f http://linuxfr.org/~linuxfan/
[^] # Re: .
Posté par pierthi . En réponse au message tableau comme argument à vsprintf. Évalué à 2.
- Ta conversion de param en va_list n'est pas du tout portable, j'espère que tu n'auras pas à le tester sur d'autres archie. Sympa pour ceux qui vont maintenir ça après ...
- Utilise au moins vsnprintf, ça coute pas beaucoup plus cher, et tu éviteras un petit buffer overflow (surtout avec une taille de 100 octets). J'espère qu'il n'est pas trop critique ce code (pas d'accès public).
- Tes paramètres passés directement à sprintf, j'espère que tu es sûr de leur contenu, parce que c'est du pain bénit pour l'injection SQL, bref une faille de sécurité monumentale. Clairement, il ne vaut mieux pas qu'il soit public ton code.
# Re: tableau comme argument à vsprintf
Posté par pierthi . En réponse au message tableau comme argument à vsprintf. Évalué à 3.
#define MAX 1024 char buffer[MAX]; int usage = 0; usage = sprintf(buffer, "%s", "UPDATE t_table set "); if (bon1) { // Hum, hum, fait gaffe à l'SQL injection hein .... usage += snprintf(buffer + usage, MAX - usage, " col1='%s',", param1); } if (bon2) { // Idem ici usage += snprintf(buffer + usage, MAX - usage, " col2='%s',", param2); } /* .... */C'est un poil plus complexe, parce qu'il y a vérification des débordements, mais si tu n'en a rien à foutre, tu pourras grandement simplifier le code ... Sinon, je ne sais pas quel SGBD tu utilises, main en général dans l'API d'accès à la base, il y a des fonctions toutes prêtes pour gérer beaucoup plus proprement ce genre de problèmes (PostgreSQL et SQLite au moins).[^] # Re: Bouton de fermeture
Posté par pierthi . En réponse au journal Regrouper les fonctionnalités sous la souris. Évalué à 10.
[^] # Re: systeme de fichier?
Posté par pierthi . En réponse au journal GLScube pour vous aider à organiser vos données. Évalué à 8.
Bref, keep cool, éteint ta machine, sort et revient dans quelques jours, tu verras la vie est belle.
[^] # T'as oublié ....
Posté par pierthi . En réponse au journal RMS et Ubuntu. Évalué à 8.
# Alors ?
Posté par pierthi . En réponse au journal Mmmmm, c'était bon.. Évalué à 7.
Toujours en train de coder emacs avec vi ? Parce que bon, je ne pense pas qu'il soit maso au point d'utiliser emacs quand même, non ?
[^] # Re: oui et alors
Posté par pierthi . En réponse au journal Notepad et réaction louche. Évalué à 8.
Amen.
# Réponse compliquée
Posté par pierthi . En réponse au message session CGI. Évalué à 1.
En gros les FastCGI te permettront d'avoir des processus persistants et maintenir des sessions assez facilement avec un peu d'immagination, plutôt que te trimbaler des balises hidden de pages HTML en pages HTML. Mais bon, comme dit le commentaire au-dessus, mixer plusieurs langages ça risque d'être assez plantogène (tu as du remarquer que le débugage des CGI c'est pas très marrant, hein ?), surtout si tu débutes ...
Une dernière solution pourrait utiliser des buzzwords comme J2EE, Structs, Hibernate, Lead architect et Pierre Tramo, mais là il faut avoir quelques années devant soit ...
[^] # Re: Utilise des CSS et Template Toolkit
Posté par pierthi . En réponse au message Perl html. Évalué à 1.
Ajoute style="background-image: url('/image.jpg')" à la balise body.
Ou rajoute <base href="/index.html" /> dans l'entête HTML.
[^] # Re: et le pire dans mac os x ...
Posté par pierthi . En réponse au journal Des gestionnaires de fenêtre par monts et par vaux : macosx, windowmaker. Évalué à 2.
Bon, ok, si tu cherches un gestionnaire de fichier à la rox-filer pour appliquer toutes sortes de filtres ou de commandes aux fichiers d'un répertoire, séléction par regex, ou un truc à la konqueror où tu peux éditer ton document koffice avec un panel ftp qui t'affiche la température de ta cafetière, tu as du remarquer que ce n'est pas trop dans la philosophie Mac (tu as quand même le montage +/- transparent des .iso, .dmg, site FTP, WebDAV et connexions SMB). De toute façon le terminal est là pour les trucs tordus.
Ce qui me gave principalement, c'est les problèmes de rafraichissement des fichiers créés autrement que par le finder (surtout avec SMB). Eh non il n'y a pas de commande "rafraichir le p...n de dossier" (la seule bidouille que j'ai trouvée, c'est de créer un dossier ou de faire un kill -9 sur le finder).
Donc, voilà, c'est juste un gestionnaire de fichier, ne cherches pas à faire du café avec, hein ...
[^] # Re: revenons en au fond:
Posté par pierthi . En réponse à la dépêche Ubuntu : le canard pimpant est arrivé !. Évalué à 3.
Gniii ?!! Si ces gars étaient à l'origine bénévole, il y a mille et une autres raisons pour que cela arrive : manque d'intérêt, mariage, naissance de gamins, problèmes persos, etc ... Alors d'un coté on tape sur Canonical, mais pour les autres raisons j'ai comme l'impression qu'on aurait rien dit. Un poids, deux mesures ? Si Debian n'a pas prévu ça, c'est 100 % de leur faute. Si leurs travaux sont si critiques, à eux de faire en sorte qu'ils puissent se transmettre à un autre, donc documenter, toussa ... Pareil pour (4).
Euh, t'es au courrant qu'il y en (beaucoup) pour qui l'informatique n'est qu'un moyen pas une fin ? Même rapporter un bug, corriger une doc, ça prends du temps. Ca me rappelle un phrase un peu dure, que j'ai lue dans un forum : "il n"y que les fous furieux de l'opensource gratuit pour croire que le temps ne coûte rien." Tout le monde n'est pas informaticien, et à encore moins envie de l'être. Mais bon tu connais le cercle vicieux : pas d'utilisateurs, pas de besoins, pas de besoins pas de logiciels, pas logiciels pas d'utilisateurs.
En tous les cas, ce n'est pas avec la part de marché de Linux, qu'on pourra un jour avoir des drivers libres et qu'on pourra se passer d'hacks immondes pour faire tourner certains. Là encore pas de drivers potables, pas d'utilisateurs, pas d'utilisateurs, aucun intérêt de libérer les drivers.
Franchement, utilisateur de Mandriva, je vois plus ça comme une guéguerre stérile qui va encore provoquer des scissions à la BSD, avec tous les gâchis et les pertes de temps que cela présuppose. Diviser pour régner, qu'ils disaient. P...n, c'est pas gagné.
[^] # Re: Je croyais
Posté par pierthi . En réponse au journal PDF pas si libre que ça.... Évalué à 5.
Pour remplacer le PDF/Postscript, il va falloir se lever tôt. Ça fait pratiquement 25 ans que le Postscript existe. Ces formats sont tellement répandus et éprouvés dans l'imprimerie, qu'ils sont pratiquement indéboulonables. Ce n'est pas qu'une question de quelques logiciels phares (où MS Office est d'ailleurs complètement marginal). Pratiquement tous les logiciels, des généralistes comme ceux d'Adobe, ou des trucs plus pointus (trapping, imposition, RIP, ...) savent utiliser ce format, et l'utilise pour dialoguer avec des applications complètement hétérogènes, sans parler des imprimantes.
Il faudra que MS arrive à convaincre un sacré paquet de monde avant de voir adopter leur format, surtout que le PDF/Postscript couvre déjà la plupart des besoins d'un imprimeur et je doute fortement que MS fasse beaucoup mieux. Quand je vois les emmerdes qu'il y a avec le format Word, je me dis que MS ne comprends strictement rien qux besoins des imprimeurs (besoin d'un format interopérable et durable avec un rendu stable).
[^] # Re: avantages de ce format
Posté par pierthi . En réponse au journal Microsoft cherche à remplacer le JPEG. Évalué à 2.
Pour le taux de compression, ça dépend quand même un peu beaucoup des données que tu as en entrée. Du 1bit compressé en JPEG, doit donner des résultats misérablissime comparés à du Group4, sans parler des artéfacts. Pareil pour des images avec pas mal d'applats, la compression Flate/RLE donne d'excellent résultats, sans pertes. C'est clairement une des forces de ce format de pouvoir utiliser une compression adapté aux données de l'image. D'ailleur vu l'universalité et la légèreté de ce format, je me demande pourquoi il n'est pas aussi répandu que le JPEG ou le PNG.
Faut dire que si le support natif dans Windows n'était pas aussi pourri, ça aiderait sans doute un peu.
[^] # Re: avantages de ce format
Posté par pierthi . En réponse au journal Microsoft cherche à remplacer le JPEG. Évalué à 1.
Ha, ha, ils sont au courrant que le TIFF sait faire ça et bien plus encore depuis, boaf, au moins 10 ans ? Y parait même qu'il y ait une lib opensource sous licence BSD qui implémente pratiquement toute la norme TIFF 6.0, avec une tétrachié de codec. Une rumeur à vérifier ....
[^] # Re: Une autre raison ...
Posté par pierthi . En réponse au journal Pourquoi nous vendons un code contenant des bogues.... Évalué à 2.
- Nada
- Poudre verte
- MultiDeskOS
Donc bon, l'honneur est sauf.|
[^] # Re: Tuer le troll
Posté par pierthi . En réponse au journal La vengeance de Tanenbaum. Évalué à 9.
-----> [] (et vite)
[^] # Re: un debat vi:emacs est nul est non avenu
Posté par pierthi . En réponse au journal Vi vs Emacs 3:1. Évalué à 5.
[^] # Re: Et beh...
Posté par pierthi . En réponse à la dépêche Sortie de TOM 2.3. Évalué à -1.
[^] # Re: Et beh...
Posté par pierthi . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 7.
Sérieux, c'est quoi l'intérêt d'un langage surdoué, quand le framework de base est à peine plus évolué que la libc ? Ok, c'est un langage Türing complete, tu peux tout faire avec, mais en combien de temps ? Si des langages comme C# ou Java ont un certains succès, c'est bien parce qu'ils proposent tout un framework utilisable et à peu près bien adapté aux besoins des entreprises d'aujourd'hui, pas d'il y a 15 ans. Parce que bon, on a franchement autre chose à faire que de recoder tout une tétrachié de wrappers pour des libs existantes (avec tous les emmerdes que ça présuppose : doc, tests, mise à jour, intégration plus ou moins bancale dans le langage, etc ...).
Tant qu'on y est, quid de l'intégration avec le système hôte ? Quid de l'intégration de Caml dans des IDEs un peu mieux foutu que vi ou emacs ? Quid d'un framework graphique qui fait autre chose que dessiner des droites et des rectangles ? Quid de la doc de tout ça (haha, je rigole d'avance à l'ampleur de la tâche) ? Quid des capacités cross-plateformes (dont les différences subtiles ont bien-sûr été documentées et à peu près testées) ? C'est l'exemple typique de sales boulots que personne ne veut faire.
Si on ajoute à ça que Caml n'est absolument pas en position de force, et que l'Inria n'a de toute façon pas les moyens de concurencer un Java ou un C#, ben faut pas s'étonner que ce langage se cantonne depuis des lustres aux cercles académiques ou à quelques niches ultra-pointues.
En tous les cas, l'approche utilisé par TOM me semble nettement plus pragmatique et réaliste.
[^] # Re: Ça c'est du troll de compét'
Posté par pierthi . En réponse au journal Logiciel Libre : la grande illusion. Évalué à 3.
Si il y a quelque chose qui s'est fait pillier dans cette histoire, ça doit être les neurones de ce gars ....
[^] # Re: La vraie question
Posté par pierthi . En réponse au journal Et si Mac OS X devenait Opensource ?. Évalué à 3.
Ouais, ça c'est l'héritage de OS 9. Pour les répertoires que tu ne vois pas dans le finder, je suppose que tu parles de /bin, /lib, /etc .... bah, franchement vouloir bidouiller la dedans avec une interface graphique, c'est pas plus mal qu'il sont cachés. Et si tu veux vraiment les afficher tu as la commande "open /bin", hein.
Gni ? Sous prétexe qu'il n'utilise pas les mêmes fichiers de conf que Linux/BSD, ça ne ferait de Mac OS X qu'un sous-produit d'Unix ? Heu, je voudrais pas te décevoir, mais ce genre de système pourrait tout à fait s'appliquer à Linux, hein ...
Il y a quelques années, j'ai participé au portage d'une appli proprio ultra-bloat qui tournait sous divers Unix, et qui utilisait à fond tous les concepts (tout fichier, mémoire partagée, mmap() et co). À part quelques couches bas-niveaux et l'intégration dans OS X (icônes, install spécifique, HIG, ...), il y a eu relativement peu de problèmes purement techniques ...
# D'ailleurs ...
Posté par pierthi . En réponse au journal Poisson d'avril ?. Évalué à 1.
* Apple installera Windows par défaut sur ses Mac^WPC.
* Microsoft expliquera comment installer Mac OS X sur sa XBox.
[^] # Re: Ca devait arriver
Posté par pierthi . En réponse au journal Projet Origami de Microsoft. Évalué à -1.
Mouais, enfin de là à dire que Microsoft est gentille petite entreprise qui bosse pour le bien-être de ses clients, et qui se bat dur pour que ses logiciels soient les meilleurs du marché, grâce aux qualités visionnaires de son fondateur, ça serait un peu trop biaisé comme vision.
Ils ont quand même etouffés pas mal de concurents, sortis des logiciels pourris beaucoup trop tôt (windows 98 qui plante au milieu du show), distillés leurs technos aux compte goutte (au hasard, Samba), quand ce n'était pas buggé et mal documenté jusqu'à la moëlle, flingués la compatibilité de leur logiciels (MS Office, un classique) pour doper leurs ventes, et surtout vérrouiller le marché pour que leur système soit préinstallé et pas un autre (qui se souvient de BeOS ? Il avait 3 pourtant trains d'avance sur windows 9x).
Il a quand même fallu attendu Windows 2000 pour avoir un système qui ne plante pas trop, même si comme tu le soulignes, les bugs planqués sous le tapis (le coup du format WMF, pour le dernier en date) et la gestion de la mémoire (swapationite aigüe) sont franchement pas terribles.
[^] # Re: Toutes les oeuvres
Posté par pierthi . En réponse au journal Magnifique !!!. Évalué à 3.
Plutot que de parler dans le vide, je te conseille de lire le sus-dit contrat.
Excellent, ce genre de phrase. Ca me fait penser aux abrutis qui envois chier les débutants Windows qui s'intéressent à Linux sous prétexe que leurs questions reflètent qu'ils n'ont pas lus toutes les man pages, les HOWTOs, la hiérarchie fr.comp.os.* depuis 1978, en plus d'Operating Systems: Design and Implementation de Tannenbaum.
Si Internet était le lieu où tout pouvait se savoir en moins d'une vie, ça se saurait, hein ...