karteum59 a écrit 868 commentaires

Du coup, j'ai l'impression que c'est injuste de reprocher à LibreOffice son manque de support d'OOXML. Il me semble évident que les logiciels qui ont été développés après la publication du standard OOXML ont pu calquer leur architecture sur le format, ce qui rend tout de suite la compatibilité plus facile
(…)
D'ailleurs, comment est-ce que OnlyOffice et al se débrouillent avec les documents odt?

Soyons clair : je ne reproche pas à LO son manque de support d'OOXML et je sais que les devs derrière LO ont fait un superbe travail avec une base de code ancienne (et des décisions / un design pris à une époque et dans un contexte différents). Mais le débat de départ c'était "pourquoi OnlyOffice utilise t-il le format OOXML ?", et c'est à cette question que j'ai tenté de répondre !

Il suffit de travailler avec un parseur XML générique et donc de garder une représentation complète du document XML, même les nœuds ou les propriétés inconnus. On travaille alors à partir de cette représentation XML générique et pas d'une sous-représentation spécifique aux fonctionnalités de LibreOffice
(…)
Cette proposition me paraît un peu compliquée

Mais je présume que ta proposition implique de changer complètement la représentation interne de LO (pas seulement l'amender à la marge), donc en parlant de compliqué…

C'était justement le sujet : Kingsoft, Onlyoffice, etc. ont pour "représentation de base" les balises/noeuds/attributs OOXML (sans forcément tout traiter non plus) là où LO utilise un filtre pour convertir dans son format interne. (N.B. je ne suis pas expert LO. Y-a t-il des contributeurs/développeurs de LO dans la salle ?)

Peu importe que OOXML soit "mal fait" là où ODF était mieux conçu (ce n'est pas le sujet, cette bataille est passée et malheureusement on l'a perdue) : regarde à quel point les suites bureautiques android (type "kingsoft office", mais il y en a plein d'autres) s'en sortent mieux que LO (i.e. ne pètent pas tout le document Word envoyé par ton collègue et que tu dois retravailler et renvoyer) => dès lors que LO parse/convertit le truc dans son format interne, il y a forcément perte d'informations. Bref, LO est cantonné à un usage personnel / sans interaction (un peu la même niche que MS-Works).

En fait, je subodore que le seul moyen de s'en sortir serait que LO garde un diff des noeuds entre début et fin de session (i.e. entre ouverture du document et sauvegarde) dans sa représentation interne, et envoie ce diff au filtre OOXML (qui du coup se contenterait de ne modifier que les noeuds ad-hoc dans le document OOXML de départ). Je ne connais pas la base de code LO mais je pense que c'est un gros boulot…

De toutes manières, ces formats sont beaucoup trop complexes pour être interchangeables. Pour cela, il faudrait que toutes les possibilités d'OOXML se retrouvent dans OpenDocument et vice-versa, ET que les logiciels MS Word et Libre Office soient capables de gérer l'ensemble de ces possibilités. Le mieux qu'on puisse espérer, c'est que chaque logiciel soit capable de lire les deux formats, et d'importer le sous-ensemble commun entre les deux.

Si le format interne est OOXML, le soft n'a pas besoin de comprendre tous les noeuds : il suffit qu'il se contente de ne toucher qu'à ceux qu'il sait interprêter (c'est comme ça que de nombreuses suites bureautiques - par exemple sur Android - savent manipuler des documents Word sans tout péter contrairement à LO qui convertit le document dans son format interne et perd de l'information au passage…)

"rédacteur technique", ce n'est pas le terme consacré pour désigner les auteurs de modes d'emploi ? :)
(désolé, vendredi, tout ça… --> [] :)

OK elle a l'air pas mal, mais je fais juste remarquer que tu trouves des Lenovo x200/t400 d'occasion pour moins de 100€ sur leboncoin (parfois moins de 70€. J'ai acheté le mien pour 40€ (avec écran et batterie HS, mais parfait pour un serveur ou un desktop fixe)), et en dehors de l'USB3 il me semble que ce type de machine remplit ton cahier des charges (de plus, j'ignore ce que donnent les ATOM récent sur le plan du bios/ME, mais le x200 a le mérite de supporter Libreboot).

OK, c'est sûrement moins "basse conso" que ta carte ATOM, mais

• pour la planète : réutiliser un vieil ordi restera toujours plus écolo qu'acheter une machine neuve !
• honnêtement, 20-30W en moyenne (et sensiblement moins en idle) ça reste "acceptable" à mon sens

La résolution de noms est devenue quelque chose de chaotique sous Linux. Si tu fais un gethostbyname("foo"), il faut regarder dans /etc/hosts, demander éventuellement à mDNS (avahi?), demander au serveur DNS local, etc… Le resolveur de la glibc tente d'avoir une architecture "ouverte" pour rajouter d'autres méthodes plus ou moins dinosauresques (telles que NIS ou WINS) et c'est en partie à cause de lui qu'il est peu recommandé / impossible de faire des binaires statiques sous Linux.

Donc c'est un souci sur l'implémentation glibc de gethostbyname()/getaddrinfo() et non sur l'API, si je comprends bien ? Pas grave, suffit de changer de crêmerie.

Ah oui, sauf que…

je n'est pas eu le temps de faire les traductions

ça valait peut-être mieux, en fait… ;o)

Avec mon XU4 (mais avec un RPi, ou un BBB, ou autre c'est grosso modo pareil) c'est à la planète ET à mon portefeuille que j'ai pensé.

A ce sujet : ton Odroid-XU4 est basée sur du ARM (donc nécessite un kernel/une distro spécifique) => sera t-il encore maintenu et utilisable dans 10/15 ans ? (je ne parle même pas de 30 ans… sachant que l'OS supporté aujourd'hui est a priori déjà obsolète vu que Hardkernel annonce "the board can run various flavors of Linux, including the latest Ubuntu 15.04 and Android 4.4 KitKat and 5.0 Lollipop"…)

Par contre, LXQT n'a pas complètement retiré sa dépendance au framework KDE

Euh, de quelle dépendance parle t-on ?
LXDE était basé sur GTK (un peu comme XFCE). Razor-QT est basé sur QT.
La "fusion" des deux (basée sur QT) n'a aucune dépendance à KDE à ma connaissance !

(pour la construction seulement, de mémoire)

Lapin compris…

Je ne connaissais pas Lumina, mais on dirait qu'il est un peu sur le même "créneau" que LXQT. Mais effectivement, dans la catégorie traductions de merde, on dirait bien qu'ils ont utilisé un traducteur automatique… Exemple :

Le arbre source pour le bureau Lumina vient d'être doux congelés en prévision de la sortie prochaine de la version 1.0.0 à la mi-Août (ciblant provisoirement 8ème Août pour finales critiques / contrôles).

Oui bon, là tu prends un exemple extrême (j'ai aussi un 486 qui prend la poussière), et les besoins d'aujourd'hui en RAM/stockage ne sont pas ceux d'hier (je doute que NodeJS tourne sur un 386/16Mo :). Mais mon propos visait surtout les montagnes de machines bien plus récentes qui malgré tout finissent à la benne (franchement, un P4 ou un Athlon avec 1 Go de RAM et l'ethernet 10/100 intégré peut encore aujourd'hui faire plein de choses). Si on arrivait à faire que chacun fasse durer ses machines au moins 15 ans ce serait déjà un progrès immense (on s'attaquera au problème des machines qui ont 30 ans dans un second temps :)

Hum, j'avais pourtant bien dit "Si c'est vraiment à la planète que tu penses"… Sur un plan purement financier (lié à la facture edf de l'ordinosaure), la reponse est parfois différente, mais ça n'était pas le propos. Et je maintiens qu'il n'existe pas de "recyclage propre". Tout au plus des moins mauvais que d'autres (dans lesquels on récupère un peu plus de métaux que d'autres). Et quand bien même il existerait un recyclage 100% propre dans lequel 100% des atomes sont réutilisés, ça ne change pas le fait que l'énergie (considérable) que nécessite la fabrication d'une machine n'est - elle - pas récupérable ! (Donc dans un monde fini on ferait mieux de faire durer autant que possible nos machines). Évidemment l'électricité (au charbon) chinoise est probablement moins chère que celle d'edf (et plus généralement, l'énergie ne vaut rien aujourd'hui, même si je doute que ce soit encore le cas demain) donc cette energie utilisée pour la fabrication est un peu invisible dans ton calcul pour le porte-monnaie, mais ça n'interdit pas de s'y intéresser "Si c'est vraiment à la planète que tu penses" (et/ou aux générations futures).

P.S pour tes machines "en veille" (au sens strict i.e. inutilisées, pas avec un serveur qui doit être capable de répondre à tout moment), il existe ça ;)

ça peut vite finir par compter, autant pour la planète que le porte-monnaie

Si c'est vraiment à la planète que tu penses, le plus important est d'utiliser les machines les plus vieilles possibles et de les faire durer le plus longtemps possible même si ce sont de vieilles tours qui consomment (ça fait autant de machines de moins fabriquées), car l'énergie nécessaire à la fabrication d'une machine domine souvent d'assez loin celle qu'elle consommera durant toute sa durée de vie ! (Sans parler de la pollution, de la consommation de métaux rares, etc.)

N.b. je pense aussi que le recours à un hébergement mutualisé/virtualisé en data-center a souvent des chances d'être plus efficace que l'auto-hebergement (taux d'utilisation des machines plus élevé => moins de machines toute chose égale par ailleurs)

Mais en fait, le manque de responsabilité d'une autorité ne change pas grand chose pour les utilisateurs de ses services en particulier, ça rend "juste" tout le système SSL moins fiable. Du coup, utiliser leurs certificats, en soi, ne pose pas vraiment de problème pour celui qui les utilise.

Sauf quand ta CA se fait virer des navigateurs ;)

FYI une autre implémentation (GPLv2) de l'algorithme de Shamir est ssss
(je manque de temps pour comparer. Si quelqu'un a un avis…)

sous Linux

En fait, ça n'est pas lié à Linux (au sens du kernel) stricto-sensu : il existe d'ailleurs des distros qui ne respectent pas le FHS :)

Concevoir un CPU RISC-V capable d'atteindre les performances et l'efficacité énergétique d'un CPU Intel actuel nécessiterait un tel travail que la moitié des lecteurs de linuxfr sera à la retraite et l'autre moitié mangera les pissenlits par la racine avant de pouvoir en profiter.

Du coup, peut-être qu'un effort de sobriété devra venir des usagers (accepter une machine moins puissante et des clients lourds / des logiciels moins "jolis") et des développeurs (accepter de passer plus de temps dans de l'optimisation et d'utiliser des langages compilés plus contraignants) pour rendre à nouveau utilisable une machine peu performante (<mode="vieux_con">dans mon jeune temps, j'ai tapé un rapport de stage complet sur un Amiga 1200 de base (68020 avec 2 Mo de RAM), et un autre sur un Psion série 5</mode> :)

mais apparemment beaucoup des ISA en dehors de x86 sont des descendants de RISC : ARM, MIPS, POWER (Performance Optimization With Enhanced RISC), SPARC…

Je ne suis même pas sûr que "descendants" soit le terme approprié : RISC est un terme générique désignant une approche (avoir un jeu d'instruction simple) et pas le nom d'un jeu d'instruction précis. Donc il y a plein d'ISA RISC qui ne sont pour autant pas descendants d'un ancètre commun initial et qui sont bien sûr incompatibles !

Actuellement plus d'une quinzaine de fabricants disposeraient d'une licence ARM, ce qui témoigne d'un marché relativement ouvert

Dans le cas des Cortex-A, c'est 249 ! :)
(Je me disais bien aussi qu'une quinzaine ça faisait peu… Par exemple, au delà des plus connus comme NVidia/NXP/TI/Qualcomm/Mediatek/Broaadcom/Samsung/Allwinner/Rockchip, il y a aussi HiSilicon (Huawei), Realtek, ST, Marvell, Apple, Toshiba, et plein d'autres moins "connus" comme Leadcore (Datang), ActionSemi, Spreadtrum, Ambarella, ZTE, AmLogic, Cavium, etc.)

Super journal ! Peu de personnes ont conscience du souci posé par le Management Engine :-/

Bon, j'ai quand même 3-4 remarques (sans grande importance, juste pour pinailler :)
Premier truc : je suis surpris par la phrase suivante dans le journal

dont le sous-projet le plus avancé semble être OpenRISC, un microprocesseur basé sur l'architecture libre RISC-V

Je pense (je peux me tromper) que OpenRISC est antérieur et n'utilise pas l'ISA RISC-V. "RISC" est un terme générique (même "ARM" signifiait "Acorn RISC Machine" !)

Tant que j'y suis, on lit aussi

MIPS Technologies appartient depuis 2013 à Imagination Technologies (qui n'est pas vraiment l'ami du logiciel libre), mais quelques compagnies continuent à produire des processeurs MIPS. La plus connue est sûrement le chinois Lemote.

Rappelons quand même que des coeurs comme MIPS24k sont utilisés dans un nombre considérables de SoCs pour routeurs chez Atheros/Mediatek/Realtek (par exemple l'AR9331, mais c'est juste un exemple)
Bon OK, on parlait d'un usage Desktop… On pourrait dans ce cas parler des SoC Ingenic, et justement comme le journal parle de EOMA68, Rhombus-Tech a justement envisagé de recourir à un processeur MIPS32 Ingenic JZ4775, qui était d'ailleurs apparemment le "meilleur" candidat d'un point de vue théorique/ouverture (là où Allwinner n'a pas spécialement bonne réputation…) mais malheureusement s'est finalement avéré irréaliste dans leur contexte (Initially, two EOMA68 Computer Cards were developed: one using an Ingenic jz4775, the other with an Allwinner A20. We planned to apply for RYF Certification on the jz4775 card because not only is there no GPU (there’s a Vector FPU similar to AltiVec), but the video processor’s source code is entirely GPL compliant, making it a seemingly perfect candidate for RYF Certification. However, upon close investigation, the only FSF-endorsed operating systems available for MIPS32 were so horribly-out-of-date that the resulting device would be pretty much unsaleable even to FSF supporters. Reluctantly we had to drop the jz4775 from immediate consideration), donc ça veut dire que "MIPS" ne signifie pas nécessairement "pas sympa avec le libre" :)
(N.B. je pense que cette réputation "pas cool avec le libre" vient surtout des GPU PowerVR et pas de la partie "MIPS", et j'avais discuté avec des personnes de Imagination Technologies il y a qq temps. J'ai retenu que des ingénieurs souhaitent faire bouger les choses en interne, mais c'est apparemment pas simple et ça prend du temps - notamment quand ils ont eux-même sous-traité / acheté du code à d'autres fournisseurs sous licence…)

Dernière chose - un peu hors-sujet : en ce qui me concerne sur le non-x86, mon premier souci est que beaucoup de fabricants de SoC et/ou OEMs se contrefichent généralement de la GPL (suffit de chercher "GPL violation" ou de demander les sources du kernel à à peu près n'importe quel OEM asiatique à base de Allwinner/Rockchip/ActionSemi/Mediatek/…), ceci alors même que ARM ne permet pas "one kernel to rule them all", et que le côté monolithique (+ l'idéologie "stable API nonsense") de Linux ne permet pas de découpler les parties dépendantes du HW du reste (pour recompiler facilement les parties génériques du kernel et combler une faille de sécurité par exemple). Bref, aujourd'hui le x86 reste encore la seule manière d'avoir une machine qui ne soit pas "jetable" au bout de 3 ans… (OK, j'exagère peut-être un peu : des fabricants de SoC comme NXP/TI s'engagent sur du support à long terme, ainsi que sur le support du device-tree, donc peut-être que j'accuse injustement ARM dans son ensemble. Mais c'est un fait que aujourd'hui tu peux booter une clé USB Linux générique sur n'importe quel PC du monde, alors qu'il faut une distro spécifique pour chaque machine ARM, réduisant sa durée de vie à celle du support)

On l'a bien vu et les contributeurs du projet Purism s'en sont mordus les doigts : dans l'état actuel des choses, il n'est pas possible de faire un ordinateur dépourvu de logiciels non-libres basé sur x86.

Purism s'y est cassé les dents, mais ce ne sont pas les seuls (et ça fait peur) : Google engineers have tried for many years to get source code from Intel, and to reverse engineer the blobs that Intel provides. So far, they have been unsuccessful. Google is also one of the companies that funds the coreboot project, and they hire a lot of the core developers, so it's not like they don't have vast resources at their disposal. Smaller companies have no chance.

Parmi les acteurs développant des plateformes ARM haut de gamme, on trouve NXP Semiconductors, surtout connu sous son ancien nom : Freescale. Leur LS2085A NPU (Network Processing Unit) est probablement ce qui se rapproche le plus d'une station de travail moderne dans le monde ARM haut de gamme.

En dehors de Freescale, il me semble que nvidia a plutôt bien progressé en matière d'ouverture (d'après ce que je comprends, je n'ai pas été vérifier dans le détail), et ils n'utilisent évidemment pas de GPU Mali. M'enfin bon, y'a toujours plein de blobs et c'est sûrement un peu moins ouvert que NXP/Vivante, n'empêche que:

• je n'ai pas connaissance d'un truc analogue au Management Engine (par contre, nvidia garde jalousement la SBK, qui permet théoriquement de débricker n'importe quelle shield-tablet avec nvflash. Mais j'imagine que rien n'empêcherait un OEM de concevoir une carte-mère à base de K1 tout en étant plus sympathique sur le bootloader/SBK)
• ça permet des machines raisonnablement performantes et peu énergivores et pas chères (bref "modernes")
• ça fait tourner Ubuntu 14.04 aujourd'hui (avec accélération graphique/vidéo. J'ignore si l'état de ce qui est libre vs blobs permet de recompiler et faire fonctionner facilement 16.04. En tout cas le kernel est basé sur un Device-Tree à ma connaissance, ce qui est moins merdique que beaucoup de concurrents)

Yep, le journal suivant de vejmarie sur RISC-V en parlait justement. A suivre :)

est-ce que tout cela suffit à justifier le fait que l’on passe d’un OS + userland qui tourne sur 32-64 Mo de RAM (et je suis gentil, je remonte à l’époque de Amiga OS 3, pas 1.x) à l’obligation de posséder 4+ Go de RAM ?

Linux fonctionne avec 16Mo de RAM sans souci (et probablement moins) avec un environnement uclibc/musl/busybox, etc. Je l'ai fait marcher sur des dongle routeurs à 5€ et j'ai quelques milliers d'OpenWRT en prod sur des machines avec 64Mo de RAM et 8 Mo de flash ! Par contre, si ta référence est une Ubuntu avec Unity (ou Gnome), des icônes en SVG, une résolution 4k, des drivers qui supportent OpenGL, la capacité de lire ou manipuler des photos/vidéos, plein de services qui tournent sur D-bus et plein de choses écrites en langage interprêté (Python/Perl/Bash), etc. effectivement les besoins hardware/RAM doivent être au dessus (mais on ne parle plus vraiment de la même chose dans ce cas :)

Pour 60 € on a un téléphone avec processeur plus puissant, plus de mémoire vive, plus de stockage, WiFi, BlueTooth, un écran tactile (mais pas de port réseau). Pourquoi les routeurs sont si chers par rapport à un téléphone ?

C'est en train de venir : MIPS est en train de disparaitre des WiSoC haut de gamme, et des SoCs comme le BCM63138 ou Marvell Armada 38x prennent le relai (capables d'adresser 1GB RAM, dual-core cortex A9 ou mieux, etc.). Mais c'est vrai: les SoCs pour routeur ont pour l'instant un train de retard. Bon du reste, si tu as un peu de volume (quelques milliers d'unités) tu peux quand même faire des routeurs assez sophistiqués et pas trop chers sur la base de system-on-module relativement cools (enfin, cool a priori mais non testé :)

(Au passage, j'aimerais tellement que des cartes comme ceci exposent les pins RF/SIM permettant de faire de la 4G puisque le SoC supporte un modem avec plein de bandes…)

les débits qui ne dépasseraient pas les 350Mb/s sur le gigabit

Rappelons au passage que OpenWRT (j'imagine qu'il en est de même pour LEDE) ne supporte pas l'accélération hardware NAT/QoS présente dans un certain nombre de chipsets (e.g. Mediatek/Atheros/Broadcom…).