karteum59 a écrit 879 commentaires

Si c'est une terre rare, alors c'est un faux probleme

1°/ Le hafnium ne fait pas parti des composés dits "terres rares" au sens chimique du terme. Et je n'ai pas inventé le fait que la plupart des gisements économiquement exploitables seraient épuisés vers 2018.
2°/ faux problème ? Comme toute ressource finie et non renouvelable, la production de terres rares atteindra un jour un pic inexorable !
3°/ Même dans le cas où les terres rares ne sont pas toujours "rares" dans la croûte (ça dépend des éléments chimiques), elles sont globalement très peu concentrées. Pour cela, leur exploitation est très polluante et aussi très énergivore. Or, on va aussi manquer d'énergie dans les années qui viennent…
4°/ La filière thorium n'est pas au point. Elle est présentée comme un remède miracle, mais pour l'instant des difficultés techniques restent encore non résolues (et par définition, on ne sait pas si/comment on pourra les résoudre !)

les puces Intel, par exemple, bénéficient de la prise en charge d’OpenGL ES à partir des CPU de génération Sandy Bridge, c-a-d à partir des puces graphiques Gen6 dans la nomenclature du fondeur)

Il y a une raison technique qui explique le non-support sur les générations précédentes ? Pour ma part, j'ai un core i5 M520 avec une puce graphique "gen5", que j'estime encore suffisamment récent pour ne pas justifier un changement de machine, et il me semblait que la gen5 disposait déjà d'un pipeline entièrement programmable (par opposition au pipeline fixe conçu pour OpenGL 1.x qui fait que les vieux laptops avec un GMA950 ne pourront jamais supporter les shaders). Accessoirement sur la page sandy bridge de wikipedia, on lit "utilisation d'hafnium comme isolant au sein des transistors des processeurs", sauf que "Les gisements exploitables de hafnium à un coût acceptable seront épuisés autour de 2018" donc ce serait bien de ne pas changer de machine tous les 3-4 matins…

Il faudrait que tu précises ta question :

• "c'est quoi l'intérêt de supporter ça dans LibO" ? Eh bien, juste de pouvoir être compatible avec les documents des autres ! La compatibilité avec .docx reste incomplète sans ça…
• "c'est quoi l'intérêt de faire ça" ? On est d'accord que c'est critiquable, mais bon, des gens l'utilisent et on ne peut rien y faire. En l'occurence ici il s'agit de la CEPT et des contributeurs/administrations associées. ça fait beaucoup de monde et je n'ai aucun moyen de pression pour faire changer les choses, d'autant que personne ne s'en plaint (à part moi) puisque tout le monde utilise MS Office et n'a aucun problème avec cette fonctionnalité (qui est d'ailleurs à leurs yeux plus simple que d'utiliser un soft d'archivage tel que winzip), donc il est absolument exclu de changer les pratiques. Note que le 3GPP ne fait guère mieux. Dans le monde réel, les gens/organisations/entreprises utilisent ce genre de truc et il faut faire avec.

Conclusion: après avoir longuement lutté, j'ai dû revenir sous Mac pour avoir un OS Unix à peu près potable tout en ayant MS Word (il y a une autre raison aussi: l'hibernation "juste marche", tout comme le Wi-Fi, le branchement d'un écran externe et la gestion d'énergie, et l'autonomie est double de celle de mon ancien vieux PC/Linux). Mais franchement, j'aimerais me passer du Mac, surtout que la stabilité de Maverick laisse à désirer (< troll > on dirait presque une Ubuntu < /troll > :)

je ne peux pas non plus ouvrir les fichiers embarqués dans un .docx (par exemple un .pdf ou un autre .docx embarqué dans un .docx conteneur)

Dafuq? Ça marche comment?

Je ne sais pas "comment ça marche" dans le détail, mais je sais juste que je n'arrive pas à ouvrir les PJ dans ce genre de fichier sous Linux.

Il permet de faire des divergences/branches/commentaires/vote/fusion sur des parties de document ? Il permet de détecter les blocs déplacés ? Il a une interface WYSIWYG aussi complète et facile d'usage que MS Word ou Google Docs (avec support des tableaux, équations, références, illustrations, etc.) ? Il est déployable facilement ?

Si oui, ça m'intéresse !

Est-ce que tu as regardé les fonctionnalités collaboratives de libreoffice

Si tu parles du mode révision, la réponse est oui. Mais c'est analogue à MS Word (donc pas la possibilité de diverger/commenter/voter/merger différentes propositions, ou alors j'ai zappé ça). Donc ça ne marche que si les collaborateurs travaillent ensemble de manière synchrone et non conflictuelle.

J'avais vu il y a quelques mois, qu'il était possible de faire du diff avec de l'odt (…)

Note que j'ai juste introduit l'idée, mais git/diff ne permet pas aisément d'identifier les blocs de texte déplacés (ils sont seulement affichés comme supprimé+ajouté)

As-tu considéré une solution sérieuse de composition (c'est ce que me donne mon dictionnaire comme traduction de "typesetting") telle que TeX/LaTeX ?

On parle de travail collaboratif, avec d'autres gens qui ne sont pas geek et ne lâcheront pas leurs habitudes avec MS Office + meeting si facilement. Une interface WYSIWYG est indispensable (pas forcément client lourd, une interface web à la Google Docs pourrait aussi faire l'affaire, mais certainement pas du LaTeX !). Et je ne suis pas responsable de ce sujet, j'essaie juste d'être force de proposition pour qu'on puisse faire plus de web-meetings et moins de meetings physiques. Mais les outils appropriés n'existent malheureusement pas.

Bravo et merci aux contributeurs !

Trois remarques/questions:

• le principal truc qui m'empêche d'utiliser LibO au bureau (en travail collaboratif sur des documents .docx) est qu'il parse l'ensemble du document pour le convertir dans sa représentation interne, et du coup on perd de l'information au passage lors de la reconversion en .docx à l'enregistrement (mise en forme cassée, etc). J'ai cru comprendre qu'un travail était en cours pour que le document enregistré à la fin ne touche que les noeuds OOXML nécessaires (correspondant aux zones du document modifiées par l'utilisateur), comme le font les suite Office sur Android. Ce serait vraiment bien => est-il possible d'en savoir plus ? (N.B. accessoirement, je ne peux pas non plus ouvrir les fichiers embarqués dans un .docx (par exemple un .pdf ou un autre .docx embarqué dans un .docx conteneur)).
• suggestion: une fonctionnalité qui me manque (et qui n'existe nulle part à ma connaissance) est la possibilité de faire des "branches" (un peu à la git) correspondant à différentes formulations de texte, et discuter/voter ensuite sur la formulation préférée.
• je termine par un troll: pourquoi Glade ? (surtout en 2014 vu l'état de Gtk+ vs QT5, et sur un produit éminemment multi plate-formes. OK… je n'ai qu'à contribuer, mais bon, je n'ai pas pu m'empêcher de le dire :)

"Crowfunding" c'est du financement d'élevage de corbeaux ? :)

--> []

Ce serait pas un peu le même concept que la Gameduino ?

(et je découvre accessoirement que la Gameduino 2 permet de belles choses ! :)

Aptitude est un frontal convivial à dpkg, l'installeur de paquets. Apt est un autre frontal, en ligne de commande. Synaptic est une interface graphique pour Apt.

Il me semblait avoir lu que aptitude était deprecated (au moins sur Ubuntu, je ne suis pas sûr concernant Debian) ?

un solveur de dépendance

aptitude a un solveur différent de apt-get mais ça n'a jamais totalement marché pour moi. Par contre je lis des choses intéressantes concernant ce que saurait faire le solveur du projet Mancoosi avec apt-get.

Si depuis des années, Qt est libre et que KDE n'ai pas parvenu à (clairement) s'imposer face au bureau GNOME, il faut peut-être en tirer la conclusion qui est que, GNOME a lui aussi ses avantages et qu'il convient mieux à certains utilisateurs et (soyons fou) que Gtk+ convient mieux à certains développeurs aussi.

Peut-être que le soutien "politique" de la FSF et de RedHat aident aussi… (et puis, le souhait un peu légitime d'avoir "one desktop to rule them all" pour éviter la fragmentation. Puisque ça ne devait pas être KDE, ils ont tout fait pour que ce soit Gnome. Manque de bol, il était techniquement très inférieur).

mais il ne faut pas oublier le problème de licence qui est à l'origine de ce gâchis. Quand il était interdit de distribuer des versions modifiées de Qt, il était légitime de ne pas utiliser ce toolkit pour bâtir un bureau libre. La vraie faute elle est là et elle repose sur les épaules de TrollTech.

La communauté aurait aussi pu développer un "OpenQT" avec une API compatible, le tout sous licence LGPL, plutôt que de partir dans des guerres de religion C vs C++ et réinventer la roue…

il y a 11 fichiers C (dont 1 en contrib et 1 pour linux) qui totalisent 4800 lignes de code contre 66000 en python.

Si >80% du temps est dépensé dans <20% du code, ce n'est pas déconnant…

comme le font les constructeurs de smartphone chinois avec Android
(…)
Ce que je crois moi c'est qu'ils envisagent une libération à la Solaris: le source est dispo (pour tout le monde ou seulement après signature de NDA) mais tu n'as que le droit d'envoyer tes patches à Jolla.

Mouais, quand on voit le respect de la GPL par les fabricants de chipset / ODMs chinois (" I've written e-mails to few producers (ZOPO, Cubot, THL), and even that I've gotten replies from ZOPO and THL, they don't want to share anything, nor the kernel, nor any other sources ") on peut se dire que même ça est risqué… :(

Même un Linux, ce n'est pas toujours évident (j'ai un vieux smartphone à base de SoC Mediatek pour lequel je n'ai jamais réussi à obtenir les sources => pas possible de recompiler kernel + Cyanogenmod).
Pour rappel, dans le monde ARM, il n'y a pas d'ACPI, et le device-tree n'est pas encore généralisé => pas de kernel générique. Une machine == un kernel. S'il te manque le device-tree ou les board files pour compiler le kernel pour ta machine, tu l'as dans l'OS !

et le problème serait réglé.

Je viens de faire la MAJ de mon Samsung GS3 LTE (i9305) vers le Android stock 4.3. J'aurais dû faire plus attention : cette MAJ inclue Knox, qui change le bootloader et laisse une trace indélébile (eFuse) si je fais quoi que ce soit non prévu par Samsung (comme rooter mon téléphone, installer CWM recovery, tenter de faire in rollback sur le bootloader, etc.). Pour l'instant, griller le eFuse semble juste interdire le changement de bootloader et l'utilisation de container knox (mais ce n'est pas clair pour moi, car je lis aussi qu'il ne serait plus possible de réinstaller de firmware officiels via Odin une fois le eFuse grillé. Or si j'installe MIUI ou Omnirom, je souhaite garder la possibilité de remettre un firmware officiel, ne serait-ce que parce que certaines fonctionnalités comme EAP-SIM ne sont dispo que sur ces derniers…)

Bref, entre UEFI+trusted boot côté PC, et la même chose (bootloaders verrouillés, eFuse, etc.) côté smartphones, garder le contrôle de sa machine devient de plus incertain (car ça n'est pas que du reverse-engineering à effectuer, mais de la crypto à casser…)

"se concentrer" == commencer par convaincre Mediatek/Qualcomm/Samsung/nvidia de sortir un kernel et des drivers libres ! (et côté baseband, tu peux généralement te gratter, à part OsmocomBB)

Pour les bagnoles, je pense a priori (me corriger si je me trompe) que la répartition du bilan énergétique entre fabrication/utilisation est plus équilibrée. Du coup il pourrait être utile d'avoir une prime à la casse ciblée (+ augmentation de la TIPP progressive) pour remplacer les véhicules lourds/énergivores actuels par des mobylettes ou "2CV nouvelle version" qui consomment 1 à 2 litres au 100… (ça serait d'ailleurs peut-être plus urgent et plus utile à budget constant que déployer de nouvelles lignes de tram en grande banlieue, qui de toute façon n'entraineront qu'un report modal négligeable).

les TIC pèsent, avec 1 500 teraWatt-heure d'électricité consommée par an, pour 10 % de la production mondiale. Soit la production de l'Allemagne et du Japon

Par ailleurs en parlant de consommation, il parait bon de rappeler que l'utilisation d'une machine pèse très peu par rapport à ce que nécessite sa fabrication. Donc le meilleur moyen de consommer moins, c'est d'utiliser nos machines longtemps (même si elles sont grosses, obsolètes et energivores !)

Sur le papier le MPPA 256 c'est (…)

Sauf que chacun de ces cores n'est en aucun cas comparable à un core i7. En particulier, ils sont plutôt mauvais pour le traitement out-of-order.
Note que ce que fait Kalray me semble assez proche de ce que fait Adapteva/Parallela http://www.adapteva.com/

Pour les cartes graphiques cela ne resoud pas le probleme de la consommation qui la est vraiment l'avancée technique majeure avec ce processeur

pas encore

Mais ça progresse très vite ! (et il me semble assez possible que ça réduise significativement l'espace économique qui sera laissé aux Kalray et Adapteva…)

La plupart des clés USB que je vois passer sont très très loin du 120Mo/s !

Hum… et ça rend Skype auditable et interopérable ?

Skype est gratuit aussi, mais "ça pue" va comprendre

J'ignorais que le code-source et le protocole de Skype étaient disponibles, auditables, et interopérables avec d'autres implémentations…

Ouais enfin, le débit d'écriture sur une clé USB n'est généralement pas transcendant non plus…

C'est super qu'il s' impliquen sur la question des drivers libres, mais on aimerait aussi voir la FSF faire plus simplement pression sur les Rockchip/Mediatek/AmLogic/HiSilicon… (et sur les ODMs ensuite) pour que ces derniers publient le code-source GPL Android utilisé (ou au moins device-tree et board files), afin de rendre les smartphones/tablette chinois (qui représentent des volumes très significatifs) devenir un peu moins jetables et un peu plus utilisables à long terme (omnirom, etc.), même si ça implique pour l'instant d'utiliser des drivers non libres…

N.b. il existe un projet de serveur X pour Android mais c'est tres limité. J'ignore s' il serait possible d'ecrire "simplement" un wrapper DDX xorg -> drivers binaires android ?