karteum59 a écrit 885 commentaires

Ma mère, par exemple, avait attendu pour ne pas avoir Vista, a acheté un portable avec Windows 7, il est tombé en panne et a été remplacé par un nouveau modèle avec Windows 8, elle m'a appelé au secours tellement elle ne l'aimait pas, et elle tourne désormais sous Ubuntu.

Ah ben finalement, tout est bien… :)

mais la crise n'affecte pas le monde de l'informatique comme les autres domaines, d'ailleurs, la crise était là bien avant que les ventes ne chutent. Et puis il n'y a qu'à voir les ventes de tablettes, alors qu'elles ne sont pourtant qu'un gadget non indispensable.

La crise va affecter notre domaine lorsque les ressources nécessaires à la fabrication de nos iBidules (terres rares, énergie, eau) vont se raréfier…

Bruxelles a infligé une amende de 561 millions € à Microsoft pour avoir rompu son engagement de permettre à l'utilisateur de choisir son navigateur Web

C'est clair que l'argument est bancal (même s'il est sûrement juridiquement valide).
Je trouve que le problème du secure-boot (à fortiori sur les marchines ARM où il est non désactivable) est un bien plus grand souci que le choix du navigateur !

(N.B. et d'ailleurs tant qu'on y est, il serait sympa que la commission interdise d'une manière plus générale les bootloaders verrouillés, et oblige les fournisseurs à donner les détails bas-niveau (doc ou device-tree + drivers) afin que la communauté puisse prendre le relais après la fin du support officiel, pour lutter contre l'obsolescence programmée et le gâchis environnemental associé…)

Oui, mais bon, des implémentations, il y en a pas des milliers, hein. Il n'y a en gros que Xfree86 dont le développement est abandonné depuis plusieurs années, et le fork X.org.

Il y a aussi android-xserver
(et aussi apparemment d'autres implémentations comme weirdx

On va essayer de savoir où il va tomber, et éventuellement évacuer la zone ou conseiller aux gens de se planquer dans les caves

Heu, on n'est déjà pas capable de déterminer où retombent nos propres satellites même après juste l'impact, alors imaginer prendre des mesures basées sur la prédiction de la zone d'impact d'une météorite…

Je vais juste répondre à ton premier point: le fait que KDE s'appuie sur un framework non libre (Qt à l'époque) était quand même sacrément choquant pour un bureau libre, et tout le monde avait bien compris la motivation de la création du projet Gnome à cette époque. Absolument rien de WTF pour le coup.

Il fallait réellement écrire un autre desktop entier pour ça ? Se contenter d'écrire un toolkit (L)GPL avec une API compatible n'aurait-il pas évité de diviser la communauté (et les contributions) en 2 ?
(bon d'un autre côté, c'est ce qui a permis à Trolltech de prospérer. QT n'en serait peut-être pas là si la boîte avait été tuée dans l'oeuf à cause d'un fork LGPL trop tôt…)

D'autre part les interfaces déclaratives chez Gtk/Gnome ça date de 1998 avec glade (ça me semble assez tôt pour une interface déclarative). QML est arrivé en 2010 (c'était déjà plus dans l'air du temps).

Oui enfin bon, bien avant l'arrivée de QML, QT designer existait et faisait déjà exactement comme Glade (et les fichiers .ui qu'il générait étaient des fichiers XML chargeables dynamiquement, comme avec Glade…)

Personne ne dit que Fossil est mieux dans tous les cas (cf ta phrase "ce n'est pas quelque chose que je recherche" : eh bien soit ! Mais je ne vois pas en quoi le serveur+wiki intégrés sont pour autant un inconvénient ! Personnellement, je trouve cet aspect autonome (sans dépendances) extrêmement commode dans de nombreuses situations et ça facilite sa démocratisation). L'utilisation de sqlite n'est pas un vrai argument, mais c'est juste pour dire que c'est simple à backuper et/ou à interroger avec des outils externes, etc.)

Argument valable aussi pour Fossil !
(qui de surcroît est beaucoup plus simple, multi plate-forme, et possède une ui web et un wiki intégrés, et tout l'historique est stocké dans une base sqlite…)

Il y a aussi Lives et Jahshaka
(et je me demande aussi à quel point Blender ne peut pas être utilisé pour ces usages là ? Apparemment je ne suis pas le seul à y penser…)

Oui, Android existe sur MIPS. Par exemple, la tablette Ainol Novo7 Paladin utilise un processeur JZ4770 (notons d'ailleurs que son concepteur Ingenic est plutôt sympa avec Linux)
Mais le gros inconvénient, c'est qu'il faut un outil comme MagicCode pour faire fonctionner la plupart des applications (et je cherche à comprendre pourquoi, dans la mesure où je pensais initialement qu'un .apk était fait de bytecode Dalvik indépendant de la plate-forme, sauf rares cas d'applications utilisant le NDK).

Faut-il rappeler aussi que Linus a fait la même erreur 10 ans plus tard ? "This 508 kB kernel size should be enough", avant d'implémenter bzImage pour contourner le problème…

OK, bon point.

• Cependant, il me semblait que les noyaux qui allaient sortir tout prochainement permettraient de faire tourner Android (i.e. plus besoin d'un noyau patché par Google) ?
• autre approche : il y a peut-être moyen de patcher "quelque part" AOSP pour faire une espèce de couche d'adaptation sur les quelques parties manquantes ? (par exemple, pour que les appels au GPS renvoient une position factice, et pour que les appels à Binder soient wrappés sur des appels DBus…). Note que je n'ai aucune idée de la faisabilité et de la quantité de travail que ça représente, c'est pour ça que je pose la question !
• ça ne dit toujours pas pourquoi l'interprêteur Dalvik sur MIPS est incapable de faire tourner la plupart des .apk (prévus pour ARM) alors que c'est sensé être du bytecode…

D'après ce que je comprends, ça reste une sorte d'émulateur/VM pour le système complet, kernel inclus (avec toute la lourdeur associée à cette approche). Je ne me suis pas encore penché de très près sur la question, mais j'aimerais comprendre

• où est la difficulté pour recompiler Dalvik, Bionic, etc. sur Ubuntu"la distro du pékin moyen", et faire tourner toutes les couches d'Android dans un chroot (beaucoup plus léger qu'une VM) ?
• pourquoi les .apk ne sont-ils pas naturellement cross-platform ? (à la base, c'est bien du bytecode pour Dalvik et pas du code natif, et je présume que les applis qui utilisent le NDK sont une minorité => pourquoi ma tablette à base de CPU MIPS ne fait-elle tourner que 5% des applis du Market, et pourquoi faut-il un hack (Magiccode) pour augmenter le taux de succès ?)

"ça ne marche pas" sous-entend que d'autres modèles fonctionnent. Sauf que ceux qui tablent sur la "croissance" vivent en fait à crédit en épuisant à toute vitesse les réserves énergétiques et minières de notre planète (qui pourtant devra continuer à faire vivre et nourrir quelques 7 milliards d'humains). Je ne cherche pas à défendre ce qu'on fait subir à la Grèce, mais il serait utile que la population dans son ensemble comprenne que la sobriété sera de toute façon au menu tôt ou tard ! Tous nos acquis sociaux découlent directement ou indirectement de la disponibilité d'une énergie abondante et pas chère…

Si tu veux être cohérent, ça signifie que tu es prêt à payer pour les sites et services que tu utilises (y compris Google) ? ET bien entendu, tu as fait un don à Wikipedia…

Notons que si Google veut à son tour faire chier Free (vu que les abonnés Free ne lui rapportent plus rien et ne deviennent qu'un poste de coût si la pub est filtrée), ils pourraient très bien bloquer le service pour toute la plage d'IP de Free, de la même manière que certains services comme Pandora et Netflix ne sont pas accessibles en France ! Free joue un jeu dangereux en prenant Google pour un crétin, car on aurait l'air fin sans Google search, YouTube, Google Maps, etc. (après, on peut discuter du problème de notre dépendance à Google…). J'imagine que Google pourrait aussi plus subtilement rajouter un bout de .js (uniquement si l'IP destination est chez Free pour ne pas ralentir les autres) qui teste si certaines URLs de pub sont accessibles, et bloque le service dans le cas contraire (ce qui aurait pour corollaire de gêner les utilisateurs de Links et autres curl). Bref, qui sème le vent…

<troll>
Si RMS préfère les logiciels GPL à LGPL, on se demande pourquoi il a soutenu Gnome face à KDE… (si je me souviens bien, le principal reproche venait de QT non libre, mais ce dernier est sous GPLv2 depuis la version 2.2 sortie en l'an 2000 !).
</troll>

Autre exemple : le noyau Linux est sous licence GPL, ce qui empêche par exemple de faire un fork pour le transformer en micro-noyau et de copier-coller du code et des algos sous forme de libs userspace, car les seules applis GPL auraient le droit de se linker dessus. D'une manière générale, la GPL restreint l'usage du code en empêchant sa réutilisation dans d'autres contextes tels que des libs. Je trouve que la MPL est un bon compromis entre GPL (trop "virale" à mon goût, et entrainant ensuite des barrières techniques pour des raisons non techniques) et la BSD (qui ne se protège pas, permettant à des industriels peu scrupuleux de prendre sans reverser…)

Wow, consternant !
Est-ce que c'est susceptible d'être reconsidéré maintenant qu'on a changé de couleur politique ?

Même celui-là ? (disponible sur F-Droid)

Hmmm… en télécoms, on est de toute façon sur un système très règlementé qui amène forcément un oligopole (l'Arcep a affirmé explicitement se projeter sur un marché à 4 opérateurs lors de l'appel d'offre pour les licences "4G". D'ailleurs cet appel d'offres était d'une hypocrisie à mourir de rire tellement c'était taillé pour les 4 gros opérateurs en place et prévu pour ne pas laisser entrer de nouvel acteur sans vraiment le dire explicitement !).
Donc la comparaison avec le livre ne tient pas. Par ailleurs, sur le plan environnemental, notre système actuel oblige à multiplier le nombre d'équipements et à mal gérer les ressources spectrales en ne permettant pas d'homogénéiser dynamiquement le ratio MHz/nb_clients.
Bref, on aurait probablement pu avoir un modèle analogue à ERDF ou RFF : une entité publique qui gère les infras structurantes sur l'aménagement du territoire (i.e. la boucle locale), et une myriade d'opérateurs qui sont en fait juste des full-MVNO par dessus… Il y a des avantages et des inconvénients
+ moins d'équipements et moins de sites => moindre empreinte environnementale
+ meilleure gestion des fréquences (mutualisation des ressources => tout le monde a le même ratio MHz/nb_client)
+ pas de licence exorbitante à rentabiliser pour les opérateurs => tarifs moins élevés
+ plus d'opérateurs => plus de concurrence et tarifs moins élevés (et peut-être plus de taxe professionnelle à long terme ?)
+ pas de concurrence sur l'infra ou de contrainte sur les coûts => meilleur déploiement en zone rurale ?
- pas de contrôle fin des opérateurs sur l'infra => pas de garantie que ça corresponde aux besoins de couverture, surtout lorsqu'ils souhaitent adresser des marchés spécifiques
- pas de concurrence sur l'infra => tarifs plus élevés ?
- moins d'argent à court terme dans les caisses de l'état (licences)
- moins de déploiements et d'équipements => moins d'emplois pour le secteur télécoms
- contrôle de l'état sur toutes les infrastructure de boucle locale (peut-être pas souhaitable en démocratie).

Aaah, les méchants opérateurs télécoms qui complotent pour garder captive la population… Sans dénier que la concurrence puisse parfois stimuler un milieu et des offres trop statiques, j'ai de nombreuses remarques (souvent d'ordre technique) :

Pourquoi payer un demi euro la minute pour une connexion 56k quand vous pouviez en passer 10 000 à la place pour un prix fixe bien inférieur ? Les industries de télécom allaient bientôt mourir ou se réduire à peau de chagrin.

Ton discours est d'une manière générale totalement décorrélé des ressources. Or, dans le monde du sans-fils, la quantité de spectre disponible n'est pas infinie, pas plus que le nombre de sites avec énergie et backhaul. Ce n'est pas pour rien que des discussions (parfois animées et beaucoup de stratégie/politique cachée derrière un vernis en apparence technique) ont lieu lors des CMR tous les 4 ans à l'ITU, et plus près de nous à la CEPT et à la commission européenne, pour récupérer plus de spectre (le RSPP demande aux administrations de dégager des fréquences pour avoir en tout 1200 MHz de spectre mobile d'ici 2015).

J'aimerais rappeler qu'un appel VoIP consomme plus de ressource radio qu'un appel en mode circuit (codecs moins efficaces, en-têtes…). Alors partir du principe que c'est gratuit => ça ne consomme rien, c'est un raccourci un peu rapide…

En 1999, la Suède était n°3 pour la rapidité moyenne de téléchargement montant, après seulement le Japon et la Corée du Sud. À présent, la Suède est en place 18 derrière Hong Kong, Singapour, Taïwan, mais aussi l'Ukraine, la Lettonie, la Lituanie, la Moldavie, et la Roumanie ! À présent en Europe, les pays de l'Est dépassent largement les pays de l'Ouest.

On parle du fixe ou du mobile ? Dans tous les cas (mais particulièrement pour le mobile), on est dans un milieu très règlementé donc ce que les opérateurs font ne dépend pas que de leur volonté propre mais aussi des moyens (notamment en ressource spectrale) qui leurs sont alloués.

L'autre point : de manière tout à fait logique, les pays qui se lancent plus tardivement ont forcément équipements plus modernes ! Les investissements sont beaucoup plus colossaux que tu ne l'imagines (juste pour te faire une idée : installer un site macrocell mobile coûte dans les 100000 EUR) et donc ça prend un certain temps à rentabiliser (je ne parle pas de s'en mettre plein les poches, juste d'avoir un retour sur investissement !)

Par exemple, le WiMax est un fiasco. Le WiMax était le « Wifi à l'échelle de la ville ». C'était un réseau wifi à longue distance dont les performances dépassaient celles de la 4G et qui ne coûtait pas cher à déployer. Les compagnies de télécoms ont réussi à placer les fréquences officielles du Wifi dans le spectre qu'ils contrôlent. Et le WiMax en est aussitôt mort, aussi sûrement que les pierres tombent. Nous aurions pu avoir des couvertures réseaux urbaines sans identifiant, sans restriction de rapidité ou de taille de données échangées, et… rien. C'est pourtant dans l'intérêt de tous sauf des télécoms.

Alors là, ça montre clairement que tu n'y connais rien ! Pourtant si tu te penches un peu sur la question (bouquins, réponses aux consultations Arcep, discussions avec des équipementiers, etc.), tu verras que :

• non, les performances du WiMAX ne dépassent pas celles de la 4G (qui d'ailleurs n'est pas 4G au sens de l'ITU/IMT-Advanced : une technologie "4G" doit permettre 1GB/s, et seul le LTE-Advanced / R10 répond au cahier des charges) ! Certains des choix technique du 802.16e et son efficacité spectrale sont relativement proches du LTE (de même que le HSPA+ a une efficacité spectrale quasi-identique au LTE), mais le standard date de 2005 et de nombreuses choses sont très inférieures - notamment la gestion des interférences, le roaming, l'implémentation de différentes tailles de canal (en WiMAX l'espacement inter-porteuses n'est pas le même entre 7 MHz et 10 MHz), la modulation uplink (PAPR bien moindre en SC-FDMA utilisé en LTE), l'overhead de la couche MAC, etc. Quant aux débits WiMAX : au mieux, en lab, sur 10 MHz TDD avec un ratio 20:18, tu as un débit downlink de 34MB/s (MIMO 2x2 inclus et supposé parfait), et 5.7 MB/s en uplink (pas de MIMO en uplink. Par contre tu peux doubler la capacité avec le MU-MIMO). Comme dans toute technologie radio, le débit dépend entre autres
  • de la taille de canal (5, 7 ou 10 MHz TDD—en comparaison le LTE supporte jusqu'à 2x20 MHz, et sa R10 supportera 2x40 MHz). Les "70MB/s à 50 km" si souvent évoqués concernent des profils de canal >10 MHz qui existent dans la norme IEEE 802.16 mais n'ont pas été retenu par le WiMAX Forum (et donc n'existent pas industriellement), de même que des profils FDD étaient définis au niveau IEEE mais pas au niveau WiMAX Forum
  • du MCS (modulation & coding rate), qui dépend notamment +/- du rapport signal/bruit, donc de la distance à la station de base et des interférences environnantes. Note que le MCS peut être différent en uplink et en downlink, et de fait on est souvent limité par l'uplink car les terminaux ont une puissance d'émission limitée (23 dBm typiquement). Le MIMO et les techniques de diversité dépendent également du fait que la matrice de canal soit "bien conditionnée" i.e. que tes trajets entre antennes soient suffisamment décorrélés, ce qui en pratique signifie en milieu urbain / multi-trajets.
  • Du nombre d'utilisateurs effectuant du trafic simultané (car la bande passante est évidemment partagée), du MCS de chacun d'eux, et de la politique d'ordonnancement (tradeoff entre équité et utilisation optimale de tes ressource : à débit identique, un utilisateur loin de la cellule a un MCS plus faible et consomme donc plus de ressources). Par rapport au HSPA+, le LTE et le WiMAX n'ont pas une meilleure efficacité spectrale. Mais par contre le fait de recourir à de plus grandes canalisations entraine un meilleur multiplexage statistique.
  • Des limites du terminal (nombreux étaient ceux qui n'avaient pas la puissance de calcul suffisante pour gérer mieux que 5 MB/s…)
  • donc en pratique sur un secteur 10 MHz, tu as à peu près une capacité de 12-15MB/s downlink et 5 MB/s uplink à partager entre tous tes usagers actifs. N.B. le LTE ne fait pas de miracle non plus (non, tu n'auras pas 300 MB/s !), mais par contre les canalisations sont plus larges (2x20 MHz) donc le ressenti utilisateur sera à l'avenant.
• toujours pour casser le mythe "70 MB/s à 50 km" qui a décidément la vie dure : les "50km" provenaient de profils point-à-point dans d'autres bandes de fréquences et qui n'ont pas grand chose à voir avec les équipements point-multipoint dont il est question ici. Le rayon de couverture est tout à fait comparable à une cellule 4G (sauf que les licences WiMAX sont dans la bande 3.5 GHz, donc en gros "ça va moins loin et ça passe moins les murs"). Ce n'est pas plus un « Wifi à l'échelle de la ville », c'est une technologie d'opérateur avec une couche MAC qui n'a rien à voir (elle est plutôt inspirée du DOCSIS, et propose une QoS sophistiquée)
• Comme tu dois le savoir, le marché de l'électronique est guidé par les économies d'échelles. Dans le monde, la plupart des "gros" opérateurs sont sur des technologies 3GPP (donc le WiMAX avait déjà du plomb dans l'aile dès le départ, même si des opérateurs comme Sprint/Clearwire se lançaient dedans, et ont d'ailleurs fait volte-face depuis). En Europe, on a eu la bonne idée de choisir une bande de fréquences différente du "mouvement d'ensemble" (donc on ne pouvait même pas utiliser les mêmes terminaux, ni les mêmes composants RF qu'aux US/Japon/Russie/…), et comme le marché était beaucoup plus petit, eh bien les composants et les terminaux ne sont jamais apparus ! Les rares terminaux qui sont apparus étaient buggés, pas finis, inutilisables et surtout non interopérables (par exemple, il fallait "patcher" le firmware en fonction du fournisseur de station de base en face…), ceci parce que les équipementiers n'investissaient que très peu en R&D. C'est le problème de la poule et de l'oeuf : les équipementiers ne veulent pas créer de produits s'il n'y a pas de marché, et les opérateurs ne veulent pas déployer s'il n'y a pas de produit ! A ce jeu là, seuls les gros acteurs peuvent briser ce cercle vicieux. Intel était en position de le faire (Centrino WiMAX), mais ne l'a pas fait. Game over.
• je t'invite à réfléchir en terme de stratégie et à te mettre à la place d'un opérateur : il existe 3 licences de 2x15 MHz en France dans la bande 3.5 GHz (3437.5-3442.5, 3465-3480, 3480-3495 MHz, et l'autre duplex 100 MHz plus haut). Outre quelques "détails techniques" (comme le fait que la canalisation typique WiMAX était de 1x10 MHz TDD i.e. très mal adaptée à ces licences, ou 1x7 MHz mais supportée par très peu de chipsets/terminaux), est-ce que tu te projettes dans un marché de type BLR (rural) ou dans de la pré-4G (urbain) ?
  • Si considères le marché BLR, il faut savoir que les zones rurales ne sont intrinsèquement pas rentables donc il faut trouver un subventionnement public. Sauf que je t'ai dit qu'il y avait 3 licences en tout point du territoire, et les collectivités ne vont évidemment n'en subventionner qu'une (au mieux). Les deux autres attributaires de licences sont donc condamnés à financer les campagnes non rentables par des déploiements pré-4G en zone urbaine rentable ! C'est ce que font typiquement les opérateurs mobile, mais qui n'était pas possible en WiMAX car…
  • les déploiements urbains sont un marché différent qui nécessite des terminaux nomades, inexistants sur cette bande (il n'y a guère que des terminaux fixes). De plus, il faut bien que tes clients aient du service partout donc qu'ils puissent faire du roaming sur la 3G quand ils sortent de la zone couverte et/ou le temps que le réseau se déploie (comme Free). Or, je te souhaite bon courage pour trouver des terminaux nomades multi-mode multi-bande capables de roaming 3G, ceci à la fois à cause du WiMAX en soi (pas de composants baseband supportant WiMAX+3G) et de la bande de fréquence (pas de RFIC/PA/FEM supportant 3.5 GHZ + les autres bandes IMT, même si c'est en train de changer. Notons aussi que les PAs ont une efficacité typique de 20% dans cette bande, contre environ 40% dans les bandes plus basses => si tu veux faire un smartphone WiMAX@3.5 GHz, l'autonomie sera pourrie et ça va chauffer !). Bref, les quelques équipementiers qui n'ont pas jeté l'éponge ont bien vite recentré le WiMAX (fût-il "mobile" depuis le 802.16e) comme une technologie exclusivement fixe/BLR à destination des pays en développement et essentiellement dans la bande 2.5 GHz.
• "Les compagnies de télécoms ont réussi à placer les fréquences officielles du Wifi dans le spectre qu'ils contrôlent. Et le WiMax en est aussitôt mort" : Gnii ??? Les bandes Wi-Fi sont du spectre non-licencié (donc n'appartiennent pas aux opérateurs) !
• "Nous aurions pu avoir des couvertures réseaux urbaines sans identifiant" : et la marmotte…, "sans restriction de rapidité ou de taille de données échangées" : la quantité de ressources radio allouées au WiMAX fait que la donne est fondamentalement analogue à la 3G, donc il n'y avait de toute façon pas de raison de faire sauter les quotas et les mécanismes de QoS (qui sont un garde-fou pour préserver un confort acceptable pour tout le monde). Pour changer ça il faudrait des ressources spectrales plus grandes ! C'est en partie ce qui s'est passé avec les licences 4G (même si je pressens qu'elles seront rapidement saturées à leur tour. D'ailleurs ce n'est pas pour rien que le RSPP demande de trouver 1200 MHz d'ici 2015 !)

Bref, s'il n'y avait que quelques "vilains petits canards" et que le WiMAX était un succès mondial, on pourrait peut-être reprocher aux acteurs Français (qui sont de petits opérateurs) de ne pas avoir suffisamment bougé. Mais en l'occurence et vu la situation, peut-on leur reprocher de ne pas avoir investi quelques millions ou milliards dans une technologie qui allait mourir… ? (d'ailleurs ceux qui ont investi en Europe ont tous déposé le bilan !). Le 3GPP a défini un profil LTE@3.5 GHz l'année dernière (et entre temps, les composants RF multi-bande évoluent aussi, et le LTE a une modulation uplink différente du WiMAX, permettant de concevoir des PAs plus efficaces) donc on verra peut-être des choses progressivement bouger sur la bande 3.5 GHz - notamment avec la saturation de la bande 2.6 GHz qui arrivera inéluctablement. Mais par contre le WiMAX est clairement mort et enterré, et les opérateurs Français n'y sont pas pour grand chose (ni les petits chipsettiers d'ailleurs, qui ont fait ce qu'ils pouvaient. BTW, pour ceux qui ne connaissent pas, la France compte un fabricant de chipsets très en pointe sur le WiMAX/4G qui s'appelle Sequans. Je vous laisse regarder jusqu'à quel point leur site parle encore de WiMAX…)

J'ai cru comprendre que le bitcode utilisé par LLVM n'était pas sensé être stable dans le temps et donc ne pouvait pas être utilisé pour de la diffusion de code (contrairement au bytecode JVM/CLR/Dalvik…). Pourtant, je me disais que ça serait bien pratique d'avoir un langage intermédiaire stable et de pouvoir compiler Debian<notre distro favorite> pour une seule architecture "virtuelle" (je considère naïvement que le gros du temps de compilation doit être dans le frontend+optimisation, mais je suis preneur d'avis éclairés sur la question !), et que apt-get s'occupe de la dernière phase (backend+édition de liens…). ça éviterait à <la distro favorite> de devoir stocker les versions compilées pour toutes les architectures (ce qui occupe de la place sur les serveurs), et ça permettrait aussi d'utiliser les optims spécifiques à son CPU (i386/i686, Altivec, SSE, armhf/armel, etc.) sans pour autant avoir les inconvénients d'une Gentoo (temps de compilation prohibitif, surtout sur des petites machines). Qu'en pensez-vous ? Est-ce que l'IR de LLVM pourrait tenir ce rôle à terme ? Ou sinon, <votre bytecode préféré> ?
(N.B. bon évidemment ça ne marche pas avec les programmes qui contiennent de l'asm inline. Mais je présume que ces programmes sont minoritaires dans une distro ?)

Pourtant un dongle Android à 30 € s'en sort très bien même avec des sites un peu complexes (voir les vidéos sur YouTube), commme quoi il n'y a pas besoin d'un monstre qui consomme 300W…

Non juste un tableur (ou une feuille de calcul sur papier) lors du dépouillement pour faire des additions ! (les bulletins pouvant parfaitement être des bulletins papier glissés dans une urne en plexiglas)