Oui dans un monde parfait ils le ferraient pour l'amour du hacker, mais je suis d'avis qu'on est pas dans un monde parfait.
Idem. Sauf que si ils ont été en position de force face à IE, je doute que çe soit grâce à l'amour que leur porte les utilisateurs normaux.
Ce n'est pas une question d'amour, c'est une question de cible commerciale. Je pense que leur cible à changé, très bien, mais qu'ils ne viennent pas ensuite pleurer que leur public initial va voir ailleurs s'il y a plus adapté.
Leur code horrible a […]
Pour que ça soit clair, je n'ai pas regardé depuis des années, si ça se trouve c'est maintenant propre comme un sou neuf, modèle d'ingénierie et de doc, grâce notamment aux ajouts de servo.
Plus sérieusement, ils ont forcément du clean/documenter un peu, sinon je n'ose imaginer les coût de la moindre intégration/évolution/correctif…
Le projet Debian n'a rien à voir. […]
Pas faux. C'est juste le 1er qui me soit venu à l'esprit, mais tes exemples (linux, gcc) sont effectivement bien plus pertinents.
J'ai envie de dire qu'on pourrait ajouter clang à l'équation, mais vu que ça semble, justement, pas mal modulaire (et je pense qu'ils dament le pion à gcc, aussi, même si, en tout cas pour C++, ça me semble moins critique maintenant qu'il y a quelques années), peut-être pas :}
Si Mozilla galère depuis des années à se financer ce n'est pas pour rien.
Le code est horrible, ce qui empêche les contributions de développeurs non spécialisés (dans FF, je veux dire) et freine les bugfix.
La volonté ne semble pas être d'avoir le moteur de rendu simple à exporter. Si c'était le cas, le couplage logiciel serait plus faible, la maintenance plus aisée (les frais de dev moins élevés).
Corriger ces points (tant dans la politique que dans la technique (migrer vers)) avec une preuve (par exemple en implémentant un truc du genre uzbl) qu'il y a cette volonté (parce que plus personne ne crois en eux, à juste titre) plutôt que de lancer de nouveaux projets ciblant la masse permettrait de réduire le coût de maintenance et de récupérer les contributions de développeurs en dehors de mozilla: les hackers, la force originelle du logiciel libre.
Parce que l'utilisateur lambda, il voit juste le côté 0€, faut pas se voiler la face.
Je ne reviendrais pas sur la paye des dirigeants, non plus, ça a été assez fait.
Garder la dynamique pour implémenter les standards et assurer la sécurité sur Firefox desktop et mobile ça prend un temps fou.
Oui, parce que justement, il serait temps d'«unfuck the web», mais oui, ça coûte, et c'est même dangereux. Surtout quand on a une réputation de merde et que plus personne n'est dupe.
Des projets communautaires de ce genre d'envergure existent, mais ça ne se crée pas facilement ni rapidement.
En effet, ça existe. Je pense à Debian, perso, mais ils ont sûrement des subventions d'entreprises. Par contre, leurs principaux frais semblent être structurels: location des machines et trucs de ce genre.
Je me demande si un projet de navigateur web sain d'esprit et fonctionnel (il n'en existe aucun actuellement) pourrais également recevoir des subventions d'entreprises… probablement, ne serait-ce que les entreprises qui font des équipements de rue et ont donc besoin d'un truc facile, stable et léger pour exposer des interfaces graphiques faciles à programmer (ou a trouver de la main d'oeuvre pour faire): des «ihm» web (j'écris ça avec beaucoup de dégoût, mais la réalité est la).
Tiens, c'est marrant, justement «un uzbl» serait susceptible de plaire pour ce type d'usage.
Et c'est très difficile de se rattraper sur un sujet aussi concurrentiel.
Évidemment. Surtout quand on s'est contenté de copier les autres sans jamais innover.
Je suis bien d'accord, et c'était justement mon point.
D'ailleurs, il faut savoir qu'une instance de runsv compilée avec musl (ou gcc en statique) consomme 4Kio de mémoire résidente, contre pas loin de 765 pour glibc (de debian 10), idem pour svlogd.
J'ai fait mes mesures, parce que ça m'amuse, surtout.
Et malgré ce 1.5Megs par daemon géré par runit, il faut plusieurs 10aines de daemon pour arriver au même niveau de consommation mémoire que systemd, une fois celle-ci divisée par le nombre de processus.
Je trouve aussi plus fiable, d'un point de vue architecture logicielle, d'avoir les daemons et leurs logs gérés par 1 ou 2 processus par daemon que l'approche de systemd, qui gère toutes ces instances dans le PID1: au moindre problème, PID1 de systemd pourrais mener à un kernel panic (plus d'init), ce qui est bien moins probable avec l'empilement de processus générés par runit (et les autres daemontools).
L'inconvénient de runit, comparé à systemd, c'est que 1) faut connaître un peu le shell (bon, sur 5-10 lignes, souvent, ça va…) et 2) "thundering herd problem", pas de vraie gestion des dépendances, et ça, c'est très chiant. En vrai, c'est la seule force non-contestable de systemd, je pense, vu que le côté déclaratif (systemd) vs un langage de script simple (runit avec dash) voire un DSL (nosh), c'est je pense assez subjectif (même si l'approche de systemd me plaît bien!).
Dans mes scripts pour runit, je source un fichier contenant, entre autres, ces lignes:
#parce que runsv redirige stdout vers les logs, pas stderrexec2>&1exec <&-
# permets que les logs contiennent ce qu'il se passe dans le scriptset -xe
À priori, je n'ai pas encore eu de soucis avec ça, mais dis-moi si tu penses que ça règle ce souci sans en exposer d'autres?
Je suis assez d'accord sur le fait qu'écrire des scripts pour gérer la supervision d'un système est casse-gueule, et je sais que runit à ses défauts (comparé à systemd), mais j'aimerai me rendre compte moi-même a quel point c'est vrai.
Et quand ça sera fait, je passerai probablement à nosh qui est dans la même logique que runit, mais peu importer les unit de systemd et inclue le plus gros avantage de systemd: la gestion des dépendances. Je ne le fais pas uniquement par flemme, pour l'instant…
Posté par freem .
En réponse au journal Linux ne m'intéresse plus.
Évalué à 5.
Dernière modification le 14 décembre 2020 à 14:50.
Foutaises. Le shell deviens horrible dès qu'on passe les 100 lignes.
Ok, j'exagère (je me moinsserai bien la). Déjà, c'est bash, et pas shell, donc on ne sait pas sur quel standard le script s'assieds. Pour un service critique. Ouch.
Ensuite, il est possible de faire des scripts de plus de 100 lignes qui sont maintenables, certes. Mais ce n'est pas le cas de la plupart de ceux que j'ai lus, et j'y inclue les miens.
Il n'y a pas non plus de véritables outils d'analyse statique pour le shell (contrairement au C, C++, Rust, etc), ce qui est un problème pour un script critique à mon avis, et pour l'analyse dynamique, idem, j'en connais pas, mais je suppose qu'on peut toujours essayer de jouer la carte du fuzzing…
Our rc.d does come with a few obvious deficiencies like not being able to always match a specific daemon when several occurrences are running (due to its process list being too generic, e.g. with a privilege separated daemon: “syslogd: [priv]”)…
Donc, les mecs en 2016 ont recodé un superviseur en shell, qui n'est même pas foutu de faire ça, alors qu'il existe daemontools et ses héritiers qui existent depuis presque 2 décennies et font très bien le job? NIH?
That said, regular Bourne shell is easy to read and write
Foutaises. Le shell deviens horrible dès qu'on passe les 100 lignes.
J'allais me log pour, justement, citer claws-mail quand j'ai lu les 3 alternatives…
Bref, je plussoie pour claws-mails, ceci étant dit, il m'est arrivé d'avoir des crash ou des freeze du MUA, et il «ne gère pas correctement le protocole non-standard utilisé par gmail».
Les guillemets devraient indiquer clairement ce que je pense à ce sujet…
À ma connaissance, il n'y a pas non plus de plugin fonctionnel pour la gestion des rendez-vous (caldav je crois?), et je n'ai jamais encore essayé d'y intégrer ldap, mais pour ces points la, il n'y a probablement que thunderbird qui peut avoir ce genre de trucs… et encore, c'est pas sûr.
Bref, je plébiscite également claws-mail. Seul inconvénient (à mes yeux): son interface nécessite l'usage de la souris.
Ah. Et, tant que j'y suis: claws-mail ne supporte pas dbus, ce qui implique qu'il faut un module pour avoir des popups quand on reçoit un mail. Ou alors, bien plus clean, utiliser "Éxécution d'une commande si du courriel arrive" pour être notifié.
J'y tiens, parce que du coup ça s'intègre a merveille dans les environnements de bureau légers et autres assemblages de WM + file browser + terminal +…
Si mozilla meurt, firefox mourra-t-il réellement? C'est un logiciel libre, qui a toujours son public, dont certains semblent être ok pour financer…
Si le public existe réellement, et est prêt à mettre la main à la poche, pourquoi ne pas forker à la fois le logiciel et l'organisation?
Certes, l'image, le porte-feuille client et les accords commerciaux (avec google) ne peuvent être migrés, du coup ça demanderais certainement un gros investissement personnel des contributeurs, mais bon, c'est faisable non?
Le résultat serait peut-être, au final, plus respectueux de la vie privée, plus proche d' «unfuck internet», par exemple en cessant de retirer le support des protocoles non-web?
Bon, perso, je n'utilise firefox que pour certains sites qui déconnent sec avec vivaldi. C'est sûr que ça serait chiant que Firefox disparaisse, mais juste parce que ça voudrait dire qu'il ne resterais plus que blink et webkit comme moteurs de rendu, ce qui aurait peut-être pour conséquence d'avoir un web qui se barre encore plus en couille (m'enfin, vu comment c'est partit de toute façon, la différence est-elle vraiment si énorme?).
Pour macOS, un système de base sans aucune applications ouvertes a déjà plus de 450 processus et 2Go de RAM utilisé…
Je répond a cette section histoire d'avoir une citation, mais je pense que ce que je vais dire s'applique à l'ensemble des systèmes d'exploitation.
Mac OS (ou windows, ou KDE, ou gnome) peut et même doit avoir une chiée de processus, parce qu'il doit être capable de s'adapter à un écosystème bordélique d'objets connectés et intelligents, absolument pas gérés par leur propriétaire.
Il faut que tout soit automatique, que tout soit plus intelligent que l'utilisateur, parce que sinon «c'est trop compliqué».
Et ça ne me choque pas.
Je pense personnellement qu'une distribution ne peux pas tout faire et le faire correctement, ou du moins, pas sans un effort non négligeable de l'utilisateur, à la fois en terme d'apprentissage et en terme de concession.
Si en plus on parle de distros maintenues principalement par des volontaires (Debian, slackware, archlinux, gentoo…) il me paraît déconnant d'espérer que ça colle aux besoins réels «locaux» sans s'investir un minimum.
Quant aux systèmes faits par des entreprises, hé bien, c'est pareil. Elles ont une cible, et vont plus oeuvrer à satisfaire la cible dans sa globalité qu'un petit groupe de barbus qui veut du simple et du bas niveau. De tout façon, s'ils voulaient vraiment ça, rien ne les empêcherait de le faire (c'est ce que font les mainteneurs de crux, de kiss, de slackware, au final, non?).
Pour info, mon système minimaliste nécessite 3 processus vivants par daemon: le daemon lui-même, une instance de runsv (le watchdog) et une instance de svlogd (les logs, que je ne consulte jamais en plus).
J'ai, à la louche, une 10aine de daemons (ttys, udev, clients dhcp, acpid, cups (tiens, faut que je lui fasse un runscript à lui d'ailleurs), ce qui est très peu.
Ensuite, il y a mon bureau. Et la, c'est le drame: mpd, xinit, xorg, claws-mail, quassel, unclutter, ssh-agent, urxvtd, xosview, une chiée de zsh… (faut que je pense a mettre les plus important sous watchdog d'ailleurs) mais en fait, ça va encore.
Ce qui est pire que le drame, c'est la Bérézina, j'ai nommé les clients web: vivaldi à un "score" de 60 dans pstree -p | grep vivaldi | wc -l. Firefox avec un seul onglet: 73.
Tout ça, en ajoutant les lignes du kernel, ça me fait 158 lignes dans mon ps. C'est un système minimaliste, qui ne fait quasiment rien automatiquement, inutilisable par «le commun des mortels».
Donc, 450 process pour macOS qui à pour cible l'utilisateur qui veux juste utiliser son outil (tournevis?) sans se prendre la tête? Ça me choque pas.
Ce qu'il faut, ce sont des distro qui soient adaptées a ces usages de niche que sont le hobby et la récup de vieux systèmes par les gens que ça intéresse.
Dans l'ensemble, je fais comme toi, je dirais. Enfin, j'évite aussi tout ce qui est basé sur electron.
Tu utilises quoi, en lieu et place de systemd?
Par exemple, j'utilise simple-scan
Ah, faudra que je teste. J'utilise xsane, et, bon, on va dire que l'IHM est quand même bien moche, même s'il fait plutôt bien le boulot et crash en l'absence de dbus installé.
l'appli stagne une bonne minute avant de s'afficher, evince me fait le coup aussi.
Pour les pdf, j'utilise mupdf en général, mais je commence a passer a zathura, parce que les limitations de mupdf sont… pénibles (le scroll page par page, c'est pas super pratique…).
Pour tes problèmes de lenteurs, vérifies que tu as bien ton hostname dans le fichier /etc/hosts, pas juste localhost. J'ai déjà vu le cas de saloperies (hein, sudo?) qui font des requêtes DNS pour on ne sait trop quoi (je serais pas surpris que les trucs qui utilisent dbus le fassent aussi, après tout, ce machin sert notamment à pouvoir identifier de manière unique ta machine… pourquoi? Bonne question…)
J'ai longtemps utilisé lilo aussi, mais plutôt que d'utiliser grub, je préfère [sys|ext|iso|pxe]linux. C'est un poil plus compliqué à configurer que lilo, mais pas de hack sale comme grub qui requiert une partition rien que pour sa gueule en gpt, et en bonus, c'est très souple, ça fait vraiment tous les types de boot que j'ai pu rencontrer.
Bons choix de couleurs et de police sérif ou semi-sérif je sais plus, rendant la chose moins archaïque.
Merci, vais tester ça, même si j'admets que le fait que kristall supporte plusieurs plus de protocoles est une sacrée plus-value, notamment du fait que je ne suis pas super convaincu par gemini.
Je viens de compiler la chose, et il faut bien reconnaître que pour un soft basé sur la SDL, c'est impressionnant!
Gemini… autant revenir aux newsgroups. J'ai des sites HTTPS enrichis qui se chargent plus vite que la majorité des hôtes gemini.
Je suis intéressé. Tu peux nous indiquer des URIs d'exemple?
C'est sûr, ça peut marcher (ça serait génial, que celui-ci marche: un OS avec un code tout propre, tout frais, à base de µkernel!). Ça donnait quoi, la concurrence à l'époque?
Pour moi, c'est plus des instructions machines que t'injectes mais bon, je m'amuse pas a exploiter des buffers overflow tous les 4 matins donc j'ai sans doute des lacunes dans le domaine.
Je ne suis pas non plus expert, mais bon, faire appeler la fonction system() à un processus (qui ne l'appelle jamais dans le code) en se démerdant pour lui passer la bonne commande, c'est bien une injection de code, non?
Concrètement, les injections de code, c'est rendu possible par la mauvaise gestion de l'entrée. Que ça soit un buffer overflow ou "un simple oubli d'assainir", c'est la même chose: on détourne l'exécution.
À noter que, il y a peut-être un point sur lequel rust encourage de manière effective la sécurité à ce niveau: il encourage l'édition de liens statique, donc on ne peux pas exploiter LD_PRELOAD :p
Je pense que la grande majorité des soucis […] DDOS […]
Mais moi aussi.
Sauf que moi, je ne précise pas "DDoS". Juste, la grande majorité. Combien de failles font partie de l'OS, comparé au nombre de failles provenant d'une application tiers?
Et quelle est la complexité des services rendus par l'OS quand c'est le cas? Parce qu'un windows qui expose un AD, il ya de bonne chances qu'il soit troué, oui. Par contre il permets un partage de fichiers et d'imprimantes simple à utiliser et administrer (comparé à du FTP/http/NFS, notamment grâce aux ihm), la synchronisation des horloges, des utilisateurs, des configurations système (avec les GPO)!
Et dans tout ça, les failles que je lis dans Misc (parce que le sujet m'intéresse un peu, donc quand je prend le train j'essaie de prendre un misc magazine pour la route, même si le niveau est trop haut pour moi, je comprend quelques trucs et j'apprend beaucoup) sont pas nécessairement des buffer overflow ou des problèmes de C, mais bien des problèmes de configuration par les admins!
cela reste une motivation légitime (même si certains la trouveront futile).
C'est la meilleure des motivations, et un excellent moteur pour faire du code de qualité. Quand on se fait chier, on est moins concentré, et la qualité s'en ressent. Hors, faire du code de merde ultra-sécurisé, moi, je n'y crois pas une seule seconde.
Sur tes mesures, j'ai compris dans les grandes lignes comment tu as pu ressortir ces chiffres mais est-ce qu'ils ont réellement une pertinence ?
C'est déjà plus pertinent que de dire "y'a cette faille" sans mettre de comparatif à côté :)
Sinon: non, c'est pas pertinent, parce que ces chiffres sont bruts, on ne sait pas facilement si le système affecté est bien dans un OS précis (freebsd,openbsd, debian/kLinux, debian/kHurd, windows NT4, etc) ou par un logiciel tiers.
On ne sait pas non plus si les gens qui ont écrit le code s'en torchent ou pas, de la sécurité et de la stabilité, et je pense que le langage est largement secondaire comparé à l'outillage et les procédures mises en places pour gérer les bugs: analyse statique, preuve de coq pour les plus matheux, test unitaires, fuzzing, etc.
Hors, dans ce cas, on parle de jeter l'histo des correctifs de bugs de plusieurs centaines d'applications pour réimplémenter dans un langage qui lave plus blanc que blanc… enfin, c'est l'impression que ça me donne quand les gens en parlent.
La vrai question serait plutôt : est-ce que les garantis de sécurité de Rust qui ne sont pas disponible dans C sont suffisamment pertinentes pour le remplacer ?
Ajoutes la question: est-ce que les garanties qu'offre un langage non standardisé, ne disposant que d'une seule implémentation de compilateur, sont assez pertinente pour écrire un OS qui prétend remplacer les distributions GNU/Linux, et on aura un meilleur débat :)
Je t'avoues avoir juste grep le bloc… par contre, on reviens sur ce que je dis plus haut:
4701: touche "IBM DB2 for Linux, UNIX and Windows (" donc un logiciel tiers ne faisant partie d'aucun de ces OS (d'aucun OS peut-être?)
8249: "the Pulse Secure Desktop Client" m'a tout l'air d'être proprio, donc si ça fait partie d'un OS, lequel? Pas Debian/kLinux ni voidlinux en tout cas.
28575: Trend Micro ServerProtect… bref, j'ai besoin de continuer?
Redox-os embarque des outils en C, c'est dans le journal: netsurf. La différence, c'est qu'ici, netsurf est considéré comme partie de la distro, de l'OS. Ces outils peuvent peut-être aussi tourner pour redox-os, et si c'est le cas, comment le fait que la plupart de l'OS soit écrit en rust aide en quoique ce soit?
Pourquoi ça ne serait pas comparable? Ici on ne parle pas de développer juste un noyau, mais un système d'exploitation complet. Basé, justement, sur un micronoyau, dont le fonctionnement se base sur des architectures client-serveur en grand nombre.
Perso, je me dis que ça serait très dommage de nos jours de limiter les IPC à une et une seule machine, alors que de plus en plus de monde dispose d'un PAN.
Dans les cas que j'ai cités, c'est du texte, mais le plus important c'est que ce sont des messages réseau.
Et une application qui ne souffre pas de problèmes de mémoire peut malgré tout avoir des problèmes de concurrence, qu'un langage ne pourra jamais résoudre car liés à des problèmes d'interaction avec les autres machines ou juste d'autres processus.
Tiens, d'ailleurs, c'set quoi leur système d'init? Non parce que s'il est inspiré de sysVinit et RC, avec cette gestion des fichiers de PID bien foireuse, ben, c'est balo pour la sécu :) (je me doute qu'ils ont fait un truc plus propre, mais je suis curieux malgré tout).
Bref, un bug ou une faille réseau, parfois, ça peut déclencher des problèmes de mémoire, mais je doute vraiment que ça soit l'élément le plus fragile de nos jours.
Dans le thread, il y a une liste des failles liées à la mémoire. J'ai fait quelques "mesures": chercher un mot clé, tout copier, balancer un xclip -o | grep '^CVE-2020' | wc -l et j'ai trouvé ça (la méthodo est foireuse, je sais):
buffer overflow: 421 lignes
injection: 763
Parser? 93.
Parsing? 205.
Toujours pas convaincu? Denial of service: 1067.
Donc oui, ok, les buffer overflow et problèmes de mémoire existent, c'est indéniable, mais je trouve que c'est limite négligeable comparé au reste, d'une part en nombre, et d'autres part en facilité d'exploitation: encore une fois, amuses-toi a exploiter un buffer overflow, avec les symboles des lib partagées chargés à l'exécution au hasard… oh, justement!
Les lib partagées… rust, ça encourage pas le static linking, justement? Ça rend ce type de protection plus compliquées à mettre en place, j'imagine.
Et leur kernel, il supporte les mécanismes de type ASLR? Parce que sinon, rust c'est safe… lol?
Perso, j'ai rien trouvé.
Dans celles-ci (les failles de buffer de 2020), je n'en vois aucune liée à linux ou bsd (grep n'a rien trouvé). Donc, aucun noyau libre ici. Ça cause pas mal d'apple, mais difficile de dire si c'set le noyau ou… un serveur (redox: µkernel, tout plein de serveurs…).
[^] # Re: Est-ce vraiment un danger?
Posté par freem . En réponse au lien La santé balbutiante de la fondation Mozilla menace Firefox. Évalué à 3.
Idem. Sauf que si ils ont été en position de force face à IE, je doute que çe soit grâce à l'amour que leur porte les utilisateurs normaux.
Ce n'est pas une question d'amour, c'est une question de cible commerciale. Je pense que leur cible à changé, très bien, mais qu'ils ne viennent pas ensuite pleurer que leur public initial va voir ailleurs s'il y a plus adapté.
Pour que ça soit clair, je n'ai pas regardé depuis des années, si ça se trouve c'est maintenant propre comme un sou neuf, modèle d'ingénierie et de doc, grâce notamment aux ajouts de servo.
Plus sérieusement, ils ont forcément du clean/documenter un peu, sinon je n'ose imaginer les coût de la moindre intégration/évolution/correctif…
Pas faux. C'est juste le 1er qui me soit venu à l'esprit, mais tes exemples (linux, gcc) sont effectivement bien plus pertinents.
J'ai envie de dire qu'on pourrait ajouter clang à l'équation, mais vu que ça semble, justement, pas mal modulaire (et je pense qu'ils dament le pion à gcc, aussi, même si, en tout cas pour C++, ça me semble moins critique maintenant qu'il y a quelques années), peut-être pas :}
[^] # Re: combien faut-il de frontend réseau pour configurer le réseau?
Posté par freem . En réponse au lien Combien faut-il d'utilisateurs de GNU/Linux pour changer une ampoule ?. Évalué à 3.
1 seul: windowsDWsystemd
/me suit vieille_moule
[^] # Re: Est-ce vraiment un danger?
Posté par freem . En réponse au lien La santé balbutiante de la fondation Mozilla menace Firefox. Évalué à 2.
Voyons ça:
Le code est horrible, ce qui empêche les contributions de développeurs non spécialisés (dans FF, je veux dire) et freine les bugfix.
La volonté ne semble pas être d'avoir le moteur de rendu simple à exporter. Si c'était le cas, le couplage logiciel serait plus faible, la maintenance plus aisée (les frais de dev moins élevés).
Corriger ces points (tant dans la politique que dans la technique (migrer vers)) avec une preuve (par exemple en implémentant un truc du genre uzbl) qu'il y a cette volonté (parce que plus personne ne crois en eux, à juste titre) plutôt que de lancer de nouveaux projets ciblant la masse permettrait de réduire le coût de maintenance et de récupérer les contributions de développeurs en dehors de mozilla: les hackers, la force originelle du logiciel libre.
Parce que l'utilisateur lambda, il voit juste le côté 0€, faut pas se voiler la face.
Je ne reviendrais pas sur la paye des dirigeants, non plus, ça a été assez fait.
Oui, parce que justement, il serait temps d'«unfuck the web», mais oui, ça coûte, et c'est même dangereux. Surtout quand on a une réputation de merde et que plus personne n'est dupe.
En effet, ça existe. Je pense à Debian, perso, mais ils ont sûrement des subventions d'entreprises. Par contre, leurs principaux frais semblent être structurels: location des machines et trucs de ce genre.
Je me demande si un projet de navigateur web sain d'esprit et fonctionnel (il n'en existe aucun actuellement) pourrais également recevoir des subventions d'entreprises… probablement, ne serait-ce que les entreprises qui font des équipements de rue et ont donc besoin d'un truc facile, stable et léger pour exposer des interfaces graphiques faciles à programmer (ou a trouver de la main d'oeuvre pour faire): des «ihm» web (j'écris ça avec beaucoup de dégoût, mais la réalité est la).
Tiens, c'est marrant, justement «un uzbl» serait susceptible de plaire pour ce type d'usage.
Évidemment. Surtout quand on s'est contenté de copier les autres sans jamais innover.
[^] # Re: moi c'est l'inverse
Posté par freem . En réponse au journal Linux ne m'intéresse plus. Évalué à 4.
Je suis bien d'accord, et c'était justement mon point.
D'ailleurs, il faut savoir qu'une instance de runsv compilée avec musl (ou gcc en statique) consomme 4Kio de mémoire résidente, contre pas loin de 765 pour glibc (de debian 10), idem pour svlogd.
J'ai fait mes mesures, parce que ça m'amuse, surtout.
Et malgré ce 1.5Megs par daemon géré par runit, il faut plusieurs 10aines de daemon pour arriver au même niveau de consommation mémoire que systemd, une fois celle-ci divisée par le nombre de processus.
Je trouve aussi plus fiable, d'un point de vue architecture logicielle, d'avoir les daemons et leurs logs gérés par 1 ou 2 processus par daemon que l'approche de systemd, qui gère toutes ces instances dans le PID1: au moindre problème, PID1 de systemd pourrais mener à un kernel panic (plus d'init), ce qui est bien moins probable avec l'empilement de processus générés par runit (et les autres daemontools).
L'inconvénient de runit, comparé à systemd, c'est que 1) faut connaître un peu le shell (bon, sur 5-10 lignes, souvent, ça va…) et 2) "thundering herd problem", pas de vraie gestion des dépendances, et ça, c'est très chiant. En vrai, c'est la seule force non-contestable de systemd, je pense, vu que le côté déclaratif (systemd) vs un langage de script simple (runit avec dash) voire un DSL (nosh), c'est je pense assez subjectif (même si l'approche de systemd me plaît bien!).
[^] # Re: moi c'est l'inverse
Posté par freem . En réponse au journal Linux ne m'intéresse plus. Évalué à 4.
Dans mes scripts pour runit, je source un fichier contenant, entre autres, ces lignes:
À priori, je n'ai pas encore eu de soucis avec ça, mais dis-moi si tu penses que ça règle ce souci sans en exposer d'autres?
Je suis assez d'accord sur le fait qu'écrire des scripts pour gérer la supervision d'un système est casse-gueule, et je sais que runit à ses défauts (comparé à systemd), mais j'aimerai me rendre compte moi-même a quel point c'est vrai.
Et quand ça sera fait, je passerai probablement à nosh qui est dans la même logique que runit, mais peu importer les unit de systemd et inclue le plus gros avantage de systemd: la gestion des dépendances. Je ne le fais pas uniquement par flemme, pour l'instant…
[^] # Re: moi c'est l'inverse
Posté par freem . En réponse au journal Linux ne m'intéresse plus. Évalué à 5. Dernière modification le 14 décembre 2020 à 14:50.
Ok, j'exagère (je me moinsserai bien la). Déjà, c'est bash, et pas shell, donc on ne sait pas sur quel standard le script s'assieds. Pour un service critique. Ouch.
Ensuite, il est possible de faire des scripts de plus de 100 lignes qui sont maintenables, certes. Mais ce n'est pas le cas de la plupart de ceux que j'ai lus, et j'y inclue les miens.
Il n'y a pas non plus de véritables outils d'analyse statique pour le shell (contrairement au C, C++, Rust, etc), ce qui est un problème pour un script critique à mon avis, et pour l'analyse dynamique, idem, j'en connais pas, mais je suppose qu'on peut toujours essayer de jouer la carte du fuzzing…
[^] # Re: moi c'est l'inverse
Posté par freem . En réponse au journal Linux ne m'intéresse plus. Évalué à 3.
Donc, les mecs en 2016 ont recodé un superviseur en shell, qui n'est même pas foutu de faire ça, alors qu'il existe daemontools et ses héritiers qui existent depuis presque 2 décennies et font très bien le job? NIH?
Foutaises. Le shell deviens horrible dès qu'on passe les 100 lignes.
[^] # Re: Sylpheed
Posté par freem . En réponse au journal Vim ou Emacs pour le courriel ?. Évalué à 5.
J'allais me log pour, justement, citer claws-mail quand j'ai lu les 3 alternatives…
Bref, je plussoie pour claws-mails, ceci étant dit, il m'est arrivé d'avoir des crash ou des freeze du MUA, et il «ne gère pas correctement le protocole non-standard utilisé par gmail».
Les guillemets devraient indiquer clairement ce que je pense à ce sujet…
À ma connaissance, il n'y a pas non plus de plugin fonctionnel pour la gestion des rendez-vous (caldav je crois?), et je n'ai jamais encore essayé d'y intégrer ldap, mais pour ces points la, il n'y a probablement que thunderbird qui peut avoir ce genre de trucs… et encore, c'est pas sûr.
Bref, je plébiscite également claws-mail. Seul inconvénient (à mes yeux): son interface nécessite l'usage de la souris.
Ah. Et, tant que j'y suis: claws-mail ne supporte pas dbus, ce qui implique qu'il faut un module pour avoir des popups quand on reçoit un mail. Ou alors, bien plus clean, utiliser "Éxécution d'une commande si du courriel arrive" pour être notifié.
J'y tiens, parce que du coup ça s'intègre a merveille dans les environnements de bureau légers et autres assemblages de WM + file browser + terminal +…
# Est-ce vraiment un danger?
Posté par freem . En réponse au lien La santé balbutiante de la fondation Mozilla menace Firefox. Évalué à 10.
Si mozilla meurt, firefox mourra-t-il réellement? C'est un logiciel libre, qui a toujours son public, dont certains semblent être ok pour financer…
Si le public existe réellement, et est prêt à mettre la main à la poche, pourquoi ne pas forker à la fois le logiciel et l'organisation?
Certes, l'image, le porte-feuille client et les accords commerciaux (avec google) ne peuvent être migrés, du coup ça demanderais certainement un gros investissement personnel des contributeurs, mais bon, c'est faisable non?
Le résultat serait peut-être, au final, plus respectueux de la vie privée, plus proche d' «unfuck internet», par exemple en cessant de retirer le support des protocoles non-web?
Bon, perso, je n'utilise firefox que pour certains sites qui déconnent sec avec vivaldi. C'est sûr que ça serait chiant que Firefox disparaisse, mais juste parce que ça voudrait dire qu'il ne resterais plus que blink et webkit comme moteurs de rendu, ce qui aurait peut-être pour conséquence d'avoir un web qui se barre encore plus en couille (m'enfin, vu comment c'est partit de toute façon, la différence est-elle vraiment si énorme?).
[^] # Re: a 99th one more
Posté par freem . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 4.
Linux. Le monde est peuplé en majorité de geeks \o/ (enfin, pour ceux qui ont un smartphone)
[^] # Re: moi c'est l'inverse
Posté par freem . En réponse au journal Linux ne m'intéresse plus. Évalué à 5.
Je répond a cette section histoire d'avoir une citation, mais je pense que ce que je vais dire s'applique à l'ensemble des systèmes d'exploitation.
Mac OS (ou windows, ou KDE, ou gnome) peut et même doit avoir une chiée de processus, parce qu'il doit être capable de s'adapter à un écosystème bordélique d'objets connectés et intelligents, absolument pas gérés par leur propriétaire.
Il faut que tout soit automatique, que tout soit plus intelligent que l'utilisateur, parce que sinon «c'est trop compliqué».
Et ça ne me choque pas.
Je pense personnellement qu'une distribution ne peux pas tout faire et le faire correctement, ou du moins, pas sans un effort non négligeable de l'utilisateur, à la fois en terme d'apprentissage et en terme de concession.
Si en plus on parle de distros maintenues principalement par des volontaires (Debian, slackware, archlinux, gentoo…) il me paraît déconnant d'espérer que ça colle aux besoins réels «locaux» sans s'investir un minimum.
Quant aux systèmes faits par des entreprises, hé bien, c'est pareil. Elles ont une cible, et vont plus oeuvrer à satisfaire la cible dans sa globalité qu'un petit groupe de barbus qui veut du simple et du bas niveau. De tout façon, s'ils voulaient vraiment ça, rien ne les empêcherait de le faire (c'est ce que font les mainteneurs de crux, de kiss, de slackware, au final, non?).
Pour info, mon système minimaliste nécessite 3 processus vivants par daemon: le daemon lui-même, une instance de
runsv(le watchdog) et une instance desvlogd(les logs, que je ne consulte jamais en plus).J'ai, à la louche, une 10aine de daemons (ttys, udev, clients dhcp, acpid, cups (tiens, faut que je lui fasse un runscript à lui d'ailleurs), ce qui est très peu.
Ensuite, il y a mon bureau. Et la, c'est le drame: mpd, xinit, xorg, claws-mail, quassel, unclutter, ssh-agent, urxvtd, xosview, une chiée de zsh… (faut que je pense a mettre les plus important sous watchdog d'ailleurs) mais en fait, ça va encore.
Ce qui est pire que le drame, c'est la Bérézina, j'ai nommé les clients web: vivaldi à un "score" de 60 dans
pstree -p | grep vivaldi | wc -l. Firefox avec un seul onglet: 73.Tout ça, en ajoutant les lignes du kernel, ça me fait 158 lignes dans mon
ps. C'est un système minimaliste, qui ne fait quasiment rien automatiquement, inutilisable par «le commun des mortels».Donc, 450 process pour macOS qui à pour cible l'utilisateur qui veux juste utiliser son outil (tournevis?) sans se prendre la tête? Ça me choque pas.
Ce qu'il faut, ce sont des distro qui soient adaptées a ces usages de niche que sont le hobby et la récup de vieux systèmes par les gens que ça intéresse.
[^] # Re: moi c'est l'inverse
Posté par freem . En réponse au journal Linux ne m'intéresse plus. Évalué à 3.
Dans l'ensemble, je fais comme toi, je dirais. Enfin, j'évite aussi tout ce qui est basé sur electron.
Tu utilises quoi, en lieu et place de systemd?
Ah, faudra que je teste. J'utilise xsane, et, bon, on va dire que l'IHM est quand même bien moche, même s'il fait plutôt bien le boulot et crash en l'absence de dbus installé.
Pour les pdf, j'utilise mupdf en général, mais je commence a passer a zathura, parce que les limitations de mupdf sont… pénibles (le scroll page par page, c'est pas super pratique…).
Pour tes problèmes de lenteurs, vérifies que tu as bien ton hostname dans le fichier /etc/hosts, pas juste localhost. J'ai déjà vu le cas de saloperies (hein, sudo?) qui font des requêtes DNS pour on ne sait trop quoi (je serais pas surpris que les trucs qui utilisent dbus le fassent aussi, après tout, ce machin sert notamment à pouvoir identifier de manière unique ta machine… pourquoi? Bonne question…)
[^] # Re: GRUB2
Posté par freem . En réponse au journal Linux ne m'intéresse plus. Évalué à 5.
J'ai longtemps utilisé lilo aussi, mais plutôt que d'utiliser grub, je préfère [sys|ext|iso|pxe]linux. C'est un poil plus compliqué à configurer que lilo, mais pas de hack sale comme grub qui requiert une partition rien que pour sa gueule en gpt, et en bonus, c'est très souple, ça fait vraiment tous les types de boot que j'ai pu rencontrer.
[^] # Re: pourquoi ?
Posté par freem . En réponse à la dépêche CentOS se saborde‑t‑elle ?. Évalué à 8.
T'inquiètes, il a juste été un peu redéfini :)
[^] # Re: moi c'est l'inverse
Posté par freem . En réponse au journal Linux ne m'intéresse plus. Évalué à 3.
clairement.
Du coup, tu utilises quelles pistes, toi, pour debloat?
[^] # Re: Lagrange
Posté par freem . En réponse au journal Kristall: un client pour http/gopher/gemini. Évalué à 3.
Vieille_moule en parle juste au dessus, et il supporte gopher et gemini :) juste pas http, donc.
[^] # Re: Client graphique Gemini
Posté par freem . En réponse au journal Kristall: un client pour http/gopher/gemini. Évalué à 3. Dernière modification le 09 décembre 2020 à 17:21.
Merci, vais tester ça, même si j'admets que le fait que kristall supporte
plusieursplus de protocoles est une sacrée plus-value, notamment du fait que je ne suis pas super convaincu par gemini.Je viens de compiler la chose, et il faut bien reconnaître que pour un soft basé sur la SDL, c'est impressionnant!
Je suis intéressé. Tu peux nous indiquer des URIs d'exemple?
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par freem . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 6.
Tu veux dire que cargo est vulnérables aux mêmes problèmes que npm? Hop moi…
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par freem . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 5.
Ralentir la cible pour pouvoir répondre avant elle aux messages légitimes, aussi.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par freem . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 5.
C'est sûr, ça peut marcher (ça serait génial, que celui-ci marche: un OS avec un code tout propre, tout frais, à base de µkernel!). Ça donnait quoi, la concurrence à l'époque?
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par freem . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 4.
Je ne suis pas non plus expert, mais bon, faire appeler la fonction
system()à un processus (qui ne l'appelle jamais dans le code) en se démerdant pour lui passer la bonne commande, c'est bien une injection de code, non?Concrètement, les injections de code, c'est rendu possible par la mauvaise gestion de l'entrée. Que ça soit un buffer overflow ou "un simple oubli d'assainir", c'est la même chose: on détourne l'exécution.
À noter que, il y a peut-être un point sur lequel rust encourage de manière effective la sécurité à ce niveau: il encourage l'édition de liens statique, donc on ne peux pas exploiter LD_PRELOAD :p
Mais moi aussi.
Sauf que moi, je ne précise pas "DDoS". Juste, la grande majorité. Combien de failles font partie de l'OS, comparé au nombre de failles provenant d'une application tiers?
Et quelle est la complexité des services rendus par l'OS quand c'est le cas? Parce qu'un windows qui expose un AD, il ya de bonne chances qu'il soit troué, oui. Par contre il permets un partage de fichiers et d'imprimantes simple à utiliser et administrer (comparé à du FTP/http/NFS, notamment grâce aux ihm), la synchronisation des horloges, des utilisateurs, des configurations système (avec les GPO)!
Et dans tout ça, les failles que je lis dans Misc (parce que le sujet m'intéresse un peu, donc quand je prend le train j'essaie de prendre un misc magazine pour la route, même si le niveau est trop haut pour moi, je comprend quelques trucs et j'apprend beaucoup) sont pas nécessairement des buffer overflow ou des problèmes de C, mais bien des problèmes de configuration par les admins!
[^] # Re: Pourquoi faire ?
Posté par freem . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 3.
C'est la meilleure des motivations, et un excellent moteur pour faire du code de qualité. Quand on se fait chier, on est moins concentré, et la qualité s'en ressent. Hors, faire du code de merde ultra-sécurisé, moi, je n'y crois pas une seule seconde.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par freem . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 4.
C'est déjà plus pertinent que de dire "y'a cette faille" sans mettre de comparatif à côté :)
Sinon: non, c'est pas pertinent, parce que ces chiffres sont bruts, on ne sait pas facilement si le système affecté est bien dans un OS précis (freebsd,openbsd, debian/kLinux, debian/kHurd, windows NT4, etc) ou par un logiciel tiers.
On ne sait pas non plus si les gens qui ont écrit le code s'en torchent ou pas, de la sécurité et de la stabilité, et je pense que le langage est largement secondaire comparé à l'outillage et les procédures mises en places pour gérer les bugs: analyse statique, preuve de coq pour les plus matheux, test unitaires, fuzzing, etc.
Hors, dans ce cas, on parle de jeter l'histo des correctifs de bugs de plusieurs centaines d'applications pour réimplémenter dans un langage qui lave plus blanc que blanc… enfin, c'est l'impression que ça me donne quand les gens en parlent.
Ajoutes la question: est-ce que les garanties qu'offre un langage non standardisé, ne disposant que d'une seule implémentation de compilateur, sont assez pertinente pour écrire un OS qui prétend remplacer les distributions GNU/Linux, et on aura un meilleur débat :)
Je t'avoues avoir juste grep le bloc… par contre, on reviens sur ce que je dis plus haut:
Redox-os embarque des outils en C, c'est dans le journal: netsurf. La différence, c'est qu'ici, netsurf est considéré comme partie de la distro, de l'OS. Ces outils peuvent peut-être aussi tourner pour redox-os, et si c'est le cas, comment le fait que la plupart de l'OS soit écrit en rust aide en quoique ce soit?
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par freem . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 1.
Ça se fait, pourtant, c'est justement une des charges utiles pour exploiter un buffer overflow.
Un OS qui ne fournit aucun service réseau n'est bon que pour les chiens et autres charognards de nos jours.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par freem . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 4.
Pourquoi ça ne serait pas comparable? Ici on ne parle pas de développer juste un noyau, mais un système d'exploitation complet. Basé, justement, sur un micronoyau, dont le fonctionnement se base sur des architectures client-serveur en grand nombre.
Perso, je me dis que ça serait très dommage de nos jours de limiter les IPC à une et une seule machine, alors que de plus en plus de monde dispose d'un PAN.
Dans les cas que j'ai cités, c'est du texte, mais le plus important c'est que ce sont des messages réseau.
Et une application qui ne souffre pas de problèmes de mémoire peut malgré tout avoir des problèmes de concurrence, qu'un langage ne pourra jamais résoudre car liés à des problèmes d'interaction avec les autres machines ou juste d'autres processus.
Tiens, d'ailleurs, c'set quoi leur système d'init? Non parce que s'il est inspiré de sysVinit et RC, avec cette gestion des fichiers de PID bien foireuse, ben, c'est balo pour la sécu :) (je me doute qu'ils ont fait un truc plus propre, mais je suis curieux malgré tout).
Bref, un bug ou une faille réseau, parfois, ça peut déclencher des problèmes de mémoire, mais je doute vraiment que ça soit l'élément le plus fragile de nos jours.
Dans le thread, il y a une liste des failles liées à la mémoire. J'ai fait quelques "mesures": chercher un mot clé, tout copier, balancer un
xclip -o | grep '^CVE-2020' | wc -let j'ai trouvé ça (la méthodo est foireuse, je sais):Donc oui, ok, les buffer overflow et problèmes de mémoire existent, c'est indéniable, mais je trouve que c'est limite négligeable comparé au reste, d'une part en nombre, et d'autres part en facilité d'exploitation: encore une fois, amuses-toi a exploiter un buffer overflow, avec les symboles des lib partagées chargés à l'exécution au hasard… oh, justement!
Les lib partagées… rust, ça encourage pas le static linking, justement? Ça rend ce type de protection plus compliquées à mettre en place, j'imagine.
Et leur kernel, il supporte les mécanismes de type ASLR? Parce que sinon, rust c'est safe… lol?
Perso, j'ai rien trouvé.
Dans celles-ci (les failles de buffer de 2020), je n'en vois aucune liée à linux ou bsd (grep n'a rien trouvé). Donc, aucun noyau libre ici. Ça cause pas mal d'apple, mais difficile de dire si c'set le noyau ou… un serveur (redox: µkernel, tout plein de serveurs…).