Title: [FR] Pourquoi j'utilise OpenBSD

	Title: [FR] Pourquoi j'utilise OpenBSD
	Author: Solène
	Date: 04 January 2021
	Tags: openbsd francais
	Description:

	Dans ce billet je vais vous livrer mon ressenti sur ce que j'aime dans
	OpenBSD.

	### Respect de la vie privée

	Il n'y a aucune télémétrie dans OpenBSD, je n'ai pas à m'inquiéter
	pour le respect de ma vie privée. Pour rappel, la télémétrie est un
	mécanisme qui consiste à remonter des informations de l'utilisateur
	afin d'analyser l'utilisation du produit.
	De plus, le défaut du système a été de désactiver entièrement le
	micro, à moins d'une intervention avec le compte root, le microphone
	enregistre du silence (ce qui permet de ne pas le bloquer quant à des
	droits d'utilisation). A venir dans 6.9, la caméra suit le même
	chemin et sera désactivée par défaut. Il s'agit pour moi d'un signal
	fort quant à la nécessité de protéger l'utilisateur.


	### Navigateurs web sécurisés

	Avec l'ajout des fonctionnalités de sécurité (pledge et surtout
	unveil) dans les sources de Firefox et Chromium, je suis plus sereine
	quant à leur utilisation au quotidien. À l'heure actuelle,
	l'utilisation d'un navigateur web est quasiment incontournable, mais
	ils sont à la fois devenus extrêmement complexes et mal maîtrisés.
	L'exécution de code côté client via Javascript qui a de plus en plus
	de possibilité, de performances et de nécessités, ajouter un peu de
	sécurité dans l'équation était nécessaire. Bien que ces ajouts
	soient parfois un peu dérangeants à l'utilisation, je suis vraiment
	heureuse de pouvoir en bénéficier.
	Avec ces sécurités ajoutés (par défaut), les navigateurs cités
	précédemment ne peuvent pas parcourir les répertoires en dehors de
	ce qui leur est nécessaire à leur bon fonctionnement plus les
	dossiers ~/Téléchargements/ et /tmp/. Ainsi, des emplacements comme
	~/Documents ou ~/.gnupg sont totalement inaccessibles ce qui limite
	grandement les risques d'exfiltration de données par le navigateur.
	On pourrait refaire grossièrement la même fonctionnalité sous Linux
	en utilisant AppArmor mais l'intégration est extrêmement compliquée
	(là où c'est par défaut sur OpenBSD) et un peu moins efficace, il
	est plus facile d'agir au bon moment depuis le code plutôt qu'en
	encapsulant le programme entier d'un groupe de règles.


	### Pare-feu PF

	Avec PF, il est très simple de vérifier le fichier de configuration
	pour comprendre les règles en place sur le serveur ou un ordinateur de
	bureau. La centralisation des règles dans un fichier et le système de
	macros permet d'écrire des règles simples et lisibles.

	J'utilise énormément la fonctionnalité de gestion de bande passante
	pour limiter le débit de certaines applications qui n'offrent pas ce
	réglage. C'est très important pour moi n'étant pas la seule
	utilisatrice du réseau et ayant une connexion assez lente.
	Sous Linux, il est possible d'utiliser les programmes trickle ou
	wondershaper pour mettre en place des limitations de bande passante,
	par contre, iptables est un cauchemar à utiliser en tant que firewall!

	### C'est stable

	A part à l'utilisation sur du matériel peu répandu, OpenBSD est
	très stable et fiable. Je peux facilement atteindre deux semaines
	d'uptime sur mon pc de bureau avec plusieurs mises en veille par jour.
	Mes serveurs OpenBSD tournent 24/24 sans problème depuis des années.
	Je dépasse rarement deux semaines puisque je dois mettre à jour le
	système de temps en temps pour continuer les développements sur
	OpenBSD :)


	### Peu de maintenance

	Garder à jour un système OpenBSD est très simple. Je lance les
	commandes syspatch et pkg_add -u tous les jours pour garder mes
	serveurs à jour. Une mise à jour tous les six mois est nécessaire
	pour monter en version mais à part quelques instructions spécifiques
	qui peuvent parfois arriver, une mise à jour ressemble à ça :

	```liste de commandes shells qui commencent par un # pour préciser que l'utili…
	# sysupgrade
	[..attendre un peu..]
	# pkg_add -u
	# reboot
	```

	### Documentation de qualité

	Installer OpenBSD avec un chiffrement complet du disque est très
	facile (il faudra que j'écrive un billet sur l'importance de chiffrer
	ses disques et téléphones).
	La documentation officielle expliquant l'installation d'un routeur avec
	NAT est parfaitement expliquée pas à pas, c'est une référence dès
	qu'il s'agit d'installer un routeur.
	Tous les binaires du système de base (ça ne compte pas les packages)
	ont une documentation, ainsi que leurs fichiers de configuration.
	Le site internet, la FAQ officielle et les pages de man sont les seules
	ressources nécessaires pour s'en sortir. Elles représentent un gros
	morceau, il n'est pas toujours facile de s'y retrouve mais tout y est.
	Si je devais me débrouiller pendant un moment sans internet, je
	préférerais largement être sur un système OpenBSD. La documentation
	des pages de man suffit en général à s'en sortir.
	Imaginez mettre en place un routeur qui fait du trafic shaping sous
	OpenBSD ou Linux sans l'aide de documents extérieurs au système.
	Personnellement je choisis OpenBSD à 100% pour ça :)


	### Facilité de contribution

	J'adore vraiment la façon dont OpenBSD gère les contributions. Je
	récupère les sources sur mon système et je procède aux
	modifications, je génère un fichier de diff (différence entre
	avant/après) et je l'envoie sur la liste de diffusion. Tout ça peut
	être fait en console avec des outils que je connais déjà (git/cvs)
	et des emails.
	Parfois, les nouveaux contributeurs peuvent penser que les personnes
	qui répondent ne sont vraiment pas sympa. Ce n'est pas vrai. Si
	vous envoyez un diff et que vous recevez une critique, cela signifie
	déjà qu'on vous accorde du temps pour vous expliquer ce qui peut
	être amélioré. Je peux comprendre que cela puisse paraître rude
	pour certaines personnes, mais ce n'est pas ça du tout.

	Cette année, j'ai fait quelques modestes contributions aux projets
	OpenIndiana et NixOS, c'était l'occasion de découvrir comment ces
	projets gèrent les contributions. Les deux utilisent github et la
	manière de faire est très intéressante, mais la comprendre demande
	beaucoup de travail car c'est relativement compliqué.
	Site officiel d'OpenIndiana
	Site officiel de NixOS

	La méthode de contribution nécessite un compte sur Github, de faire
	un fork du projet, cloner le fork en local, créer une branche, faire
	les modifications en local, envoyer le fork sur son compte github et
	utiliser l'interface web de github pour faire un "pull request". Ça
	c'est la version courte. Sur NixOS, ma première tentative de faire un
	pull request s'est terminée par une demande contenant six mois de
	commits en plus de mon petit changement. Avec une bonne documentation
	et de l'entrainement c'est tout à fait surmontable. Cette méthode de
	travail présente certains avantages comme le suivi des contributeurs,
	l'intégration continue ou la facilité de critique de code, mais c'est
	rebutoire au possible pour les nouveaux.

	### Packages top qualité

	Mon opinion est sûrement biaisée ici (bien plus que pour les
	éléments précédents) mais je pense sincèrement que les packages
	d'OpenBSD sont de très bonne qualité. La plupart d'entre eux
	fonctionnent "out of the box" avec des paramètres par défaut
	corrects.
	Les packages qui nécessitent des instructions particulières sont
	fournis avec un fichier "readme" expliquant ce qui est nécessaire, par
	exemple créer certains répertoires avec des droits particuliers ou
	comment mettre à jour depuis une version précédente.

	Même si par manque de contributeurs et de temps (en plus de certains
	programmes utilisant beaucoup de linuxismes pour être faciles à
	porter), la plupart des programmes libres majeurs sont disponibles et
	fonctionnent très bien.

	Je profite de l'occasion de ce billet pour critiquer une tendance au
	sein du monde Open Source.

	* les programmes distribués avec flatpak / docker / snap fonctionnent
	très bien sur Linux mais sont hostiles envers les autres systèmes.
	Ils utilisent souvent des fonctionnalités spécifiques à Linux et les
	méthodes de compilation sont tournées vers Linux. Cela complique
	grandement le portage de ces applications vers d'autres systèmes.
	* les programmes avec nodeJS: ils nécessitent parfois des centaines
	voir des milliers des libs et certaines sont mêmes un peu bancales.
	C'est vraiment compliqué de faire fonctionner ces programmes sur
	OpenBSD. Certaines libs vont même jusqu'à embarquer du code rust ou
	à télécharger un binaire statique sur un serveur distant sans
	solution de compilation si nécessaire ou sans regardant si ce binaire
	est disponible dans $PATH. On y trouve des aberrations incroyables.
	* les programmes nécessitant git pour compiler: le système de
	compilation dans les ports d'OpenBSD fait de son mieux pour faire au
	plus propre. L'utilisateur dédié à la création des packages n'a pas
	du tout accès à internet (bloqué par le pare-feu avec une règle par
	défaut) et ne pourra pas exécuter de commande git pour récupérer du
	code. Il n'y a aucune raison pour que la compilation d'un programme
	nécessite de télécharger du code au milieu de l'étape de
	compilation!

	Évidemment je comprends que ces trois points ci-dessus existent car
	cela facilite la vie des développeurs, mais si vous écrivez un
	programme et que vous le publiez, ce serait très sympa de penser aux
	systèmes non-linux. N'hésite pas à demander sur les réseaux sociaux
	si quelqu'un veut tester votre code sur un autre système que Linux. On
	adore les développeurs "BSD friendly" qui acceptent nos patches pour
	améliorer le support OpenBSD.

	### Ce que j'aimerais voir évoluer

	Il y a certaines choses où j'aimerais voir OpenBSD s'améliorer. Cette
	liste est personnelle et reflète pas l'opinion des membres du projet
	OpenBSD.

	* Meilleur support ARM
	* Débit du Wifi
	* Meilleures performances (mais ça s'améliore un peu à chaque
	version)
	* Améliorations de FFS (lors de crashs j'ai parfois des fichiers dans
	lost+found)
	* Un pkg_add -u plus rapide
	* Support du décodage vidéo matériel
	* Meilleur support de FUSE avec une possibilité de monter des
	systèmes CIFS/samba
	* Plus de contributeurs

	Je suis consciente de tout le travail nécessaire ici, et ce n'est
	certainement pas moi qui vais y faire quelque chose. J'aimerais que
	cela s'améliore sans toutefois me plaindre de la situation actuelle :)
	Malheureusement, tout le monde sait qu'OpenBSD évolue par un travail
	acharné et pas en envoyant une liste de souhaits aux développeurs :)
	Quand on pense à ce qu'arrive à faire une petite équipe (environ 150
	développeurs impliqués sur les dernières versions) en comparaison
	d'autres systèmes majeurs, je pense qu'on est assez efficace!