reno a écrit 3879 commentaires

en attendant en france

==> en province
à Paris ce que tu décris c'est seulement le Dimanche ou au mois d’août en dehors des quartiers touristiques.

NB: Ceci n'est en aucun cas une pub pour les cafés/restaurants de Paris, les garçons de cafés malpoli à Paris ça n'est pas qu'une légende, il y en a beaucoup malheureusement..

Pas plus qu'avec OpenGL puisque
1) il y a déjà des extensions spécifiques à chaque carte avec OpenGL
2) les pilotes OpenGL étant très compliqués, il n'est pas rare d'avoir du code qui fonctionne sur X mais pas sur Y (même sans utilisée ces fameuses extensions).

Donc avec Vulkan, normalement le problème (2) devrait diminuer, mais (1) reste bien sûr.

Et la version Anglaise dit "Intel stated in 2015 that the pace of advancement has slowed, starting at the 22 nm feature width around 2012, and continuing at 14 nm. Brian Krzanich, CEO of Intel, announced that "our cadence today is closer to two and a half years than two.”

C'est ce que je disais: la loi de Moore a du plomb dans l'aile..

Bien que Canon soit considéré comme bon en 'cout à la page' il faut se méfier: ma Canon faisait très souvent des nettoyages des tètes d'impression, nettoyage qui consomme de l'encre..
Nettoyage qui n'ont pas empêché la tète d'impression de tomber en panne au bout de 3 ans..

Je suis passer chez HP, je verrai bien si l'imprimante dure plus longtemps, mais elle fait déjà beaucoup moins de nettoyage des tètes d'impression, c'est toujours ça de gagné..

Dommage que les lasers ça coûte cher, je me souviens en avoir trouvé une à un prix presque raisonnable avant de découvrir qu'elle ne faisait pas le recto/verso: j'ai failli me faire avoir, je ne pensais pas que ça existait encore au 21ème siècle une imprimante non recto/verso.

xcomcmdr: RISC = Reduced Instruction Set Computer, donc le RISC est une propriété des ISA, des jeux d'instructions. Le jeux d'instruction x86 n'a PRESQUE PAS évolué vers un jeu d'instruction type RISC (load/store, décodage simple, etc).
Le seul point sur lequel on peut dire qu'ils ont évolué c'est le nombre de registre accessible dans l'ISA qui a augmenté lors du x86-64 (bien que restant très inférieur aux 32 registres entiers classique des ISA RISC).

Les implémentations des x86 et des RISCs se sont rapprochés oui, les ISA non.

Ça fait 20ans que la loi de Moore va s'arrêter dans les 5 prochaines années.

Tu retardes: je considère que la loi de Moore s'est déjà arrêtée..

Les processeurs RISC-V sont théoriquement peu puissants et peu efficaces énergétiquement

Peu puissants oui, mais "peu efficaces énergétiquement"?
Je pense qu'il s'agit d'une erreur: ils ont même pas de CCR pour améliorer leur efficacité énergétique.

Après ça dépend si tu parles de l'ISA ou des implémentations: l'ISA a été conçue pour être efficace énergétiquement mais les implémentations c'est autre chose..

Linux, c'était pas encore vraiment ça.

Mais Linux avait déjà une dynamique fortement positive et un avenir prometteur.

Haiku a choisi la licence MIT car elle permettrait, plus facilement que la GPL, de partager du code avec une éventuelle continuation propriétaire de BeOS. Utiliser un noyau Linux n'était donc pas possible.

Oui enfin préférer miser sur "une éventuelle continuation propriétaire de BeOS" plutôt que sur Linux (même en 2001), comment dirais-je?
"il n'est pire aveugle que celui qui ne veut pas voir.."

Et ça n'explique pas pourquoi Haiku n'a pas pris un noyau BSD plutôt qu'un noyau développé par une seule personne.

Tu as raison, la sécurité en nécessite très peu de RAM (juste la gestion des droits d'accès des pages).

Après se faire la compétition sur qui a l'OS et la GUI qui prends 100, 200 ou 300 MO de RAM quand le navigateur web a besoin de plus de 4GO, bof..

Tu es de très mauvaise foi avec ton exemple, la résolution d'un Amiga était pourrie et il n'y avais aucune sécurité, maintenant on a des moniteurs UHD et tout le monde est connecté à Internet, la sécurité n'est donc plus optionnelle, tout ça nécessite beaucoup de RAM.

En plus la "compétition" au niveau de l'OS et l’environnement de bureau qui utilise peu de RAM me parait plutôt ridicule quand on vois les besoins mémoires des browser web capable d'afficher les sites web actuels..

Je pense que tu fais erreur: ces personnes ne cherchent pas "le succès rapidement": autrement ils auraient pris un noyau Linux ou *BSD et ils se seraient focalisés sur les couches hautes, mais ça n'est pas "sexy": réutiliser l'existant ça apporte des contraintes donc ça ne les attire pas, par contre développer quasiment tout depuis le début, ça oui ça leur plait donc le fait que ça dure longtemps n'est pas vraiment un problème pour eux.

Bien sûr (à mon avis), c'est juste reculer pour mieux sauter: à la fin il y a quand même le travail de 'peaufinage' chiant mais nécessaire (les pilotes de périphériques, les bugs bizarres, etc) et finalement les contraintes de l'existant.. ça explique pourquoi beaucoup de projets sont dans l'état 'presque fini' et y restent: les bureaux Linux sont champions pour ça..

Je suis plutôt d'accord avec ta conclusion: sur un ordinateur avec un CPU puissant, de la mémoire et un SSD, les OS classiques marchent (enfin) bien (merci les SSD).

Pour un SoC complètement libre, il faudrait un GPU libre aussi.

Dans un premier temps, le RISC-V semble plutôt cibler les IoT qui n'ont pas besoin de GPU.
Si tu lis plus haut, ils n'ont même pas encore stabilisé la partie FPU et SIMD..

et la majorité des 10 plus puissantes centrales électriques du monde sont des barrages, avec un simple mur de béton et des turbines.

Simple? Vraiment ?
https://en.m.wikipedia.org/wiki/Dam_failure

De mémoire une comparaison entre Thumb2 et x86 avait trouvé Thumb2 légèrement + dense que le x86, c'était peut-être légèrement moins dense mais
1) ça se tenait dans un mouchoir de poche.
2) le x86-64 est moins dense que le x86 (sauf pour faire des calculs 64 bits évidemment).

Je ne suis pas tout à fait d'accord: ajouter un décodeur x86 dans le CPU et sous utiliser le CPU car le compilateur ne peut voir qu'un petit nombre de registre, ça a aussi des conséquences au niveau de la consommation.

Et pour ce qui est de la densité de code moins importante des RISC, tu retardes: ARM et MIPS ont tout les deux des extensions avec instruction 16 bits, qui ont une densité de code équivalente à celle des x86, ce qui permet d'avoir le "meilleur des mondes" pour ces RISCs: du code compact pour le "tout venant" mais quand même accès a beaucoup de registre/des instructions supplémentaire quand il y a besoin.

Après il est vrai qu'ARMv8 n'a pas cette extension ce que je trouve très surprenant.

Mais pourquoi donc on n'a pas de concurrent qui propose une puce compétitive face à un Xeon 10 cœurs par exemple?

Sérieux tu pose réellement la question? Pour la même raison que les RISCs haute performance (Alpha et autre) sont morts: Intel peut vendre ses x86 dans le monde Windows ET dans le monde Linux alors qu'un NEW-Alpha sera confiné au monde Linux, donc le retour sur investissement est beaucoup plus difficile --> Intel a les meilleurs fab.

Certes Intel a un désavantage: le jeu d'instruction x86 qui nécessite un décodeur complexe et ça a été probablement un gros désavantage quand les transistors étaient "rare et cher" mais maintenant que le problème principal est "quoi faire avec tout ces transistors?" le désavantage est réduit..

N'ayant jamais eu de smartphone, je ne vois pas ce qui pourrait manquer dans cette approche.

C'est parce que tu manques d'expérience pratique:
*F-droid est nul par rapport aux stores classiques: pas de capture d'écran, pas de retour des utilisateurs ou de votes des utilisateurs.

*Cyanogenmod, c'est de l'aléatoire: j'ai lu des retour avec des problèmes de stabilités, une durée de batterie diminuée, un GPS qui ne marche pas ou le bluetooth: ça dépend du smartphone, ça peut peut-être bien marcher mais il faut bien se renseigner avant.

*est ce que ça marche bien la navigation a partir des cartes OSM?
Quand je vois que Waze une fois m'a bien planté (~45 minutes de retard, sympa quand on a 3 enfants dans la voiture), j'ai tendance à me méfier maintenant..

il semble surtout dire que la marché s'écroule car tous les constructeurs sortent les mêmes machines sans innovation + il y a le mobile qui vient parfois remplacer le PC.

Personnellement je trouve qu'il a raison: quand je vois les tarifs des PC portables avec SSD.. Pas de quoi s'étonné que les ventes de PC baissent..
Un HDD sur un PC portable, c'est une hérésie ça devrait être au minimum un combo SSD+HDD(SSHD) ou un SSD uniquement.

A force de reprendre toutes les idées du C/C++, on va se retrouver avec du C/C++…

Au "petit détail" près qu'en Python les int sont des "big int" non?
Adieu les débordements entiers si fun en C/C++..

J'ai du mal a réconcilier la notion de 'fair use' classique a ce qu'a fait Google (réimplementer totalement les API)..
Donc je suis en désaccord avec le 1er jugement (les API ne devraient pas être copyrightable) ET avec le 2ème jugement, c'est grave docteur?

1) Oracle avait perdu le premier procès mais gagné en appel et la cour suprême avait refusé de s'occuper de l'appel de l'appel donc les API sont copyrightable aux USA.

2) l'appel qu'Oracle va certainement faire va aller devant la même cour d'appel qui lui avait donner raison sur le fait que les API étaient copyrightable.

==> j'attendrai encore avant de sortir le champagne, même si la perte du procès est effectivement une bonne nouvelle..

MDR les "gender icons".

Gérer le kernel avec cvs??
Tu es sérieux là?

svn je connais moins.

Pharo est un langage de programmation orienté objet, en Smalltalk

Smalltalk étant un langage, "en Smalltalk" pour moi ça veut plutôt dire "implémenté en Smalltalk" ce qui ne donne absolument aucune idée de ce qu'est Pharo: il y a plein de langage implémenté en C très différent du C.. Je dirais plutôt "une variante de Smalltalk" ou "un Smalltalk" si tu veux vraiment faire court.

Le lien en question: http://www.vox.com/2016/4/28/11518804/weight-loss-exercise-myth-burn-calories