karteum59 a écrit 873 commentaires

Tu as le problème en cas d'écriture sur une copie, tu les modifies toutes. (…) Il ferait mieux de créer un nouveau type de lien

Est-ce un problème ou est-ce le comportement souhaité ? Je pense que ça dépend des cas d'usage (dans mon cas, je ne souhaite surtout pas de COW…)

…mais les US ne sont pas mon propre état (la Chine non plus).
Par ailleurs, je n'ai parlé nulle part d'échapper aux enquêtes de police, mais j'ai simplement dit que migrer sous Linux et sur du hardware de confiance permet d'éviter des choses plus sournoises (et sans contrôle d'un juge) telles que backdoors/malwares dans ton OS ou dans ton hardware !

Mais du reste il y a une vraie opposition entre tes propos ("état de droit") et ceux de T.Nitot ("état de surveillance, antichambre de la dictature")…

Commencer par lui dire « reformate ton disque et installe Linux Mint », c'était trop de responsabilité, un trop grand risque de lui faire perdre ses données et le dégouter de sortir de sa zone de confort informatique, déjà pas bien étendue
(…)
c'est maintenant qu'il faut l'ouvrir pour éviter d'entrer dans un état de surveillance, antichambre de la dictature

Il y a plein de choses (simples et moins simples) pour échapper à la surveillance "publicitaire" un peu partout sur le web (mouchards, GAFA…). Par contre, échapper à la surveillance des états (notamment US) me semble plus difficile sans passer 1°/ sous un OS auditable et de confiance (donc libre), 2°/ avec du matériel de confiance (certaines cartes ARM ou un laptop avec Libreboot sont davantage de confiance que les derniers ordi qui ne bootent pas sans le Management Engine…), 3°/ avoir un OS minoritaire en parts de marché et sérieux sur les MAJ de sécurité signifie aussi être moins vulnérable aux malwares (qui peuvent aussi provenir des états)

Bref, je pense que Linux fait aussi partie de la solution…

les hardlink posent certain problème

Les symlinks aussi : tes deux (ou plus) copies de fichiers ne sont plus toutes "égales", donc si tu effaces le fichier "de référence" tes autres "copies" deviennent des liens cassés et les données sont perdues. Avec des hardlinks la donnée reste là tant que le compteur de références est > 0. Bref remplacer les copies par des symlinks ne doit être fait que lorsqu'on sait très précisément ce qu'on fait (par exemple, c'est OK si on a une arborescence propre "de référence" et d'autres arborescences "à trier" où il est OK de remplacer les doublons par des symlinks). Par ailleurs, si tu déplaces le fichier de référence (ou si tu déplaces les symlinks qui auraient un path relatif e.g. avec du "../../something") tu te retrouves aussi avec un lien cassé. Idem si tu fais un chroot(). Bref, pour cet usage je trouve que les symlinks sont une approche un peu casse-gueule…

La fonctionnalité de détection et effacement des duplicatas m’intéresse tout particulièrement

En fait, il y a plein de softs qui font ça, à commencer par fslint (voir le code de findup, en gros c'est un gros pipe :) et fdupes et plein d'autres (N.B. j'utilise git ls-tree -r HEAD | cut -d' ' -f3- | sort | uniq -D -w 40 pour trouver les doublons dans un repo git). Le principe est un peu toujours le même :

• parcourir le fs (tiens d'ailleurs j'ai découvert qu'il y avait une fonction appelée ftw() qui faisait ça dans la libc)
• trier les fichiers par taille et ne retenir que les entrées présentes plus d'une fois
• calculer un hash (éventuellement sur une portion du fichier pour aller plus vite si on accepte le risque de faux-positif)
• les "doublons" sont les fichiers de même taille et de même hash (on peut aussi prendre en compte la similitude entre basenames, mais en ce qui me concerne j'évite ça compte tenu des soucis entre lower/uppercase sur les fs unix, et des troncature à 8 caractères sur les fs préhistoriques…). Certains programmes se contentent de lister les doublons mais d'autres proposent de remplacer les entrées excédentaires par un hard link si les fichiers sont sur le même fs.

Par contre, je ne connais pas de programme qui te factorise les sous-arborescences (i.e. qui évitent de lister tous les fichiers et sous-dossiers quand tu as deux dossiers identiques). J'ignore si FIM le fait, mais en tout cas c'est ce manque que j'ai modestement essayé de combler avec un petit script sobrement intitulé Duplicide. Feedbacks welcome :)

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.)