Enj0lras a écrit 250 commentaires

je pense que c'est surtout les applications qui ont des problèmes. Je me connecte souvent en ipv6 only avec du linux et du BSD sans problème. J'imagine que c'est les outils similaires à NetworkManager et compagnie qui créent des problèmes au dessus.

En attendant tous mes clients travaillent avec MS Office et j'ai jamais vu l'un d'eux utiliser LO.

C'est probablement parce que LO n'utilise pas Qt. Ils attendent que les devs investissent énormement de temps pour convertir la suite à Qt, ils n'aiment pas que le code soit sale.

C'est donc bien une priorité de passer à Qt.

Au lieu d'avoir un script d'init par distribution (qui font tous à peu près la même chose), il y a un fichier .service fourni par le projet concerné (exemple : Nginx) qui fonctionne partout sans modification.

Avant, il avait 7 systèmes d'init différents. Incompatibles entre eux.

Maintenant, il y a 7 systèmes d'init différents. Incompatibles entre eux. La situation est bien meilleure.
Encore une fois, Unix != Linux. Si tu veux un truc qui "tourne partout", comme Nginx, tu dois supporter beaucoup de choses. Nginx tourne sous BSD, qui utilisent deux version de de scripts RC différents (mais relativement compatibles en réalité). Nginx tourne sous gentoo/slackware etc. Nginx tourne sous Solaris, qui utilise SMF, et des fichiers XML (mais compatible avec sys-v inits il me semble, comme quoi c'est possible). Nginx tourne sous OS X, qui utilise launchd et des fichiers XML, mais différents.

Mais je crois que tu as raison. Il suffit de fournir un .service et ça tourne partout.

Parce que convertir toute la suite à Qt est n travail de titan ? Parce que même si Qt était meilleur que Glade, le gain serait trop faible par rapport au travail nécessaire ? Parce que la solution actuelle fait son job et qu'il n'y a pas besoin de recoder la roue ?

Sinon, une réponse plus sur le fond :

FreeBSD prétend être l’un des OS les plus sûr par sa conception et utilisation.

Déjà, j'espère que FreeBSD ne prétend pas ça parce que ça serait un gros mensonge.

• paquets/ports : 90% de ce qui est raconté n'est plus vraiment d'actualité avec FreeBSD 10. Une bonne partie est vraie, mais c'est présenté uniquement du point de vue négatif des choses.

• Support matériel : il y a bien évidement moins de pilotes que sous linux. Après ça dépend des domaines, par exemple les controlleurs raids sont très bien supportés, les chipset bluetooth moins. Ça ressemble à ce qu'il se passait sous linux il y a pas si longtemps. ça dépend de ton materiel.

• Je ne comprends pas du tout l'argument du "c'est plus monolithique que linux", je ne vois pas du tout sur quoi c'est fondé

• Il me semble que chiffrement + TRIM, ça a changé récement aussi

D'un point de vue général, les commentaires sont relativement fondés mais ça sent l'argumentaire un peu biaisé qui cherche à démontrer que "freebsd c'est nul et linux c'est mieux", ça n'insiste que sur les points négatifs dont parfois l'importance peut s'avérer relative quand tu utilises l'OS.

Moi je voulais aller au état-unis, mais on m'a dit que la CIA et les sionistes avaient orchestré les attentats du 11 septembre. Du coup, je rete perplexe. Je me doute bien que la réalité n'est pas si terrible, mais ça fait peur.

Tu peux aimer systemd, c'est ton droit, mais de là à raconter n'importe quoi…

Il n'y a qu'un seul processus :

      fork + exec                  exec
Init --------------> Shell script -------> daemon

Eventuellement, le shell script peut effectuer des forks pour appeler des commandes externes, mais ce n'est pas forcément le cas, les scripts sont relativement simples.

Beaucoup de code répetter, j'aimerais bein que tu m'explique ou. Tout le code commun se trouve dans rc et rc.subr. Si tu y vois du code répetté, tu es obligé d'admettre que la description des units est du code (déclaratif certes) répétté, car cela fonctionne exactement pareil.

Pas de support de l'évenementiel, c'est vrai et c'est une raison historique. (à l'époque, c'était une raison de performances). Toutefoirs, ça dépend de ton usage encore une fois. Moi ça ne me dérange pas j'utilise un outil de supervision distinct pour faire ce genre de chose sur les daemons critiques. Bref ça dépend de ce dont tu as besoin.

Je ne comprends pas cette volonté d'imposer une technologie en voulant absolument convaincre toute le monde que c'est la meilleure pour eux et pour n'importe qui, et de toute manière tant pis si les gens sont pas convaincu parce qu'on fera tout pour les forcer à l'utiliser quand même.

Embrace and extend. Bienvenue chez Microsoft^W les partisans de systemd.

Remplacer Sendmail par un Ssmtp (ou similaire) serait aussi judicieux dans ce cas.

C'est le but de dma(8)

Il accepte les mails locaux, et les délivre aux utilisateurs, il envoit des mails locaux ou distant, mais ce n'est pas un serveur smtp qui écoute sur le port 25 exterieur.

Oui mais l'API noyau ne sert à rien en elle même, et ce n'est qu'une partie du travail. La manière d'écrire des applications a été finalisée que très récement avec la stabilisation du modèle daemon délégant son autorité, casper.
Ce travail n'a été mergé que très récement, il y quelques semaines. Je ne pense pas qu'on puisse le considérer comme stable, surtout quand on parle d'un mécanisme de sécurité. Je ne dirais pas que capsicum est fini/présent.

Principalement tirés de : https://wiki.freebsd.org/WhatsNew/FreeBSD10

logiciels par défauts

• le serveur DNS BIND est remplacé dans le système de bse par unbound et LDNS.

plateforme

• Freebsd tourne désormais sur EC2.

Noyau

• le support du pilote DRM/KMS radeon, tel que présent dans linux 3.8. une nouvelle console VT(9) aka newcons a vocation à remplacer l'ancien émulateur de console syscons. VT(9) fonctionne avec DRM, et il peut être utilisé quand KMS est activé, permettant d'avoir accés à une console après avoir démarer X avec un pilote KMS. newcons améliore aussi le support d'utf8.

• les buffers d'entrée sorties, notament utilisés par la couche de systèmes de fichiers virtuel, peuvent désormais être utilisés sans être mappés dans un espace d'addressage. C'est à dire qu'au lieu d'accéder à la mémoire en utilisant des addresses virtuelles pointant vers un buffer contigu, on n'a pas besoin de faire correspondre des pages virtuelles aux pages mémoire physiques pour y accéder. Une liste des pages mémoire physique est conservée, et la lecture écriture utilise cette liste de page directement. Cela améliore grandement les performances. En effet, les buffers sont en général mappés dans l'espace mémoire virtuel du noyau, qui est mappé pour tout les processus. Donc, quand on crée un buffer, on a pas besoin de modifier la table des pages mémoires virtuelles, et donc à notifier tout les cpus que le cache des pages virtuelles est invalide. Ce qui est un gros gain.

• le pilote netmap a été ajouté. Netmap est un framework qui permet d'utiliser directement les cartes réseau sans passer par la pile réseau et le mécanisme des sockets. La communication se fait par une zone mémoire mappée en espace utilisateur qui donne directement accés aux buffers de paquet, et à une copie des files TX et RX du pilote.

• Une nouvelle pile SCSI entièrement en espace noyau

Capsicum a beaucoup progressé, et sont API a été complétement changée depuis 9-RELEASE, mais ce n'est ps à proprement parlé terminé. Les logiciels/libs ne sont pas matures et pas tous mergés par défaut. Capsicum demande un très gros travail pour modifier les applications, mais de plus en plus d'application sont adaptées, et le modèle de sécurité a été affiné/implémenté depuis freebsd 9-RELEASE, toutefois je ne pense pas qu'il ne puisse être considéré comme suffisament fini avant freebsd 11.

ou alors tu peux utiliser les paquets pré-compilés.

Quel troll !

Haskell est quasiment aussi vieux que C++ (haskell début des années 90, C++ milieu des années 80), à 5 ou 6 ans près. Et le premier standard de Haskell date de la même année que le premier standard de C++.

Je suis d'accord, cet argument n'ira pas loin, il ne marche pas.

apparament, le noyau distribué par SteamOS est loin d'être un noyau vanilla, c'est un noyau avec divers patchs, certains de la branch -rt et des options de compilation spécifiques qui ne sont pas forcément ceux d'autres distributions. Rien n'interdit de compiler son propre noyau de la même manière, mais c'est à mentionner.

Le script rc ne ressemble pas du tout à du systemd : par exemple, de la configuration est accédée par rc.subr, ce qui n'est pas le cas dans systemd où toute la configuration pour le service est soit dans l'initscript soit gérée par le service dans sa propre configuration.

Grande nouvelle. systemd ne lit pas la conf de l'unit. ça c'est fort. Dans ce cas, pourquoi écrire un unit s'il n'est pas lu ?

Il y a inclusion d'un autre script (qui lui-même en inclus d'autres) dans les scripts shell, spécifiquement de /etc/rc.subr, qu'il faut ajouter au nombre de lignes nécessaires pour que cela fonctionne. Ce qui rajoute plusieurs dizaines de lignes tout de suite (surement plus de 200 lignes).

Impressionant comme raisonnement. rc.subr c'est l'init en lui même, ce n'est pas quelque chose que tu vas modifier toi même.

Un script systemd fait donc 1,5 millions de ligne de code, si on inclue tout le code de systemd. D'ailleurs, je me demande s'il ferait pas plusieurs 10aines de millions, car il a besoin de gcc pour fonctionner. En fait, ça doit même dépasser ça si on inclue le code de linux. Le niveau de troll est vraiment impressionant…

Le fait que l'équipe soit réduite peut entrainer des changements plus simplement, mais il ne faut pas se leurrer, linux bénéficie d'un temps de développement complétement incomparable à DragonFlyBSD. Mais DragonFly essaye de pallier à ces problèmes en ne supportant qu'une seule architecture et en réutilisant au maximum les pilotes de FreeBSD.

Mais je pense que ça a aussi ces effets bénéfiques. Par exemple, linux change très souvent ses API internes. Pour ce qui est d'un projet comme DragonFly, c'est juste inconcevable de modifier une API sans de bonne raison, et ça entraine surement plus de stabilité du code (pas au sens "moins de crash" mais au sens moins de changement des interfaces).

Personnellement, je l'utilise dans un cas bien précis. Pour installer des logiciels sur des machines où je ne suis pas administrateur. pkgsrc gère ça très bien, et c'est la meilleure solution que j'ai trouvé jusqu'a présent

Je suis d’accord, mais je dis que dans certaines circonstances ça peut être plus flexibles. Imaginons la X=truc, si un jour je décide de désactiver la fonctionnalité X de systemd, on pourra ne plus en tenir compte. Parce qu’on a beau vanter le fait que le Shell c’est turing-complet, il faut voir que de l’autre côté on a toujours le côté turing-complet mais avec l’avantage de l’unification de pas mal de variables.

Je vois pas du tout en quoi tu peux pas faire ça avec du shell et une lib comme rc.subr. D'ailleurs, si tu définis une variable qui n'est plus utilisée par la suite, elle n'est juste plus utilisée; Pas de soucis.

Sinon, je suis curieux de voir une machine de turing écrite en systemd :].

Bah pas de trucs à recopier dans un fichier de configuration, impossible de se tromper sur un nom de démon du coup, et puis il y a des fonctionnalités en plus (conf temporaire par exemple)! Extrait du man de systemctl pour la commande systemctl enable NAME:

Un peu comme, avec rcNG, rcenable NAME et rcdisable NAME tu veux dire ?

 The sh utility is the standard command interpreter for the system.  The
 current version of sh is close to the IEEE Std 1003.1 (``POSIX.1'')
 specification for the shell.  It only supports features designated by
 POSIX, plus a few Berkeley extensions.

En pratique, ces extensions sont très très limitées, comme par exemple le support de "echo -n" qui n'est pas strictement POSIX. Mais je serais curieux de trouver un script qui tourne sous ash mais pas sous bash/zsh/{m,pd,}ksh/csh.

Le vrai problème se situe plus dans les commandes appelées, mais il suffit de lire attentivement la section "Conforming to" des pages de manuels, comme quand tu codes en C.

Tout d’abord, la documentation dans le script, je trouve ça bof.

Literate programming FTW ! Plus sérieusement, je vois pas trop où la mettre d'autre, créer une page de manuel pour chaque script d'init semble un peu overkill.

D’autre part, même à fonctionnalité égale la syntaxe des fichiers d’unité systemd est plus sympa, avec User, Group ou TimeoutSec, OOMScoreAdjust (ces dernières fonctionnalités semblent manquer dans ton exemple…).

Mais, ce que j'essaye de dire, c'est que la syntaxe, c'est là même à 5 caractères près :

postgresql_user=pgsql

vs

User=pgsql

Franchement, faut être exigeant pour trouver l'une plus moche que l'autre ! L'overhead de :

postgresql_user=${postgresql_user:-"pgsql"}

est là pour permettre de configurer ça dans /etc/conf.d ou /etc/rc.conf justement. (ça veut dire, "si la variable est indéfinie, alors assigner "pgsql" comme valeur par défaut").

Dans tous les cas c’est pas le script Shell qui m’intéresse mais ce qui gravite autour et qui est assez rébarbatif à faire, et sur ce point-là systemd est quand même bon.

Tu parles de quoi, par exemple par curiosité ?

Je trouve pas ça super propre quand une commande peut faire les choses à notre place en faisant toutes les vérifications nécessaires (systemctl…)

Je suis curieux de savoir ce que tu entends par là

Il est (ou a été) utilisé

Se sera pas pas portable (bash d'un coté, Ash de l'autre, paths hardcodés, appels de fonctions spécifiques…)

Il y a quelque temps de cela, des gens se sont mis autour d'une table et ont écrit un truc nommé standard qu'ils ont appelé POSIX.
Ash est une implémentation du shell POSIX. Donc, en théorie, tout ce qui tourne avec Ash tourne avec n'importe quel shell POSIX. D'où l'intérêt.