reno a écrit 3881 commentaires

Oups, tu as raison je confonds avec les autres RISCs comme le MIPS et l'Alpha (qui ont 32/31 registres mais 64bit).

Décidèment j'aime de moins en moins le jeux d'instruction ARM:
-toujours pas de 64bit juste une variante de PAE,
-pas de TRAP sur dépassement entier comme le MIPS..

> les changements de contexte "coûtent" plus sur ARM que sur une architecture x86 classique.

Ca doit dépendre de la version de l'ARM, non?
Suivant qu'ils aient un "tagged TLB" ou pas, je pense..

Parce que sinon je ne vois pas pourquoi les changement de contexte couteraient plus cher sur un ARM que sur un x86, mis à part peut-être le nombre de registres (et encore c'est du 32*32bit alors que pour un x86 ça peut être du 16*64bit == égalité).

> Si un attaquant prend le contrôle de la carte, il a un accès fortement privilégié au système.

Ça ce n'est pas un problème nouveau, il me semble que les IO-MMU peuvent éviter que la carte pollue le reste du système.

> Donc non, les firmwares doivent aussi être libres, c'est tout aussi primordial que le code classique, pour les mêmes raisons : la possibilité de le modifier.

Moui, en pratique c'est plus compliqué de modifier un firmware, qu'un code classique donc l’intérêt en est d'autant diminué..

Bah, il y a un coté sexiste qu'ils n'y avait pas dans l'originale.
Plus du Franglais..

Je propose:
Les sauvegardes, c'est pour les mauviettes: les vrais hommes mettent leurs données importantes sur un serveur FTP et laissent le reste du monde les recopier.

Peut-être qu'une distribution fera ce boulot, mais ce n'est pas sûr du tout: comme je l'ai mis plus haut pas mal de distributions ont packagée KDE4.0 sans même avertir leurs utilisateurs que c'était du 'bleeding edge' d'ou une certaine frustration des utilisateurs et des développeurs KDE!

J'ai bien l'impression que ça va être reparti pour un tour..

>Les devs de KDE n'ont pas toutes les configs possibles avec tous les drivers possibles pour établir leur liste noire.

Nous sommes bien d'accord.

>Ceci a été posté début juillet : http://blog.martin-graesslin.com/blog/2010/07/blacklisting-d(...)
>Ca concerne l'établissement de cette fameuse liste noire, et ca a été posté 1 mois avant la release, en même temps que la RC2.

Oh je ne dis pas qu'ils n'ont pas essayé, mais regarde dessous.

>Je ne tiens pas la team KDE pour responsable (et encore moins coupable) si la blacklist de ces cas particuliers n'est pas complète.

C'est là ou je ne suis pas d'accord!
Ce sont eux qui ont choisi d'ajouter par défaut des nouveaux effets graphiques *pas* les distributions.
C'est donc leur responsabilité de s'assurer que la blacklist pour ces effets tient la route et leur *gros* problème est de demander qu'on ne leur retourne que les cas d'erreurs..
Quand on demande de tester, il faut obtenir tout les retours: positifs et négatifs, autrement tu ne peux pas savoir si la fonctionnalité est réellement testée ou pas et la liste noire est donc incomplete.

En plus, les développeurs de KDE devraient se souvenir qu'on ne peut pas se reposer sur les distributions sans vérifier leur boulot: dois-je rappeller que beaucoup de distributions ont choisi d'installer KDE4.0 sans prévenir leurs utilisateurs qu'il s'agissait d'une version de test?
D'ou une 'frustration' certaine des developpeurs KDE a cette période..

J'ai lu l'article, c'est bien beau d'avoir une infrastructure pour gérer les problème des driver mais comme il reste des tas de gens qui se plaignent que KDE marchent mal chez eux, en général le nouvel effet kisscool^W blurred est en cause, cela montre que les listes blanches/noires n'ont pas été renseigné correctement.

Conclusion: l'infrastructure est en place certes, mais cela n'a pas été testé suffisamment puisque les utilisateurs ont toujours des problèmes.

> KDE a toujours revendiqué le fait d'utiliser au maximum les fonctions disponibles [coupé] ca les poussera à améliorer ces fonctions là aussi (enfin j'espère !)

Sauf qu'entre temps les utilisateurs en patissent!
Dans une version qui est censé *corriger* des bugs et stabiliser KDE4, tu trouves ça normal ??

Et bien a priori ils ont fait une infrastructure (*) qui permet justement de sélectionner ce qui marche ou pas.

Mais ils ont pas l'air d'avoir fait beaucoup de tests pour vérifier ce qui marche ou pas..

Bref un travail a moitié baclé: l'infrastructure sans les tests c'est beaucoup moins utile..

A mon avis, pour avoir un KDE au top ils devraient:
- faire un bureau basique qui fonctionne partout
- mettre des fonctionnalités avancés mais désactiver par défaut et demander aux utilisateurs de tester et de leur rapporter ce qui marche ou marche pas.
- activer les variantes qui fonctionnent, faire des rapports de bugs pour les autres.
Bref, beaucoup de boulot, il est beaucoup plus probable qu'ils vont continuer a faire des effets WAHOU a deux balles, activés par défaut, qui marchent chez eux, et tant pis pour toi si tu n'as pas une NVidia avec les pilotes propriétaires.

*: http://blog.martin-graesslin.com/blog/2010/09/driver-dilemma-in-kde-workspaces-4-5/

De succès dans l'exercice oui, mais bon et alors?
Cela n'en fait pas une raison pour lire ce livre, plutôt une bonne raison pour l'éviter.

>> décrire la vie telle que tout le monde peut la voir, dans un style littéraire sans intérêt particulier, je n'en vois pas l'intérêt.
> Pourtant Balzac l'a fait avec certaines de ses oeuvres. Mais bon, ce n'est pas du même niveau :-)

Flaubert aussi dans "L'Éducation sentimentale", un "classique" que j'ai malheureusement eu à lire à l'école et comme 99% des gens de ma classe, je l'ai trouvé *chiant* au possible.

Bon, je ne peux pas me moinsser pour avoir dit une bétise, mais je peux te plusser, c'est déjà ça.

C'est pour cela que j'ai dit 'quasiment': quand tu compare le nombre de driver pour NewOS par rapport à Linux ou FreeBSD au moment ou Haiku a démarrer..

On ne parle pas de la même chose!
On parlait de fatigue des yeux, pas du rendu des couleurs, ni de la qualité d'image..

Les écrans LCDs ont une image plus stable que les écrans CRT, c'est pour cela qu'ils fatigue moins les yeux , enfin sauf quand ils ont une mauvaise backlight.

Si tu veux troller sur BeOS, j'en ai un beau: Haiku est reparti 'quasiment from scratch' au lieu de prendre un noyau existant (Linux, *BSD) pour cloner BeOS.

Après tout, c'est bien connu qu'il est impossible de faire un OS différent sur un noyau existant: Android, MacOS X n'existent pas..

Si, si, j'ai le droit, c'est Vendredi!

Franchement, tout les moniteurs LCD sont excellents comparés aux écrans cathodiques..
Ce que j'aimerais bien c'est que la définition des écrans augmente (200 DPI ce serait déjà pas mal), cela aiderait aussi pour la fatigue visuelle.

Bof, quand tu sais que l'informatique a *commencé* avec des logiciels "libre", ce contexte me paraît quand même très réducteur..

Mais bon, oui, si on oublie les débuts de l'informatique alors ce n'est pas faux.

C'est un bon résumé.
Et dans certains situation la BSD peut être aussi une très bonne façon de faire avancer le libre: pile TCP-IP, codec Vorbis, etc.
Dans ce cas la, il importe plus que le format utilisé au final pour communiquer soit dans un format bien documenté et libre que le code reste libre, et pour cela produire du code sous license BSD, 'glibc', 'boost' peut aider a l'adoption par rapport a du GPL ou même du LGPL (contrainte 'discutable' sur le linkage statique).

>> Faut un peu arrêter avec cet "esprit du libre". La BSD est une licence, point barre. Tout ce qui est permis par une licence fait partie de l'"esprit" de la licence.
Faut assumer. <<

Ou changer de licence, ce qui est le cas ici..

Note que la c'est une 'entreprise de propriété intellectuelle' aussi connu sous le nom de 'patent troll' qui attaque donc il ne peut pas y avoir de replique: ils n'ont pas de produits réel eux, ce sont juste des sangsues..

Un lien interessant sur D2:
http://www.informit.com/articles/printerfriendly.aspx?p=1609144

C'est le chapitre sur le parallelisme (en Anglais) du livre d'Andrei Alexandrescu sur D.

D2 n'est pas Clojure ou Erlang, mais un language dont les variables globales sont locale au thread par défaut et qui fournit des primitives d'envoi de message, de compare-and-swap2, c'est déjà très bien!

Il y en a deux:
- GDC (backend GCC)
http://bitbucket.org/goshawk/gdc/wiki/Home

L'auteur original s'est arrêté, cependant le développement a repris, il est fonctionnel pour D1 et est en passe de redevenir fonctionnel pour D2, mais ne l'est pas encore..

- LDC (backend LLVM), mais il n'est utile que pour D1 pas pour D2, c'est celui la qui sera intégrer dans Fedora14 je crois.
http://www.dsource.org/projects/ldc

Donc pour D1 c'est bon, pour D2 (le plus intéressant) pas vraiment il n'y a que le compilateur officiel de fonctionnel pour le moment (dont le frontend est libre ceci dit).

Oui, eh?
Intel n'est pas le seul a faire des bidouilles pas très belle:
ARM vient d'annoncer une extension 40-bit mais chaque processus restant limité à 32 bit.. Bref, comme PAE quoi, c'est aussi une bidouille moche pour résoudre les limitations en mémoire..

MIPS, PowerPC eux ont une vrai extension 64-bit..

> gérant la mise à l'échelle.

Pour aller au grenier?

Bon, plus sérieusement, c'est compliqué de traduire le concept de scalabilité, ce serait quelque-chose comme:
"ne pas empecher de supporter un grand nombre d'utilisateur|de connections|de transactions."

Autant utiliser le terme Franglais, c'est plus concis!

> Le desktop n'est qu'une commodité, et même un anachronisme dans le monde des petits écrans mobiles

N'importe quoi..
Differents besoins --> differents outils pour les satisfaire..
On n'utilise pas un téléphone (même un smartphone) comme on utilise un ordinateur de bureau et vice-versa.
Certains besoins sont communs, ok, et l'un peut remplacer l'autre mais ce n'est pas une majorité loin de la.

Bah, l'ACPI c'est juste une preuve de plus qu'Intel est souvent très mauvais coté définition d'interfaces, comme autre preuve j'ai:
- se louper totalement sur le MMX: le partage des registres MMX avec les registres FP étant une c... sans nom
- loupage partiel avec le SSE première version, SSE2 étant bien plus régulier
- ne pas être capable de faire évoluer le x86 correctement, en final c'est AMD qui a du le faire..

Je ne pense pas que tout ces ratages soient anti-Linux, c'est juste qu'Intel a d'un coté des super-ingénieurs qui gérent les meilleurs fonderies aux monde, de l'autre des dirigeants qui prennent des décisions très, très 'surprenantes':
- pousser le Pentium4 a plusieurs GHz: un responsable de la conception de CPU a démissioné pour protester!
- la derniere en date étant l'achat d'un éditeur d'antivirus!