Enj0lras a écrit 250 commentaires

Je connais pas bien SMF, même si on m'en a parlé plusieurs fois, mais l'idée qui est en train de faire son bonhomme de chemin pour rcNG (impulsée par bapt d'ailleurs) c'est d'avoir un processus de contrôle pour chaque daemon. Si le processus se vautre, seul ce daemon serait impacté.

Je ne parle pas d'écrire une alternative mais d'améliorer l'existant en important des choses qui manquent (comme le monitoring des daemons).

Non, la question a un but bien précis. Identifier les fonctionnalités clées de systemd qui plaisent aux utilisateurs et essayer de les implémenter autre part.

Passons sur les 3 premiers points, qui sont en effet importants mais sont des évidences. Pourrais tu préciser les points 4 et 5 ?

Je vois que le vivre ensemble c'est pas ton fort. Je pose une question dont la réponse m'intéresse et je me fais agresser. Je m'intéresse aux fonctionnalités intéressantes pour un utilisateur, un point c'est tout. J'ai pas envie de rentrer dans ton troll ou dans un grand débat sur la vie l'univers et le reste.

J'admets ne plus avoir suivi les débats sur systemd depuis au moins 1an et ne l'utiliser que très rarement. Mais cette dépêche est intéressante, je trouve notament le paragraphe sur la modularité très juste. Je dis souvent que la modularité n'a rien à voir avec la séparation en processus. La modularité c'est la séparations en "modules" de codes ayant un rôle particulier qui fonctionnent chacun avec des dépendances minimales et possédant des API stables et documentées, ainsi que, c'est mieux, un système de build permettant de compiler les briques séparéments. Je pense que c'est selon cette définition qu'on accuse souvent systemd d'être monolithique.

Pour revenir au sujet de ce commentaire, certaines personnes réfléchissent à ce que d'autres systemes d'inits, comme le vieux init BSD, peuvent apprendre de systemd. Non pas techniquement, mais sur le plan des fonctionnalités. Ainsi, ayant plutôt tendance à voir la partie négative des choses j'aimerais poser la question suivante :

Qu'est ce que selon vous systemd a apporté à votre expérience utilisateur ?

C'est vrai que c'est un peu root pour le tout venant, installer dfly sur un desktop ça marche, de mieux en mieux, mais c'est quand même loin d'un ubuntu. Et ça marchera plus ou moins bien selon ton matos. Pour ce qui est de l'upgrade, faut dire que tu dois faire ça au plus 2 ou 3 fois par an. Et il y a moyen de bricoler sans compiler à la main, en téléchargant une .img et en copiant les fichiers sur ton disque dur.

Si tu es intéressé par l'installation de xfce sur dfly, j'ai écrit un journal à ce sujet :

http://linuxfr.org/users/enj0lras/journaux/installe-une-libellule-dans-ton-bureau

tu peux toujours utiliser gcc ou clang avec visual studio.

Bein, je suis pas openBSD moi :p, que ça soit bien fait est une opinion personnelle. Par contre je rejoins les gars d'openBSD sur le fait que la base de code est difficile à maitriser, et je pense qu'avoir un httpd basique dans base est une bonne idée, beaucoup d'installations n'ont pas besoin de servir beaucoup de traffic et là un truc plus simple fait sens.

oui mais il ya privsep.

Tu peux même pas comparer avec FAT12, parce que ça gère pas assez de fichiers :P (on parle d'un truc de l'ordre de 200k fichiers là, c'est lent même sur ext4 un rm -rf là dessus)

Un exclave est censé obéir aux ordres de son maitre et pas faire des choses sans son autorisation. Enfin du moment que tu lui dis que tu veux qu'il se connecte automatiquement, c'est bon, mais que l'OS face ça de base, ça me gène.

Non mais là tu compares NetworkManager à la configuration d'ipv6 dans le noyau… Ça n'a rien à voir. Rien ne t'interdit d'avoir un truc comme NetworkManager (je crois pas que ça marche sur openBSD) d'installé qui va lancé automatiquement un dhcp. Mais bon, ça n'a strictement rien à voir avec ce qui est décrit ici. Si tu as un truc similaire à NetworkManager installé et lancé au démarage de ta machineę il lancerait un dhcp sur ton interface, et activerait peut être l'autroconfiguration ipv6. Bref, ça serait pareil que sous ubuntu, parce que "DHCPv6" activé par défaut, ça veut pas trop dire grand chose, il faut que quelque chose le lance. Alors que les addresses link local, ça par contre, c'est le noyau qui s'en charge.

Sinon, ça fait un long moment que j'ai pas utilisé NetworkManager, mais vers l'époque de Gnome 3.0 quand je l'avais, il fallait que l'utilisateur clique sur "activer la connexion filaire" pour que ça se connecte automatiquement, je ne me souviens pas que c'était par défaut. Si c'est maintenant par défaut, je trouve ça dommage.

C'est bien la première fois que j'entends ça, j'ai jamais utilisé un OS ou dhcp était activé par défaut sur les interfaces réseax…

Je comprends pas ce que tu veux dire… DHCP n'est activé par défaut sur une aucune interface, encore heureux, que ça soit v6 ou v4. Il faut que tu dises explicitement que tu veux un daemon DHCP.
Au passage, DHCP, ça peut être dnagereux, souviens toi de la faille bash et de dhclient (celui de l'isc, je sais pas si c'était aussi possible sous le fork de openbsd).

peut on en 2014 faire un langage «accessible» qui produit du code robuste (ce que ni Haskell, ni Scala, ni OCaml n'ont réussi à faire par exemple) ?

C'est marrant, c'est pas la manière dont j'avais envisagé rust. J'aurais plutôt dit que l'objectif c'est de fiare un langage performant, qui ne sacrifie pas le contrôle que possède le développeur sur la gestion de la mémoire pour obtenir de la robustesse.

C'est quelque chose que ni ocaml, ni haskell, ni scala n'ont essayé de faire.

c'est marrant, j'ai comme l'impression que tu avais envie de troller et que tu as juste cherché un pretexte pour placer ton petit laius sur la sécurité.

Désactiver ipv6 par défaut, ça veut dire :

1. ne pas auto-configurer des addresses link-local
2. ne pas répondre aux RA, et aux nodes information request
3. activer automatiquement dès que tu ajoutes une ipv6 "manuellement" (ça peut être avec dhcp)

Bref, ça ressemble pas mal à ce que tu dis non ?

Tu as déjà lu le code d'nginx ? C'est propre, il n'y a pas à dire, très portable, chaque fonctionnalité spécifique à un OS est cachée sous une couche de compatibilité.

Par contre, c'est une base de code assez compliquée à maitriser. Nginx est écrit pour être entièrement asynchrone, en utilisant epoll/kqueue, avec des mécanismes pour abstraire cela (c'est un peu une libevent à lui seul).

Tiens d'ailleurs je me rends compte qu'il y a aussi postgresql84. Mais bon, postgresql c'est un cas particulier où les utilisateurs ont pas forcément envie de maj leur infra quand ça marche vu que c'est assez lourd à faire.

Dans la pratique, ça dépend des ports, si c'est un port plutôt orienté bureau/utilisateur final, ou un port plus utile pour un serveur ou du développement. Pour ce qui est "utilisateur final", et donc plutôt ce qui est mentionné dans cette dépêche, c'est une rolling release, avec seulement la dernière version fournie, un peu à la arch.

Pour les logiciels qui nécessitent plus de maintenance, comme apache, bind, php, ou postgresql, il y a en général la dernière version mineure des 2 ou 3 dernières versions majeures, dont l'une est le "défaut".

Par exemple, il y a en ce moment :

• postgresql90 -> 9.0.18
• postgresql91 -> 9.1.14
• postgresql92 -> 9.2.9
• postgresql93 -> 9.3.5
• postgresql94 -> 9.4 beta 3

Mais c'est encore plus compliqué que ça, car certains paquets, mettons, php pgsql, dépendent des libs de postgresql, et il y a parfois des changements d'ABI etre versions majeures. Donc, il y a une version qui est le défaut. Donc même si des paquets binaires sont fournis pour chacune de ces versions, si tu veux installer un paquet binaire qui dépend de la bibliothèque pgsql, le paquet sera compilée contre la version par défaut. Si tu veux l'utiliser avec une autre version, il faudra que tu recompiles le port en question.

Cela dit, maintenir des dépots avec des versions par défaut différentes s'avère très très très simple sous FreeBSD grace à poudriere, tu peux continuer à utiliser les paquets binaires officiels et compiler juste automatiquement tout les ports qui vont être modifiés par ton changement, puis ajouté le dépot créer dans ta conf de pkg pour qu'il installe les dépendances depuis ce dépot en priorité.

Merci, j'ai tendance à faire beaucoup de fautes :/

Par contre pour ce qui est d'ip, ce n'est pas le cas. ip est un outil linux, les ifconfig de chacun des BSD restent présents la tête haute !

Non, il n'y a que les soft-updates

j'ai vu à ce sujet qu'il y avait le projet vt chez freebsd pour moderniser la console, ça en dit quoi du côté de la libellule ?

Du côté de la libellule, il y a des patchs qui trainent, que j'ai utilisé pendant un moment, mais qui ne sont pas encore finis. je sais pas trop où ça en est mais il y a quelqu'un qui travaille là dessus. Contrairement à vt, je crois que c'est juste une adaptation de la console actulle pour dessiner dans un framebuffer. C'est vrai que c'est un peu embettant dans l'état actuel des choses parce qu'une fois que tu as lancé Xorg avec le pilote DRM, tu ne peux plus voir tes consoles TTY (même si elles sont toujours là et que tu peux taper dedans à l'aveugle). Peut être dans la prochaine version :).

, est-ce qu'UFS ne serait pas suffisant pour avoir l'équivalent (j'ai l'impression qu'HAMMER a plus à voir avec btrfs, alors que je privilégie le terre-à-terre de la fiabilité aux fonctionnalités « magiques » ) ?

Je ne sais pas vraiment, si tu n'es pas attiré par les fonctionnalités tels que l'historique (crois moi, c'est plus utile qu'on ne le pense, plus la peine d'avoir des alias pour demander de comfirmer avec cp ou rm ou mv, plus la peine de faire attention, si tu fais une erreur tu peux la corriger après coup), évidemment c'est pas très utile. Je ne sais pas quelles sont les performances, j'aurais dit que hammer était un poil au dessus quand même, mais pas sûr, ça doit dépendre des workload.

Par contre du point de vu de la fiabilité, rien ne dit qu'UFS est plus fiable. Déjà, 90% des gens sous dfly utilisent HAMMER (sauf pour des petites VM), donc plus d'utilisateurs pour rapporter des éventuels bugs. Et surtout, c'est pas parce que HAMMER a pleins de fonctionnalités qu'il est énormément plus gros : hammer doit faire dans les 30k lignes, et UFS dans les 20K lignes, la différence n'est pas énorme.

Bon, en relisant une 3éme fois, je remarque quelques erreurs :

cpdup -i0 -j0 -VV /mon/dossier@@@@0x000000016cd60eb0 /recupération/pfiu

devrait être :

cpdup -i0 -j0 -VV /mon/dossier@@0x000000016cd60eb0 /recupération/pfiu

*/30 * * * * hammer-cleanup

devrait être

/30    *   *   *   *   hammer cleanup

En outre, on me signale que :

sysctl machdep.mwait.CX.idle=AUTODEEP

ne fonctionne qu'avec les CPU intels, et si on veut que cela soit pris en compte au reboot, il faut ajouter ça dans /etc/sysctl.conf (sans la commande sysctl au début).

Pour les processeurs AMD, je cite :

For modern AMD CPUs one should try machdep.cpu_idle_hlt=3 (for max. powersaving) or alternatively set machdep.cpu_idle_repeat to a low enough value (between 0 and 10 makes sense for me, lower value = more power saving)

Oui, j'hésite vraiment à l'installer. Le cron fourni par défaut est un bon vieux vixie cron. Mais j'ai pas encore franchi le pas parce que j'ai un peu la flemme de voir comment remplacer le cron de l'OS simplement.