freem a écrit 5059 commentaires

les systèmes libres non embarqués resteront à jamais de niche

Linux. Le monde est peuplé en majorité de geeks \o/ (enfin, pour ceux qui ont un smartphone)

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.

Donc, là, c'est un peu toi que je trouve ne pas être habituel.

T'inquiètes, il a juste été un peu redéfini :)

La recherche du débloat est ce qui me motive et il y a de quoi faire. :)

clairement.
Du coup, tu utilises quelles pistes, toi, pour debloat?

Vieille_moule en parle juste au dessus, et il supporte gopher et gemini :) juste pas http, donc.

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?

Rust n'est pas bien loti pour toutes les attaques type Trusting Trust

Tu veux dire que cargo est vulnérables aux mêmes problèmes que npm? Hop moi…

Ralentir la cible pour pouvoir répondre avant elle aux messages légitimes, aussi.

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

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-4701, https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8249 et https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28575

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?

L'injection de code sur du compilé, je demande à voir.

Ça se fait, pourtant, c'est justement une des charges utiles pour exploiter un buffer overflow.

Le DDOS c'est une problématique réseau, je vois pas le parallèle avec un OS.

Un OS qui ne fournit aucun service réseau n'est bon que pour les chiens et autres charognards de nos jours.

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

Je suis vraiment pas expert dans le domaine

Moi non plus, mais j'ai déjà exploité une injection SQL ou PHP (sur des sites spécialisés). J'ai déjà essayé d'exploiter un programme avec un bug mémoire: c'est pas la même.

Parce que linux, c'est un noyau.

La, les mecs font juste la même chose que GNU, 30 ans après, avec un langage tout frais (la ou le C avait déjà de la bouteille et essuyé des plâtres j'imagine), et ce, en vrac (déjà été dis mais peu importe).

À côté de ça, linux, c'était "juste" un noyau, Linus Torvalds ne s'est "pas fait chier", il a repris l'existant. Beaucoup.

Je pense que tout est dis ici: d'un côté, la réutilisation de l'existant, le pragmatisme, de l'autre, l'idéal théorie et le NIH.

Au fait, j'ai un scoop: les failles de sécurité les plus faciles à exploiter… c'est pas les buffer overflows, ce sont les injections de code et les déni de service (un jeune de 16 ans peut exploiter ce type de failles).
Et c'est pas côté kernel, mais userland. C'est bien d'avoir un noyau et des outils de ligne de commande en béton armé (contre les problèmes de mémoire uniquement je suppose, pas contre les bugs fonctionnels, qui sont bien plus délicats à repérer), mais ce qui est important pour un serveur ou une machine embarquée, ce sont les daemons. Pour une machine de bureau, c'est l'interface graphique qui marche pour de vrai, l'accès au web (d'ailleurs, netsurf qu'ils embarquent n'est pas codé en rust) qui supporte le bloat javascript, une suite bureautique et la performance (parce que le jeu vidéo fait aussi partie des usages importants).

Bref. On peut faire une distribution autour de linux en utilisant les outils gnu, le navigateur web de mozilla et le bureau KDE. C'est ça, la force des distros GNU/Linux: le bazar.

Ce nouvel OS aura: moins de développeurs que les devs des BSD (un langage moins répandu), moins d'outils (parce qu'il faut du spécifique rust à tous les coups) et pas de support matériel (parce que si c'était si facile, ça ne serait pas aussi galère sous linux, et si un µkernel étais la panacée, GNU/Debian/kHurd serait stable).

Zut, on est pas vendredi.

Pour contrebalancer un peu tout ça: je pense que c'est bien. J'aime énormément l'idée des µkernels perso, et si j'avais plus de motivation, je bricolerais bien avec hurd. En faire un en rust? Pourquoi pas.
Dommage de vouloir faire l'OS complet, par contre, mais bon, on a le droit de faire son «pet project» :)

y'a D sans doute […] pour remplacer du C ou C++

De ce que j'ai lu (pas grand chose, certes), le D semble très très fortement influencer ses utilisateurs pour utiliser le poubellier, ce qui est admis comme étant incompatible avec la performance (que ce soit de vitesse ou d'occupation mémoire, mais pour la vitesse d'écriture ça aide, probablement).

Des langages que tu cites et que je peux trouver facilement dans wikipedia fr, seul rust peut concurrencer C ou C++. Et il me semble pas que rust puisse embarquer du C aussi facilement que C++ (un simple #include bien souvent), alors qu'il s'agit probablement de la base de code la plus importante, et une des plus vieilles, avec donc pas mal de correctifs de bugs.

D'ailleurs, ce point est important: toutes les failles de sécurités ne sont pas liées à la mémoire, loin de la. Et c'est encore pire pour les bugs, alors que tout refaire (peu importe le langage cible), c'est aussi devoir reprendre tous les debugs, de 0.

Va falloir passer par des mails alors, parce que de mémoire linuxfr.org n'a pas de mécanisme de message privé.

Haha, j'adore l'idée de virer l'heure pour gagner quelques méga-octets de mémoire.

En fait, ce n'est pas «virer l'heure», mais virer un daemon qui garde la machine à l'heure via le protocole ntp.
Pour une machine non critique, le faire au démarrage (après le réseau bien sûr) puis une fois toutes les semaines est amplement suffisant, pas besoin que ça tourne en permanence.
Le plus amusant pour moi, c'est que le daemon contenu dans le paquet «ntp» de debian consomme… :

3340 76468 ntpd

la moitié de mémoire résidente, 25% de moins de mémoire virtuelle. C'est pas rien, et ça fait pas juste client, mais serveur aussi.
Mais il fallait que cette bouse (oui, je me permets maintenant de dire ce que j'en pense, j'ai été assez sympa avec ce machin pour remplir mon quota de neutralité pour plusieurs mois) de systemd réinvente la roue…
Il suffit de voir, dans ta liste:

5628 23352 /lib/systemd/systemd-udevd
6412 95148 /lib/systemd/systemd-timesyncd
7244 19552 /lib/systemd/systemd-logind
8140 40376 /lib/systemd/systemd-journald
9524 21260 /lib/systemd/systemd --user
10064 104032 /sbin/init

Donc, à peu près 47.8Mio de RSS.
Si je compare avec mon système, sur lequel je n'ai pas logind (pas l'utilité), ça fait du 40.6Mo pour ton système, et:

% ps -orss,vsz,comm -A | grep -e ntp -e syslog -e runit -e runsvdir -e runsv -e svlogd -e udev
  728   2152 runit
  736   2312 runsvdir
  740   2160 runsv
  740   2160 runsv
  668   2160 runsv
  732   2160 runsv
  744   2160 runsv
  736   2160 runsv
  736   2160 runsv
  740   2160 runsv
  744   2160 runsv
  680   2160 runsv
  740   2304 svlogd
  748   2304 svlogd
  744   2304 svlogd
 5180  22552 systemd-udevd
  672   2304 svlogd
  748   2304 svlogd
    4   2208 syslogd
  740   2304 svlogd
 3340  76468 ntpd

Soit: ps -orss,vsz,comm -A | grep -e ntp -e syslog -e runit -e runsvdir -e runsv -e svlogd -e udev | awk 'BEGIN{ printf "0" }{ printf "+%s",$1;}' | calc ==> 21640Ko, donc ~21.5Mo :)
C'est juste la moitié, et ce, sachant qu'il est possible de compiler runit statiquement, ce qui réduit de manière drastique la consommation mémoire (sur le build muslc de voidlinux, j'étais à 4Kio de RSS par instance de runsv et de svlogd).

Je pensais qu'il y aurait un applet busybox pour ntp, je me suis trompé, dommage, j'aurai pu descendre encore plus ce bloatware.
Par contre, ils parlent de ntpclient. N'ayant jamais utilisé, je ne saurais le recommander, mais je vais le mettre sur ma liste de trucs a tester :)

Je suis sûr qu'on me diras que 20Mo de gagné, c'est pas grand chose de nos jours, mais tu es aux 1ères loges pour constater que, parfois, ça compte :)
Je ferais peut-être un journal sur la construction d'une Debian économe en mémoire un de ces 4, en comparant le résultat avec la Debian par défaut, ça occupera le vendredi.

Tu sais, tu aurais pu aider. Je ne comprend pas pourquoi personne ne lui a dit d'ajouter le flag magique qui supprime tous les warnings: -Werror. Moi, quand j'ai des warnings et des bugs sur mon code et que j'utilise rm a.out; gcc -Werror -Wall -Wextra foo.c, ben j'ai plus de warnings ni d'exécutable buggué.

en général, j'utilise top et je dépatouille un peu

Top est plus que limité, par nature. Je m'en sers aussi, mais pour visualiser l'usage CPU instantané, quand je n'ai pas de serveur graphique. Sinon, j'utilise xosview combiné à ps -opcpu,pid,comm -A.
Mais pour analyser l'usage mémoire, je trouve ps plus pertinent: pas besoin que ça bouge tout le temps, au contraire, il faut pouvoir se concentrer et analyser les lignes.
À chaque outil son usage.

j'ai remplacé mpd par mopidy, mais c'est vraiment similaire

Nope. nopenopenope!

59156 1205724 /usr/bin/python3 /usr/bin/mopidy

Et chez moi:

35920 658788 mpd --no-daemon /home/berenger/.config/mpd/mpd.conf --stderr

Donc, mopidy bouffe presque le double de mémoire, résidente ou pas.

Ceci mis à part, j'ai l'impression de voir une machine qui est faite pour un usage normal ici, pas pour un serveur de ficher et jukebox. Et clairement, une machine dont l'install par défaut n'intègre pas vraiment les outils ensembles…

Ce que je vais lister est ce qui, à mon avis, est optimisable, mais ça reste mon avis, par rapport a ce que j'ai compris de ton usage, et je suis quelqu'un qui déteste le bloat, quitte a utiliser un environnement minimal… qui s'adapte extrêmement bien à des petites machines, pour le coup :)

Faible impacts (moins de 5meg potentiellement récupéré par changement, mais quand on chercher le moindre meg…):

• ssh-agent, c'est pour que le client ssh se souvienne de tes clés. Ta machine est censée être le serveur, non?
• agetty est lourd (pour un getty). Il peut être remplacé avantageusement par mingetty, ngetty, fgetty, et d'autres;
• cron? Si tu utilises systemd, c'est inutile: systemd en embarque une implémentation de mémoire;
• dbus et toute sa clique, c'est des dépendances de gtk, on peut s'en passer en vrai, mais je recommanderais pas à un débutant (parce que c'est se faire chier pour pas grand chose);
• geoclue.. démo? Ça à l'air d'être pour que ta machine sache ou elle est, genre, GPS? Pour un serveur?
• rsyslogd? Alors que tu utilises systemd-journald? J'en vois pas l'utilité, ou alors c'est que systemd-journald est pas foutu de faire son job correctement: j'aimerai pouvoir le dire, mais j'en doute fort;

Catégorie suivante, impacts non négligeables:

• alsactl, permets de gérer des paramètres avancés, plusieurs cartes son. Comme tu veux, mais moi je dis: inutile;
• cups, 8Mo + 11Mo, sert à l'impression;
• GVFS, 11Mo, sert à monter automatiquement les périphériques et à les afficher dans ton gestionnaire de fichiers, si je ne m'abuse;
• menu-cache, mets en cache des fichiers .desktop… euh, soit, mais tu as vraiment tant d'applications que ça? Non parce qu'il bouffe plus de 5Mio, et un seul fichier .desktop pèse quoi… 4Kio (parce que 4Ko c'est la taille d'une page mémoire)? Le noyau rentrerai plus de 1000 fichiers .desktop dans cet espace mémoire. Pour moi, c'est du bloat;
• dhclient: tu pourrais utiliser par exemple udhcpc. Chez moi, ce dernier à une empreinte RSS de 4ko. Contre plus de 5Mo chez toi, pour le même rôle, sauf si tu as des besoins avancés de ce côté, mais je vois pas, perso (pas encore eu de problème avec, dans mes usages, pendant plusieurs années);
• at-spi-bus-launcher: composants d'accessibilité de gnome. Ça dépend vraiment de toi, ici, peut-être est-ce nécessaire. Si ça n'est pas le cas, c'est 6Mo;
• systemd-timesyncd: 6Mo pour un client ntp? Wow. Vive systemd. Sinon, est-ce critique que ta machine soit mise à l'heure en permanence? Ce genre de trucs sont surtout utiles pour des machines qui gèrent de l'authentification, par exemple dans un LAN qui utilise kerberos;
• lightdm. Gestionnaire d'affichage léger, à plus de 13Mo. J'ai pas la même définition de léger, mais soit. N'empêche, je suis persuadé que, par exemple, xdm est plus léger. De toute façon, ces outils sont d'une utilité douteuse: une session qui lance startx quand démarrée sur un TTY, c'est nettement plus léger (0Mo). Tu peux te renseigner sur le sujet ici par exemple;
• ModemManager? Tu as une puce LTE dans cette machine? Enfin, même si c'est le cas, il y a bien, bien plus léger, puisqu'on est restreint sur les ressources (ici: ~10Mo);
• colord: ~14Mo, tu règles vraiment finement les couleurs de l'écran sur cette machine?
• PA sert à gérer le son par application, je ne vois pas l'intérêt (dans ce que j'ai compris de ton usage, hein). Il consomme plus que je pensais d'ailleurs: ~24Mo;
• clipit, ~37Mo, pour gérer… euh… le presse papier? Sur un (rôle de) serveur?
• wicd, ~40Mo, sert a gérer les connections réseau, c'est pratique quand tu en changes souvent, mais si la machine est censée rester toujours sur le même réseau, c'est totalement inutile;
• le bluetooth, blueman donc, ~50Mo, tu en as déjà parlé;

Bon, je vais m'arrêter la, c'est déjà beaucoup.
Je pense que tu peux récupérer pas loin de 150Mo facilement sur ta machine, sans perte de confort.
Si tu pousses «l'optimisation», tu peux peut-être récupérer plus de 300Mo de mémoire résidente. Ces nombres me paraissent excessifs, j'avoue… mais je me base sur ton log :)

Si tu cherches des pistes d'économie, le mieux, c'est de commencer par mesurer.
Perso, pour avoir une idée de ce qui pèse lourd sur ma machine, j'utilise la commande suivante:

ps -orss,vsz,args -A --sort=rss

Elle indique, pour chaque processus de ta machine, sa mémoire résidente, c'est à dire, ce qui est effectivement en mémoire, la mémoire "réservée" (c'est plus subtil que ça, certes) et la ligne de commande exécutée, le tout trié par occupation mémoire résidente.

Maintenant que tu peux mesurer par toi-même, place au laïus:
Je n'aime pas systemd, que je considère gourmand, oui, mais surtout parce que c'est un logiciel critique et pourtant il n'est pas "stable", au sens que de nouvelles fonctionnalités sont ajoutées en permanence. Entres autres.
Maintenant, il est très probable que, sur 1Gio de RAM, ça ne soit pas ici que tu récupéreras le plus de mémoire, et comme il est intégré par défaut dans (la plupart des) les distros, tu as moins de risques de problèmes, plus de facilité a te faire aider en l'utilisant.
C'est important, et je ne te recommande pas de changer d'init (de framework système, je devrais dire en vrai).
Sans être particulièrement complexe pour des machines simples, mieux vaut être à l'aise avec son système avant de jouer avec ça.
Pour info, j'utilise personnellement runit-init, mais ça nécessite que je fasse mes scripts moi-même, puisque pas très bien supporté par debian. Pas de souci, j'ai l'habitude.
Runit a un coût par processus surveillé qui est supérieur à systemd (entres autres parce que lié dynamiquement, c'est la faute a debian ça, mais peu importe). Selon mes calculs, par contre, il faudrait beaucoup de daemons pour que ça soit plus lourd que systemd: ~30 avec le build de debian, plusieurs centaines avec un build mieux foutu. C'est de l'ordre des centaines de kilo-octets ici. Tu as plusieurs millions de kilo-octets de ram avec ton giga.

Pulse-audio par contre est un meilleur candidat je pense: il sert surtout (a ce que je sais) a permettre de gérer le son par application: pour une machine qui sert de jukebox, 0 intérêt.

Ensuite, dans ton bureau, tu as sûrement pleins d'applications installées pour rien, les nettoyer va virer de l'espace disque seulement, la plupart du temps, mais dans certains cas, ces logiciels vont démarrer tout seuls, pour diverses raisons. Gain probable ici, plus pertinent que changer systemd ou PA.

Debian installe, de mémoire, automatiquement un serveur de mails, par exemple. Je doute que tu en aies l'intérêt, et, oui, il est démarré automatiquement. En fait, Debian installe par défaut les paquets "recommandés". Ce sont des dépendances optionnelles qui peuvent potentiellement apporter une fonctionnalité. Si tu connais l'usage que tu veux faire de ta machine, tu peux sûrement en virer beaucoup.

Si vraiment tu veux réduire l'usage RAM, tu peux aussi cesser d'utiliser un gestionnaire de session graphique: il te faudra juste démarrer la session graphique à la main, ou ajouter dans ton .profile un truc de ce goût: if [ "/dev/tty1" = $(tty) ] then; exec startx; fi, qui fera que ta session graphique se lancera automatiquement quand tu te log sur le 1er terminal.

Une machine de 1gig de ram devrais pas, au démarrage et en console, consommer plus de 40megs de ram, je pense. Sur une VMs minimaliste, j'ai 22megs, mais bon, y'a rien de rien (juste 6 tty, même pas de réseau), donc bon.
Ajouter un bureau léger tel que LXDE devrais tenir largement en dessous de 100megs de ram, donc si ta RAM est vraiment le problème (ce dont je doute) tu dois avoir bien des merdes lancées… ce qui inclue évidemment un navigateur web. Ces machins (enfin, firefox, chromium, ses clones, et ceux basés sur webkit) sont des gouffres, et on peut rien y faire. Firefox bouffe moins que chromium cela dis, me semble avoir mesuré y'a quelques mois, et il devrais tenir dans 1 gig. Si pas trop d'onglets, profil neuf (vide), et sites légers.

Je peux essayer d'aider, si tu colles la sortie du ps que j'ai indiqué en début de message.

Peut-être une piste ici.
À lire avec un peu de contexte, vu que ce n'est pas le 1er billet de la personne sur le sujet (je crois que c'est le 2nd, il en mentionne un autre, j'avais lu tout ça mais ça fait quelques temps)