karteum59 a écrit 873 commentaires

Tu pinailles, j'ai bien voulu dire MBits/s (sinon j'aurais dit Mo/s, on est sur linuxfr :)

Du reste, je voulais principalement dire que la différence / la nouveauté du LTE dans les débits pics provient essentiellement de
- modulations d'ordre supérieur (64QAM, downlink uniquement, près de la BS uniquement)
- MIMO (en NLOS principalement)
- canalisations plus large (ce qui n'augmente pas l'efficacité spectrale vu que ça nécessite plus de spectre, modulo un détail : les canalisations plus larges permettent un meilleur multiplexage statistique -> si l'usager A transmet son paquet de données très vite, il libèrera d'autant plus vite l'ensemble de la ressource spectrale et limitera d'autant la probabilité de devoir partager la ressource (donc le débit) avec un usager B. Dans un autre domaine, ça me rappelle le raisonnement décrit ici http://linuxfr.org/news/gestion-de-lénergie-se-dépêcher-de-ne-rien-faire :)

Bref, dès qu'on s'éloigne un peu du centre de la cellule, l'efficacité spectrale redevient rapidement la même qu'en HSDPA. Si on intègre ça sur l'ensemble d'un secteur, on a donc une efficacité spectrale un peu supérieure, mais pas de manière révolutionnaire. Donc non, toutes choses égales par ailleurs (i.e. 2x5 Mhz, pour comparer au HSDPA) une cellule LTE ne permettra pas tellement plus de taquiner les 10Mo/s qu'une cellule HSDPA. D'ailleurs, même sur du 2x20 MHz LTE en bande 7, je pense qu'on devrait taper dans les 40-45 MBits/s de capacité downlink moyenne sur un secteur (N.B. c'est une estimation au doigt mouillé et je n'ai pas pu tester => qu'on me corrige au besoin. Je prends pour hypothèse une majorité d'usagers en QPSK et 16QAM, et du MIMO pas toujours fonctionnel).

Par ailleurs, au niveau normatif, tous ces aspects (MIMO, 64QAM, large canalisations) sont désormais spécifiées ou en cours de spécification pour le HSPA (rel.7 pour le MIMO/64QAM, plus récent pour le HSPA à 2, 4 ou 8 porteuses pour avoir des canalisations aussi larges que le LTE). Donc l'avantage du LTE n'est pas/plus dans les débits pics mais dans d'autres aspects : par exemple, l'industrie investit davantage sur le LTE, alors que les features avancées du HSPA+ ne sont pas forcément toujours implémentées. Surtout, l'OFDMA est plus efficace sur de large canalisations (permet une égalisation algorithmiquement plus simple, notamment lorsqu'il y a du MIMO), même si ça a des inconvénients (PAPR, gestion des interférences entre cellules voisines...). Il y a probablement aussi quelques guerres de brevets derrière...

Tout à fait. C'est la raison pour laquelle les opérateurs mettent un quota sur le volume de données : la capacité d'une cellule reste de l'ordre de 10MB/s à partager entre tous les usagers de la cellule (le LTE fait un peu mieux, mais ce n'est pas une révolution : la modulation 64QAM n'est disponible que tout près de la station de base, et le MIMO ne fonctionne pas bien en ligne de vue... Bref, en moyennant sur une cellule, on a peut-être un gain d'efficacité spectrale de 50 ou 70% par rapport aux technologies antérieures, mais pas x10 comme les équipementiers le prétendent souvent ! (on a eu le même coup avec le WiMAX :) ). Donc : pour faire transiter plus de monde et/ou leur donner plus de débit, il n'y a que deux solutions : demander plus de spectre (c'est ce qui vient de se passer avec l'attribution des bandes dites "4G" - N.B.: le LTE n'est pas 4G au sens de l'ITU, seul le LTE-Advanced et le 802.16m répondent au cahier des charges IMT-Advanced, mais les marketeux n'ont pas attendu... :) et densifier (ce qui coûte cher et n'est pas toujours aisé). Il faut bien se dire que ce n'est pas parce que c'est sans fils et qu'il n'y a pas de tranchées à creuser que ça ne coûte pas cher (compter un ordre de grandeur d'environ 100k€ pour un nouveau site macro). Dans tous les cas et malgré la limitation de capacité à 10-15MB/s/secteur, si on veut que le modèle tienne économiquement, on ne peut pas se limiter à 15 clients / BS même si on leur "vend" un accès internet > 1 MB/s. Donc, cela veut dire qu'on compte sur le multiplexage statistique (le fait que tout le monde ne fait pas de trafic en même temps) pour que ça marche. Comme ce multiplexage statistique se fait directement à l'échelon le plus bas (radio, limite physique), contrairement au DSL où c'est fait plus haut dans le réseau donc "moyenné" sur davantage de clients, on est obligé d'avoir un taux de contention plus faible, et malgré ça quelques clients gourmands peuvent encore rapidement saturer une cellule. Bref, c'est OK si les gens font du web, mais ça marche beaucoup moins bien si tout le monde se met à utiliser son accès mobile comme un accès fixe (bittorrent, youtube, IPTV, visioconf, etc.). Le quota n'est peut-être pas la manière la plus fine de résoudre le problème (il y aurait sûrement bien des manières d'être plus efficace. "man tc" et google lartc pour les linuxiens que nous sommes :), mais à ce jour c'est la dissuasion la plus simple (et comprise par les clients) contre les usages "abusifs" (= qui détérioreraient la qualité du réseau pour les autres usagers. Bon certes, les opérateurs pourraient AMHA reconnaître qu'utiliser bittorrent pour télécharger ses iso debian la nuit lorsque le réseau est peu chargé ne constitue pas un usage abusif, mais c'est un autre sujet... :).
Tout ça pour dire que le fixe a encore de beaux jours devant lui (fiabilité, débits, pas de quotas ni de bridage sur les usages, IP publique...), et que malgré la libération du 2.5 GHz et du 800 MHz pour le LTE, il est probable qu'il y ait bientôt besoin à nouveau de plus de spectre radio... ! :)

Et sur http://hongkongeek.com/ tu trouves des téléphones Android (avec navigateur web, google maps, etc) pour 100 € ! Pas des foudres de guerre certes, mais ça peut suffire à bcp de monde.

Tout à fait, le jeu est superbe, bravo aux développeurs ! (même s'il saccade/rame encore sacrément dès qu'il commence à y avoir beaucoup d'objet (notamment dans les batailles), et ce sur une config raisonnable (core i5 540m + NVidia gt330m). S'il y a des dévs dans la salle : est-ce qu'il ne serait pas possible de gérer les ordres du joueur (déplacement sur la carte, sélection des bâtiments et des personnages, etc.) dans un thread séparé de plus haute priorité ?)

Donc les devs Gnome considèrent nécessaire et sain de changer ses machines au minimum tous les 3 ans... ça fait du bien de voir qu'il y en a qui pensent à la planète !
(jette donc un coup d'oeil à ça... y'a pas que le pétrole qui s'épuise ! -> http://www.eco-info.org/spip.php?article129 )

(pour ma part, je garde mes machines au moins 5 ou 6 ans, ce qui est encore trop peu, mais mes vieilles machines servent ensuite à d'autres jusqu'à ce qu'elles meurent de leur belle mort - j'ai encore un athlon 800 / 512 Mo en activité chez ma mère et un Duron 1000 chez ma soeur, et je ne considère pas cela comme des "petites" machines compte tenu de ce qu'on faisait déjà avec beaucoup moins quelques années avant. Halte au gaspillage !)

Effectivement, pour reprendre le commentaire plus haut, ce fork sera peut-être septique :)

A part ça, dans le genre desktop en QT autre que KDE, il y a aussi Antico (http://www.giuseppecigala.it/Antico.html)

Dans le fond je suis plutôt d'accord avec toi, mais je vais mettre un bémol car j'aime bien pinailler :)
L'analyse sur la viabilité entre modèles économiques n'est pas la même si le modèle est pris isolément ou si on le met en concurrence avec d'autres : effectivement, le modèle à base d'abonnement ne marche pas en milieu concurrentiel face au modèle gratuit+pub, mais ça ne veut pas dire qu'en théorie il ne marcherait pas dans l'absolu en l'absence de ce modèle qui constitue un peu une "concurrence déloyale" (je présume que le "bon débarras même si j'utilise Google aujourd'hui" cité plus haut se plaçait peut-être dans ce contexte là : pas possible de faire émerger un concurrent viable à base d'abonnement tant qu'un Google "gratuit" (grâce aux pubs) prend toute la place. La réponse "arrête d'utiliser Google alors" me semble abusive car 1°/ ce n'est pas possible aujourd'hui faute de concurrence sérieuse et 2°/ à supposer que Google puisse être maté, on verrait alors émerger des concurrents basés sur d'autres modèles économiques et il serait alors possible de ne plus utiliser Google)

Mais on s'égare, et avec des "si", on mettrait Paris dans une bouteille... :)

Il me semblait que Skype pouvait "élire" tout noeud possédant une IP publique (i.e. ta machine aussi) comme "super peer", i.e. relai potentiel ?

apt-get install pinfo te réconciliera peut-être avec les info (et au passage, pinfo fonctionne aussi avec les man, et gère/insère des liens hypertexte entre pages man !)

Un "ls --color | most" interprête correctement la couleur, contrairement à less (exemple valide également pour colorgcc, cmake, etc.)

Surtout quand la fin de son interview se termine par "Je suis trop modeste pour ça" (juste à côté de "Être en avance sur son temps n'est jamais bon" :)

Sur ma Pandaboard, vsftpd avait à une époque la fâcheuse manie de se vautrer en état "uninterruptible sleep" ("D"). Après un peu de recherche, on constate qu'un processus dans cet état n'est pas killable : aucun moyen de le supprimer (sachant qu'il monopolise toujours le port 21/23) => rebooter est la seule solution ! Indépendamment du bug spécifique à cette situation (noyau ou vsftpd), j'ai été stupéfait de découvrir que mon Linux ne proposait aucun moyen de killer le truc, aucun appel système, aucune commande, rien !
Autre exemple de "petit souci" : avec un ancien disque dur USB avait plein de secteurs défectueux qui bloquaient fréquemment les I/O (i.e. même pas moyen de faire un dd_rescue, ce dernier freezant définitivement (ou mettant un temps non acceptable à se décoincer à chaque freeze)). J'ai réussi à faire un script qui note la position pour pouvoir reprendre "un peu plus loin" que la zone fautive à chaque tentative, mais il fallait tout de même que je débranche/rebranche le câble USB à la main à chaque itération car le process dd_rescue ou cp -a n'est pas killable dans cet état "D" (pas vu non plus de moyen simple de forcer un reset du device ou du bus USB par soft... (N.B. quelqu'un sait-il si c'est possible avec la libusb ?))

Le post ci-dessous n'est pas inintéressant à ce sujet...
http://owni.fr/2011/08/29/google-suppression-compte-donnees-personnelles-vie-privee-god/

Soit, mais si
- l'utilisation se fait via un hub ou un réseau sans-fil (== bande passante partagée)
- le téléchargement est simultané
alors le multicast a un clair avantage par rapport au P2P présenté !

Jolie initiative pour l'enseignement, ça me rappelle le LOGO — également avec des variantes en Français il y a longtemps... En même temps, je me dis que si tout le monde s'y met [1, 2] ça risque d'être une belle galère pour réutiliser du code GPL fait par d'autres :)
[1] http://reganmian.net/blog/2008/11/21/chinese-python-translating-a-programming-language/
[2] http://en.wikipedia.org/wiki/Non-English-based_programming_languages

Mais que dire de l'abandon par de grands noms du LL de la portabilité vers ce systemes

Ce point de vue est encore minoritaire (et je crois que le projet Gnome a justement refusé la dépendance à systemd demandée par le "grand nom" en question).

Enfin, en ce qui concerne la licence, il y a de quoi être aigri parfois quand on voit son code passer sous GPL et quand on n'est plus en mesure d'en récupérer les améliorations. Même si c'est justement le propre de la licence BSD de le permettre

C'est permis par la licence. Point.
La BSD ne se protège pas, c'est quelque chose qu'il faut accepter lorsqu'on fait du code sous BSD. En même temps, j'avoue que la GPL peut agacer car elle pose des limites juridiques à ce que je peux techniquement faire (par exemple, si je souhaite expérimenter un concept de micro-noyau, en déplaçant une partie du code de Linux dans des libs userspace, mon micro-noyau+libs n'autorisera pas les applis propriétaires et le résultat ne pourra donc pas être iso-fonctionnel avec Linux, à cause d'une limite juridique et non technique. Idem si je souhaite réutiliser dans une lib du code sympathique trouvé dans une appli GPL, et permettre à des applis non-GPL de se linker à ma lib). De là à dire que la GPL limite l'innovation et la créativité, il n'y a qu'un pas... que je franchirai allègrement car on est vendredi :)
Du coup, je pense que la LGPL est un bon compromis et pourrait être utilisé de manière plus générale — même pour des applis/noyau — car elle se protège davantage que la BSD sans pour autant "viraliser" du code écrit par d'autres dans un cadre de liaison dynamique, et elle permet donc de réutiliser le code dans d'autres contextes et notamment sous forme de lib partagée. J'ai l'impression que la LGPL pourrait être la licence rêvée des dévs BSD aigris (mais qui n'aiment pas la GPL) ! Les gars, que diriez vous de basculer tout Free/Net/OpenBSD sous LGPL ?
C'était ma contribution au troll, bon vendredi :)

Enfin bon, je pense que personne ne prétendrait aujourd'hui que Gnome est proche des 10% de parts de marché, ni même a une chance de les atteindre bientôt?

Il a peut-être une chance d'atteindre prochainement les 10% de parts de marché parmi les Linuxiens ?

(oops désolé, on n'est pas vendredi... :)

Je pense que le raisonnement s'applique toujours : à savoir que l'empreinte environnemental d'un joujou numérique apparaisse largement dominé par sa fabrication et non par sa consommation courante, quand on prend en compte l'eau, l'énergie (notamment quand la production est en Chine et que les centrales sont au charbon), les matières premières (y compris les terres rares, dont l'extraction est très polluante), les multiples transport de ces dernières puis des pièces détachées puis des produits finis... (et on pourrait remonter loin si on incluait aussi l'impact environnemental de la fabrication et de l'utilisation des véhicules et machines qui servent à fabriquer et transporter tout ça :)
Acheter un Linutop pour dire d'être "éco-friendly" n'a pas de sens si on jette une machine encore valide en même temps... Hors cas extrêmes, l'attitude la plus sage semble donc de garder ses machines les plus longtemps possible (i.e. jusqu'en fin de vie), même si elles consomment plus que le dernier truc à la mode.
L'autre point : ces "derniers trucs à la mode" ont effectivement une durée de vie intentionnellement de plus en plus réduite. cf. Cf. http://www.youtube.com/watch?v=iB8DbSE0Y90 (j'ai gardé mon dernier PC fixe pendant plus de 10 ans en ne changeant que ce qui était nécessaire. On ne peut pas en dire autant des machins embarqués où rien n'est réparable/remplaçable, appareils photo, box et autres smartphones, etc. Je me demande si ma Pandaboard (oui, j'ai craqué... :) sera encore vivante dans 10 ans).

N.B.: pour la Freebox comme pour le reste, le problème de la conso en veille a été résolu chez moi simplement grâce à une multiprise avec interrupteur ! (sauf pour le boîtier Freebox réseau, car il faut bien que le téléphone puisse sonner... :)

C'est un petit peu hors sujet, mais : à quand une interface de configuration pour ip6table au niveau de la Freebox ? (c'est quand même une des choses qui me gêne un peu : devoir configurer un firewall à la main dans chacune des machines derrière la box, alors qu'en IPv4 le NAT permettait intrinsèquement de les rendre non joignables depuis l'extérieur...)

Dans le même genre, il y a aussi http://moonos.org/

-> []

Va dans about:config et change le flag ui.allow_platform_file_picker !

Dans le cas de Firefox, va dans about:config et change le flag ui.allow_platform_file_picker. Pour le reste, tu peux jeter un oeil à ça http://kde-apps.org/content/show.php?content=36077 :)

"Il faut vous enivrer sans trève. Mais de quoi ? De vin, de poésie ou de vertu, à votre guise, mais enivrez vous !" :)

Comme à l'accoutumée sur Trollfr...
Tiens, BTW, http://www.trollfr.org/ utilise apparemment OpenBSD :)