freem a écrit 5059 commentaires

Totalement hors-sujet par rapport à fedora, mais:

Je n'ai pas regardé, mais je serais surpris que voidlinux n'ait pas les symboles de debug. Je n'ai personnellement pas utilisé Arch plus d'un jour (il est des choses qui marquent les souvenirs, comme un paquet Xorg qui à un problème de dépendance direct après l'installation…) mais de ce que je lis au sujet d'arch, voidlinux semble coller pas trop mal à la philosophie (et d'expérience personnelle, ça marche nickel avec un démarrage nettement plus rapide que Devuan que j'ai en double boot. Faudra que je compare avec Debian, un jour, en gardant à l'esprit que j'utilise le build musl de void, pas le build gcc)?

Du coup, questions, as-tu testé void? Pourquoi? Et si testé sans être satisfait, pourquoi également?
[edit]
Aussi, si tu cherches une rolling release, pourquoi fedora? À ma connaissance, c'est une distrib classique, versionnée?

La façon de vérifier serait de faire une étude pour voir combien de temps quelqu'un mets à être efficace avec un clavier + souris + écran pour participer au web (pas juste pour lire, j'insiste) par rapport au fait de s'habituer à l'usage d'un appareil tactile.
Je doute que quelqu'un soit capable d'écrire plus vite que moi qui utilise mon clavier (et je ne suis pas dactylo, je n'ai même pas la prétention de taper vite, je précise) avec un écran tactile de la taille d'une feuille A5, personnellement.
Ensuite, même pour la recherche d'info techniques, je me vois mal utiliser une tablette: l'espace est trop restreint, je ne pourrai pas avoir autant d'informations simultanées, voire même j'ai pas vu de tablettes afficher plus d'une fenêtre à l'écran, donc impossible de comparer les données, alors que mon navigateur supporte nativement l'affichage de plusieurs pages simultanément, tout en me laissant voyager très facilement entre divers onglets et donc diverses sources d'info. Et je me limite au navigateur ici.

Ce qui est certain, c'est que mes collègues qui ont dans les 25 ans utilisent bel et bien leur PC (quitte à avoir parfois leur machine perso au taf… mais ça, ça m'arrive aussi) et non une tablette pour chercher des infos pour le taf, pas leur téléphone ou une tablette. Si c'était vraiment plus pratique pour eux, je n'ai aucun doute qu'ils en utiliseraient.

Perso ça dépend de ce que je veux faire.
Je suis parfois piéton (le plus souvent en fait), parfois en bus, parfois en train, parfois en voiture, parfois en bus, parfois en camionnette et j'ai passé aussi quelques heures en camion.

Ceux qui pensent qu'un moyen de locomotion fera disparaître tous les autres sous prétexte qu'ils ne l'utilisent pas ne sont que des imbéciles à la vue courte.
Et c'est la même chose pour l'usage des outils informatiques, que ce soit les outils en ligne de commande vs outils graphiques, outils en local ou sur serveur, PC classique vs tablettes ou téléphones…
Le PC classique deviens un outil plus spécialisé? Et alors? Il sera malgré tout utilisé encore de longues décennies par tous les gens qui ont besoin d'écrire rapidement du texte parce que désolé mais le tactile c'est pas adapté (pas de retour de force, devoir garder le cou fléchi pour regarder en bas ou pire avoir le bras en l'air…) ou pour ceux qui veulent jouer confortablement à certains types de jeux (le tactile, c'est bien, mais ça masque juste un peu l'écran quand même… pas pratique dans un FPS ou un STR).

Excuse-moi c'est le use-case du shell intéractif au quel je pensais. Qu'il y ai un dash dans la distribution pourquoi pas, de là à augmenter les outils autour.

C'était un peu pour narguer, mais le sujet m'intéresse réellement :)

Plus rapide ? […]

Pas faux.
Mais du coup, comment ça marche dans le cas ou un serveur tombe? On redescend une sauvegarde direct (en faisant un back de la machine fautive pour analyse j'imagine) même si ça risque de prendre du temps, ou on essaie de la réanimer pour essayer de restaurer le service au plus vite? Et dans ce cas, comment?

Ce n'est pas parce que GCC support ARM, x86-n, RISC que l'application qui a été d'abords codée pour x86 se retrouve automagiquement optimisée pour ARMv99.

Naturellement, puisqu'il faudrait déjà qu'elle soit écrite de manière portable, ce qui est loin d'être trivial à faire (pour une taille, on prend quoi? Un size_t dépendant du compilo qui lui-même dépendra du compilo, ou un uint64_t qui permettra d'avoir toujours le même résultat? On peut aussi considérer qu'on n'aura jamais plus de 0xFFFF éléments, et dans ce cas un uint16_t serait peut-être plus approprié?).

Ce que je voulais dire, c'est que recompiler pour une archi permets d'utiliser les spécificités de cette archi et les optimisations liées, plutôt qu'utiliser un tronc commun qui se basera probablement sur un dénominateur commun.
Et puis, il reste le fait de désactiver les dépendances dont on sait qu'elles ne seront jamais utilisées. Honnêtement, je ne pense pas que sur les machines x86 actuelle ou le CPU glande la plupart du temps ce soit pertinent, mais si les machines à base d'ARM sont sensiblement plus lentes, ça pourrait être pertinent de faire le propre dans les dépendances au lieu de viser le système universel, je suppose?

Archeux pensant qu'une recompilation avec 3 flags == optimisation.

Parce qu'arch est basé sur l'idée de recompiler la plupart des composants? Je n'en ai pas eu l'impression au cours de mes lectures.

Le "compatible Android" a déjà remplacé le "compatible PC" comme standard de machine le plus répandu. Que Linux n'arrive pas encore à s'y adapter, c'est un autre problème.

Me semble pourtant bien que Linux est compatible Android, vu qu'Android se base sur Linux?

Du coup, je me dis que je dois pas comprendre ce que tu veux dire.

soit un runtime comme python […] un shell interactif en prod c'est déjà plus du minimale

Euh? Python intègre, de mémoire, un shell interactif. M'en suis pas servi en soit, mais je ne doute pas qu'il soit autrement plus complet que dash ou ash?

Mais bon, dans l'idée, tu n'as pas tort. Juste, du coup, en supposant que Murphy frappe et que le système pète, tu fais comment pour récupérer ton système? Restauration de backup direct plutôt que passer par un shell distant pour retaper le fichier qui va bien qui serait potentiellement plus rapide?
Au final, avoir un busybox prêt à l'emploi (potentiellement qui intègre en fait un peu plus qu'un système minimal pour le coup, vu qu'on peut y trouver des outils dhcp entres autres) me semble pas excessif en cas de coup dur?

la preuve les récents tests des PC Windows 10 sous ARM, comme le Asus NovaGo. Où l'on s’aperçoit que même avec des applications natives ARM les performances ne sont pas au niveau d'un ordinateur x86.

Peut-être que si ça finit avec une tétrachiée de CPU ARM incompatibles ou avec des jeux d'optimisations possibles différents (un peu comme le x86 à une époque, en fait) une distribution dont la spécialité est de tout recompiler pour que les briques logicielles soient faites sur-mesure pour utiliser à fond le hard et délestées des composants inutiles (je pense notamment au fait que mes machines perso n'ont aucun usage pour le protocole SMB et pourtant il me suffit de quelques paquets à installer pour l'ajouter. C'est bien, mais ces instructions de vérification runtime doivent bien être exécutées, consommant quelques cycles et pourrissant quelques caches?) pourrait tirer son épingle du jeu?

Du coup, les distros de type gentoo qui recompilent tout depuis les sources (enfin, il est possible d'installer des binaires aussi je crois?) et en permettant d'élaguer les fonctionnalités inutilisées par un système donné seraient peut-être les plus à même de rendre ce type de systèmes exploitables?
Bon, du coup, ça exclue toute distribution (linux ou autre kernel) non spécialisée pour à la fois l'usage et le hard, et je doute que les gars de chez MS s'amusent à compiler une galaxie de versions?

Bon, d'un autre côté, si les OS binaires ne sont pas un minimum performants, il est peu probable que ça atteigne les foules, et donc que ça se répande dans le public.

Idem, je ne vais dessus que par accident, l'habitude de cliquer à côté des journaux pour consulter les forums…

En plus, niveau du bruit et de l'espace pris pour rien, il semble que même naviguer à -42 ne permette pas de voir les liens négatifs.
Bref, je trouve aussi ça d'un intérêt plus que limité, et même gênant, puisque j'y vais par erreur, alors que je voudrais les éviter (mais, à priori, si je faisais l'effort, je pourrais modifier le thème pour ne plus les voir… hum, non merci. Pas envie d'apprendre à utiliser CSS pour ça.)

PS : Bien penser à sauvegarder ses données avant la rencontre, ça fait gagner du temps !

Vu qu'il a 2 disques, il peut aussi juste en débrancher un et y aller avec uniquement le disque vide branché :)

c'est pas une bête de course au niveau du proc

Est-ce si important que ça? Si les tâches sont bien réparties dans le temps, je ne pense pas.
La compilation ça fait mouliner c'est vrai, mais même en C++, je me suis aperçu que la façon de travailler permets de réduire drastiquement les temps de compilation.
Bien découper le code, compiler (et commiter, mais c'est une autre histoire) régulièrement… avoir un environnement léger et pas une usine à gaz… À mon sens, de nos jours, le plus utile dans un CPU, c'est son cache, pas son nombre de coeurs ni sa fréquence. Puis viens la quantité et la vitesse de la RAM, encore une fois avant la puissance brute du CPU.

Si tu veux un maximum d'autonomie, il faut une grosse batterie avec du matériel moins puissant. Et il faut paramétrer le système correctement, pour qu'il colle à ton usage.

Deux éléments qui ont une grosse consommation énergétique sur les PCs:

• la radio (WiFi, bluetooth…)
• l'écran.

Donc, l'idéal, ce serait d'avoir des modules radios que tu peux désactiver mécaniquement (amuses-toi à trouver ça… pas trop dans l'air du temps) ainsi qu'un écran le plus petit possible (sans que ça n'impacte l'utilisabilité de l'appareil pour toi, bien sûr).
D'un autre côté, plus l'écran est petit, moins il y a de place pour les composants, ce qui implique d'avoir une batterie plus petite (ce qui rend aussi le PC plus léger et donc plus simple a balader partout, je me souviens de mon 1015 PEM que j'avais tout le temps sur moi, et avec lequel je programmais sans problème, mais bon, mon environnement de travail est hyper léger et l'affichage optimisé pour pas avoir de trucs inutiles genres coins arrondis qui font perdre de la place pour des prunes) donc l'énergie embarquée réduit. Reste à voir si la réduction de capacité est supérieure ou inférieur à la réduction de la consommation.

Après, il faudrait faire des benchmark j'imagine, mais je suppose que l'on gagne pas mal avec un SSD, du fait qu'il n'a pas besoin de tourner (aux sens propre et figuré du terme) en permanence pour permettre un accès rapide aux données.
Pour les unités de calcul, je crois que c'est la finesse de gravure le plus important de ce point de vue la. Mais honnêtement, de mon expérience personnelle (pas super riche, je te l'accorde) tous ces points sont négligeables devant les 2 premiers.

Ah tiens ça à l'air sympa ça, le WE de 3 tombe bien, je commence a avoir pas mal de trucs sur la todo-list :)

un Linux sans outil GNU, je ne connais pas

Compte tenu que la distribution VoidLinux n'utilise pas que la libc, mais aussi musl, peut-on considérer le build musl comme sans GNU? Remplacer bash par dash (ou zsh) est quelque chose que bien des distribs ont déjà fait pour le coeur des systèmes (problèmes de performances, je crois), pour gawk il y a awk et mawk, perl c'est pas gnu, sed et grep, p'tet? Mais on dois pouvoir porter ceux des *BSD de toute façon…

Bref, je ne crois pas que nos jours le GNU/Linux soit réellement pertinent. Sinon, y'a-t-il un GNU dans l'androïde? Je n'en suis pas si sûr.

J'essaye infructueusement de faire l'analogie avec les "box" Internet avec des enjeux financiers et sécuritaires qui me semblent encore plus importants.

Dans le cas des box, ce n'étais pas un problème de GNU, mais un problème de GPL tout court me semble. Je crois que les licences et les composants n'étaient pas cités, ce qui enfreignait des licences, justement.

Ensuite on va pas non plus prétendre être aussi célèbre que Tux et GNU. :p
Un jour, peut-être!

Un bon point de départ serait d'être présent dans les jeux vidéos, genre supertuxkart. L'air de rien, jouer à ce jeu m'a fait découvrir quelques projets :p (bon, je les utilise pas, mais l'important c'est de garder l'existence des logiciels dans un coin de ROM cérébrale, avec quelques mots-clés contextuels le reste se retrouve sur le petit ternet).
Remarque, je ne sais pas, c'est peut-être déjà le cas? Je n'y ai pas joué depuis quelques temps :)

Effectivement, si l'objectif est d'avoir 1 et un seul terminal sur un bureau dédié, et avoir un environnement classique sur les autres, ce ne sera pas la solution.
Mais dans ce cas, il dois bien y avoir moyen de configurer ton gestionnaire de session pour qu'il ouvre automatiquement un terminal sur un bureau?
Et si ce n'est pas le cas, un bricolage un peu sale à base de xdotool devrais le faire. Cet outil permets en théorie d'automatiser tout ce que tu saurais faire au clavier ou à la souris, dans le cas de la souris la seule contrainte c'est de connaître la position des cibles au sein de la fenêtre à manipuler. Je l'ai personnellement utilisé sur ce truc pour contourner le fait qu'il est (ou était, je sais pas ce ça donne maintenant) impossible de versionner le code, et qu'évidemment la gestion des fichiers est absolument merdique, sans parler d'un éditeur de texte primitif. Bref, j'avais scripté pour uploader les sources à coups de souris ^{^} donc ça doit être faisable pour ton problème sans trop d'efforts.

C'est la première dépêche que je vois avec un score négatif sur DLFP je crois. Ça remonte à quand, la précédente?

C'est vrai, mais à vue de nez, ça ressemble vraiment à un ELF classique. Bon, je n'ai pas vérifié les détails (je savais le faire sous windows, mais c'était avec du PE, sous windows et y'a 10 ans… déjà…merde.) mais ça y ressemble.

Normal, le marché est saturé.

Manifestement, même les utilisateurs de ce truc n'aiment pas en lire.

Qu'on me rende Zenitram, là, maintenant … DLFP is dying !

C'est la section «liens», ça le rend tout chose :)

De manière générale, le point d'entrée est situé sur le raccourci "init" ? Cad uImage vient tapé dans Init ?

Je ne suis pas sûr pour les architectures ARM, mais à priori ça doit être la même chose.
Voici, (à peu près, j'essaie d'être générique, et vu mon niveau c'est évident que malgré mes efforts il y a des choses erronées dans ce laïus), ce qui se passe à partir de la mise sous tension d'un système:

1. Le système démarre un firmware à partir d'une ROM. Dans les architectures «traditionnelles» ou en tout cas les seules que j'aie connues (i386 et x86_64) ces firmwares sont divisés en (au moins) 2 familles: BIOS et UEFI.
2. Ces firmware passent la main à un programme appelé gestionnaire de boot. Windows en à un qui n'est pas trop nommé, sous Linux on a traditionnellement utilisé Lilo et Grub sur les disques durs, tandis que les installateurs CDs ont tendance à utiliser syslinux. Ce gestionnaire de boot permets d'une part de choisir le noyau à lancer, mais aussi quels paramètres lui donner (typiquement avec les distributions linux classiques: chemin de la partition racine, binaire qui contiendra le PID (appelé init)).
3. Ce gestionnaire de boot charge un programme en mémoire et lui passe la main. Ce programme, dans les systèmes Linux traditionnels, est en fait une image disque minimaliste qui contiens 1 noyau linux, des modules à charger (les pilotes des systèmes de fichiers, le nécessaire pour un éventuel déchiffrement de ceux-ci, les pilotes de clavier, souris… en restant le plus minimaliste possible). Il s'agit de l'«initramfs».
4. L'initramfs à pour rôle de pré-initialiser le «système matériel», je ne connais pas trop les détails, mais je sais que cette phase n'est pas vitale, on peut démarrer un kernel directement) pour pouvoir charger le noyau réel,
5. le noyau charge le premier processus, appelé l'init. Il en existe plusieurs, mais les plus célèbres sont sysVinit, systemd et openrc. Le plus utilisé par les distributions de nos jours est systemd.
6. le processus d'init démarre les divers services nécessaires à la machine pour être plus qu'un tas de silicium et de cuivre. Généralement, tu vas avoir udev (qui va exposer les informations au sujet du matériel provenant du noyau dans /dev), quelques terminaux virtuels (les fameux /dev/tty*), un gestionnaire de réseau, openssh, ton gestionnaire de session (lightdm, gdm, kdm, slime,…)…
7. le gestionnaire de session ainsi que les tty sont traditionnellement les outils qui permettent à l'utilisateur final d'utiliser physiquement la machine (openssh aussi, mais c'est à travers le réseau), ils te demandent donc habituellement un login et un mot de passe, puis te laissent la main.

PS: il y a un bouton répondre en dessous des commentaires, afin de répondre à une personne cible, ça rend les échanges plus faciles, et cerise sur le gateau, ça évite de réecrire un titre ;)
J'imagine qu'il faudrait voir pour améliorer la visibilité d'ailleurs, ça arrive régulièrement qu'un nouveau ne le remarque pas.

Dans ton cas, je doute que le code JavaScript fasse plus de quelques ko, ce qui fait la masse de l'application est la masse de dépendences

C'est bien le problème, justement, on passe d'une tarball de moins de 10Mo (ressources incluses) à un bloc de pas loin de 100Mo en «compilé». Je suis d'accord avec toi que le problème vient probablement de la masse des dépendances, et on dirait que le collègue n'a aucune idée des outils dont il dépend vraiment… pour faire simple, c'est un peu comme si on installait une Debian en installant tous les paquets suggérés «juste au cas ou»…

C'est toujours mon attente que tu pourrais essayer de vérifier mais je serais surpris si le binaire en question était bien plus qu'une archive auto-extractrice, qui une fois explosée te permet de retrouver ton code JavaScript.

Pas bête, je n'ai pas essayé de le passer à 7z, mais bon, ça serait triste, parce qu'une compression réduit de 70% la taille du blob. Je suis aussi persuadé, après une inspection rapide à l'éditeur de texte que les symboles ne sont pas stripés, mais strip semble ne rien faire?

Pour “sauver les meubles” il faudrait voir si l'application originale peut être installée en connection WiFi au lieu de 3G et s'assurer que les màj ne fassent rien de plus que tirer le nouveau code JavaScript.

C'est plus ou moins l'état ou j'en suis actuellement… garder le «compilateur» et npm (au moins, j'ai réussi à trouver comment faire pour pas que ce truc tourne en tant que root… au pire, son utilisation ne pourra flinguer qu'un compte utilisateur. Les MàJ de ce truc restent hyper dangereuses, mais bon… j'hésite limite à passer en testing en fait…) sur la machine pour recompiler le code.

Le problème est que je ne connais pas JavaScript, et donc évidemment pas NodeJs et encore moins electron.js.
C'est censé compiler, mais je doute très fortement que ce soit comme en C, en C++, en Rust, en pascal, en Java… bref dans un langage traditionnellement compilé, c'est à dire que le générateur de binaire ait bien vérifié que tous les appels mènent bien quelque part.
Peut-être qu'il existe des outils d'analyse statique pour le JS, remarques. Je n'ai pas encore creusé cette piste…

Sinon recoder l'appli en ne faisant que les appels necessaires.

Je t'avoue que j'ai été tenté, quand j'ai vu un soft de même pas une 10aine «d'écrans» peser aussi lourd. Mais bon, j'ai une tonne de taf, l'intégration de cette appli au système n'est pas à franchement parler mon métier principal.

Merci pour les infos, mais il semble bien que je ne vais pas pouvoir utiliser wvdial:

wvdial: utils/wvtask.cc:303: static int WvTaskMan::yield(int): Assertion `*current_task->stack_magic == WVTASK_MAGIC' failed.

Je vais voir pour reporter ça quand j'aurais 5 minutes du coup.