Les efforts de maintenance sont pour moi sur les drivers à chaque changement d'API. Des APIs qui changent moins souvent, ca demande moins de maintenance des drivers.
il faut bien maintenir ton API qui est connecté qq part !
Va dire cela à ceux qui ont du matos qui n'est plus fonctionnelle sous Vista...
Et non, doubler ou tripler l'effort de maintenance pour des bouts externes ne vaut pas le cout. Et je suis persuadé que 80% de la différence de qualité (plantage) entre windows et Linux, c'est justement cette gestion des drivers par le noyau. (sous linux, une bonne source de plantage, c'était le serveur X comme par magie en espace utilisateur, alors que c'est normalement une garantie de stabilité...)
Tu veux des "mémoires transactionnelles" en HW? j'ai des doutes sur ce qui est attendu exactement, mais j'ai l'impression que c'est encore un truc complexe que les softeux refilent au hardeux en croyant au Père noël.
Lisaac est "bydesign" conçu pour mettre en contradiction les gains de perf avec la modularité du code.
Pas du tout, c'est même complètement idiot comme argument. Lisaac favorise la découpe en horizontal et optimise en vertical.
En gros, toute lib est compilé en global mais si tu veux faire des modules pour Linux, tu pourra à terme. Le coté "composant" de Lisaac n'existe pas encore, mais il pourra exister plus tard en ayant toujours la compilation global sur les libs. Le grain est bien plus gros que le fichier C.
La modularité dans le design du code est indépendant de la technologie que tu emplois derrière pour faire tourner le tout.
Linux n'est pas un microkernel pourtant tout les sous systèmes sont clairement identifié en interne. Les drivers ont un système objet pour se déclarer et être utilisé par l'OS.
Concernant le coté compile global de Lisaac, c'est une faiblesse qui est à relativiser. La compilation par fichier .c a été faite à cause de la faiblesse des machines de l'époque. Depuis la définition du C, les cpus ont gagné en vitesse, et la raison du saucissonnage du code n'a plus lieu d'être.
On sait que Lisaac doit être capable de gérer des millions de lignes de code. Aujourd'hui, on sait que 50000 lignes se compilent en une dizaine de seconde sur un atom, mais derrière gcc rament franchement (qq minutes ?). Cela laisse de la marge.
La cote d'azur est étiré le long du littoral. C'est peu dense dés que tu t'éloigne de la côte, un peu le contraire d'un centre ville. Comme beaucoup d'endroit tu te retrouves sur des routes à 90Km/h. Donc, un trajet de 15 minutes en voiture te prendrai plus d'une heure à vélo.
Quand il faut 24 cycles pour atteindre le controlleur DRAM, ce n'est pas seulement un problème de bande passante mais aussi de latence parce que le contrôleur est à l'autre bout du chip.
Les busmatrix ne sont souvent qu'un moyen pour cacher les interconnections sous le tapis. De toute façon tous les flux de données important se font vers ou depuis la RAM.
A la limite, il faudrait juste une connexion en étoile vers le contrôleur mémoire et un APB pour gérer la configuration.
Ou bien encore un gros anneau comme sur certain FPGA ou le cell.
Je pense qu'une version propre, serait un gros NAT + une adresse ipv6 pour un FAI. Les boites se comportant comme des dhcp, il est facile de leur faire faire le choix.
Il faudrait que fasse la différence entre l'annonce de ARM sur une macro cell et le marché.
Concernant l'arm11 SMP, est-ce que tu connais du vrai silicium ?
Pareil pour le cortex A9, le 4430 n'aura que 2 cores max. Si il sort un jour à 4 cores, cela sera pour dans 1 an minimum.
Heu, sur un cpu arm tu es libre d'avoir le controlleur memoire que tu veux. Et la bande passante du bus AHB (entre le cpu et le controlleur memoire) est assez enorme.
Sauf qu'ils ne le font pas parce qu'ils n'ont pas le même genre de culture que intel/amd. Un chip de téléphone c'était avant tout la basse consommation, une myriade de périphérique, une taille petite, une intégration poussé, un prix bas. Les perfs ne rentraient en compte qu'au niveau du type de cpu ARM embarqué.
La bande passante d'un bus AHB classique est totalement ridicule par rapport au moindre petit x86. Il s'agit avant tout d'un bus 32 bits a vitesse plus faible que celle du cpu ! Dans un athlon64, le contrôleur mémoire est intégré dans le pipeline du cpu.
Pour avoir de la vrai puissance, il faudrait passer aux 64 bits en gardant la même fréquence avec une connexion direct au contrôleur mémoire, voir une connexion par port AHB du Cortex (de mémoire, il en a 2 ou 3, data et code séparé) et ne pas passer par un bus.
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: L'utilisation récurrente de la vidéo d'Adolf Hitler pose question.
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Affaire Zataz suite. Évalué à 2.
http://www.youtube.com/watch?v=zwySDvEr7GY&hl=fr
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
il faut bien maintenir ton API qui est connecté qq part !
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
Va dire cela à ceux qui ont du matos qui n'est plus fonctionnelle sous Vista...
Et non, doubler ou tripler l'effort de maintenance pour des bouts externes ne vaut pas le cout. Et je suis persuadé que 80% de la différence de qualité (plantage) entre windows et Linux, c'est justement cette gestion des drivers par le noyau. (sous linux, une bonne source de plantage, c'était le serveur X comme par magie en espace utilisateur, alors que c'est normalement une garantie de stabilité...)
"La première sécurité est la liberté"
[^] # Re: Rien de transcendant dirait-on
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Noop : encore un nouveau langage ou bien nouvelle génération de langage. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
De plus, vu le peu d'info disponnibles, peu d'optimisation sont possible.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
Pas du tout, c'est même complètement idiot comme argument. Lisaac favorise la découpe en horizontal et optimise en vertical.
En gros, toute lib est compilé en global mais si tu veux faire des modules pour Linux, tu pourra à terme. Le coté "composant" de Lisaac n'existe pas encore, mais il pourra exister plus tard en ayant toujours la compilation global sur les libs. Le grain est bien plus gros que le fichier C.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet (Compilation globale/séparée)
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
Linux passe directement de la case je casse l'API à la case je corrige tous les drivers.
Si l'API introduit une faille de sécurité tu la gardes ?
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 3.
Linux n'est pas un microkernel pourtant tout les sous systèmes sont clairement identifié en interne. Les drivers ont un système objet pour se déclarer et être utilisé par l'OS.
Concernant le coté compile global de Lisaac, c'est une faiblesse qui est à relativiser. La compilation par fichier .c a été faite à cause de la faiblesse des machines de l'époque. Depuis la définition du C, les cpus ont gagné en vitesse, et la raison du saucissonnage du code n'a plus lieu d'être.
On sait que Lisaac doit être capable de gérer des millions de lignes de code. Aujourd'hui, on sait que 50000 lignes se compilent en une dizaine de seconde sur un atom, mais derrière gcc rament franchement (qq minutes ?). Cela laisse de la marge.
"La première sécurité est la liberté"
[^] # Re: approche local vs. globale?v
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 5.
"La première sécurité est la liberté"
[^] # Re: Tanenbaum avait-il raison ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: On ne parle pas de la meme chose...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Le troll
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Train....
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SNCF : Antibes-Grenoble en 16h, c'est possible.. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: voiture ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SNCF : Antibes-Grenoble en 16h, c'est possible.. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: mouais...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal ARM sort l'artillerie lourde. Évalué à 2.
Les busmatrix ne sont souvent qu'un moyen pour cacher les interconnections sous le tapis. De toute façon tous les flux de données important se font vers ou depuis la RAM.
A la limite, il faudrait juste une connexion en étoile vers le contrôleur mémoire et un APB pour gérer la configuration.
Ou bien encore un gros anneau comme sur certain FPGA ou le cell.
"La première sécurité est la liberté"
[^] # Re: Train....
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SNCF : Antibes-Grenoble en 16h, c'est possible.. Évalué à 2.
\o/ copain !
Alors tu es coté mer de verdure ou montagne + autoroute ?n
"La première sécurité est la liberté"
[^] # Re: Revenons à la question initiale pour comprendre
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le NAT chez ton FAI ou la fin du Web tel qu'on le connaît ?. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: le mouchard n'est pas obligatoire
Posté par Nicolas Boulay (site web personnel) . En réponse au journal La solution pour adopter HADOPI (1,2,...). Évalué à 7.
"La première sécurité est la liberté"
[^] # Re: mouais...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal ARM sort l'artillerie lourde. Évalué à 2.
Concernant l'arm11 SMP, est-ce que tu connais du vrai silicium ?
Pareil pour le cortex A9, le 4430 n'aura que 2 cores max. Si il sort un jour à 4 cores, cela sera pour dans 1 an minimum.
Heu, sur un cpu arm tu es libre d'avoir le controlleur memoire que tu veux. Et la bande passante du bus AHB (entre le cpu et le controlleur memoire) est assez enorme.
Sauf qu'ils ne le font pas parce qu'ils n'ont pas le même genre de culture que intel/amd. Un chip de téléphone c'était avant tout la basse consommation, une myriade de périphérique, une taille petite, une intégration poussé, un prix bas. Les perfs ne rentraient en compte qu'au niveau du type de cpu ARM embarqué.
La bande passante d'un bus AHB classique est totalement ridicule par rapport au moindre petit x86. Il s'agit avant tout d'un bus 32 bits a vitesse plus faible que celle du cpu ! Dans un athlon64, le contrôleur mémoire est intégré dans le pipeline du cpu.
Pour avoir de la vrai puissance, il faudrait passer aux 64 bits en gardant la même fréquence avec une connexion direct au contrôleur mémoire, voir une connexion par port AHB du Cortex (de mémoire, il en a 2 ou 3, data et code séparé) et ne pas passer par un bus.
"La première sécurité est la liberté"
[^] # Re: mouais...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal ARM sort l'artillerie lourde. Évalué à 2.
3000 pages, c'est, en gros, pour une ligne par champs de bits. Pour comprendre mieux, il faut la doc de la sous partie.
"La première sécurité est la liberté"