Donc, si j'ai bien compris, si tu crées n'importe quel morceau de musique et que tu as un contrat chez la Sacem, ben ce morceau leur appartient. Que tu ne veuilles pas des services de la Sacem, que tu aies utilisé ton propre matos, que tu te fous de la rénumération que tu pourrais tirer de ce morceau, que ce tu aies tout créé par toi même, sans aide aucune de la Sacem, ben, ça appartient quand même à la Sacem ?
Heu, la vaseline est fournie avec les contrats qu'on signe avec eux ?
Ça ne serait pas plutôt les oeuvres dont tu voudrais voir la Sacem gérer les droits, que tu n'es plus propriétaire (en contrepartie, la Sacem te reverse les miettes^W^Wune juste rétribution pour les diffusions à la radio, télé, ou quand quelqu'un siffle sous sa douche^W^W^W^W^W^W^W), et donc que tu ne peux pas en faire ce que tu veux sans payer la "taxe" à la Sacem. Enfin, c'est ce que j'avais cru jusqu'à présent.
C'est comme s'il y avait une clause dans mon contrat de travail qui dirait que tous les logiciels libres que je crérais le soir, sur mon ordi, ben appartiendrait quand même à mon employeur !!
Haha, à chaque fois qu'une niouze de ce type sort, je m'attends à un commentaire de ce genre. Perso, je me demanderais plutôt à quoi ça ne sert pas, tant les possibilités sont décuplées avec l'utilisation d'un GPU.
Est-ce que t'aimerais encore utiliser des interfaces de ce genre (qui était encore la norme il n'y a pas si longtemps) : http://www.efalk.org/Widgets/Xaw.gif
J'en doute, personne n'aimerait revenir à ce genre d'horreur, à moins de vouloir reléguer Linux au rang de curiosité inutilisable.
Sinon les effets sont peut-être discutables (même si je trouve ça plutôt bien). Mais :
1- Ça marche.
2- Ça montre que les possibilités sont inifiniement plus vastes qu'avec un rendu logiciel ultra-poussif.
Ceci dit, si y'a un gourou du sujet pour m'expliquer quels choses indispensables/très utiles ne sont possibles qu'avec Xgl, je suis preneur.
Il y une killer feature qui me plairait bien : la possibilité d'afficher du 1600x1200 sur un moniteur limité à du 1024x768 (fréquent sur les portables). Avec de l'anti-aliassing, c'est tout à fait correct, moyennant un thème pas trop pourri (comme le thème par défaut de GTK1). Quand on voit le chemin que prennent les interfaces actuelles, quelque chose me dit que ça ne sera pas du luxe .....
Bon, ça doit être une question d'habitude, mais je trouve le logo SeaMonkey super moche. Quelqu'un sait s'il y un moyen de remettre le logo animé à droite de l'URL par l'original de la suite Mozilla (ouais, je sais on n'est pas dans les forums ici) ?
Sans déc, comment ils ont pu laisser tomber le lézard rouge, pour cette espèce de bestiole qui ressemble à que dalle ? De loin, ça me fait penser à un oiseau :-\ (C'est peut-être fait exprès ...)
Boaf, le Lab comme espace colorimétrique sur le serveur X, je n'y crois pas trop non plus. Juste pour ceux qui débarquent, une gestion colorimétrique n'est ni plus ni moins qu'un moyen de garantir que les couleurs s'afficheront pareilles d'un périphérique à l'autre (camera, scanner, écran, imprimante, ....).
Je ne pense pas qu'il ait besoin que le serveur X sache gérer le Lab en interne (X sait d'ailleur déjà convertir le Lab => RGB), pour faire une bonne gestion colorimétrique. On peut largement le faire au niveau applicatif.
Genre avant d'afficher une image, l'appli applique un profil d'entrée qui converti le RGB/CMYK en Lab, puis un autre profil de sortie en fonction du périphérique (écran / imprimante), qui convertira le Lab en RGB/CMYK. Ca à l'air beaucoup, mais des libs comme littlecms font ça en 2/3 lignes de code C et en un clin d'oeuil, même sur la dernière des bouses. Avec ça, X n'a absolument pas besoin de gérer le Lab.
Le vrai problème est de générer (ou récupérer) ces foutus profils ET les conditions techniques de leur utilisation (genre pour une imprimante, quel mode d'impression, quelle réduction d'encrage, linéarisation, ...). Changez un paramètre, et vous pouvez regénérer votre profil. Sauf que générer un profil, c'est :
1. Délicat, il faut savoir ce qu'on fait.
2. Il faut du matos qui coute la peau du cul (spectro), en plus de logiciels spécialisés.
Même si dans l'idéal, les constructeurs pourraient fournir ces profils, la plupart du temps, ils sont noyés dans les drivers pour Windows et Mac OS, avec une licence proprio évidemment :-(
Et puis bon, garantir des couleurs identiques entre une imprimante et un écran, je n'y crois pas non plus, tant les gamuts sont différents. Dans ce cas, autant se contenter d'approximation, au lieu de sortir l'artillerie lourde.
D'ailleurs, un peu HS, mais qu'est ce qu'on peut faire contre une image PNG complètement blanche (que des zéros, donc qui se compresse assez bien), mais qui fait dans les 30000x30000 pixels. Compressés, ça doit faire quelques centaines de Ko, mais décompressé on atteint les 2.5 Go, de quoi mettre à genoux une machine pendant un bon bout de temps (ou au pire faire planter le programme) ?
Retaillage à la volée ? Alors c'est le CPU qui risque de chauffer un peu. Bref, on est pas à l'abri d'un boulet ....
Il a désasembler la lib en question, et apparemment, la dll exécute bien du code arbitraire contenu dans le fichier.
Amusant quand même. Cette "feature" doit être présente depuis 15 ans dans Windows et une armée de programmeurs, payés, n'a pas été capable de trouver un truc pareil. Sans parler des soit disant audits, pour se la péter dans des rapports style Get The Fact.
Quand je pense que sous Linux, une poigné de développeurs ont réussi à débusquer une faille où un == a été transformé en =, qui donnait les droits root en faisant un appel système, perdu dans des millions de lignes de code. J'ai envie de dire : Mouhahahhahahhaaaa !
Huh ? en quoi il est ridicule ? Il argumente sur une faille avec des faits pour le moins troublants (une taille de 1 pour un header, qui lance un thread et execute le code, image dont on peut apparemment afficher depuis IE : je trouve ça énorme, un truc aussi dangeureux on le met au moins entre #ifdef DEBUG).
Alors, soit c'est de l'incompétence crasse de la part de Microsoft, soit c'est délibéré. Je suis le premier à casser du sucre sur Microsoft, mais ça m'étonne qu'un truc pareil ait pu passer.
Idem pour moi. En fait depuis l'annonce du service Gmail.
Scanner et conserver le contenu des mails ... pour quelques bonnes raisons (commerciales ou pas) est une idée à laquelle je ne puis souscrire.
Mouarf, je pensais que cette légende urbaine était morte, ben non :
1. Pratiquement tous les fournisseurs d'accès doivent scanner les mails entrant pour vérifier qu'il n'y a pas de virus, ou que ce n'est pas un spam. Pareil pour gmail, il y a juste un programme en plus qui t'insère des pubs (discrètes quand même).
2. Dans gmail, il y a une option pour effacer définitivement les mails. Maintenant, tu peux pousser la parano en disant que rien ne t'indiques qu'il sera effectivement effacé, ce à quoi je dirais, que sur internet, tu n'as aucune garantie, que la moindre donnée émise ne soient pas interceptée à moment ou un autre. Alors bon ....
Sinon, en 1 an d'utilisation, je n'ai eu aucune annonce commerciale, non filtrée en tant que spam (je n'en dirai pas autant de mon mail sur free.fr, plus ancien il est vrai). Je parirai que ça doit être pareil pour ceux qui l'utilise depuis bien plus longtemps. C'est juste un webmail assez bien foutu. Le jour, oû il feront les cons avec, bye bye gmail (c'est pas les webmail qui manquent de nos jours, et ça je pense qu'ils le savent).
Quitte à critiquer, autant y aller direct :
Google est une boite coté en bourse, qui doit rendre des comptes à des actionnaires, par toujours sensibilisé aux technologies, pour ne pas dire intéressé par le profit à court terme, ce qui pousse à une course à la diversification vers les marchés les plus rentables. Avec gmail, google (moteur de recherche), google groups, et quelques cookies bien placés, ils peuvent effectivement tracer certaines habitudes de consommation. Mais encore une fois, pour les plus paranos, il est possible de filtrer.
Sinon, taper sur Google parce qu'ils utilisent des DRM pour diffuser des films, ça me semble la mauvaise cible. Vous immaginer les gars de Google se pointer chez Universal, Sony pictures, etc, en leur disant : "bon on aimerait diffuser vos film en divx/xvid/ogm, sans restriction, comme sur les réseaux P2P". Pour la réponse, j'hésite entre "merde" ou "allez vous faire foutre".
D'un autre coté, un desktop dont le logo est l'empreinte d'un troll et l'autre qui utilise un framework développé par trolltech, moi je dis, que ce n'est plus de l'invitation, c'est carrément de la provocation :-)
> Sous linux : un clavier une souris, mes trois mains
Ha, ha, quel bel exemple de Darwinisme : c'est probablement du à l'usage prolongé d'Emacs : les pieds et les mains ne suffisent plus, il faut des tentacules supplémentaires ....
> La "taxe" sur les supports vierges n'est pas une taxe mais une redevance
"Il y a autant de différence entre taxe et redevance, qu'entre enculade et sodomie".
Je ne sais plus ou j'ai lu ça, ça doit être dans les fortunes linuxfr :-)
Arf, je ne connais pas WinDEV, mais d'après la description que tu en as faite, ça ressemble étrangement à un autre produit ultra-proprio : 4D. À un détail près :
- Le langage et le framework est encore plus pourri que VB (pas d'objets, pas de priorité des opérateurs (si, si :-), pas évaluation en circuit court des expressions booléennes, bugs * 100000).
(Sinon pour le reste tout pareil, en plus c'est crossplateforme Mac OS / Windows, bien qu'ils aient laissé tombé Mac OS 9).
Mais bon, je crois que c'est loin d'être un mauvais outil. Il est infiniement plus "productif", que GTK (qui est pratiquement un cas d'école d'anti-productivisme : doc pas terrible, architecture objet pourrie, framework insipide [que des fonctions = trop pénible à documenter, pas assez de généralisation = productivité 0]).
Le pire c'est que les devs de GTK avait connaissance d'un toolkit assez bien conçu, avec une architecture objet assez élégante et codé en C, le tout opensource : Xt, fourni avec X11 (Gimp à l'origine avait été codé en Motif, basé lui-même sur Xt). Quel beau gâchi.
Pour moi, ajax c'est le mauvais chemin pour un web simple à utiliser et à developper,
Je ne serais pas aussi catégorique. l'AJAX n'est effectivement pas très productif pour produire des interfaces avec des contrôles "riches", et pour cause l'HTML DOM Level 2 est une "API" assez bas niveau. Ajoute à cela un CSS positionning bien souvent douloureux, et un jeu de balise (form) assez limité, tu te retrouves forcément avec des tartines de codes dès que tu veux un truc qui clignotes et bouge dans tous les sens.
D'un autre coté, qui peut le plus, peut le moins. Je ne suis pas sûr qu'en partant directement avec des contrôles "riches" (à la backbase), on aurait autant de créativité avec AJAX. Avant d'en arriver là, il faudrait un minimum de standardisation. Et là, on peut compter sur des troublions comme Microsoft pour te pourrir l'interopérabilité comme il se doit. Alors que bon, il faut quand même reconnaitre que AJAX, ce n'est pas si compliqué et ça fonctionne quasiment partout (même sous IE, j'avoue que je m'attendais au pire avec celui là).
Et puis, il faut savoir utiliser AJAX dans son domaine et pas lui demander la lune. Un client nous avait demandé d'étudier le passage d'une application en client Web (même limité). Sauf que cette application utilisait intensivement le système de fichier local et la drag'n drop. Ça aurait été faisable, mais avec une ergonomie pitoyable.
Ça, ça serait du vrai web 2.0. et ça éviterait tout à chacun de devoir connaitre des codes de retour HTTP obscure, le protocole http etc...
Ouais, bon, tu tapes "XmlHttpRequest" dans google => J'ai de la chance et pouf tu tombes sur cette page qui t'apprends 90% de ce que tu as besoin de connaitre.
> Comment ça se fait que ce soit considéré comme une difficulté par tout le monde ?
En théorie c'est tout simple, il suffirait d'appliquer une formule R = 1 - C + C*K + K, etc ... Sauf que les couleurs que tu obtiens ne sont pas du tout celle que tu trouveras sur une presse. C'est parce que le cyan d'une "imprimante" se rapproche plus d'un bleu et le magenta d'un rouge en réalité (le top que j'ai vu c'est sur une epson10600UC : le cyan était pratiquement du bleu marine à 720dpi, le magenta du pourpre et le jaune trounait à l'orange).
Chaque imprimante à ses propres teintes, et les courbes de densité ne sont absolument pas linéaires (dépende du type d'encre et du média). Donc ces belles formules, ne correspondent rarement, pour ne pas dire jamais à la réalité. "On" a donc inventé les profils ICC : en gros on travaille dans un espace abstrait (XYZ ou Lab), et à partir de là on transpose dans ce qu'on veut.
Les constructeurs d'imprimantes fournissent en général des profils ICC pour certains de leur média (on peut aussi les générer manuellement avec un spectrophotomètre (cher) et des logiciels adaptés (très chers)). Pareil pour les constructeurs de moniteurs et la boucle est bouclée :
Avec le profil ICC de l'imprimante (profil d'entrée) on converti le CMYK => XYZ/Lab. Et avec le profil ICC du moniteur (profil de sortie) on converti l'espace XYZ/Lab => RGB. Et pouf : on simule une impression sur notre écran (dans la pratique c'est pas si génial que ça [il faut que le moniteur soit un peu près bien calibré], mais toujours mieux qu'une conversion triviale).
Une des libs qui se chargent de faire cette conversion s'appelle justement littlecms. Elle ne prend pas en charge la création des ICC (là par contre, je ne connais rien de libre), "juste" la conversion. Avec ça plus de problèmes de cyan trop clair, de rouge dégueux, de gris pas neutre, de patés baveux avec 400% d'encrage (avec de bons profils ICC).
Actuellement ce qui est fait dans Gimp c'est :
TIFF CMYK => RGB (espace de travail interne à Gimp) => (impression cups) reconversion vers CMYK. Dans la théorie ce n'est pas pire, mais dans la pratique les résultats sont trop imprevisibles, c'est pourquoi on préfère travailler directement en CMYK.
Vraiment pas mal du tout ce logiciel, que je ne connaissais pas avant d'avoir vu un journal parlant de lui, avec une démo assez prometteuse tournant sous Linux (que j'ai testée sur un "merdon" 350 avec 256M de RAM : incroyable, mais c'est tout à fait utilisable).
Bossant justement dans le monde du pré-presse, là ou Illustrator, Quark et PhotoShop règnent en maitre incontestés. Je voulais quand même voir si ce logiciel avait une chance de pouvoir remplacer à terme un Illustrator.
Ben, visiblement, il a exactement le même problème que Gimp : ok en RGB, mais complètement à coté de la plaque pour le CMYK. Je ne parle même pas des "spots colors" (canaux avec couleurs arbitraires, très courant en sérigraphie), apparamment absent. Ce genre de fonctionnalité quasi inutile pour le pékin moyen, est malheureusement indispensable dans l'imprimerie.
Je ne parle évidemment pas d'une conversion triviale, comme il y a actuellement (dans Xara et Gimp), mais avec une vraie gestion colorimétrique (beaucoup de soft proprio utilisent en plus une lib sous license BSD extrêmement bien foutue : little CMS http://www.littlecms.com ), via profils ICC. J'ai justement du faire quelques outils pour visualiser des TIFF assez volumineux (60x80'' en 2400dpi 1bit 8 plans) avec cette lib. J'aurais bien aimé utiliser un soft comme celui là pour visualiser ça, ça sera toujours infiniement mieux, que ce que je pourrais faire.
On pourrait même envisager de faire du proofing colorimétrique, ça mettrait quelques claques à certains soft proprios, qui coutent la peau du c*l.
2. threads lourds (on dit aussi processus) : marche pas sous Windows.
iThreads : trop de bidouille à mon gout.
POE : l'artillerie lourde. Pour le coté léger, on repassera.
3. La POO en perl est de la POO classique mais faite en perl.
Ah ben personne ne l'aurais deviné. Tu veux aussi expliquer comment on affecte des variables ou qu'est qu'un langage de programmation ?
5. Ouais bien sûr, mais une version de production, et un minimum testée sous Unix (et Windows, ben ouais, on n'a pas forcément le choix). Parce que bon une version alpha, quasi indisponible sur toutes les distros, ça va être super pour le déploiement.
> PS : ne pas savoir autre chose que du CGI avec perl 5.8 n'est pas le signe d'une
> grande maitrise de perl. essaie au moins mod_perl, tu y gagneras en perf.
Ben alors qu'est qui va pas ? T'as une mauvaise journée ? Rhôo, j'ai même dit le quart du huitième de ce que j'ai fait sous perl, et paf t'as réussi à déduire ça. T'es fort toi.
Ça me parait plutôt ambitieux comme projet. Surtout, je ne suis pas sûr que perl soit le langage le plus adapté.
Il y a des trucs qui sont vraiment *mal* foutus dans perl :
- programmation multi-threadée : c'est de la bidouille infâme (à éviter autant que possible).
- accès à des bibliothèques externes (pas écrites en perl) : pour du code propre, tu peux réver.
- la programmation objet et les structures de données : ça fait un peu scotch et ficelle (passer par des tables de hachages pour les structures, les références pour les objets, ...)
- la machine virtuelle est lente à démarrer sous Windows.
Tout ces petits problèmes seraient résolus dans Perl 6 (quand il sortira). Pour la version 5.8, je n'ai jamais réussi à l'utiliser pour autre chose que des CGI.
[^] # Re: Toutes les oeuvres
Posté par pierthi . En réponse au journal Magnifique !!!. Évalué à 1.
Donc, si j'ai bien compris, si tu crées n'importe quel morceau de musique et que tu as un contrat chez la Sacem, ben ce morceau leur appartient. Que tu ne veuilles pas des services de la Sacem, que tu aies utilisé ton propre matos, que tu te fous de la rénumération que tu pourrais tirer de ce morceau, que ce tu aies tout créé par toi même, sans aide aucune de la Sacem, ben, ça appartient quand même à la Sacem ?
Heu, la vaseline est fournie avec les contrats qu'on signe avec eux ?
Ça ne serait pas plutôt les oeuvres dont tu voudrais voir la Sacem gérer les droits, que tu n'es plus propriétaire (en contrepartie, la Sacem te reverse les miettes^W^Wune juste rétribution pour les diffusions à la radio, télé, ou quand quelqu'un siffle sous sa douche^W^W^W^W^W^W^W), et donc que tu ne peux pas en faire ce que tu veux sans payer la "taxe" à la Sacem. Enfin, c'est ce que j'avais cru jusqu'à présent.
C'est comme s'il y avait une clause dans mon contrat de travail qui dirait que tous les logiciels libres que je crérais le soir, sur mon ordi, ben appartiendrait quand même à mon employeur !!
# WTF ?
Posté par pierthi . En réponse au journal Sortie de Code-libre.org. Évalué à 2.
[admins-Computer:~] admin% ping projets.code-libre.org
ping: unknown host projets.code-libre.org
[admins-Computer:~] admin% ping bleurp.code-libre.org
ping: unknown host bleurp.code-libre.org
[admins-Computer:~] admin% ping www.code-libre.org
PING code-libre.org (64.20.35.106): 56 data bytes
64 bytes from 64.20.35.106: icmp_seq=0 ttl=50 time=46.296 ms
64 bytes from 64.20.35.106: icmp_seq=1 ttl=50 time=30.933 ms
^C
--- code-libre.org ping statistics ---
3 packets transmitted, 2 packets received, 33% packet loss
round-trip min/avg/max = 30.933/38.614/46.296 ms
[admins-Computer:~] admin%
Voilà, voilà .... depuis quelques heures maintenant.
C'est dommage je cherchais justement un site pour héberger quelques uns de mes projets, qui soit un peu moins bloat que sourceforge.
[^] # Re: A quoi ça sert ?
Posté par pierthi . En réponse à la dépêche NLD 10 le poste du travail de demain par Novell (avec XGL et Compiz). Évalué à 10.
Est-ce que t'aimerais encore utiliser des interfaces de ce genre (qui était encore la norme il n'y a pas si longtemps) :
http://www.efalk.org/Widgets/Xaw.gif
J'en doute, personne n'aimerait revenir à ce genre d'horreur, à moins de vouloir reléguer Linux au rang de curiosité inutilisable.
Sinon les effets sont peut-être discutables (même si je trouve ça plutôt bien). Mais :
1- Ça marche.
2- Ça montre que les possibilités sont inifiniement plus vastes qu'avec un rendu logiciel ultra-poussif.
[^] # Re: J'aime pas XGL
Posté par pierthi . En réponse au journal Novell et les effet graphique. Évalué à 1.
Il y une killer feature qui me plairait bien : la possibilité d'afficher du 1600x1200 sur un moniteur limité à du 1024x768 (fréquent sur les portables). Avec de l'anti-aliassing, c'est tout à fait correct, moyennant un thème pas trop pourri (comme le thème par défaut de GTK1). Quand on voit le chemin que prennent les interfaces actuelles, quelque chose me dit que ça ne sera pas du luxe .....
# L'égout et les odeurs
Posté par pierthi . En réponse à la dépêche Sortie de Mozilla SeaMonkey 1.0. Évalué à 2.
Sans déc, comment ils ont pu laisser tomber le lézard rouge, pour cette espèce de bestiole qui ressemble à que dalle ? De loin, ça me fait penser à un oiseau :-\ (C'est peut-être fait exprès ...)
Sauvez le lézard !!!
[^] # Re: Le flou
Posté par pierthi . En réponse au journal Quel logiciel manque t-il sur Linux ?. Évalué à 2.
Je ne pense pas qu'il ait besoin que le serveur X sache gérer le Lab en interne (X sait d'ailleur déjà convertir le Lab => RGB), pour faire une bonne gestion colorimétrique. On peut largement le faire au niveau applicatif.
Genre avant d'afficher une image, l'appli applique un profil d'entrée qui converti le RGB/CMYK en Lab, puis un autre profil de sortie en fonction du périphérique (écran / imprimante), qui convertira le Lab en RGB/CMYK. Ca à l'air beaucoup, mais des libs comme littlecms font ça en 2/3 lignes de code C et en un clin d'oeuil, même sur la dernière des bouses. Avec ça, X n'a absolument pas besoin de gérer le Lab.
Le vrai problème est de générer (ou récupérer) ces foutus profils ET les conditions techniques de leur utilisation (genre pour une imprimante, quel mode d'impression, quelle réduction d'encrage, linéarisation, ...). Changez un paramètre, et vous pouvez regénérer votre profil. Sauf que générer un profil, c'est :
1. Délicat, il faut savoir ce qu'on fait.
2. Il faut du matos qui coute la peau du cul (spectro), en plus de logiciels spécialisés.
Même si dans l'idéal, les constructeurs pourraient fournir ces profils, la plupart du temps, ils sont noyés dans les drivers pour Windows et Mac OS, avec une licence proprio évidemment :-(
Et puis bon, garantir des couleurs identiques entre une imprimante et un écran, je n'y crois pas non plus, tant les gamuts sont différents. Dans ce cas, autant se contenter d'approximation, au lieu de sortir l'artillerie lourde.
[^] # Re: La référence....
Posté par pierthi . En réponse au journal Vérificateur grammatical libre, la suite.. Évalué à 1.
http://groups.google.ca/group/fr.comp.os.linux.debats/browse(...)
Ils sont ouverts, mais c'est très loin d'être gagné ....
[^] # Re: Evangéliser...
Posté par pierthi . En réponse à la dépêche Jabber explose !. Évalué à 2.
Retaillage à la volée ? Alors c'est le CPU qui risque de chauffer un peu. Bref, on est pas à l'abri d'un boulet ....
[^] # Re: Le pauvre...
Posté par pierthi . En réponse au journal Steve Gibson accuse Microsoft. Évalué à 8.
http://www.grc.com/sn/SN-021.htm
Il a désasembler la lib en question, et apparemment, la dll exécute bien du code arbitraire contenu dans le fichier.
Amusant quand même. Cette "feature" doit être présente depuis 15 ans dans Windows et une armée de programmeurs, payés, n'a pas été capable de trouver un truc pareil. Sans parler des soit disant audits, pour se la péter dans des rapports style Get The Fact.
Quand je pense que sous Linux, une poigné de développeurs ont réussi à débusquer une faille où un == a été transformé en =, qui donnait les droits root en faisant un appel système, perdu dans des millions de lignes de code. J'ai envie de dire : Mouhahahhahahhaaaa !
[^] # Re: Le pauvre...
Posté par pierthi . En réponse au journal Steve Gibson accuse Microsoft. Évalué à 8.
Alors, soit c'est de l'incompétence crasse de la part de Microsoft, soit c'est délibéré. Je suis le premier à casser du sucre sur Microsoft, mais ça m'étonne qu'un truc pareil ait pu passer.
[^] # Re: Retour vers le passe
Posté par pierthi . En réponse au journal Google souffle le chaud (Google Pack) et le froid (DRM). Évalué à 6.
Mouarf, je pensais que cette légende urbaine était morte, ben non :
1. Pratiquement tous les fournisseurs d'accès doivent scanner les mails entrant pour vérifier qu'il n'y a pas de virus, ou que ce n'est pas un spam. Pareil pour gmail, il y a juste un programme en plus qui t'insère des pubs (discrètes quand même).
2. Dans gmail, il y a une option pour effacer définitivement les mails. Maintenant, tu peux pousser la parano en disant que rien ne t'indiques qu'il sera effectivement effacé, ce à quoi je dirais, que sur internet, tu n'as aucune garantie, que la moindre donnée émise ne soient pas interceptée à moment ou un autre. Alors bon ....
Sinon, en 1 an d'utilisation, je n'ai eu aucune annonce commerciale, non filtrée en tant que spam (je n'en dirai pas autant de mon mail sur free.fr, plus ancien il est vrai). Je parirai que ça doit être pareil pour ceux qui l'utilise depuis bien plus longtemps. C'est juste un webmail assez bien foutu. Le jour, oû il feront les cons avec, bye bye gmail (c'est pas les webmail qui manquent de nos jours, et ça je pense qu'ils le savent).
Quitte à critiquer, autant y aller direct :
Google est une boite coté en bourse, qui doit rendre des comptes à des actionnaires, par toujours sensibilisé aux technologies, pour ne pas dire intéressé par le profit à court terme, ce qui pousse à une course à la diversification vers les marchés les plus rentables. Avec gmail, google (moteur de recherche), google groups, et quelques cookies bien placés, ils peuvent effectivement tracer certaines habitudes de consommation. Mais encore une fois, pour les plus paranos, il est possible de filtrer.
Sinon, taper sur Google parce qu'ils utilisent des DRM pour diffuser des films, ça me semble la mauvaise cible. Vous immaginer les gars de Google se pointer chez Universal, Sony pictures, etc, en leur disant : "bon on aimerait diffuser vos film en divx/xvid/ogm, sans restriction, comme sur les réseaux P2P". Pour la réponse, j'hésite entre "merde" ou "allez vous faire foutre".
[^] # Re: Kde 7, un nouveau noyau pour GNU?
Posté par pierthi . En réponse au journal Kde 4, un nouveau framework pour la gestion du matériel?. Évalué à 6.
C'est bon, poussez pas ...
# Arf, même pas honte ...
Posté par pierthi . En réponse au message Hello les ami(e)s. Évalué à 2.
Ha, ha, il te faut un Mac alors :-)
Ouais, je sais, elle était facile .... et même, si je me suis paumé sur ce forum, je connais la sortie .... -> []
[^] # Re: c'est open-source ici!
Posté par pierthi . En réponse au journal Gmail et les .exe. Évalué à 1.
MSI puxor, NSIS roxor
Piouf, mouler à 2 heures du réveillon, c'est grave docteur ?
[^] # Re: perso...
Posté par pierthi . En réponse au journal Linus encourage le basculement vers KDE. Évalué à 10.
[^] # Re: Cela dépend de l'OS lancé
Posté par pierthi . En réponse au sondage Pour utiliser mes ordinateurs je me sers. Évalué à 10.
> Sous linux : un clavier une souris, mes trois mains
Ha, ha, quel bel exemple de Darwinisme : c'est probablement du à l'usage prolongé d'Emacs : les pieds et les mains ne suffisent plus, il faut des tentacules supplémentaires ....
:wq! _o/
[^] # Re: /o\
Posté par pierthi . En réponse au journal "'auteur de NVU tire à boulet rouge sur les auteurs de l'ammendement VU. Évalué à 9.
"Il y a autant de différence entre taxe et redevance, qu'entre enculade et sodomie".
Je ne sais plus ou j'ai lu ça, ça doit être dans les fortunes linuxfr :-)
[^] # Re: Et Swing ?
Posté par pierthi . En réponse à la dépêche CamelBones 1.0.0b5. Évalué à 1.
Parce que ça : http://linuxfr.org/comments/640117.html#640117
Mouhahaha ! :-)
[^] # Re: Bouche toi et le nez et observe
Posté par pierthi . En réponse au journal Obligation professionnelle et Windev 10. Évalué à 2.
- Le langage et le framework est encore plus pourri que VB (pas d'objets, pas de priorité des opérateurs (si, si :-), pas évaluation en circuit court des expressions booléennes, bugs * 100000).
(Sinon pour le reste tout pareil, en plus c'est crossplateforme Mac OS / Windows, bien qu'ils aient laissé tombé Mac OS 9).
Mais bon, je crois que c'est loin d'être un mauvais outil. Il est infiniement plus "productif", que GTK (qui est pratiquement un cas d'école d'anti-productivisme : doc pas terrible, architecture objet pourrie, framework insipide [que des fonctions = trop pénible à documenter, pas assez de généralisation = productivité 0]).
Le pire c'est que les devs de GTK avait connaissance d'un toolkit assez bien conçu, avec une architecture objet assez élégante et codé en C, le tout opensource : Xt, fourni avec X11 (Gimp à l'origine avait été codé en Motif, basé lui-même sur Xt). Quel beau gâchi.
[^] # Re: Bof
Posté par pierthi . En réponse au journal La folie de Web 2.0. Évalué à 2.
Je ne serais pas aussi catégorique. l'AJAX n'est effectivement pas très productif pour produire des interfaces avec des contrôles "riches", et pour cause l'HTML DOM Level 2 est une "API" assez bas niveau. Ajoute à cela un CSS positionning bien souvent douloureux, et un jeu de balise (form) assez limité, tu te retrouves forcément avec des tartines de codes dès que tu veux un truc qui clignotes et bouge dans tous les sens.
D'un autre coté, qui peut le plus, peut le moins. Je ne suis pas sûr qu'en partant directement avec des contrôles "riches" (à la backbase), on aurait autant de créativité avec AJAX. Avant d'en arriver là, il faudrait un minimum de standardisation. Et là, on peut compter sur des troublions comme Microsoft pour te pourrir l'interopérabilité comme il se doit. Alors que bon, il faut quand même reconnaitre que AJAX, ce n'est pas si compliqué et ça fonctionne quasiment partout (même sous IE, j'avoue que je m'attendais au pire avec celui là).
Et puis, il faut savoir utiliser AJAX dans son domaine et pas lui demander la lune. Un client nous avait demandé d'étudier le passage d'une application en client Web (même limité). Sauf que cette application utilisait intensivement le système de fichier local et la drag'n drop. Ça aurait été faisable, mais avec une ergonomie pitoyable.
Ouais, bon, tu tapes "XmlHttpRequest" dans google => J'ai de la chance et pouf tu tombes sur cette page qui t'apprends 90% de ce que tu as besoin de connaitre.
http://developer.apple.com/internet/webcontent/xmlhttpreq.ht(...)
[^] # Re: Pas mal, sauf ...
Posté par pierthi . En réponse à la dépêche Xara Xtreme passe sous GPL et se rapproche d'Inkscape. Évalué à 5.
En théorie c'est tout simple, il suffirait d'appliquer une formule R = 1 - C + C*K + K, etc ... Sauf que les couleurs que tu obtiens ne sont pas du tout celle que tu trouveras sur une presse. C'est parce que le cyan d'une "imprimante" se rapproche plus d'un bleu et le magenta d'un rouge en réalité (le top que j'ai vu c'est sur une epson10600UC : le cyan était pratiquement du bleu marine à 720dpi, le magenta du pourpre et le jaune trounait à l'orange).
Chaque imprimante à ses propres teintes, et les courbes de densité ne sont absolument pas linéaires (dépende du type d'encre et du média). Donc ces belles formules, ne correspondent rarement, pour ne pas dire jamais à la réalité. "On" a donc inventé les profils ICC : en gros on travaille dans un espace abstrait (XYZ ou Lab), et à partir de là on transpose dans ce qu'on veut.
Les constructeurs d'imprimantes fournissent en général des profils ICC pour certains de leur média (on peut aussi les générer manuellement avec un spectrophotomètre (cher) et des logiciels adaptés (très chers)). Pareil pour les constructeurs de moniteurs et la boucle est bouclée :
Avec le profil ICC de l'imprimante (profil d'entrée) on converti le CMYK => XYZ/Lab. Et avec le profil ICC du moniteur (profil de sortie) on converti l'espace XYZ/Lab => RGB. Et pouf : on simule une impression sur notre écran (dans la pratique c'est pas si génial que ça [il faut que le moniteur soit un peu près bien calibré], mais toujours mieux qu'une conversion triviale).
Une des libs qui se chargent de faire cette conversion s'appelle justement littlecms. Elle ne prend pas en charge la création des ICC (là par contre, je ne connais rien de libre), "juste" la conversion. Avec ça plus de problèmes de cyan trop clair, de rouge dégueux, de gris pas neutre, de patés baveux avec 400% d'encrage (avec de bons profils ICC).
Actuellement ce qui est fait dans Gimp c'est :
TIFF CMYK => RGB (espace de travail interne à Gimp) => (impression cups) reconversion vers CMYK. Dans la théorie ce n'est pas pire, mais dans la pratique les résultats sont trop imprevisibles, c'est pourquoi on préfère travailler directement en CMYK.
# Pas mal, sauf ...
Posté par pierthi . En réponse à la dépêche Xara Xtreme passe sous GPL et se rapproche d'Inkscape. Évalué à 8.
Bossant justement dans le monde du pré-presse, là ou Illustrator, Quark et PhotoShop règnent en maitre incontestés. Je voulais quand même voir si ce logiciel avait une chance de pouvoir remplacer à terme un Illustrator.
Ben, visiblement, il a exactement le même problème que Gimp : ok en RGB, mais complètement à coté de la plaque pour le CMYK. Je ne parle même pas des "spots colors" (canaux avec couleurs arbitraires, très courant en sérigraphie), apparamment absent. Ce genre de fonctionnalité quasi inutile pour le pékin moyen, est malheureusement indispensable dans l'imprimerie.
Je ne parle évidemment pas d'une conversion triviale, comme il y a actuellement (dans Xara et Gimp), mais avec une vraie gestion colorimétrique (beaucoup de soft proprio utilisent en plus une lib sous license BSD extrêmement bien foutue : little CMS http://www.littlecms.com ), via profils ICC. J'ai justement du faire quelques outils pour visualiser des TIFF assez volumineux (60x80'' en 2400dpi 1bit 8 plans) avec cette lib. J'aurais bien aimé utiliser un soft comme celui là pour visualiser ça, ça sera toujours infiniement mieux, que ce que je pourrais faire.
On pourrait même envisager de faire du proofing colorimétrique, ça mettrait quelques claques à certains soft proprios, qui coutent la peau du c*l.
Cela dit, en RGB déjà, nul doute qu'il déchire.
# Voui, moi aussi !
Posté par pierthi . En réponse au journal Logo Debian dans Les noces funèbres de Tim Burton ?. Évalué à 8.
http://img74.imageshack.us/img74/4850/spirale0lh.png
:-)
[^] # Re: Heu, perl ?
Posté par pierthi . En réponse au message Qui m'aime me suive !!. Évalué à 2.
2. threads lourds (on dit aussi processus) : marche pas sous Windows.
iThreads : trop de bidouille à mon gout.
POE : l'artillerie lourde. Pour le coté léger, on repassera.
3. La POO en perl est de la POO classique mais faite en perl.
Ah ben personne ne l'aurais deviné. Tu veux aussi expliquer comment on affecte des variables ou qu'est qu'un langage de programmation ?
5. Ouais bien sûr, mais une version de production, et un minimum testée sous Unix (et Windows, ben ouais, on n'a pas forcément le choix). Parce que bon une version alpha, quasi indisponible sur toutes les distros, ça va être super pour le déploiement.
> PS : ne pas savoir autre chose que du CGI avec perl 5.8 n'est pas le signe d'une
> grande maitrise de perl. essaie au moins mod_perl, tu y gagneras en perf.
Ben alors qu'est qui va pas ? T'as une mauvaise journée ? Rhôo, j'ai même dit le quart du huitième de ce que j'ai fait sous perl, et paf t'as réussi à déduire ça. T'es fort toi.
# Heu, perl ?
Posté par pierthi . En réponse au message Qui m'aime me suive !!. Évalué à 1.
Il y a des trucs qui sont vraiment *mal* foutus dans perl :
- programmation multi-threadée : c'est de la bidouille infâme (à éviter autant que possible).
- accès à des bibliothèques externes (pas écrites en perl) : pour du code propre, tu peux réver.
- la programmation objet et les structures de données : ça fait un peu scotch et ficelle (passer par des tables de hachages pour les structures, les références pour les objets, ...)
- la machine virtuelle est lente à démarrer sous Windows.
Tout ces petits problèmes seraient résolus dans Perl 6 (quand il sortira). Pour la version 5.8, je n'ai jamais réussi à l'utiliser pour autre chose que des CGI.