nud a écrit 977 commentaires

Vu que c'est redhat qui pousse dans cette direction ils ont peut-être quelque chose dans les cartons.

Et Nemiver ça sent le pâté? Par contre oué, le vala c'est la plaie à déboguer (déjà le "compilateur" est plein de bugs et les gusses derrière vala ne comprennent rien à la compatibilité ascendante), je comprends pas pourquoi tant de gens dans Gnome qui utilisent ça.

La RFC 6752 "Issues with Private IP Addressing in the Internet" est semble-t-il de circonstance.

Sauf que biodégradable ou non il va finir dans la poubelle, et donc dans l'incinérateur. Je doute que quiconque ne mette les plastiques biodégradables dans leur compost.

C'est un cycle court, donc ce n'est pas considéré comme polluant dans la mesure où le maïs de l'année suivante va emprisonner la même quantité de CO2. C'est le même raisonnement qui est appliqué quand on dit que les pellets de bois ne sont pas polluants par opposition au mazout (qui est un cycle très long): tu ne libères pas du nouveau carbone dans l'atmosphère.

Du reste, si ton maïs passe par une phase "plastique" à courte durée de vie, il finira de toute façon dans l'incinérateur avec les autres déchets. Mais effectivement c'est un cycle court donc c'est moins polluant que du plastique à base de pétrole.

Les liens symboliques c'est à faire en dernier recours quand même, car on se trompe vite dans les droits (un -a manquant derrière le cp et c'est foutu) et ça peut causer des dysfonctionnements assez folklo à débugger. Il faut commencer par les usual suspects (voir plus bas) avant de chipoter.

Inutile sur un PC de bureau de séparer /var. Ne séparez plus non plus /usr, c'est chercher des misères avec udev.

Tu peux procéder avec du -sh /* | sort -h et aller récursivement dans les dossiers qui ont une taille suspecte (tu peux aussi utiliser baobab si tu as Gnome, et il y a sans doute un équivalent KDE)

Typiquement, ton espace disque est bouffé par:

• Les archives de ton gestionnaire de paquets. Commence par un pt-get clean ou équivalent.
• Des logs, en particulier si un événement s'est produit et a rempli le disque. Une fois j'ai eu un disque rempli par des logs qui me prévenaient que mon disque était presque plein toutes les 5 secondes… jusqu'à ce qu'il n'y ait plus de place pour écrire les logs. Idem avec postfix.log si tu as un problème de relai de mail.
• Des gros fichiers temporaires dans /tmp (sauf si tmpfs), genre une iso téléchargée avec Firefox et autres joyeusetés du genre.

Commence par vérifier cela avant de perdre ton temps avec baobab.

Certes. Mais est-ce dans ce cas bien légal vis-à-vis de la législation européenne ?

Ah les joies du plein emploi…

J'ai été surpris par ce nouveau connecteur et l'absence de port USB. Il me semblait en effet qu'en Europe les smartphones devaient obligatoirement être équipés d'un port micro-usb pour le chargeur, mais apparemment donner un adaptateur avec le smartphone est suffisant (ce qui est con vu que du coup on perd l'avantage du chargeur universel, sauf à se balader toujours avec l'adaptateur).

Après faut voir aussi les droits sur l'univers BSG, le design des appareils, tout ça.

tout dépends de ce qu'on entend par "installer",

make vs make install.

Compiler quelque chose n'impose pas de l'installer, par contre cela impose d'installer toutes les dépendances de compilation. C'est le problème mentionné ici: le mainteneur de lfs ne veut pas installer systemd mais la fusion lui impose d'installer les dépendances de compilation de celui-ci, qui comprennent la libdbus.

Après il pourrait probablement installer la libdbus sans installer le dbus complet, comme c'est déjà le cas sur une debian serveur par exemple.

systemd dépend de la libdbus car il propose une "activation dbus" similaire à l'activation par socket, mais utilisant un nom dbus. Si on avait un autre mode d'IPC de type bus répandu il dépendrait probablement de la lib idoine pour fournir également une activation paresseuse pour ce protocole d'IPC.

Tu n'as pas bien suivi.

la fusion nous oblige à installer systemd

Non, la fusion oblige juste à compiler systemd, mais udev reste fonctionnellement indépendant.

les dev de Dbus avaient plus ou moins promis que la fusion n'empêcherait pas l'usage de Dbus sans systemd

Non, On peut toujours utiliser dbus sans systemd… Le problème est ici udev, qui est compilé avec systemd, qui nécessite la libdbus.

Gnome (et sa galaxie d'applications) qui va nécessiter systemd

Non, Gnome utilise juste de certaines interfaces dbus simples implémentées par systemd et qui pourraient être implémentées par d'autres démons de la même façon (genre org.freedestktop.hostname1). On ne peut pas même parler de dépendance: si tu n'as pas de démon qui implémente cette interface tu peux juste pas changer ton hostname depuis la GUI.

les gars de LFS ont déjà fait un script pour compiler Dbus sans systemd

Non, dbus a pas besoin de systemd, c'est udev qui a été fusionné, pas dbus.

Sauf que systemd est idéalement placé pour se rendre compte que le service disparaît au moment où il disparaît. Idem s'il bloque. Il reçoit le sigchld, il contrôle le socket, bref, il est où il faut pour ça.

Les services externes de monitoring (mon, monit, god et consorts) ne font que du polling, donc si tu vérifies tes services une fois toutes les 5 minutes tu cours le risque de rester avec un service down pendant 4:59 au pire des cas. Systemd peut réagir immédiatement.

J'attends la sortie de wheezy justement pour pouvoir utiliser systemd sur des serveurs, justement pour avoir cette surveillance qui fonctionne bien mieux avec systemd qu'avec mon.

Juste car c'est le même auteur, tu peux tout à fait faire tourner ces petits programmes triviaux sans systemd, certaines distro le font. Ça utilise probablement un .so commun mais ça marche aussi avec sysvinit.

la tentative de dépendance obligatoire dans GNOME.

Ce point a déjà été discuté précédemment. Gnome ne dépend pas de systemd, mais il dépend d'interfaces D-Bus diverses (genre org.freedesktop.hostname1) spécifiées au sein de freedesktop.org, et qui sont pour l'instant uniquement implémentées par des petits utilitaires fournis par systemd. Ces interfaces sont triviales (vraiment) et peuvent être implémentées facilement par un autre outil.

Il s'agit juste de déplacer la maintenance des outils spécifiques aux distros au sein des distros au lieu de les garder au niveau de l'upstream, car de toute façon les outils upstream (system-tools-backend) ne supportaient que redhat, debian et opensuse.

Note que la distinction PC vs Mac n'a plus vraiment de sens, de nos jours c'est plutôt PC livré avec Windows vs PC de marque Apple livré avec MacOSX.

Non je suis le pape et j'attends ma sœur.

Non, c'est à côté

Par contre Samsung risque d'empocher des indemnités de rupture pas piquées des vers.

Et encore, tout le monde n'était pas là.

Il ne me demande pas de l'accepter, je sais afficher l'image. Et ça marche sur les autres pages. Vous voyez l'image sur la page des journaux vous?

Bon en fait c'est nul, le logo n'apparaît pas sur la page d'accueil, juste le texte.