Bof pour la "continuité", cette optimisation n'est pas spécialement réservée aux CPUs multicoeurs/SMPs: d'ailleurs Arjan a bossé sur son laptop Asus901 (avec un seul CPU).

[ Répondre ]

>> Par exemple un noyau Linux "vanilla" n'est pas un noyau pour entreprise.
>A bon ? C'est pas tout les distributions qui patch le noyau tu sais ?

Les distributions qui n'ont pas les moyens de patcher le noyau utilisent en général une branche 'stable' du noyau (exemple Slackware utilise 2.6.27.7) pas juste le dernier noyau en date..

[ Répondre ]

D'autant plus que les points qu'il aborde avec (2) sont plus du domaine des formats de données ouverts que des logiciels libres..

[ Répondre ]

Au sujet des écrans, ce lien me parait intéressant:
http://www.akihabaranews.com/en/news-17221-LG+Display+Unveil(...)

Je ne sais pas si c'est la techno de Pixel Qi|OLPC mais le résultat me semble en partie similaire, ce qui m'a fait très plaisir car vu le rythme plutôt faible d'innovation qu'apportent les fabriquants de laptops j'étais pessimiste sur le fait qu'une techno de ce type nous arrive un jour..

Bon ce ne sont pas encore les écrans OLED ou FED/SED qui seraient vraiment le top, mais ce sera déjà un net progrès si cette annonce se concrétise!

[ Répondre ]

Moi je suis peut-être trop pessimiste, mais je ne place pas grand espoir dans ces MIPS/ARM pour portables:
1- compatibilité logicielle: avec du x86 tu as Windows et Linux, avec du MIPS/ARM tu n'as que Linux (et encore pas tout car certaines appli tel Flash ne sont dispo que pour Linux/x86).
Le transcodage logiciel ferait perdre un quelconque avantage puissance/prix si les MIPS/ARM en avaient un (cf 2).

2- le volume de vente: les RISCs ont perdu contre les x86 sur le marché des PC pour la raison (1) mais aussi car leur faible volume de vente ne leur pemettaient d'avoir des investissements comparable pour la fabrication des CPUs, le même phénomène me semble probable pour les MIPS/ARM pour portables.
Mais la c'est plus difficile a évaluer: les CPU 'low power' servent aussi pour l'embarqué, donc le volume de vente des CPU MIPS/ARM pourrait être suffisant pour rester compétitif mais il y a le problème du chipset: les chipset non x86 ont souvent été plus cher et moins complet (effet du volume des ventes), les portables x86 peuvent réutiliser les chipset 'desktop x86' ce qui est beaucoup plus souple (pas besoin d'attendre d'avoir des chipset dédiés pour portable), certes cela fait des portables avec un moins bonne autonomie mais avec beaucoup de fonctionnalités, d'un point de vue marketing ça a l'air de passer a l'heure actuelle..

[ Répondre ]

Je t'ai plussé pour la première partie, mais je n'aurais pas du car je ne suis pas du tout d'accord pour la seconde partie: pourquoi interdire les licences OEM??

Je ne vois pas du tout en quoi du logiciel jetable est scandaleux, d'autant plus que pour une fois c'est du jetable qui ne produit pas de déchet..

Ce qui est scandaleux c'est la partie vente liée, a part cela il n'y a rien de scandaleux a pouvoir choisir de payer moins cher un logiciel en acceptant la contrainte qu'il soit lié à un ordinateur.

[ Répondre ]

J'ai cru que c'était un troll de l'auteur de l'article mais non c'est vraiment dans l'intitulé du concours..

Pour illustrer la "simplicité" d'Haskell je propose cela:
http://blog.shikiryu.com/wp-content/uploads/2007/06/pendu.jp(...)

PS:
Si vous considerer qu'Haskell est simple et que je trolle alors vous devez être capable de m'expliquer ce qu'est un monade *simplement*, après tout c'est utilisé pour faire des entrée/sortie en Haskell ce qui est plutôt fondamental comme besoin!

[ Répondre ]

L'ordre des priorité me choque quand même: Arjan quand il a voulu démonter que son laptop pouvait booter en 5s, il a pris XFence pas KDE4..
Et je serai curieux de savoir ce que donne KDE4 sur un OLPC XO-1, quelqu'un a t'il essayé?

Maintenant forcément les widgets c'est plus joli..

[ Répondre ]

Ne comprenant *rien* à LDAP (dn, on, cn... qu'est-ce que c'est que cette soupe d'acronyme à la noix?? comment on s'en sert?), j'ai acheter le magazine pour l'article sur LDAP, mais je suis déçu ça n'explique pas cela.. :-(

D'ailleurs je n'ai jamais vu aucun article qui expliquait clairement ce bazar, ce qui est curieux..

En plus le panégyrique pour OSS m'a paru bizarre: le développement de logiciels libre présuppose qu'on fasse confiance à leur auteurs, mais avec la période de développement privée d'OSS je ne vois pas trop comment leur faire confiance..

La prochaine fois, je prendrais le temps de feuilleter avant, parce que la bof..

[ Répondre ]

Bon pour les ACL, extended attributes ok, c'est une fonctionalité utile, mais le boot en ZFS ce n'est pas vraiment critique..

[ Répondre ]

>pas de quoi fouetter un chat la dessus.

Ah bon, tu trouves normal qu'il ait fallu plusieurs procès pour faire changer ses pratiques à Microsoft??

[ Répondre ]

>>la vente liee c'est les constructeurs, pas MS<<

N'importe quoi!!!
La tu exagères vraiment: je ne sais pas si c'est toujours le cas actuellement mais il y a un temps MS fournissait des réductions aux constructeurs suivant le pourcentage des ordinateurs que les constructeurs vendaient avec Windows.

Comme l'immense majorité de leur ventes étant avec Windows et que les marges des constructeurs sont très, très basse, ça revient à *imposer* aux constructeurs à faire de la vente liée..

Je me souviens entre autre qu'Hitachi avait prévu de vendre des ordinateurs en dual boot BeOS/Windows, une visite de MS plus tards ils ont abandonné le projet (il y a d'ailleurs eu un procès la dessus).

[ Répondre ]

??
J'aimerai bien savoir en quoi UTF-8 n'est pas un vrai support d'Unicode..

La réponse du dessous que c'est une option a la compilation parait plus logique, donc cela veut dire que l'utilisation mémoire sera soit grosso-modo inchangée par rapport a latin-1/ASCII (bin oui, compté le nombre d'accent utilisé en moyenne dans une phrase..) soit doublée (UTF-16) soit quadruplée (UTF-32).

Je comprends qu'on utilise UTF-16 sous Windows l'OS utilisant UTF-16, par contre sous Linux utiliser UTF-16 ou UTF-32 j'ai plus de mal a comprendre: les CPUs sont tres puissant donc "gacher" de la mémoire/du cache, cela ne me parait pas optimal..

[ Répondre ]

>> les chaînes de caractères qui sont désormais unicode par défaut (avec une occupation mémoire doublée et donc une moins grande efficacité des caches)<<

Quel encodage utilise Python?
Parce que si c'est UTF-8, il n'utilisera pas plus de place pour les chaines ASCII qu'ASCII justement..

[ Répondre ]

Parce que Python est mal fichu?

Désolé, mais je considère que la gestion des 'template string' est pas terrible dans plein de langage y compris Python.

En C, tu as printf: avantage les format string sont puissants, inconvenient: pas typesafe, les variables sont toutes regrioupées a la fin.

Pour moi l'idéal serait:
puts "salut %{nom} tu as %02d{age}\n";
la lisibilité de mettre les variables au milieu de la chaine et la possibiité d'avoir quelque conversion simple pour l'affichage comme printf permet.

[ Répondre ]

>>si elle n'est pas bonne je ne vois pas quelle bonne foi ils peuvent invoquer.<<

Je ne vois pas le rapport.!
Même si le juge leur donne tort sur leur interpretation, cela ne veut pas dire que l'interpretation de Free était pour autant de mauvaise foi, juste que les avocats qu'ils ont consulté était d'un avis différent du juge..
Les zones de flou, les désaccords des experts en droit ça existe sans pour autant qu'une des partie soit de mauvaise foi pour autant..

[ Répondre ]

Bin, c'est un RHE tres, tres 'nettoyé' donc ni yum, ni interface graphique..

(meme installer le rpm de yum echoue car python n'est pas present)

[ Répondre ]

Pourquoi devraient-ils dire ce qu'il ferait de cette argent?

[ Répondre ]

Oui enfin les 'libristes' c'est une étiquette collée sur beaucoup de monde, la question, les auteurs de logiciels veulent-ils une licence qui dit que quand on loue un équipement, le fournisseur du matériel doit mettre a disposition le code source des logiciels qui tournent dessus ou pas?

Pour RMS, je n'ai pas de doute sur son point de vue, pour Linus Torvalds je pense que c'est non: cf ses prises de positions contre les clauses anti-tivoïsation de la GPLv3..

Apres le probleme avec toutes ces nuances: BSD, LGPL(qui en plus a plein de variantes car beaucoup n'aime pas la restriction sur l'édition de lien statique), GPLv2, GPLv3, AGPL, c'est qu'à chaque fois il y a une fragmentation des échanges de code possibles..

J'ajouterai que malheureusement le coté compatibilité purement d'un point de vue juridique a aussi son importance: la GPLv2 est incompatible avec la licence Apache je crois, ce qui est assez absurde..

[ Répondre ]