freem a écrit 5019 commentaires

Par exemple LO, c'est Lutte Ouvrière et GPL c'est Gaz Pétrole Liquide. J'en ai une tripotée comme ça.

Moi, un ami de mon père (ex-CGT-iste pour le contexte, l'ami) m'a «appris» que FO de Force Ouvrière, c'est Fesses Ouvertes dans le genre imagé :)

les pommes, d'une façon, générale, c'est bon pour la santé

Tout dépend de la distillation aussi!

Et c'est une raison pour continuer?

bon en même temps si en plus d'utiliser des ordinosaures il utilise des bootloader de la préhistoire c'es sur que ça aide pas.

Je préfère utiliser un bootloader de la pré-histoire plutôt qu'une usine à gaz telle que GRUB2 :)

En pratique, j'utilise sur mes systèmes normaux syslinux, hein. Je devrais p'tet tester, sauf que, bah, de ce que je vois, le problème n'est pas lié au bootloader: après tout, LILO charge bel et bien l'initrd, c'est juste l'initrd qui n'arrive pas à trouver la partoche maîtresse…

En tout cas pour moi le symptome est plus probablement un pilote de chipset spécifique non compilé / pre-chargé dans l'initrd utilisé actuellement.

C'est aussi ma conclusion, je cherche à savoir comment identifier un tel pilote.

surtout avec lilo … mais s'il utilise bien les UUID c'est justement fait pour ne pas avoir de problème du genre.

Si c'était ça, j'aurai réglé le problème en 2 lignes de bash, vraiment. Enfin, pas forcément bash, mais… bref.
Sauf que, UUID ou LABEL (ce que j'utilise en pratique sur mes systèmes normaux, parce que sérieux, les UUID c'est illisible!) au final, ce ne sont que des liens symboliques créés par udev vers les /dev/sdXY je crois? Hors, justement, ces fameux fichiers sont absents…

[edit]
fourchage de doigts, j'avais écrit gnome au lieu de grub…

Le disque est reconnu puisque grub se lance, il lance bien le kernel mais peut-être l'ordre des disques ou l'UUID n'est pas le même. L'initrd contient bien les bons modules pour le système de fichier puisqu'il démarre sur l'ancien PC.

Je n'utilise pas grub, mais LILO sur ce disque.
L'UUID n'est pas utilisé (enfin, j'ai mis à jour LILO pour ne plus l'utiliser, au cas ou, et me baser sur le schéma sdXY, mais ça n'a rien changé..).
À savoir qu'il semble qu'aucun disque ne soit détecté par linux, mais que le BIOS lui ne vois aucun souci?
Je le sais parce qu'en finissant sur le busybox, ls /dev/ ne liste aucun périphérique de disque, que ce soit les anciens (hdXY) ou les «nouveaux» (sdXY). Je pense que le problème est la, mais… rien n'est sûr.

Effectivement, je peux essayer de passer par un live cela dit… mais vu que la tendance actuelle est plutôt à lâcher les anciennes archis, j'ai un doute… en tout cas, sur Debian, je m'expose à des problèmes. D'autres en effet sont des pistes à creuser, merci pour le nom, je vais voir ça.

Mon azerty en est largement capable, lui aussi. Tant que c'est pas la disposition de windows, du moins…

• pas. Produire n'est pas écolo.

Tu pars du principe que tout le monde est productif au boulot, la, non?

c'est chiant quand ton plus court chemin est un sens interdit,

En même temps, c'est toujours chiant les réglementations, pour ceux qui se font réglementer…

le danger pour la personne sur ce mode de transport (à cause de l'énergie cinétique d'une voiture)

Une voiture sur une piste cyclable? Reste les routes, ok, mais bon, les motards et les cyclistes sont dans le même cas, ils n'ont pas non plus de carrosserie. Donc, ils utilisent des équipements plus ou moins contraignants (casques, renforts, etc).

largement supérieur à celui pour un piéton

Le problème est que les trottoirs sont aussi utilisés par des handicapés, des enfants et des personnes âgées, public potentiellement plus fragile que la moyenne, et pas forcément capable d'esquiver un véhicule dont le propriétaire à perdu le contrôle ou roule de manière imprévisible.
Ce qui ne sera pas (en théorie) le cas d'une voiture sur une route, qui offre plus de moyens de signalétique et donc d'anticipation (théorique, encore).

• comment tu apprécies la vitesse "rouler au pas" pour la contravention. ça risque d'être à la tête du client.

C'est p'tet justement bien le problème. Pour faire une réglementation équitable, ce genre de choses doit être prises en compte.
Quant au fait de «rouler au pas»… sérieusement? Quel est l'intérêt de ce genre de trucs si c'est pour aller aussi vite qu'un piéton?

Ça me semble pourtant évident:

je n'utilise même pas gnome ni n'execute ses applications, pas de GDM/Lightdm, c'est juste un relica de l'installation de base.

Quelqu'un qui n'utilise pas et à désinstallé des applications peut légitimement être choqué du fait que ces applications sont encore connues du système pour moi.
Ici, elles semblent en plus consommer de l'espace mémoire, ça va au-delà du simple fichier de conf, des UID/GID ou des logs qui traînent encore ici ou là malgré une éventuelle purge…

u'une voiture de 1,5 tonnes qui n'ira pas plus vite.

Ah? Tu vas à 80Km/h avec ton VAE? Ou alors tu as omis de préciser "en ville"?

Quant aux batteries, elles ont toutes un nombre de charges/décharges limité.

Renault aurait un partenariat pour réutiliser les batteries des Zoé, qui sont manifestement juste louée, afin de réutiliser les batteries en perte d'efficacité pour stocker l'énergie des éoliennes et autre trucs de particuliers.
Manque de bol, il semblerait que les théories à ce sujet soient fumeuses, les batteries de voitures électriques semblent difficiles à tuer, potentiellement à cause de systèmes nommés BMS pour Battery Management System.

Tu noteras l'excès de conditionnel, je ne tiens pas tout ça d'articles vérifiables, mais d'une source d'information vivante que j'ai pour collègue depuis quelques mois.
La ou je veux en venir, c'est que peut-être que justement la techno utilisée est bancale, puisqu'il semblerait que certaines tiennent plus longtemps que prévu.

Pour le reste, avoir une douche dans sa boîte est un luxe que je n'ai que rarement connu, et les vêtements en question, y'a pas que décathlon dans la vie. En fait, je dirais même qu'on s'en fout du magasin, l'important étant plus de choisir les fringues pour leurs propriétés (1ere couche absorption de sueur, 2nde isolation thermique, 3eme coupe-vent&protection contre la pluie sans pour autant être hermétique… je crois me souvenir d'une matière nommée gortex? sais plus….) que leur marque. Mais bon, c'est juste des trucs que j'ai appris en me renseignant, après tout.

Euh, sinon, pardonnez mon inculture, mais, c'est quoi, un split-brain, pour une DB?

Bon, c'est vrai, moi, j'ai pas sourcé.

Cela dit, je pense que chaque couche que l'on ajoute ne peux que faire perdre de l'efficacité énergétique, et pas en gagner, sinon on aurait résolu pas mal de problèmes avec juste des gens payés à pédaler….

C'est étrange, j'ai l'impression que wikipedia ne confirme que le cas du terrain plat, que je qualifierais d'exceptionnel?

On firm, flat ground, a 70 kg (150 lb) person requires about 60 watts [5] to walk at 5 km/h (3.1 mph). That same person on a bicycle, on the same ground, with the same power output, can travel at 15 km/h (9.3 mph) using an ordinary bicycle,[6] so in these conditions the energy expenditure of cycling is one-third that of walking.

Traduction à la va-vite:

Sur un terrain plat et dur,un individu de 70Kg nécessite 60W pour marcher à 5km/h, contre 15km/h avec une bicyclette ordiaire.

Mais, c'est quoi, un vélo ordinaire? C'est quoi, un terrain dur?
Et puis, ça donne quoi, sur un terrain réel?

Désolé, mais sur ce coup, wikipedia est trop vague pour être une référence.

Je pense qu'un paramètre à prendre en compte est l'accessibilité des chemins.

Y'a un an, j'étais plus rapide à pied qu'en bus pour aller au taf.
À cette époque, j'étais en région parisienne, et passer par le parc (de saint cloud je crois… j'y suis resté que 3 mois) me permettait de faire la route en moins de 1H30, en bus ça prenait 2H facile, coûtait ~1€50 par trajet, et m'imposait de faire avec la foule….

Faire le chemin à pied me permettait de m'éclater: j'ai toujours aimé crapahuter, et sans être gâté par la nature (ancien asthmatique léger, allergique aux acariens, notamment) je ne suais pas tant que ça.
Ça aurait été sûrement plus rapide en vélo, mais j'aurais eu moins de liberté sur le chemin à prendre, et le vélo est plus coûteux énergiquement parlant que la marche (ça fatigue plus au kilomètre, et me semble que l'animal qui marche génère mois de CO2 que l'animal qui pédale, et l'animal qui marche sans courir se nique probablement moins les articulations).

Je m'égare. Ce que je veux dire, c'est qu'il y a plus de chemins praticables à pied qu'en vélo, électriques ou non, et pire pour les véhicules larges. Notamment par temps de neige.

C'est comme souvent: il n'existe pas de panacée.

Ho merde… ce qu'il faut pas lire… mais bon, ça me distrait en vrai, surtout que je suis de mauvais poil depuis lundi (quand Murphy balance une claque dès le lundi matin, en même temps…)

Mon objectif (ou mon excuse), c'était : ne pas arriver en sueur au boulot, parce que j'ai pas de temps à perdre pour reprendre encore une douche là-bas.

Bah, tant qu'a prendre une douche, autant n'en prendre qu'une seule. Je sais bien que c'est contre les conventions, mais si tu sais que tu vas prendre une douche au taf, fais ton coup de VAE qui te fait suer, et prends ta douche après… C'est ridicule de prendre la douche avant et après selon moi.
Après, peut-être que ton n+1 aimera pas l'idée, ça, ça sera une bonne excuse.

Mon objectif (ou mon excuse), c'était : ne pas arriver en sueur au boulot, parce que j'ai pas de temps à perdre pour reprendre encore une douche là-bas.

Alors, je m'étais renseigné vite fait sur comment faire de la rando pédestre genre des GR. Il existe ce qu'on appelle le système 3 couches. De mémoire (quelques années, hein):

• 1 ère couche est un tissu qui colle au corps, et absorbe vachement l'eau;
• la 2ne est une couche remplie… d'air. Histoire que ça respire, mais sans refroidir;
• la 3ème est une une couche semi isolante: elle est capable de laisser passer l'air principalement dans un seul sens, mais pas l'eau;

Ces pistes devraient t'aider à éviter la sueur, et à gagner en confort de manière générale pendant les balades. Un point à noter: ajouter des couches, ça ajoutes juste des inconvénients. C'est au final un peu comme une distro: plus t'as de couches, plus le matos en dessous en sue :D

Évidemment, le vélo sera mort avant que j'ai rentabilisé le coût en faisant moins de plein (peut-être pas le vélo, mais la batterie au moins finira par mourir, c'est dans ses gènes).

Tu as une source? Ou c'est juste une habitude héritée des batteries au plomb qui servent juste à démarrer le système thermique?

L'important n'est pas la taille, mais qu'elle laisse bosser :)

je trouvais ça abusé d’indexer des entiers naturels

Bah, en fait, si tes entiers tiennent sur 8 octets chaque mais que t'en as moins de 65000, un hash sur 2 octets pourrait les indexer pour te permettre de les retrouver plus vite, potentiellement.
Je ne connais pas mongoDB, genre, pas du tout en fait, mais bon, si t'as un tableau d'indexes de petite taille, tu peux améliorer la localité des données et donc améliorer l'usage des caches CPU, non?

évidemment, il y a un problème de perfs,

Pas si sûr, ça…

Je veux dire, tout dépends du perfs qu'on vise: une lib partagée, ça peut vite bouffer plus de mémoire et de temps au démarrage qu'un IPC. Et puis, si la lib partagée plante, c'est l'appli qui plante, alors qu'avec un IPC type socket unix, ben, on est pas obligé de mourir si le conjoint se suicide à coup de division par 0…

La ou l'on pourrait avoir un boost de performance entre un IPC et une lib GPL (dont on a le source, donc!), c'est si la lib exporte beaucoup de symboles non utilisés par un programme, et que ce programme est le seul à l'utiliser (ça arrive pas si rarement que ça, d'avoir une lib partagée qui ne l'est pas vraiment…).
Dans ce cas, faire un exécutable qui se lie statiquement au code et communique via socket va réduire l'overhead, contourner la licence, et régler le problème d'instabilité voire même de potentielles escalades de droits (et j'ai parlé que de sockets, qu'on peut en plus trimbaler d'une machine physique à une autre, pas de trucs plus poussés ou l'impact de perf est plus réduit).

Bref, considérer le "shared library" comme la panacée, je trouve ça exagéré. Pour moi, il y a un juste milieu entre le multi-processus, les lib partagées, et les libs statiques, qui change en fonction des besoins en blindage, performance et souplesse.

Et ça s'appelle… le télé-travail \o/ (quoique pour le côté écolo, j'imagine que ça se discute, en fonction de la voiture…)

Cela dit, moi, quand on me traite de feignasse, je répond que oui, en effet, et que d'ailleurs, quelqu'un qui est feignasse et qui bosse (donc, à un contrat), y'a de bonnes chances que s'il reste, c'est qu'il est aussi efficace qu'un bosseur…
Pour moi, une feignasse, c'est quelqu'un qui fait un maximum de choses avec un minimum d'efforts. Qualité que je respecte au plus au point, et domaine dans lequel je n'excelle pas assez à mes goûts, vu que je fais parfois bien des efforts pour pas grands résultats… mais, j'y travaille, à optimiser mon temps de travail :)

La liaison (statique ou dynamique, ça n'a pas beaucoup d'importance) d'une bibliothèque fait partie de son fonctionnement normal (et on peut même aller plus loin, c'est même sa seule modalité de fonctionnement).

Alors, juste pour faire mon pointilleux, la glibc6 sur une debian est un exécutable:

% /lib/x86_64-linux-gnu/libc.so.6
GNU C Library (Debian GLIBC 2.24-11+deb9u3) stable release version 2.24, by Roland McGrath et al.
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 6.3.0 20170516.
Available extensions:
    crypt add-on version 2.1 by Michael Glad and others
    GNU Libidn by Simon Josefsson
    Native POSIX Threads Library by Ulrich Drepper et al
    BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.

Bon, de la à dire que ça sert à quelque chose, il y a un pas que je n'oserais franchir hein :)

Plus sérieusement, on peut aussi considérer que de nombreux outils sont en fait des bibliothèques, c'est juste que le "lien" se fait via socket plutôt que par dlopen(): on peut penser notamment à mpd ou, de ce que j'ai cru comprendre, BSD AUTH, checkpwd, …
Au final, je trouve ça étrange à minima que différencier les droits accordés en fonction du moyen technique utilisé pour établir une relation de dépendance totale ou partielle.
D'ailleurs, en parlant de dlopen(), ça marcherait comment avec une lib sous GPL? Après tout, ce n'est pas pris dans l'édition des liens du coup, non?

C'est juste que j'ai l'impression qu'il n'a pas cherché, mais je reconnais avoir été trash, mes excuses.

Debian ≠ Ubuntu

Ha oui, pardon, voici le lien corrigé: http://lmgtfy.com/?s=d&q=debian+python+gi

Cela dit, la plupart des solutions que l'on trouve pour Debian s'appliquent aux *buntu, et vice versa (quand ça concerne un paquet particulier, je veux dire).

Quand on utilise une distribution binaire, on est en droit de s'attendre à avoir des choses qui fonctionnent par défaut, avec cette chose magique qu'on appelle des dépendances.

Franchement, ce n'est pas la première fois que je vois un paquet python mal empaqueté, dans Debian et ses filles. Et ici, il s'avère que pour une fois l'erreur est particulièrement claire, concise et rapide à arriver: il manque le module python "gi", il faut donc l'installer. Si jamais il l'est déjà, alors la, on a un vrai gros problème, mais j'en doute.
Vu que c'est un module avec un nom à la con pour les recherches (2 lettres…), préciser un nom de distribution augmente le nombre de chances de connaître le nom exact du paquet à installer.

Si ça n'est pas le cas, on a peut-être besoin d'apprendre ce que sont les Recommends, qu'on a peut-être désactivés sans savoir quelles seraient les conséquences. Auquel cas, quelques explications s'imposent.

Si un programme ne se lance pas parce que dépendance manquante, c'est un bug, recommends installés ou pas.
Les recommends, ça ajoute des fonctionnalités, ce sont des options. Le programme est censé fonctionner sans elles, mais en offrant moins de fonctionnalités, ce qui offre un système plus léger et au nombre de paquets plus restreint, ce qui permet donc de réduire les emmerdes lors de MàJ, bien qu'il faille apprendre à identifier les fonctionnalités dont on a besoin (la-dessus, le système de paquet dpkg est peu verbeux, dommage).

Ce qui est amusant, c'est que pas mal de dépendances (je pense notamment aux fontes, mais pas que) "Depends" devraient en fait être des "Recommends" ou "Suggests", mais c'est un autre débat, et surtout un choix des empaqueteurs, que je respecte.

Renvoyer vers une recherche web plutôt que vers un gestionnaire de suivi de bogues (peut-être même vers un éventuel rapport de bogue pré-existant), ça n'est pas vraiment pertinent, en plus d'être hautain.

J'avoue.

Inviter à signaler le bogue au bon endroit (quitte à ce que ça soit fermé pour cause d'« erreur utilisateur »), c'est probablement la meilleure chose à faire, non ?

Clairement.
Je ne sais pas s'il est installé par défaut sous Ubuntu (probablement, vu qu'il l'est sous Debian, déjà), mais c'est le rôle du paquet "reportbug", qui guide l'utilisateur dans la construction d'un rapport de bug tout en récupérant les informations utiles (version du paquet concerné, liste des bugs affectant déjà ce paquet, etc etc).

Tant que personne ne s'amuse à faire un code de conduite viral, on pourra s'en sortir :p

Dans CMake, utiliser la macro __FILE__ cause l'inclusion du nom de fichier absolu, ce qui est très pénible et lié au fait que cmake génère une configuration avec des noms de fichiers absolus et non relatifs à la racine du projet.

Comment Meson se comporte-t-il sur ce point?

PS: je le mets ici afin que l'auteur du journal soit notifié, au cas ou il ne suive pas le thread sur la repro.

Debian […] a de bon résultats quand même

Je n'ai jamais dit le contraire, je mettais juste l'accent sur le fait que si c'est déjà difficile pour l'une des distributions qui dispose du plus de contributions (opinions purement et simplement tirée d'une perception erronée de la réalité) alors ça ne risque pas d'être trivial.

une fois que tous les problèmes de reproductibilité seront corrigés (doux rêve)

Ironiquement, et dans le sujet du journal, ça implique de se passer de cmake, puisque ce dernier inclue le chemin absolu vers le fichier source quand on utilise la macro __FILE__, ce qui est extrêmement désagréable (compiler manuellement avec des chemins relatifs résous le problème avec gcc et clang, donc c'est bien la faute de l'outil qui génère le process de build.
De la même manière, la moindre modif de l'endroit où l'on compile implique de devoir reconfigurer… c'est hyper chiant!
Je constate d'ailleurs que j'ai oublié de poser la question, je vais corriger ça de suite. Peut-être que la réponse me plaira.
Et si ce problème est solvable en passant à meson, je pense que je vais au moins switcher mes projets persos dans un 1er temps, puis voire pour le pousser au taf (là ou avoir la possibilité de debug sans devoir squatter le PC ou compiler depuis un chroot (mes collègues ont déjà du mal à faire des commits propres, je vais pas leur imposer ça) serait vraiment une valeur ajoutée…).

Mais garantir la reproductibilité dans le temps avec le flot de modifications qui arrive tout le temps, c'est difficile

Si le source brut change, c'est même impossible. Ce que j'entend par source brut, c'est le source après passage du pré-compilateur, sans les caractères blancs ni les commentaires.

Le rapport avec Yocto, c'est sur les changements de l'environnement de build justement, pas des sources : Yocto rebuild au moindre changement d'environnement d'un soft tout l'OS, ce qui donne des résultats binaires différents à chaque fois car ils ne se concentrent pas sur la reproductibilité.

S'ils se basaient sur des programmes «réputés reproductibles», et s'ils ne s'amusent pas à inclure les données d'environnement ( HOME, $(date), horodatage des fichiers source, ce genre de choses) ça ne devrait pas être insurmontable, tu as bien montré que certains arrivent à avoir une ISO qui est reproductible.

Et l'ironie, c'est qu'ils se basent sur la disponibilité des sources en lignes, en trackant par défaut les derniers git

C'est dommage pour la repro, mais c'est pertinent pour les bugfixes. De ce que tu m'expliques, j'ai l'impression de parler d'une Arch pour l'embarqué en fait. Je suppose que c'est un choix…

http://lmgtfy.com/?s=d&q=debian+python+gi

Je sais que ça peut paraître hautain de juste balancer un lien comme ça, mais la…