reno a écrit 3886 commentaires

Désolé, mais si ces gens tiennent ce genre de propos en publique, c'est qu'en général ils répondent a des questions, donc il donne leur avis en toute honneteté, ce n'est pas parce qu'ils contribuent a des softs libres qu'ils pensent pour autant que Monsieur tout le monde sera capable d'utiliser des softs libres sans qu'il y ait un administrateur systeme pour leur tenir la main..

Pour le point 2, les "gourous" comme tu les appelle, ça les fait bien souvent rire d'avoir de l'influence, Linus se moque souvent de ceux qui le prenne pour un gourou, justement.

Pour le point 3, l'entreprise qui veut porter ses jeux sous Linux a bien du soucis a se faire coté rentabilité de l'opération. C'est négatif?
Désolé, mais c'est vrai: ce n'est pas moi qui le dit mais Id qui conçoit pourtant ses jeux dès le début pour être multi-plateforme!

>[] Linux, c'est un concurrent de MSWin. Et c'est censé être pareil.

Bin justement ça ne l'est pas pareil, il y a plein de trucs ou MSWin et ses applications est meilleur et d'autre ou Linux/Free est meilleur.

On s'impose aussi rarement en niant la réalité ou alors il faut être tres bon en marketing.

Les contributeurs au logiciel libre (a part les entreprises ou ceux qui sont "entrés en religion") bien souvent ne veulent pas faire de marketing..
Les logiciels libres s'imposent uniquement là ou ils sont les meilleurs: Apache a la majorité des parts de marchés parce qu'il est un des meilleurs.

Les logiciels libres s'imposeront dans le desktop?
Ce n'est pas gagné mais dans bien des domaines les applications propriétaires font du "sur place": il est fort probable que dans ces domaines là le libre l'emporte.
Les jeux est un des domaines ou la nouveauté compte: avoir la meilleure histoire, le meilleur rendu 3D, etc..
Il est très douteux que des jeux libres puissent être compétitif, de plus le dual-boot tue les ventes de jeux propriétaires portés sous Linux..
Bref, le secteur des jeux sera probablement un des dernier a etre porté sous Linux si jamais il y a suffisamment d'utilisateur Linux "a la maison" un jour, ce qui n'est pas gagné.

Et alors?

Le nombre de jeux disponible sous Linux est ridiculement faible par rapport a Windows.
Qui te dit que Marcello Tossati jouait a des jeux portés par Loki?

En ce moment personellement je joue a IL2 et Deus Ex: deux jeux non portés sous Linux.
Et non je n'utiliserais pas de console, les jeux consoles sont differents des jeux PC et ne m'attirent pas.

Tu lui reproches quoi exactement a Marcello Tossati? Sa franchise? De jouer?

Tout le monde sait que le manque de jeux est un point faible de Linux, Loki s'est planté, ID a dit que financièrement ce n'était pas rentable de porter des jeux sous Linux et que le portage sous Linux rapportait moins d'argent que celui pour Mac.

Comme la sélection de jeux disponible sur Mac ne m'impréssione pas, le problème des jeux sous Linux va durer longtemps, et le dual-boot aussi.
Il y a des tas d'autres utilisateur a convaincre: le desktop d'entreprise, les gens qui jouent uniquement au démineur.

Tu as essayé FrameMaker ?

A part son prix déraisonnable, je le préfere de loin a Word..

Certes mais j'imagine qu'une radio a besoin d'avoir des bonnes relations avec les maisons de disques, non?

L'inverse est également vrai bien sur, mais RadioFrance n'est pas le seul diffuseur..

Par contre que la BBC ai trouvé un accord avec les maisons de disque, ça c'est plutot une bonne nouvelle!
Ca me rend plus optimiste, meme si pour autant que je me souvienne la diffusion de la BBC en ogg est un test, ce n'est pas encore définitif..

Moui effectivement, tu peux essayer de "changer les regles" en essayant que Radio France laisse tomber la contrainte: il faut que le systeme de diffusion integre un DRM.

Mais ce que je faisais remarquer, c'est que ce n'est pas gagné du tout: la contrainte du DRM ne vient pas en premier lieu de Radio France (qui a mon avis n'en as pas grand chose à faire, les ventes de compilation d'émission radio doivent se monter à environ 0) mais des maisons de disques.

Et là, tu peux toujours essayer de discuter avec les maisons de disque sur l'aspect "liberté d'expression,etc", tu touche au portefeuille des éditeurs: les sous rapportés par la vente de CD!

Bon courage pour les convaincre!

Esprit combatif ou pas, je me demande si l'obstacle des DRM ne risque pas de tout bloquer?

Pour que RadioFrance puisse diffuser de la musique sur le web, il faut qu'il ait l'autorisation des maisons de disque: j'ai comme dans l'idee qu'elles ne seront pas d'accord si la diffusion se fait sans proteger les sources.

Certes la protection a l'heure actuelle n'est pas tres bonne, mais cela m'etonnerait que comme arguments cela suffise: la protection n'est pas bonne alors diffuson sans aucune protection!

Un robot, et j'imagine que pour avoir le droit d'avoir un nom en .kid.us, il faudra signer une charte avec des obligations et que si tu ne les respectes pas, ca va barder...

M'étonnerait: les sites en .kid.us n'auront le droit d'avoir des liens uniquement vers d'autres site en .kid.us, forcément cela limite l'intérét de la chose à part pour les sites spécificiquement conçus pour les enfants..

Ca depend ce que tu appelles l'exception: a l'epoque des BBS, il y avait quand meme pas mal de soft qui tournaient sur de Mainframes IBM pour faire les "choses sérieuses".

Ceci dit je ne connais pas la licence sous laquelle IBM fournissait ses softs a l'epoque..

> Cite-moi un seul avantage du proprio par rapport au libre du point de vue de l'utilisateur !

Celui d'exister MAINTENANT!
Il y a une foultitudes de logiciel propriétaires dont l'équivalent en libre n'existe pas maintenant, certes peut-etre qu'un jour l"equivalent libre existera mais ce n'est pas forcément gagné!

Comme ces logiciels proprietaire existe maintenant, on peut les acheter pour les utiliser.

Un exemple?
Un simulateur de vol joli par exemple: il n'y a pas d'équivalent libre d'IL2 avec une qualité graphique comparable (oui j'ai regardé les capture d'écran des simulateurs de vols libre, en un mot heuh, *perfectible*).

Peut-etre qu'un jour tout les logiciels seront libres et tout le monde mangera a sa faim et il n'y aura plus de guerre, et les poules auront des dents mais en attendant les logiciels propriétaires sont la et resteront longtemps ne serait-ce que pour relire les données au format propriétaire: un cercle vicieux, très, très stable!

Tout a fait, merci pour le lien.
J'espere que ceux qui bossent dessus se "synchroniseront" avec le consortium OASIS (ou vice-versa) autrement cela va etre comme d'habitude pour les standards, le probleme sera de choisir lequel utiliser!..

J'ai envoy'e un mail au gens de 1dok.org pour savoir quelle est leur position la-dessus..

Il n'y avait pas un groupe de chercheurs Allemands qui bossait la-dessus?

Il me semble avoir déja lu quelque-chose dans ce genre..

Hors-sujet: urpmi a des problemes:
Pour le probleme de cdrom, je confirme que urpmi gere tres mal la chose: en general pour installer une distrib j'utilise des CD-RW (evolue trop vite pour gacher des CD-R) or j''ai aussi un vieux lecteur de CD dans mon ordinateur, pour une raison que j'ignore urpmi va toujours chercher les package sur le lecteur de CD par le graveir : d'ou a chaque upgrade, destruction de la base, reconstruction.

C'est pénible, c'est long et cela m'est arrivé d'avoir du mal a reconstruire la base, j'ai essayé de regarder les sources,
--> beurk! du Perl, sauce imbitable. Fin HS.

Tu achetes une GeForce et attends vivement que le kernel n'autorise plus l'import de driver closed-source?
C'est du masochisme?

ATI fournit peut-etre un driver closed-source, mais eux ils fournissent les specs de la carte (pas toute malheureusement) et il y a des projets open-source qui essaye de faire des driver.
Ce serait encore s'ils fournissaient leur driver en open-source, mais c'est toujours mieux que NVidia qui lui ne fournit pas du tout les specs de sa carte..

Juste pour m'oter un doute: ATI fournissait ses specs jusqu'a la Radeon 8500, mais est-ce toujours vrai pour la 9700Pro (R300)?

Note que ça peut être un avantage: le copier/coller en programmation, c'est *mal* !!

Tu risque de devoir faire la meme modification/correction 20 fois, si tu fais 20 copier/coller..


Ceci dit au moins avec Python, tu es sur que le code est toujours indenté: c'est un language lecteur-friendly pas écrivain-friendly.

Mais comme en maitenance de code, on passe plus de temps a relire du code qu'a en ecrire, c'est aussi du bénéfice pour le développeur.

Un truc qui m'ennuie fortement c'est que ce sont les espaces qui sont conseillés pour indenter le code.
Grrr, cela fait 10 ans que j'indente mon code religieusement avec des tabulations de 4 blanc et maitenant pour Python il faut changer, c'est con mais je n'aime pas du tout ça..

> Faut être tordu pour 'installer des prises US en France et vice versa, ou alors savoir exactement ce que l'on fait.

Bon exemple des problemes posés: pas mal d'alimentations fonctionne sur les 2 normes: ca ne m'étonnerait pas qu'elles soient plus cher a cause de cela: juste un peu plus cher certes vu les volumes en question mais plus cher tout de meme.

Pareil pour les logiciels libres: en général on ne paye pas pour eux, mais le temps passer a générer n packaging pourrait etre mieux utilisé a paufiner un seul packaging.

>>le but c'est d'avoir des OS qui sont le plus facilement administrable
>Avec une techno de 1997 ?

? La techno Unix est super-vieille, l'age d'une techno n'est pas le premier critere autrement il faut abandonner Unix pour Windows.

> - Ils ont tiré leur standard vers le bas en prenant le plus petit denominateur commun (du coup, en excluant le .deb)

D'accord: ils auraient prendre un format RPM entier et recent, pas juste une portion: comme cela il y aurait toutes les fonctionnalités de RPM, pas juste une partie. Les distros auraient mis a jour leur version pour etre conforme.

Pour ce qui est d'autoriser le format .deb: imagines un peu si les organismes de normalisations avaient autorisés plusieurs tailles de prise pour la maison, le bordel..
Pour moi, rien n'empeche de faire l'equivalent de apt-get avec des .rpm, mais toute comparaison des formats .rpm et .deb degenere en flamewar et tourne en général a: "avec mon format X on peut faire cela avec le format Y on ne peut pas, avec une réponse aussitot: tu retardes, cela fait tant d'années que le format Y supporte cela."

> 'installer le package de sa distrib ou un rpm de 97 "LSB copain
Malheureusement les RPM "tout chaud" sortis par les distros sont souvent buggés, avec une distribution conforme a LSB, je crois que j'hésiterais avec un RPM fait par le gars qui code le logiciel.

> Cela dit, la resolution de conflit avec nombre de passe fixé, franchement, C'est pas propre. Je garde mes .deb. Et toc !

Tu as tout le fait le droit, mais par contre ne t'étonnes pas de devoir utiliser de plus en plus l'outil de convertion .RPM --> .DEB.

> D'abord la LSB n'aurait jamais dû s'intéresser au format de package.

Ca c'est ton avis, pas le mien: les formats de packages, c'est comme les formats de prises électrique, si tu en as plusieurs c'est le bordel pour installer tous ensemble.
Le but ce n'est pas d'avoir le format le mieux, franchement les .deb et .rpm sont grosso-modo équivalent, le but c'est d'avoir des OS qui sont le plus facilement administrable.

Je ne connais pas le format installshield, mais s'il était ouvert (tous le monde peut packager leur projet sans avoir a payer une license au fabriquant d'installshield), multi-plateforme (c'est un standard de Windows, je ne sais pas s'il dépend de spécifité de Windows), puissant et avec des outils libre, oui cela aurait été une bonne idée de l'utiliser: comme cela les projets multi-plateformes n'aurait eu qu'un seul outil de packaging a utiliser..

> Enfin, la plupart des gens ont pas trop envie que rpm aille foutre la merde dans leur fs (en particulier dans /etc).

Je ne sais pas d'ou tu sors cela, mais "la plupart des gens" utilise justement des distributions pour se simplifier la vie, et il est plus rapide de taper urpmi <toto> et que lire le README, le INSTALL, du package, de ses dépendances,compiler, etc..

Pour ce qui est de mettre la merde dans le /etc, les bons outils de packaging te permettent de faire une install a blanc pour te dire quelle fichiers ils vont modifier ou alors de rediriger le / dans /tmp/toto et apres tu regarde ce qu'il a fait dans /tmp/toto.

Et si un rpm peut te mettre le bazar dans /etc, un make install peut faire la même chose!

Les drivers d'ATI ne sont fournis qu'en binaire, mais ils fournissent une partie des specs pour que les developpeurs puissent faire des driver libre.

Une partie seulement pour des problemes Macrovision par exemple.
Mais il y a quand meme la majorite des specs, le probleme c'est juste que c'est extremement complique de faire un driver pour ces usines a gaz que sont l

Pour ce qui est du format RPM, c'est le format de la LSB, si ta distribution ne supporte pas ce format, utilise les outils de convertion qui vienne avec ta distribution: avoir different format de packaging, c'est aussi stupide que si les formats de prises electrique n'etait pas standardise, si tu veux utiliser quelque-chose d'autre que le standard, il faut utiliser des adaptateurs!

Bah, je pense qu'il a lu XvsBerlin en diagonale et n'a pas compris.

Et pour ce qui est de la latence, au contraire elle est censé être amméliorée pour certaines partie: quand tu clique sur un menu, pas besoin d'appeller le client, c'est le serveur qui se débrouille tout seul pour faire apparaitre le menu, pareil pour déplacer des fenetres,etc..

Pour ce qui est de la résolution: un écran LCD de 22.2" vendu par Viewsonic a une resolution de 200 dpi: resolution 3840x2400.

Evidemment il coute $8,000, mais 200 dpi, ce n'est pas tres eloigné de la résolution des imprimantes.

L'idée derriere le vectoriel, c'est surtout que ce qui apparaisse a l'écran soit indépendant de la résolution, ce qui me parait plutot une bonne idée..

J'ai suivi le projet depuis un certain temps (j'ai meme donné un tout petit coup de main pour traduire une doc en Francais), mais il y a une chose qui me décoit beaucoup dans Berlin/Fresco, c'est la consommation mémoire de l'ensemble: je me souviens d'un portage fait par un des développeurs du projet sur IPaQ il avait bouffé toute la mémoire du portable, alors que TiniX plus un toolkit léger prend beaucoup moins de mémoire..

Je sais bien que de toute maniere Fresco ne sera pas vraiment disponible avant que la moindre machine bas de gamme n'ai 1 Go de RAM, mais franchement cela me gene..

PicoGUI est un autre systeme qui etait prevu au depart pour les PDA et a une architecture semblable (toolkit dans le serveur) a Berlin, cependant la derniere fois que j'ai regardé l'affichage ne pouvait pas etre accéléré par le matériel, génant..

Enfin les deux ont une conception que je trouve nettement meilleure que X, la page Fresco vs X resume bien la chose.

1)Ton premier chapitre: j'ai l'impression que Motif/lesstiff ne se sont pas imposé pour diverses raisons: Motif est commercial et trop cher, lesstiff a mis longtemps a se finaliser et l'utilisation du toolkit Motif a des problemes par exemple la gestion du pavé numérique, et Motif etait moche et on ne pouvait pas facilement changer son look.

L'uniformité n'était pas un probleme, je pense qu'avec les nouvelles approches toolkit dans le serveur on pourra customiser facilement le serveur tout en gardant un look coherent pour tout les applications: le pied pour ceux qui veulent des interfaces facon "sapin de Noel".

Uniforme ne signifie pas que tout doit ressembler a Motif(beurk) pour autant..

2) Meme Apple ou Microsoft n'arrive pas vraiment a garder un look coeherent: il y a plein de toolkit different pour les deux, je doute que Berlin y arrive mieux, ne serait-ce que a cause de la compatibité nécéssaire avec les applications X..

3) Quand au fait que les interfaces actuelles soient trop limitative et qu'il y a vraiment mieux.. Bof! Ca fait des années que je lits cela et je ne vois toujours rien venir

4) Euh personellement les sites web qui ressemblent a des sapins de Noel, j'en connais peu et ceux que je connais je les ai toujours trouvés mal fichus.
Memes les rares site web "joli" et bien fait te retire partiellement le controle de tes actions: attendez pour pouvoir cliquer que je vous montre ma joliee animation..
Moi une application qui me fait ce coup la, elle ne tient pas deux secondes sur mon disque dur!
Si tu connais une exception, je suis curieux de voir cela.

>Par contre, j'ai adoré l'article sur la compression fractale de LMF.

Ah?
Je ne l'ai pas du tout aimé: dans leur "soi-disant" démonstrations mathématique, il manquait des définitions: qu'est ce qu'est qu'une réduction, par exemple.

Si on veut se la jouer mathématique, il faut être un poil rigoureux, sinon ca n'apporte rien: juste "se la jouer" parce qu'on utilise des termes compliqués..

Bah, c'est tout simplement que a l'heure actuelle, économiquement parlant cela n'a pas de sens de porter des jeux sous Linux.

JC peut faire ce qu'il veut: avec les poches pleines justement on n'est plus limité par les considérations financieres.

Mais pour les autres entreprises, ils auraient du mal a justifier devant leurs actionnaires le portage sous Linux, déja que beaucoup de jeux ne sont pas portés sous MacOS..
Or le nombre de particulier sous MacOS est nettement plus important que le nombre de gens qui ont Linux uniquement sur leur PC..

Bof; que ce soit K|Geramik ou Blue curve cette unification "esthétique" de KDE/Gnome me parait plutot creux.

C'est bien beaux que ca se ressemble, mais est-ce que, par exemple si je change les fontes dans le panneau de configuration de KDE, les applications Gnomes vont prendre cela en compte?

Si l'integration n'est pas TRES poussée avoir des applications qui sont homogene en apparence mais qui de temps en temps réagissent de maniere differente va etre tres penible pour les utilisateurs..

Merci pour le tuyeau, j'essayerai.

Bon plus qu'a me lire les docs Mozilla pour trouver comment on regles les &é"''(çà(_(à accents sous Solaris et j'aurai un Mozilla utilisable.