Je suis d’accord pour les Flatpak, très pratique pour les logiciels propriétaires.
Le fait d’aller vers ce format est je pense la course à la nouvelle technologie.
Si une nouvelle version d’un logiciel a besoin d’un Qt plus récent par exemple, il est pris directement via le framework disponible en flatpak et on peut s’affranchir d’une bibliothèque obsolète sur le système source.
Je peux comprendre que certains restent sur une Debian stable par exemple tout en voulant des logiciels un poil plus récent qui corrigent parfois des bugs ou ajoutent des fonctionalités intéressantes.
Dans le cas d’un LibreOffice sous Debian, il y a en effet les DEB du site tu me diras, mais s’il y a une bibliothèque pas assez récente sur le système, tu es coincé.
Je privilégierais un Flatpak sur une base Debian au lieu d’un PPA ou dépôt tiers, qui causera, pour un logiciel, moins de soucis sur le long terme (car rappelons le, on n’installe pas son système toutes les semaines)
Flatpak c’est pas mal dans deux cas de figure. 1) Quand il faut installer des bousins propriétaires comme Teams, Skype, Zoom ou Spotify, et 2) Quand on a une appli avec des dépendances complexes et qu’on n’arrive plus à compiler une version récente sur sa distrib (comme Darktable > 4.0 sur une base RHEL 8.x par exemple). Ce qui est bien avec Flatpak, c’est que ça t’installe toute l’appli dans une sorte de bac à sable à part, ce qui peut être une base pratique pour isoler certaines applis potentiellement intrusives comme Skype.
Ceci étant dit, la tendance des distributions à aller de plus en plus vers ce format (ou vers Snap) pour leurs “App Stores” me paraît assez funeste. Faudrait rappeler aux mainteneurs des distributions la signification de “partagées” dans “bibliothèques partagées”.
Merci pour ton billet très intéressant.
“Du coup, pas de contenu statique, pas besoin de suivre les comptes. “ -> pas de contenu dynamique tu voulais écrire non?
Merci pour ton retour ! Alors je n’étais peut être pas assez clair dans mon introduction, mais mon ambition n’était sûrement pas de faire un état des lieux du champ des possibles sur le sujet, mais plus de partager mon approche personnelle, avec mes choix, par rapport à mes besoins.
J’ai le sentiment de par mon expérience que les debian-like sont plus populaires en termes de volume d’utilisateurs, et si j’en crois les estimations ce ressenti semble plutôt vraisemblable. Après, je ne compare en aucun cas la qualité ou les fonctionnalités de l’une ou l’autre des solutions, je ne connais pas suffisamment les *BSD pour juger. Mais je me met en todo de tester FreeBSD prochainement ;)
Pour résumer mon expérience, j’ai testé différentes choses (clairement pas toutes !) et je suis arrivé aujourd’hui à un fonctionnement qui me permet de facilement expérimenter de nouvelles choses, et de répondre à mes besoins long terme qui sont en effet d’héberger différents services. Je m’essaye à l’exercice de partager cette expérience, à la fois pour la faire connaître et également pour en débattre et collecter d’autres retours d’expérience qui peuvent me faire découvrir de nouvelles manières de faire. Donc en tout cas, merci d’avoir pris le temps de me lire et de me répondre ainsi !
Je sens que les esprits s’échauffent, je vous invite tous les deux à un dialogue dans le calme et le respect. Vous pouvez également échanger via les Messages privés du Jdh.
Un avis reposant sur des constatations cela ne compte pas d’après vous. L’écosystème Linux est plus dynamique et varié, ou représentatif (pour moi, ou, selon moi). Pourquoi l’ANSSI n’a t’elle pas repris OpenBSD mais CLIP OS ? Ne pas répondre, c’est une question rhétorique (argument d’autorité).
Je ne connais pas les SE BSD mais j’ai quand même envie de donner le mot de la fin (punch line). C’est spacieux et imposant mais c’est archaïque et limité. Tout repose dans les fondations. Trop rigide (ou monolithique). Évidemment difficile de changer un SE. Néanmoins, je pense que ce n’est pas aux utilisateurs d’ordinateurs de s’adapter. D’autant plus que, malgré une certaine notoriété, ils ne décollent pas pour le plus grand nombre. C’est le signe de quelque chose de fondamental. Une des raisons évidente est que le support ne suit pas (sauf pour les spécialistes), bien que les usages peuvent changer. Pour rebondir sur votre propos, on peut affirmer qu’utiliser une couche de compatibilité binaire dans le(s) noyau(x) BSD afin de pouvoir lancer de nouvelles applications (élaborées pour le noyau Linux) semble encore moins la panacée.
J’ai plusieurs ptites machines pour l’autohébergement :
routeur turris omnia sous openwrt dans lequel j’ai rajouté un SSD et qui héberge quelques containers :
container de backup qui fait du rsnapshot
blocky pour le résolveur dns
gitea pour héberger mes quelques repos persos
isso : système de commentaire de mon blog
samba : un partage de quelques fichiers
web : reverse proxy vers les autres machines
odroid hc2 sous alpine qui sert de NAS avec un disque sata et un en usb :
samba pour le partage de fichier
rsnapshot pour les backup
odroid n2 sous alpine qui sert pour les services un peu plus lourd mais qui pourrait au final disparaitre
nginx+php pour le web
knot : serveur DNS de mes domaines
molly-brown : serveur gemini
postgres : db pour quelques services
nib : bot irc
Un simili NUC sous alpine qui a vocation a potentiellement remplacer l’odroid n2 de par son stockage plus pérenne
syslog pour toutes les autres machines
grafana/influx/prometheus pour le monitoring de toutes les autres machines
postgres : pour remplacer celui sur la N2
mpv pour regarder des films
odroid hc2 sous alpine extérieur un nas en backup extérieur
samba
un VPS sous alpine extérieur associatif
nginx+php pour du web divers
postfix/dovecot/rspamd/redis : mes mails
knot : encore pour mes domaines
pleroma : mon compte dans le fediverse
postgres : pour les différents services
matrix2051 : pour me connecter à matrix via mon client irc
Le tout est interconnecté avec du wireguard avec uniquement du logiciel libre et sans dépendances à des services extérieurs sauf pour le VPS (mais c’est fait par du gentil).
Personnellement, j’ai eu du mal avec cet article, avec sa “vision” très limitée - descriptive - de l’auto-hébergement.
le premier point que j’ai trouvé intéressant est le fait de mentionner qu’on fait avec ce que l’on a sous la main, de fait qu’il existe différentes solutions matérielles ET logicielles.
mais :
ne citer que VirtualBox, pour parler de VM est très réducteur ; qu’il soit cité en exemple, soit… mais il y a d’autres logiciels, dont le bien plus stable qemu. Certains vanteront Docker - qui n’est pas de la virtualisation.
Dire qu’en général, on tourne sous Linux pour de l’auto-hébergement ; je trouve cela aussi très réducteur. Ne pas mentionner les *BSD est une faute en soit, dont FreeBSD qui est très utilisé pour l’auto-hébergement, voire en solutions commerciales, bien plus que Linux. (à mon sens).
(d’aucuns utilisent même NetBSD en ce sens… voire OpenBSD. Maintenant, il est vrai que ce sont des communautés très restreintes, très ciblées, voire élitistes)
Devoir utiliser fail2ban n’est pas la panacée, et me fait toujours l’effet d’un pansement appliqué sur une plaie béante.
Quant je vois comment le parefeu sous OpenBSD, à savoir PF, est capable de faire de la mitigation de ce genre d’exploits et autres tentatives, je reste surpris de la nécessité de ce genre d’outils sous Linux.
Après je rejoins l’avis de Lord aussi, faire de l’auto-hébergement, et se reposer sur certaines solutions nommées, me semblent hors du propos ; tu deviens dépendant de ces grands aspirateurs à données.
Pour finir, tu as raison de dire que l’objectif de l’auto-hébergement est d’apprendre, mais ce n’est qu’un des objectifs, le principal étant d’héberger ses propres données, quelque soit le service actif “derrière” ; mais je ne suis pas certain que ton expérience après plusieurs années soit l’itération qui restera réaliste pour d’aucuns. (personnellement, je trouve que tu te “compliques” la vie, avec ce genre de solution, utilisant des tiers majeurs).
L’important est de trouver ce qui vous convient le mieux.
Absolument. Le “problème” si c’est en un vraiment, et d’apprendre à trouver ce qui nous convient le mieux ;)
L’auto-hébergement est une solution qui permet de l’apprendre. :D
Personnellement, comme tu l’as certainement compris, je fais ça sous OpenBSD.
Donc, @home, je me suis fait un NAS, avec chiffrement des données en RAID 1 (le fameux RAID1C) + backup (borg). Ce NAS est éteint la nuit, par soucis d’économie d’énergie et peu de nécessités réelles à ce qu’il soit fonctionnel alors qu’on dodote. Il peut faire aussi office de serveur multimédia… et bien d’autres aspects.
Et, pendant plusieurs années, j’avais aussi mes services DNS+Web (nsd, DNSSEC, …, Nginx) sur un serveur @home, qui aujourd’hui sont hébergés chez openbsd.amsterdam - location de VM OpenBSD sur serveurs OpenBSD. Le principe est que cela me coûte moins cher en matériel+électricité de louer ma VM que d’avoir à la maison (achat, entretien, …). Il n’en reste pas moins que c’est géré par mes soins.
Les serveurs de mails relatifs à mes deux NDD sont aussi sous OpenBSD, avec l’outil principal qu’est OpenSMTPD, par un copain, @vinishor, serveurs lui aussi chez openbsd.ams.
À-propos d’un de mes deux NDD, pendant des années géré par Gandi, actuellement chez bookmyname. (pour des histoires de coût là encore ; depuis trois ans environ). L’autre étant un sous-domaine eu.org m’est totalement gratuit.
En amont de tout cela, j’ai un routeur, flashé sous OpenWRT, qui m’assure la protection “maison” dont j’ai besoin.
(d’ailleurs, pour la même raison d’économie d’énergie, les deux puces Wifi sont éteintes la nuit logiciellement… )
Et sinon, y’a de l’auto-hébergement… sous OpenBSD.
Et, perso, quand je compare à ce que je devais faire sous Linux (Debian/*Buntu), mon choix en restera là : OpenBSD.
Et, pour ceux qui veulent s’y mettre, @prx a écrit une excellent doc, en FR et en EN :
https://si3t.ch/ah
Mouai je suis pas spécialement d’accord quand tu dis qu’un VPS chez OVH c’est encore de l’auto-hébergement.
Tu ne maîtrises pas l’hyperviseur qui est l’infrastructure.
Après comme tu dis c’est à l’apprciation de chacun et il n’est pas possible de s’autohéberger à 100%, tu dépendras toujours à un moment ou un autre d’un presta (FAI, registrar, électricité, matériel…). Tout dépend de l’endroit où tu poses le curseur.
Mais bon Cloudflare et Google sont parmis les plus gros du monde pour des services Internet et donc dépendre d’eux est un peu l’antithèse de l’autohébergement à mon sens. Surtout que dans ton cas la plus-value semble de leurs services n’a pas l’air énorme…
Hmm, l’introduction du Pinephone (Pro) sur le site officiel est trop vague. On peut avoir l’impression que le projet évolue au fil de l’eau « […] but also to actively create a market for such a device ». Ou à moins d’être un « hard-core Linux user » ? Bref, comme beaucoup, pour l’utilisateur lambda, je vois pas ce qu’on peut en faire.
Je suis d’accord pour les Flatpak, très pratique pour les logiciels propriétaires.
Le fait d’aller vers ce format est je pense la course à la nouvelle technologie. Si une nouvelle version d’un logiciel a besoin d’un Qt plus récent par exemple, il est pris directement via le framework disponible en flatpak et on peut s’affranchir d’une bibliothèque obsolète sur le système source. Je peux comprendre que certains restent sur une Debian stable par exemple tout en voulant des logiciels un poil plus récent qui corrigent parfois des bugs ou ajoutent des fonctionalités intéressantes. Dans le cas d’un LibreOffice sous Debian, il y a en effet les DEB du site tu me diras, mais s’il y a une bibliothèque pas assez récente sur le système, tu es coincé. Je privilégierais un Flatpak sur une base Debian au lieu d’un PPA ou dépôt tiers, qui causera, pour un logiciel, moins de soucis sur le long terme (car rappelons le, on n’installe pas son système toutes les semaines)
Flatpak c’est pas mal dans deux cas de figure. 1) Quand il faut installer des bousins propriétaires comme Teams, Skype, Zoom ou Spotify, et 2) Quand on a une appli avec des dépendances complexes et qu’on n’arrive plus à compiler une version récente sur sa distrib (comme Darktable > 4.0 sur une base RHEL 8.x par exemple). Ce qui est bien avec Flatpak, c’est que ça t’installe toute l’appli dans une sorte de bac à sable à part, ce qui peut être une base pratique pour isoler certaines applis potentiellement intrusives comme Skype.
Ceci étant dit, la tendance des distributions à aller de plus en plus vers ce format (ou vers Snap) pour leurs “App Stores” me paraît assez funeste. Faudrait rappeler aux mainteneurs des distributions la signification de “partagées” dans “bibliothèques partagées”.
Oups >.< j’ai fini par m’emmêler entre statique et dynamique. C’est corrigé, merci pour la remarque :)
Merci pour ton billet très intéressant. “Du coup, pas de contenu statique, pas besoin de suivre les comptes. “ -> pas de contenu dynamique tu voulais écrire non?
Nokia et son n9 a visé le grand public aussi. C était un excellent système mais la c’est Microsoft qui l’a flingué.
Si vous souhaitez un phone alternatif, mais plus grand public (j’ ai pas dit ouvert hein). Il reste Jolla Mobile avec son Sailfish OS.
Merci pour ton retour ! Alors je n’étais peut être pas assez clair dans mon introduction, mais mon ambition n’était sûrement pas de faire un état des lieux du champ des possibles sur le sujet, mais plus de partager mon approche personnelle, avec mes choix, par rapport à mes besoins.
J’ai le sentiment de par mon expérience que les debian-like sont plus populaires en termes de volume d’utilisateurs, et si j’en crois les estimations ce ressenti semble plutôt vraisemblable. Après, je ne compare en aucun cas la qualité ou les fonctionnalités de l’une ou l’autre des solutions, je ne connais pas suffisamment les *BSD pour juger. Mais je me met en todo de tester FreeBSD prochainement ;)
Pour résumer mon expérience, j’ai testé différentes choses (clairement pas toutes !) et je suis arrivé aujourd’hui à un fonctionnement qui me permet de facilement expérimenter de nouvelles choses, et de répondre à mes besoins long terme qui sont en effet d’héberger différents services. Je m’essaye à l’exercice de partager cette expérience, à la fois pour la faire connaître et également pour en débattre et collecter d’autres retours d’expérience qui peuvent me faire découvrir de nouvelles manières de faire. Donc en tout cas, merci d’avoir pris le temps de me lire et de me répondre ainsi !
Perso, je suis très calme et tiens à le rester ;)
Et, je n’irais pas plus loin dans la discussion.
Je sens que les esprits s’échauffent, je vous invite tous les deux à un dialogue dans le calme et le respect. Vous pouvez également échanger via les Messages privés du Jdh.
Tcho !
Merci d’utiliser le biais cognitif d’argument d’autorité ; vous vous rendez compte que vous vous décrédibiliser par vos propres soins ?!
Vous vous rendez compte que vous comparez des informations complètement hors de propos l’une de l’autre pour essayer d’asseoir votre argument ?!
Bref…
Un avis reposant sur des constatations cela ne compte pas d’après vous. L’écosystème Linux est plus dynamique et varié, ou représentatif (pour moi, ou, selon moi). Pourquoi l’ANSSI n’a t’elle pas repris OpenBSD mais CLIP OS ? Ne pas répondre, c’est une question rhétorique (argument d’autorité).
Quand on ne connaît pas, on ne donne pas son avis ; et on ne se fait pas son avis, sur ce qu’on ne comprend pas. :(
Quand on ne connaît pas… le mieux est de chercher à connaître et comprendre. ;)
De fait, je ne répondrais pas plus à cette ineptie, cette mascarade de raisonnement.
EOD.
Je ne connais pas les SE BSD mais j’ai quand même envie de donner le mot de la fin (punch line). C’est spacieux et imposant mais c’est archaïque et limité. Tout repose dans les fondations. Trop rigide (ou monolithique). Évidemment difficile de changer un SE. Néanmoins, je pense que ce n’est pas aux utilisateurs d’ordinateurs de s’adapter. D’autant plus que, malgré une certaine notoriété, ils ne décollent pas pour le plus grand nombre. C’est le signe de quelque chose de fondamental. Une des raisons évidente est que le support ne suit pas (sauf pour les spécialistes), bien que les usages peuvent changer. Pour rebondir sur votre propos, on peut affirmer qu’utiliser une couche de compatibilité binaire dans le(s) noyau(x) BSD afin de pouvoir lancer de nouvelles applications (élaborées pour le noyau Linux) semble encore moins la panacée.
J’ai plusieurs ptites machines pour l’autohébergement :
Le tout est interconnecté avec du wireguard avec uniquement du logiciel libre et sans dépendances à des services extérieurs sauf pour le VPS (mais c’est fait par du gentil).
Personnellement, j’ai eu du mal avec cet article, avec sa “vision” très limitée - descriptive - de l’auto-hébergement.
le premier point que j’ai trouvé intéressant est le fait de mentionner qu’on fait avec ce que l’on a sous la main, de fait qu’il existe différentes solutions matérielles ET logicielles. mais :
Dire qu’en général, on tourne sous Linux pour de l’auto-hébergement ; je trouve cela aussi très réducteur. Ne pas mentionner les *BSD est une faute en soit, dont FreeBSD qui est très utilisé pour l’auto-hébergement, voire en solutions commerciales, bien plus que Linux. (à mon sens). (d’aucuns utilisent même NetBSD en ce sens… voire OpenBSD. Maintenant, il est vrai que ce sont des communautés très restreintes, très ciblées, voire élitistes)
Devoir utiliser fail2ban n’est pas la panacée, et me fait toujours l’effet d’un pansement appliqué sur une plaie béante. Quant je vois comment le parefeu sous OpenBSD, à savoir PF, est capable de faire de la mitigation de ce genre d’exploits et autres tentatives, je reste surpris de la nécessité de ce genre d’outils sous Linux.
Après je rejoins l’avis de Lord aussi, faire de l’auto-hébergement, et se reposer sur certaines solutions nommées, me semblent hors du propos ; tu deviens dépendant de ces grands aspirateurs à données.
Pour finir, tu as raison de dire que l’objectif de l’auto-hébergement est d’apprendre, mais ce n’est qu’un des objectifs, le principal étant d’héberger ses propres données, quelque soit le service actif “derrière” ; mais je ne suis pas certain que ton expérience après plusieurs années soit l’itération qui restera réaliste pour d’aucuns. (personnellement, je trouve que tu te “compliques” la vie, avec ce genre de solution, utilisant des tiers majeurs).
Absolument. Le “problème” si c’est en un vraiment, et d’apprendre à trouver ce qui nous convient le mieux ;) L’auto-hébergement est une solution qui permet de l’apprendre. :D
Personnellement, comme tu l’as certainement compris, je fais ça sous OpenBSD.
Donc, @home, je me suis fait un NAS, avec chiffrement des données en RAID 1 (le fameux RAID1C) + backup (borg). Ce NAS est éteint la nuit, par soucis d’économie d’énergie et peu de nécessités réelles à ce qu’il soit fonctionnel alors qu’on dodote. Il peut faire aussi office de serveur multimédia… et bien d’autres aspects.
Et, pendant plusieurs années, j’avais aussi mes services DNS+Web (nsd, DNSSEC, …, Nginx) sur un serveur @home, qui aujourd’hui sont hébergés chez openbsd.amsterdam - location de VM OpenBSD sur serveurs OpenBSD. Le principe est que cela me coûte moins cher en matériel+électricité de louer ma VM que d’avoir à la maison (achat, entretien, …). Il n’en reste pas moins que c’est géré par mes soins. Les serveurs de mails relatifs à mes deux NDD sont aussi sous OpenBSD, avec l’outil principal qu’est OpenSMTPD, par un copain, @vinishor, serveurs lui aussi chez openbsd.ams.
À-propos d’un de mes deux NDD, pendant des années géré par Gandi, actuellement chez bookmyname. (pour des histoires de coût là encore ; depuis trois ans environ). L’autre étant un sous-domaine eu.org m’est totalement gratuit.
En amont de tout cela, j’ai un routeur, flashé sous OpenWRT, qui m’assure la protection “maison” dont j’ai besoin. (d’ailleurs, pour la même raison d’économie d’énergie, les deux puces Wifi sont éteintes la nuit logiciellement… )
Ce n’est pas vraiment correct d’affirmer cela, bien que je comprenne ce que vous avez voulu dire : « […] There is a long road ahead of us, all of us, and it will require time and effort for the software to reach a degree of maturity that would satisfy mainstream users. »
Ils ne visent absolument pas le marché des utilisateurs grand publique.
Et sinon, y’a de l’auto-hébergement… sous OpenBSD. Et, perso, quand je compare à ce que je devais faire sous Linux (Debian/*Buntu), mon choix en restera là : OpenBSD.
Et, pour ceux qui veulent s’y mettre, @prx a écrit une excellent doc, en FR et en EN : https://si3t.ch/ah
Mouai je suis pas spécialement d’accord quand tu dis qu’un VPS chez OVH c’est encore de l’auto-hébergement. Tu ne maîtrises pas l’hyperviseur qui est l’infrastructure.
Après comme tu dis c’est à l’apprciation de chacun et il n’est pas possible de s’autohéberger à 100%, tu dépendras toujours à un moment ou un autre d’un presta (FAI, registrar, électricité, matériel…). Tout dépend de l’endroit où tu poses le curseur.
Mais bon Cloudflare et Google sont parmis les plus gros du monde pour des services Internet et donc dépendre d’eux est un peu l’antithèse de l’autohébergement à mon sens. Surtout que dans ton cas la plus-value semble de leurs services n’a pas l’air énorme…
Hmm, l’introduction du Pinephone (Pro) sur le site officiel est trop vague. On peut avoir l’impression que le projet évolue au fil de l’eau « […] but also to actively create a market for such a device ». Ou à moins d’être un « hard-core Linux user » ? Bref, comme beaucoup, pour l’utilisateur lambda, je vois pas ce qu’on peut en faire.