>>+ Manque d'homogénéité :
> Va falloir que l'on m'explique en quoi cela gène l'utilisateur !
> Même sous windows cela existe. Tu trouves que Liveware est intégré au reste de l'interface ?
> idem pour WMP ou winamp ?
Juste pour dire que je suis d'accord avec lui, c'est un poil génant au niveau de l'interface:
le copier/coller ne marche pas toujours, les applications en Motif ne supportent pas que NumLock soit enfoncé, la roulette de la souris est mal supporté parfois,etc..
Des petits trucs, plus le fait que c'est lourd en mémoire de charger n toolkit..
Je ne vois pas en quoi l'optimisation pour le probleme des shared libraries est spécifique à Linux, c'est plutot un probleme au niveau applicatif..
RMS n'a pas envie que KDE puisse tourner correctement sur Hurd?
C'est parce que les développeurs de KDE ne se sont pas excusés?
Vu la vitesse a laquelle la GlibC évolue, je me demande s'il ne vont pas se faire forker comme ça a été fait pour GCC..
Ca fait combien de temps que KDE se bat pour contourner des problemes lié au librairie dynamique, au linker ? Deux ans? Plus?
Le fork pourrait même prendre avec lui un des développeur principal vu la façon dont il s'entend avec RMS?
Pour le problème de lecture des formats propriétaire?
Comme tu disais: c'est à la lumiere de cela que l'on voit l'intérét des logiciels ouverts.
Et j'ajouterais: Et les limites du libre :-(
[^] # Re: frein au développement du bureau sous Linux
Posté par Anonyme . En réponse à la dépêche Linux est il pret pour le desktop ?. Évalué à 1.
> Va falloir que l'on m'explique en quoi cela gène l'utilisateur !
> Même sous windows cela existe. Tu trouves que Liveware est intégré au reste de l'interface ?
> idem pour WMP ou winamp ?
Juste pour dire que je suis d'accord avec lui, c'est un poil génant au niveau de l'interface:
le copier/coller ne marche pas toujours, les applications en Motif ne supportent pas que NumLock soit enfoncé, la roulette de la souris est mal supporté parfois,etc..
Des petits trucs, plus le fait que c'est lourd en mémoire de charger n toolkit..
Je ne vois pas en quoi l'optimisation pour le probleme des shared libraries est spécifique à Linux, c'est plutot un probleme au niveau applicatif..
RMS n'a pas envie que KDE puisse tourner correctement sur Hurd?
C'est parce que les développeurs de KDE ne se sont pas excusés?
Vu la vitesse a laquelle la GlibC évolue, je me demande s'il ne vont pas se faire forker comme ça a été fait pour GCC..
Ca fait combien de temps que KDE se bat pour contourner des problemes lié au librairie dynamique, au linker ? Deux ans? Plus?
Le fork pourrait même prendre avec lui un des développeur principal vu la façon dont il s'entend avec RMS?
Pour le problème de lecture des formats propriétaire?
Comme tu disais: c'est à la lumiere de cela que l'on voit l'intérét des logiciels ouverts.
Et j'ajouterais: Et les limites du libre :-(
reno