Bertrand Mathieu a écrit 126 commentaires

Ca serait pas une idée concurrente de MultiDeskOS, par hasard?

C'est comme au début de messenger, il y avait une RFC pour la première version du protocole... et maintenant?

dans son choix entre la pillule bleue (couleur et surnom d'IBM) et la pillule rouge Microsoft

et la pillule passe? D'ailleurs c'est marrant, les-dites pillules: la bleue est grosse avec le nom des marques en grand on dirait une boite de savon, la rouge (microsoft) est toute petite avec vaguement le logo windows qu'on voit très mal, on dirait un compteur à vélo. Ils ont surement voulu signifier que la solution bleue est plus dure à "avaler", mais en même temps ce qu'il y a dessus est très clair (et "accessible" au sens W3C, c.f. description texte vs image en ligne). Bref on en fait la lecture qu'on veut.
En plus les images sont de très mauvaises qualité.

utilise foomatic-gui (apt-get install foomatic-gui) + hpijs (regardes aussi les autres paquets foomatic)
il va créer directement l'imprimante qui va bien, que ce soit avec cups ou lpd. Ensuite tu peux te connecter avec ton navigateur sur le port de cupsd, et tu verras ton imprimante (je l'ai fait hier - faut pas oublier de relancer cups (/etc/init.d/cupsys restart sous debian))

Tu es dans un cas où le langage est développé de façon plus ou moins exploratoire. Comme tu dis, l'interpréteur sert de référence. Il n'en reste pas moins un interpréteur du langage, qui traduit une suite d'instructions en un comportement attendu par l'humain. Que l'interpréteur serve de standard de fait n'est qu'une éventualité, prend par exemple pour t'en convaincre des langages qui ont été largement implémentés: C/C++ (des normes, et pas de compilateur de référence), Java et sa JVM (dont les specs sont disponibles), Lisp...

"R# une alternative libre au langage Rebol"

et puis tant qu'on y est, "clone" (dans la dépêche) ou "alternative" d'un langage je ne trouve pas que ça veuille dire grand chose. "R# une implémentation libre de Rebol" ça me parait plus juste. A moins qu'un langage soit défini par le soft qui l'implémente, ce dont je doute.

Au final, si on a trop de systèmes d'exploitation différents, on se retrouve avec des applications qui manquent sur certains systèmes, du matériel supporté uniquement par certains systèmes, ...

Ou alors on arrive dans un monde où il n'y a plus d'OS homogène/massivement dominant, et les fabricants ont alors le choix entre faire comme actuellement (c.a.d developper pour un seul OS, voire 2) ou relacher leur specs pour que quiconque dispose du savoir-faire puisse écrire les drivers. Pareillement, le respect des standards reste le seul moyen de communication fiable.
Enfin si une application doit être portable le mieux est encore d'utiliser un langage qui ne présente pas de dépendance forte avec la plateforme, ce qui pousse plutôt au développement et à l'utilisation de tels langages (par ex: pourquoi écrire une interface de gravure de CD en c++ voire c? pour le plaisir des segfaults?).

Mon avis c'est que même si présenté comme tel la diversité multiplie les efforts (tant que ça d'ailleurs?), au final les perspectives de qualité sont sans commune mesure, par le fait même de l'hétérogénéité. Evidemment tirer tous azimuts n'est pas fantastique non plus.

Il y a cabextract pour ça, même si je ne suis pas certain que ça marche pour tous les CAB (on dirait qu'il y a plusieurs méthodes de compression)

http://www.kyz.uklinux.net/cabextract.php(...)

msttcorefonts s'en sert pour installer les polices Windows.

ben, je suis sous debian et j'ai récemment changé ma voodoo3 contre une GeForce4. Oui pas de pb, faut un peut lire les docs comme toujours, mais pas de pb tant qu'on ne veut qu'une seule des 2 libGL à la fois. MesaGL a été désinstallé (remplacé par nvidiaGL), et c'est pas un paquet officiel qui me permettra de faire ce genre de jonglage.

Maintenant rien ne t'empeche d'installer Mesa en meme temps que les drivers Nvidia, je l'ai deja fait, et c'est pas bien compliqué

Ça dépend ce que tu entends par "pas bien compliqué". J'ai tendance à considérer qu'un utilisateur de base sait au plus installer des paquets déja fait, mais est complètement perdu s'il fait face à un configure. Parce que je parle bien du problème posé par la distribution du programme. Si je prend une RedHat (par exemple, no troll), est-ce que je peux «facilement» installer les 2 libs en même temps? Est-ce que moi je peux «facilement» livrer un RPM qui ne posera pas de pb quel que soit la config d'arrivée? Je suis dubitatif.

Concernant le problème éventuel de licence de Mesa/DRI/noyau/whatever, il me semble que ATI fait du DRI non?

Nvidia a quand même un gros problème je trouve sous linux: ils n'utilisent pas DRI. Pour la plupart des utilisateurs ça ne change pas ce qui s'affiche. Mais moi en tant que programmeur, j'estime que la lib GL standard sous linux est MesaGL. J'ai programmé il y a peu un programme qui effectue un rendu openGL en ligne de commande, il utilise libOSMesa (offscreen Mesa, livré en standard avec Mesa). Je souhaite bon courage à ceux qui ont une NVidia pour effectuer une installation parallèle de Mesa pour ce genre de chose. Je n'ai pas trouvé de chose équivalente dans la libGL de nvidia, mais en même temps je ne vais pas commencer à faire du spécifique pour chaque constructeur de carte graphique. Mon programme ne peut donc fonctionner sous toutes les configurations, et ce pour une raison technique particulièrement stupide. Sous windows, ils remplacent aussi DirectX par le leur?

Vous diriez quoi si demain Creative Labs se prenait de faire des drivers proprio sous linux qui n'utilisent ni Alsa ni même seulement OSS, même si c'est pour une carte son qui déchire tout?

En cherchant un peu dans le système de bugs:

http://www.openoffice.org/project/www/issues/show_bug.cgi?id=10199(...)

Les autres bugs liés aux fonctions 'spécial' PDF (pdfmarks) renvoient souvent vers celui-ci. La seule chose c'est qu'on ne sait pas si la nouvelle méthode de création des PDFs (sans passer par une imprimante virtuelle) arrange les choses. Il y a fort à parier que oui.

2 choses:
La première personne demande pour Linux mais n'a pas l'air de s'y connaitre. Merveilleux! Mais pour les plus réticents on peut se contenter de leur montrer que OOo existe sous windows (je ne me vois pas installer Linux à tous mes correspondants quand même).

Plus technique, concernant OOo: on parle plus haut de l'export PDF. Une fonction que je n'ai pas vue, c'est la préservation des liens dans le PDF. J'ai quelques hyperliens dans mon CV (c'est à la mode le CV dans les commentaires :-)), est-ce que quelqu'un qui suit OOo de près sait pourquoi le PDF retire les liens? C'est à dire, est-ce que ça n'est pas implémenté pour d'autres raisons que purement liées au developpement du module (choix politique, etc...)?

le support de SSE2 et 3dNOW! pour les architectures ia32 Est-ce que quelqu'un peut dire comment ça se traduit dans la pratique? Ce sont les "targets builtins"? (voir la page info de gcc 3.2, chapitre "C extensions"). Ou est-ce seulement la reconnaissance des opérandes assembleur? Autre question qui découle de ça: les builtins mmx par exemple sont-ils simples à s'en servir ou vaut-il mieux des bouts de code asm à la place?

si je me rappelle bien la citation de gandhi souvent reprise par des défenseurs du libre:

"first they ignore us. Then they laugh. Then they fight. Then we win."

Je commence à croire que ça se vérifie!

Enfin bon, en tant qu'abonné au cable je constate que la page "infos réseau" me donne "désolé, réservé aux abonnés wanadoo cable". Evidemment je consulte depuis une machine branchée sur le cable, autrement dit c'est pas bien dur de s'assurer d'où je viens (IP). C'est même pas fait correctement. Il va sans dire qu'il y a des problèmes plus importants (dont beaucoup liés à leurs serveurs smtp, des fois les mails envoyés avec une adresse @free.fr ou @yahoo.fr passent, des fois le serveur refuse le relaying), mais même la partie émergée de l'iceberg est agaçante.

enfin il faut souligner que dans le cas présenté c'est AOL qui oblige à ça, vu que c'est aol qui filtre les IPs autorisées à se connecter.

je sais qu'on ne peut pas le savoir avant la fin. L'idée c'était de noter à intervalle régulier un hash md5. Quand tu as récupéré ton fichier, tu connais les intervalles et on te fournis la liste de hash. A chaque fois que tu atteins une marque tu compares avec le md5 correspondant. Par exemple toujours pour une ISO, au lieu de ne fournir que le md5 final on fournit également la valeur du hash tous les 50Mo mettons. Mon idée est plus claire comme ça?

pour les autres solutions je ne vois pas trop (c'est quoi "slip"? ça me fait seulement penser à un nom de protocole, toutes blagues à part). Et rsync n'est pas souvent proposé pour télécharger. Enfin des erreurs j'en ai déjà eu plusieurs fois, surtout sur des téléchargements où j'ai du faire des reprises plusieurs fois de suite.

ce qui serait pas mal peut-être ce serait d'avoir des hash intermédiaires pour les gros fichiers. Un exemple pratique: on vérifie une ISO fraichement téléchargée et malheureusement il y a une erreur. Avec un tel système md5 serait capable d'indiquer un endroit où reprendre le téléchargement pour ne pas avoir à recommencer de zéro. En plus la détection d'erreur pourrait aller plus vite puisqu'on a plus besoin d'atteindre la fin du fichier pour faire une comparaison de hashs, on peut le faire à intervalle réguliers.

Si je ne me trompe pas l'algo md5 est un accumulateur (dans cette hypothèse ça me parait jouable).

oui c'est un peu ironique et pas vraiment sérieux non plus. Néanmoins faire la promotion d'un soft c'est quand même un peu ça. Il faut retirer du mot "marketing" l'idée que c'est un peu bidon bien sur; il est tout à fait clair que le libre ne peut et ne veut s'exporter que parce qu'on est capable de démontrer les qualités d'un soft et que tout un chacun peut vérifier ce qui en est vraiment.
(et suivant la définition prise pour 'opensource' ça peut très bien aller avec l'idée de 'marketing' du monde propriétaire au fait)

"la sauvegarde des documents se fera en .doc car c'est le format adopté dans la tête des gens. Et il est dur de faire changer les mentalités même avec les plus beaux arguments du monde (format ouvert) "

ou alors une bonne campagne marketing avec l'idée que le format est plus récent donc meilleur (après tout il s'agit de convaincre des gens qui n'y entendent rien et ne veulent pas vraiment savoir pour la plupart). Voire l'appeler 'doc-pro'?! :-).

D'ailleurs, est-ce que ce ne serait pas une bonne idée d'avoir des outils d'import/export depuis MSoffice vers le format OO? Je ne parle pas de faire ça dans le but de faciliter la transition (ou risquer de la freiner), mais de permettre la diffusion de documents OO qui puissent être lus par le plus de monde possible sans conversion en .doc de la part du créateur...

Moi quand je lis qu'ils veulent réserver ça aux opérateurs je ne peux m'empecher de mettre ça en relation avec les lois toutes proches concernant le log des données de connexions... Comme ça personne n'y échappe. Donc une raison politique par-dessus le marché.

Achat de Orange au prix fort (entre autre parce que Orange avait une licence UMTS, ce qui valait cher en 99). Bref des rachats dans tous les sens de boites liés à la télécom dans les autres pays (mobile, données, opérateurs). Un peu comme Vivendi quoi (sauf que FT est peut-être plus viable??).

et -1 pour un commentaire aussi constructif...

pour ton admin faire le ménage c'est "rm -rf"? eh ben y en a qui sont mal lotis... :-(
et chez lui quand il fait le ménage dans une pièce il balance tous les meubles par la fenêtre peut-être aussi?

-1 aussi ça n'apporte rien

--
engueules ton admin tous les jours même si tu ne sais pas pourquoi lui le sait