freem a écrit 5019 commentaires

Merci pour ces retours.

Malgré que ça me tentait pas mal, je pense que ce ne serait pas le plus pertinent du coup, ou du moins, pas encore, les diverses cartes à piloter me semblent avoir une interface trop hétéroclite du coup.

Trêve de plaisanterie, mais je me dis quand même que 90% des utilisations des forums/listes de diffusion/réseaux sociaux sont possibles en NNTP et çà serait beaucoup plus efficient.

Je ne connais pas Usenet (trop jeune, je suppose) mais à lire rapidement l'article francophone de wikipedia (intéressant pour le coup), je me dis que c'est une sorte d'IRC permanent… je n'en vois du coup pas trop l'intérêt pour un site web, mais effectivement, j'imagine que la plupart des usages seraient réalisables.
Enfin, je ne vois pas trop comment supporter l'édition de contenu (correction de fautes, collaboration autour d'une dépêche, modération… qui sont des fonctionnalités très importantes à mon sens) du fait de la réplication qui expose à des désynchronisation?

Je sais que tu plaisantais, mais je trouve intéressant de chercher à connaître le fonctionnement global des protocoles, et le http(s) everywhere ne m'a jamais paru si pertinent que ça…

Certains citent la phrase à la quel ils répondent

Ce n'est pas toujours possible, ne serait-ce que parce que sur mon tel, il semble m'être impossible de sélectionner du texte hors d'une zone d'édition quand je répond… ça, et les accents qui sont lourds (du coup, à chaque fois, la prévisualisation ressemble à un sapin de Noël, mais j'ai trop la flemme de devoir faire 2s de manipulation pour chaque accent…) dessus.

L'autre cas est quand on répond à un commentaire court dans sa globalité, et non sur un ou deux points précis.

Du coup, la citation en elle-même, même si c'est un outil puissant, n'est ni forcément adaptée ni nécessairement exploitable. Pour le problème que j'ai avec le téléphone, je suppose qu'il «suffirait» d'ajouter un bouton «répondre en citant»?

Sinon, peut-être que l'on pourrait ajouter dans la ligne «Répondre» un indicateur type «message en réponse à […]»? Ça ne me semble toujours pas idéal, et je doute que ça éclaire tant que ça, ceci dit…

… et c'est les evenements qui sont loin, combines au mode fifo de la page d'accueil.
Que l'on soit un reclus ou simplement habitions (en 4D) trop loin d'un evenement, celui-ci ecrase du contenu plus pertinent, qui a plus d'interet general.

Je ne dis pas qu'il n'en faut pas, au contraire, mais ca serait pratique de pouvoir les filtrer, par exemple avec des points sur une mapemonde, et les gens pourraient ensuite cliquer sur les points (bon, ca, ca semble difficile) et que ca ne remplace pas les depeches/journaux intemporels (sortie de soft, debats, …). J'imagine que le plus simple serait une section pour les contenus localises (dans le temps et l'espace?)?

perso, je vois autour de moi plus de disques mecaniques que ssd: question de prix, sans doute.
Tout ceci etant dit, il y a un point qui fait que l'interet de separer le /boot de / n'est pas necessairement pertinent de toute facon: les distrib tendent a installer les modules dans /lib, donc le kernel en lui-meme, ou meme l'initramfs sont inutiles ou presque en stand-alone…
Perso, je pense que du coup le mieux est de juste avoir une partoche qui contiens un bootloader chaine, ce qui est au final ce qui est fait avec les uefi boot (en fat en plus) et laisser le /boot sur le /.
Apres, je ne pense pas avoir rencontre assez de situations pour avoir une idee vraiment precise du probleme.

Quel est l'intérêt d'avoir le /boot en début de disque, au juste?
Le début de disque (mécanique, j'entend), moi, je le réserve aux données qui sont souvent accédées, le /boot, j'ai plutôt tendance à le mettre en fin de disque du coup, parce que j'imagine que le kernel n'est lu qu'une seule fois… je préfère mettre le /usr en début, qui contient tous les programmes utilisés de façon aléatoire et bien souvent à multiple reprises lors de mes sessions.

Je me plante?

Pour avoir utilisé libyaml, le truc utilisé par le module de python, ben, je ne conseille pas d'utiliser ce truc, en tout cas pas si on veut de la performance et de la stabilité…
Je me suis tapé des segfaults que j'ai pu corriger en moins de 4H (patch envoyé à l'époque en même temps que le rapport de bug, je ne suis pas certain que le rapport ait été accepté, vu que le dépôt semblait mort. Du coup, itou pour le patch logiquement). Et non, ce n'était pas un cas d'utilisation à la con, c'était même un truc très simple.
Pour la performance, quand on commence a hijacker malloc pour qu'il alloue toujours au moins 1 octet, ça crains, et dans la pratique, quand mon code tournait, le CPU faisait du malloc de petites quantités de RAM en permanence, et prenait plusieurs minutes pour parser un fichier de quelques kibi octets.

Du coup, j'ai cherché d'autres lib qui correspondraient à mes standards et dont le code me semblait assez propre. Je n'ai rien trouvé de satisfaisant.
Conséquence, j'ai commencé à lire le standard de yaml, et j'ai compris l'état de l'existant: certes, le yaml, c'est joli et lisible… mais une horreur à traiter, les règles sont floues et multiples et de mémoire, le comportement quand on rencontre un token dépend du contexte…

En Python, les MemoryError en sont de bons exemples. Même si dans 99.9% des cas, cette erreur n'est lancée que si l'utilisateur fait quelque chose d'incorrect, elle peut techniquement se produire dans n'importe quelle opération.

Voir ne pas se produire du tout et avoir l'OOM killer qui entre dans la danse sur pas mal de distributions basées sur Linux, vu que par défaut sur Debian, le kernel est optimiste et considère que les applications n'ont pas besoin de toute la mémoire qu'ils réclament.

Je la trouve assez limitee, cette chanson, je prefere de loin open source de magic mushroom. Pas le meme style musical, certes, mais pourtant j'aime beaucoup le punk, donc ca viens pas de la. Ceci dit… tiens, une question, la chanson est-elle open source?

Je suppose que ca a ete verifie, mais, ton user sous mageia a-t-il acces aux fichiers contenant la bdd?

Sans lire la discussion, laisses moi deviner quelques problemes:

• les exceptions n'ont pas d'ABI stable
• qt necessite une surcouche a make

Bon, je t'avoue que, d'un autre cote, j'aurais bien apprecie une ihm non basee sur gtk, parce que, ma foi, j'ai en horreur le widget d'exploration de fichiers de gtk, je prefere voir les chemins reels (non traduits donc) et complets, avec par defaut soit le dernier dossier utilise par l'appli, soit le $HOME.
Mais c'est 1) hors sujet, 2) parce que j'aime avoir le moins de trucs caches possibles et 3) peut-etre lie a la config par defaut de ma distrib (debian a un packaging et une conf par defaut assez douteux sur certains points)…

Bref, quels toolkits graphiques sont utilisables en rust, au final?

pourquoi wpa_supplicant est-il le pire?
Est-ce juste sur ce point ou de maniere generale?
Il y aurait des outils alternatifs portes sur les plus gros os "posix" (dans mon cas linux, mais vu que j'ai l'intention un jours de passer a net ou open bsd…)?

Desole pour les questions, mais moi et la secu, ca fait malheureusement 2, si ce n'est plus…

ce sont les dependances qu'il faut regarder, la barre rouge n'indique que si un paquet a un probleme en se basant sur les numeros de version, hors tu as plusieurs sources: il n'est donc pas impossible que certaines sources te fournissent un numero de version compatible, mais dont l'ABI (https://fr.m.wikipedia.org/wiki/Application_binary_interface) ne l'est pas. Ce genre de probleme est delicat a regler (y compris sous windows pour le coup) surtout pour un debutant. L'usage de kali n'est peut-etre pas etranger au probleme, je ne serai pas surpris que leurs paquets ne soient pas tout a fait compatibles avec ceux de debian (et donc probablement des autres sources que tu as ajoutees) surtout pour des choses liees a la securite (ici, le chiffrement).

sinon, tu peux aussi temporairement installer un autre explorateur de fichiers, le temps de resoudre ce probleme (de preference un qui ne soit pas base sur gtk ou gnome, ca reduirait le risque de problemes d'ABI)

j'ajouterais comme question: aucune info dans les logs de xorg (ou dans le tty duquel est lance xinit)? Peut-etre aussi un probleme de focus lie a i3 (ou une application qui aurait trouve le moyen de recup certains evenements clavier, on sait jamais) vu que l'ot specifie qu'il lui faut bouger la souris?

Le plus simple a mon avis serait de passer par aptitude (dans un terminal. Sans arguments il lance une interface semi graphique assez utilisable) puis d'aller selectioner nautilus et afficher les details (touche entree): en bas il y a la liste des dependances, parmi elles, l'une aura un nom proche de ton erreur, aller dedans, et tout en bas il y aura la liste des versionsaccessibles par le reseau, tu peux donc upgrade/downgrade par la.

je suis pas tres clair mais fatigue…

Bizarre ton truc, on dirait que c'est la mauvaise version de la lib qui est installee… du coup essaies de reinstaller les dependances (via aptitude par exemple) a une autre version (aptitude permets de downgrader les paquets, s'ils sont encore connus).
Si pas possible, tu peux regarder dans /var/cache/apt/archives et essayer de downgrade manuellement avec dpkg.

Par curiosite, ca a pete apres une MaJ? Tu as peut-etre configure d'autres sources, et des depots seraient en conflits?

Tout est dans le titre.

De memoire, la commande pour configurer les touchpads, c'est synclient, qui peut activer ou desactiver le touchpad en lui passant quelque chose du style que tu as poste

C'est d'ailleurs ecrit dans le message d'origine: 125 secteurs morts, ca veut dire soit que le hdd est en fin de vie, soit qu'il a pris un choc qui en a endommage une partie.
Dans tous les cas, reussir a installer serait de toute facons s'exposer a des emmerdes en cascade plus tard.

Je ne rebondissait que sur le fait que l'on ne pouvait souvent faire les choses que d'une maniere en C et posix. Ce qui, a mon avis est faux (mais comme je l'ai dit, je ne suis pas expert en C ni en posix, il me reste tant a apprendre).
Pour le reste, le seul langage anterieur a C que je connaisse est l'asm intel 16 (et un peu 32 donc pas sur de l'anteriorite) bits… meme pas en fait, je sais pas qui est le1er né. Du coup, savoir pourquoi C s'est impose m'est impossible. Je suppute que son gros avantage etait justement qu'il n'etait pas trop bas niveau pour l'epoque (par exemple compare a l'asm), portable et efficace (pas trop de couches intercalaires pour faire le moindre truc). Mais…ca reste supposition de ma part, et j'ai pas envie d'apprendre le B rien que pour le decouvrir :)

Pour ce qui est des binaires perdus, liberer pourrait etre interessant aussi, parce que meme sans l'original, il est souvent relativement simple de recuperer les ressources (surtout quand le format est utilise dans un code dont on a les sources, et puis, ca manque tres souvent).
Pour ce qui est du code, c'est nettement plus complexe, mais je crois avoir souvenance que l'auteur de keeperfx (un… euh, comment dire… fork a partir du binaire de dungeon keeper) a une methode qui permets un portage progressif.
Bon, faut etre cale, surtout dans son cas qui est de la recup de binaire DOS (pas PE j'imagine donc, probablement du code mode reel?), et avoir du temps, mais vu que le repreneur ici a des sources liees (autres versions du meme moteur, ou petites lib internes, que sais-je?) y'a p'tet moyen via des outils tels qu'IDA de retrouver une partie non negligeable. Ce serait cela surement un travail de titan, j'imagine. C'est deja super de liberer et porter ces vieux codes!

Au sujet du static link, je pense que pour un dev isole c'est mieux: au moins tu es sur que tu n'auras pas de libs manquantes au runtime, et en plus il n'est pas ilpossible que le binaire soit plus performant ainsi (cf les opinions des dev de suckless, entres autres. La mienne, c'est que le full dynamic c'est pas vraiment pertinent, surtout quand on utilise des trucs genres exceptions ou methodes virtuelles).

Ok pour les I/O, mais le souvent couvre-t-il aussi les calculs alors? Par exemple les divisions par puissances de 2?
Ou l'acces a la memoire, que tu consideres le role principal du C (pour moi, le role de C n'est pas de manipuler la memoire, mais de faire des programmes portables et performants qui font quelque chose, peu importe quoi, l'acces memoire etant un moyen, non une fin)?

Pour ce qui est de la "double API"… d'un cote y'a posix (et non unix, qui est un OS, pas un standard) de l'autre C, ce sont des outils differents, et ce point (les acces aux fichiers) se comprends facilement: open est bas niveau, moins portable que fopen (puisque pas forcement implemente par les os non posix), et plus souple. Bref, ce ne sont pas des doublons.

Au final, j'ai l'impression que tu te concentres sur des details d'implementation pour dire qu'on ne peut faire les choses que d'une facon avec ces outils… tiens, un exemple de plusieurs facons de faire un truc avec posix: effectuer plusieurs choses en "meme temps". Multi-thread ou multi-process. Pour communiquer? Entre la memoire partagee, les sockets et les signaux, y'a du choix.
Certes, il y a de grosses differences entre leurs roles et capacites (surtout pour les signaux, pour lesquels envoyer un message complexe necessiterait enormement de code, vu que je ne crois pas qu'il soit possible d'attacher une info, mais c'est faisable, en construisant un systeme qui utiliserait un signal pour envoyer 1, un autre pour les 0… ce serait moche, oui, mais faisable a priori) mais le point est la: ces outils permettent d'echanger des messages.
Tiens en parlant de sockets: poll, epoll, select ou eselect? Ces fonctions font la meme chose, avec diverses limitations ou avantages.

Voila qui devrait aider a ce que tu comprennes mes doutes.

Plutôt un conjugaison nazi du coup, non?

avec PAM

Du coup, complètement hors sujet, mais PAM, c'est quoi, en vrai, l'intérêt de ce truc?
J'ai vaguement compris que c'est censé être une lib pour gérer la sécurité, mais ça m'a toujours eu l'air vachement complexe et lourd, un peu trop peut-être pour être vraiment sûr? Il y a des gens qui utilisent vraiment ce truc? Je veux dire, volontairement, en dehors du fait que ce soit installé par défaut sur la distribution… j'ai cru comprendre que certaines (slackware, pour ne pas la nommer) s'abstenaient de l'utiliser?

Bon, tu ne sais peut-être pas, mais vu que tu en parles je me suis dit que tu avais essayé de comprendre le fonctionnement de ce machin :)

les concepts d'Unix et de C sont simples et élégants, il n'y a souvent qu'une seule façon de faire chaque chose

On ne doit pas connaître le même C alors. Affichage de chaînes de caractères: printf, puts. Idem pour la lecture.
Définir un bloc de code réutilisable, entre les macros et les fonctions, on a aussi plus d'une façon de faire.
Passer plusieurs données à une fonction? Variadic arguments, pointeurs sur listes.
À l'origine, il était aussi possible de ne pas déclarer le type de retour des fonctions si on retournait un int…

Du coup, une seule façon de faire les choses en C… mouai.

Pour UNIX, je ne connais pas assez l'API des kernels pour juger, mais je doute fort que les choses ne puissent se régler que d'une seule façon.