La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Autres systèmes d'exploitation => Discussion démarrée par: pitalugue le 22 avril 2022 à 09:02:01
-
Sortie semestrielle d'OpenBSD, la 7.1 depuis hier.
https://www.openbsd.org/71.html
-
Sortie d'OpenBSD 7.2 ce jour.
Le cycle des sorties d'OpenBSD ne tombe plus systematiquement sur le 1er mai et 1er novembre depuis quelque temps mais globalement elles restent espacees de 6 mois. Le support est assure pour la derniere version publiee et la precedente. La numerotation de ces versions ne suit pas un schema version_majeure.version_mineure, aussi 7.2 pourrait etre lue comme 72, il s'agit de la 53eme publication de 2.1 a 7.2 + une version anterieure.
https://www.openbsd.org/72.html
A noter , deux petits patchs devraient etre rapidement mis a disposition (ASN1 et x509) car corriges depuis le gel definitif du code de la 7.2 le 27 septembre.
Il y a longtemps eu trois varietes: release / stable / current, chacune ayant son arbre code source. Il etait possible de migrer binairement entre versions et aussi via un snapshot de developpement. Les paquets externes sont la aussi disponibles sous forme source a compiler dans un port tree ou sous forme binaire pour release et snapshot. Le systeme gere excellement les jeux de dependance entre ces paquets.
Ceci existe toujours mais avec deux caracteristiques supplementaires depuis quelques annees:
- on peut ajouter des patchs a "release" par binaire, plus besoin de compiler.
- certains paquets externes sont patches et mis a disposition deja recompiles entre deux versions d'OpenBSD, ils sont dits "stable" mais disponibles pour la branche "release"
De fait, plus beaucoup de raisons de ne pas suivre la branche release versionee tous les 6 mois et gerer tout ou la majorite des mises-a-jour via binaires.
A noter pour les aventuriers que les snapshots contiennent parfois du code (compile donc) qui n'est pas encore disponible dans "current" qui represente la branche publique de developpement.
-
Bien que ce message porte sur OpenSSH et non pas OpenBSD, je le place ici puisque le premier est chapeauté par le second.
La release 8.8 avait déprécié les clefs RSA en SHA1 et incité le mouvement vers ed25519.
Il est question que ssh-keygen génère ed25519 par défaut désormais https://marc.info/?l=openbsd-tech&m=166774468028210&w=2
La prochaine version d'OpenSSH nous indiquera si c'est acté mais par anticipation, prudence pour vos procédures automatisées ou certains accès cloud.
Au passage, la release 9.0 d'avril dernier avait au passage introduit une première lutte pour résister à l'informatique quantique. Et cela évolue https://marc.info/?l=openbsd-tech&m=167358832318821&w=2
Et contrairement à la remarque précédente, ceci est acté dans le code depuis mi-janvier.
-
Bien que ce message porte sur OpenSSH et non pas OpenBSD, je le place ici puisque le premier est chapeauté par le second.
La release 8.8 avait déprécié les clefs RSA en SHA1 et incité le mouvement vers ed25519.
Il est question que ssh-keygen génère ed25519 par défaut désormais https://marc.info/?l=openbsd-tech&m=166774468028210&w=2
La prochaine version d'OpenSSH nous indiquera si c'est acté mais par anticipation, prudence pour vos procédures automatisées ou certains accès cloud.
Au passage, la release 9.0 d'avril dernier avait au passage introduit une première lutte pour résister à l'informatique quantique. Et cela évolue https://marc.info/?l=openbsd-tech&m=167358832318821&w=2
Et contrairement à la remarque précédente, ceci est acté dans le code depuis mi-janvier.
hello
si je m'attendais à voir un sujet openbsd par ici...
après tout comme sur reddit/hfr/consors..
cependant c'ets un os orienté serveur, et ultra sécurité
j'ai vu le projet isotop, assez porteur
je me suis interrogé sur un équivalent d'yunohost basé sur bsd..
mais j'admets, qu'à minima utiliser openbsd dans les telcos pour remplacer la box abonné final est un projet intéressant
surtout si on met en avant le coté cyber... et en ces temps :)
-
À propos d'OpenBSD, j'avais trouvé intéressant ce site : https://isopenbsdsecu.re/
-
À propos d'OpenBSD, j'avais trouvé intéressant ce site : https://isopenbsdsecu.re/
et
https://why-openbsd.rocks/
mais la problématique d'openbsd, c'est doublement :
que sur laptop/desktop, à moins d'avoir un pc récent, c'est assez lourd/lent comme système
et le bat blesse aussi sur la prise en charge du matériel : cartes graphiques , cartes wifi.. sur sept ordis portables testés, seuls 2 machines ont les deux, fonctionnelles et rrepérées (nvidia, broadcom, catastrophique dans l'OSS)
sinon pour du serveur/routeur, ca passe..
-
Quand je vois l'énergie importante qui est mis en place coté Linux pour suivre le matériel, je me doute que cela doit être compliqué coté BSD.
Il suffit de regarder https://launchpad.net/ubuntu/+source/linux-firmware/+changelog ce sont une centaine de nouveaux matériels rajoutés chaque mois (des touches propriétaires d'un PC portable aux cartes réseaux 100 Gb/s, c'est varié).
Adolescent, j'étais fan de BeOS, un OS alternatif français et sa grande faiblesse était le support matériel limité (il fallait s'assembler un PC avec les composants supportés pour avoir un truc vraiment fonctionnel).
En 2023, la marche pour créer un nouveau système d'exploitation qui a un support des n'importe quel PC semble désormais trop haute...
OpenBSD arrive à récupérer des dev réalisés pour Linux coté drivers ?
-
Quand je vois l'énergie importante qui est mis en place coté Linux pour suivre le matériel, je me doute que cela doit être compliqué coté BSD.
Il suffit de regarder https://launchpad.net/ubuntu/+source/linux-firmware/+changelog ce sont une centaine de nouveaux matériels rajoutés chaque mois (des touches propriétaires d'un PC portable aux cartes réseaux 100 Gb/s, c'est varié).
Adolescent, j'étais fan de BeOS, un OS alternatif français et sa grande faiblesse était le support matériel limité (il fallait s'assembler un PC avec les composants supportés pour avoir un truc vraiment fonctionnel).
En 2023, la marche pour créer un nouveau système d'exploitation qui a un support des n'importe quel PC semble désormais trop haute...
OpenBSD arrive à récupérer des dev réalisés pour Linux coté drivers ?
mwif, dans les SE "récents" qui font un peu "old-school", ya surtout haiku qui reprend beos sur certaines lignes.. et qui colle une volée énorme à reactos, jamais vraiment stable en presque vingt ans de dev.. alors qu'haiku (pour l'avoir testé) est bien plus efficace sur certains points..
quant aux drivers coté openbsd, leur logique est simple :
soit c'est OSS et en général ca passe et c'este bien supporté
soit ils se débrouillent pour faire au mieux.. mais c'est clair que pour les cartes broadcom, yen a moins d'une sur deux qu'est supportée
le pire c'est vraiment nvidia, c'est de l'affichage basique de chez basique
là où je crois que ubuntu et meme debian commencent à intégrer du "blob/binaire" pour supporter du hardware, histoire de pas trop couler sous les critiques du "sam'ach'pas", openbsd n'en est pas vraiment ouvert..
-
hello
si je m'attendais à voir un sujet openbsd par ici...
...
mais j'admets, qu'à minima utiliser openbsd dans les telcos pour remplacer la box abonné final est un projet intéressant
surtout si on met en avant le coté cyber... et en ces temps :)
Le fil de discussion n'a aucune ambition. Juste diffuser un peu d'information auprès de ceux qui connaissent déjà mais ne surveillent pas précisément le calendrier de l'OS.
Ce forum a des profils de tout type en objectif et compétence. Il est probable que le projet profiterait à plusieurs forumistes mais il ne s'agit pas d'inciter des gens qui luttent déjà avec des tutos et des OS qui présentent des interfaces visant à faciliter les prises en main. Ce serait ne rendre service ni aux gens ni au projet. Même si l'usage de l'OS est précisément facile et documenté, la première marche est un peu haute, il faut non seulement avoir un peu de connaissance Unix mais surtout bien connaître les protocoles qu'on veut manipuler.
J'ai fait le même chose en signalant le cycle de vie de FreeBSD et peut-être même un ou deux messages sur HardenedBSD et cheriBSD. Idem Linux From Scratch.
-
À propos d'OpenBSD, j'avais trouvé intéressant ce site : https://isopenbsdsecu.re/
De temps en temps on a droit à ce genre de papier. Ca fait plus de vingt ans qu'il faut déboulonner la statue, briser le totem et rayer le nom du dictateur bénévole d'OpenBSD.
Cependant quand on va au-delà des dires des "rézosocio" et de quelques aigreurs locales, le constat varie peu lorsqu'on scrute les CVE et les zero days en nombre et sévérité chaque année affectant réellement tel ou tel système.
J'utilise l'OS des "masturbating monkeys" depuis 2006 et, personnellement, rien à reprocher question sécurité et on devrait même dire approche de la sécurité. Ironiquement c'est après des incidents majeurs pour lesquels l'OS fut mieux prémuni que ce genre de papier se pointe comme si cela pouvait justifier la propre situation d'autres OS.
Parfois on vire dans la tragi-comédie. Par exemple depuis quelques mois le projet s'attaque à un aspect particulier de protection mémoire et dès l'annonce publique on a vu fleurir des commentaires sur l'inutilité de la démarche, sachant que d'autres OS voudraient exploiter des caractéristiques internes de processeurs récents pour se prémunir. Le gag c'est quand dans la justification on colle des échanges où un ingé Intel stipule que cela ne couvre pas tous les cas. Et puis après avoir subi spectre et consorts, même en tant que béotien je trouve curieux de s'en remettre aux fabricants de cpu pour garantir certains aspects de sécurité. Comme si on n'avait rien appris.
La meilleure reste pour moi quand "ils" ont fait croire que les services gouvernementaux américains avaient placé, il y a longtemps, une faille via le système de génération de nombre aléatoire / entropie. Il avait quand même fallu procéder à un audit. C'est dingue ce que l'égo de certains amène à faire. Là encore si j'ai bonne mémoire c'était quand on s'était aperçu de la faiblesse de ces RNG dans d'autres OSes.
Ceci dit dans le cadre des usages restreints que la plupart des gens sur ce forum (j'imagine) ont de leur infrastructure domestique, ce qui importe le plus c'est la correcte mise en oeuvre des défenses quel que soit l'OS, plutôt que de savoir qui a la plus grosse.
-
Quand je vois l'énergie importante qui est mis en place coté Linux pour suivre le matériel, je me doute que cela doit être compliqué coté BSD.
...
OpenBSD arrive à récupérer des dev réalisés pour Linux coté drivers ?
Oui et non, n'étant pas partie prenante du projet, c'est un peu délicat de leur prêter voix. Néanmoins je crois que dans la conduite de ce projet il manque probablement plus d'argent que de bras (ou plutôt de neurones).
Je pense raisonnablement qu'ils n'ont jamais eu l'ambition d'une couverture universelle du matériel. C'est sélectif et en fonction de ce que les membres utilisent eux-mêmes. Par exemple, pour des ordis portables on devrait trouver un support historique pour la gamme thinkpad IBM/Lenovo et les machines Apple. Bien sûr il faut couvrir des indispensables et parfois ça manque.
Quant aux drivers fournis par les constructeurs comme sous Linux par exemple, je crois qu'il leur importe encore plus d'avoir, en fait, accès aux documentations et spécifications plutôt que d'avoir un code qui tombe du ciel.
Pour ce qui est de secteurs essentiels d'un OS, du genre libc, libcrypto, intégration/bascule vers un nouveau compilateur du système etc, c'est plus la qualité d'un petit nombre qui compte et au contraire ils sont plutôt en pointe. Il faut aussi noter l'éco-système de fonctions réseaux, il semble y a voir un lien nourri actuellement avec RIPE, dans les deux sens. Probablement ce dernier voit là une opportunité de diversifier l'offre pour certains daemons et fonctions.
Pour ce qui est de l'import systématique de code Linux, on voit régulièrement des commits pour le graphique Intel et AMD mais je n'en connais pas la nature exacte. C'est différent de FreeBSD qui a créé une couche de compatibilité du noyau et aspire ainsi graphique et WiFi. Par contre, il est fréquent que l'apparition d'un pilote dans un des BSD finisse par être adapté par les autres.
Personnellement, ce que j'attends le plus pour l'OS est encore différent: la fourniture d'un système fichier/stockage moderne, je croise les doigts pour qu'Hammer2 ou équivalent finisse par y atterrir un jour.
-
pour le support matériel effectivement c'est très orienté sur la clareté du code, et des différents docs à dispo
c'est clair que openbsd n'a pas l'ambition de ses organisateurs, à savoir outrepasser le simple domaine routeur/serveur (aka passif) face aux actifs appareils utilisateurs
ils sont hyper drastiques sur l'ouverture du code source, et des licences correspondantes
pour hammer2 je crois que c'est mal barré, au meme titre que d'autres implémentations.. je crois savoir que le licensing joue presque autant que la dispo des inforamtions afin d'adapter le matos à openbsd
openbsd/netbsd partagent beaucoup de choses, mais sont clairement une chapelle à part de freebsd ; ce dernier partage avec haiku sa pile réseau, par ex (donc beaucoup plus de composants supportés sur haikus qu'opensd..)
edit: un OS réseau tournant sous oepnbsd (cas très rare):
https://marketplace.cloud.vmware.com/services/details/halon-vsr-virtual-security-router/?slug=true
-
OpenBSD 7.3 sort ce jour et cette version particulière me fait plaisir. https://www.openbsd.org/73.html
Hasard du calendrier, la sortie se télescope avec FreeBSD 13.2 qui sera officiellement annoncé demain. Les premiers un peu en avance de leur calendrier semestriel habituel et les seconds en léger retard après 6 release candidate nécessaires pour détection et corrections de fin de cycle.
En terme de performance il y a plusieurs limitations qui se font lever. Autrement ca avance sur la plupart des fronts.
Néanmoins j'attends avec impatience l'incorporation dans le système même des fonctions de Gelatod plus en adéquation avec la structure et les exigences de l'OS et, un jour peut-être, des avancées pour le sous-système stockage.
On ne peut également pas ignorer l'introduction de mesures de sécurité assez décriées. Il se trouve que cela a été le cas de la plupart des apports sécuritaires d'OpenBSD avant que cela devienne des implémentations largement adoptées. Même en étant non spécialiste mais en ayant un minimum de connaissances, la version orale des explications livre bien plus que la présentation écrite brute et les commentaires de tout poil sur Internet. On comprend aussi qu'outre fermer déjà quelques portes et complexifier certaines attaques, les auteurs ont autre chose à l'esprit qu'ils comptent livrer au cours des trois ans qui viennent. Ce qui se joue aussi c'est l'adoption de bonnes pratiques dans l'éco-système global. Nous verrons bien.
-
Merci. Je n'ai pas bien compris : l'introduction de mesures de sécurité assez décriées, c'était déjà en place sur OpenBSD et cela arrive dans FreeBSD ?
N'hésite pas à faire un comparatif des avantages / inconvenant de OpenBSD 7.3 vs FreeBSD 13.2 vs Linux.
Imagine une personne qui connait un peu Linux et qui voudrait essayer BSD : Que lui conseiller ?
Peut-être séparer un usage serveur et usage desktop.
-
Merci. Je n'ai pas bien compris : l'introduction de mesures de sécurité assez décriées, c'était déjà en place sur OpenBSD et cela arrive dans FreeBSD ?
N'hésite pas à faire un comparatif des avantages / inconvenant de OpenBSD 7.3 vs FreeBSD 13.2 vs Linux.
Imagine une personne qui connait un peu Linux et qui voudrait essayer BSD : Que lui conseiller ?
Peut-être séparer un usage serveur et usage desktop.
à titre personnel, je peux donner mon retour d'expérience
cela ne vaut pas sainte parole, mais :
openbsd n'est pas vraiment orienté desktop, bien que son utilisation y soit possible : l'interface, kde, gnome, meme xfce, reste assez modérée par le système à contrario de liux
pour un utilisateur linux avancé, ou expert, aller sur openbsd est réalisable, le plus dur sera l'installation du système, en ligne de commandes uniquement
pour un néo-nuxien, entendre moins de cinq ans de banquise, aller d'abord sur freebsd ; par ex hellobsd & nomadbsd ont été réalisés pour une approche différente de linux, en s'extirpant du bureau de macos, notamment pour le premier
pour openbsd ya bien isotop qui fait dans l'environnement de bureau, mais de dev, par des devs, pour des devs.
enfin, pour openbsd, faut bien savoir que :
-c'est une forteresse numérique, enfin de ce que la réputation (qu'elle n'a pas volé) laisse à entendre
-en terme de perfs, ce critère est très secondaire : ne pas s'attendre à y avoir plus de réactivité sous openbsd que sous nux, bien au contraire
-en termes d'usage, openbsd est plus simple mais aussi plus "rustique" dans une certaine dimension : ne surtout pas s'attendre à tomber sur un bureau sexy par défaut ; d'ailleurs l'install openbsd par défaut n'apporte jamais d'interface graphique. Elle peut être configurée à la mano en supplément
-pour le graphique, nvidia ce sera le minimum syndical, zéro accélération, c'est de l'affichage windows 98, ca fonctionnera, en résolution maximale pour ceux qui ont de la chance. Les autres devront aller sur du ati/amd
-pareil pour le wifi : atheros et intel globalement bien supportés ; broadcom reste roi du wifi grand public, et une carte sur deux n'est pas supportée sous openbsd. Vous voici prévenus ;)
voilà pour la première contribution.
openbsd je le surnomme, par rapport à l'environnement de bureau ou d'ordi portable : "l'unix par ceux qui bossent, pour ceux qui bossent"
entendre, le HDMI facile pour du YT sur la télé en moins d'une minute, je donne pas cher que ce soit pas réalisable. J'ai pas pu le faire de mon coté.
sinon pour éviter tout ce qui est relatif au divertissement et bosser, oui le système est assez "restrictif" en termes de perfs pour s'y preter ;)
ps: ya encore des guerres de chapelles sur pas mal de choses :
la plus célèbre est le FS (systeme de fichiers), qui pour différentes raisons sont encore très mal compatibles du linux
également pour la pile réseau : haiku prends la pile réseau de freebsd, qui passe presque partout ; openbsd, c'est "notre code ou aucun code"
les devs d'openbsd sont assez tranchés, pas que sur le plan technique, ya beacoup d'adaptations ou d'améliorations matérielles qui auraient pu etre possibles si les devs n'étaient pas restrictifs sur la simple problématique de licence. Je sais plus laquelle/lesquelles, mais une licence d'un code source peut tres bien etre l'élément bloqueur à une intégration logicielle.
au final, openbsd est un système à deux doigts de l'élitisme, fait par leurs devs, et uniquement pour eux ; ils le laissent en OSS pour les aventuriers qui veulent plonger dans l'inconnu, pas pour le petit geek qui veut tester un "windows xp gratuit" comme l'était linux/ubuntu dans les années 2000.
mais au final, l'alternative reste intéressante. Pour moi c'est une bonne expérimntation (en tri/quadboot) au meme titre que :
haiku (héritage de beos)
plan9 (ou 9front, dont le très long pdf est assez magique à lire):
https://fqa.9front.org/book.pdf
https://pspodcasting.net/dan/blog/2019/plan9_desktop.html
https://linuxfr.org/users/deuzene/liens/plan-9-desktop-guide
https://linuxfr.org/users/ploum/journaux/plan9-l-os-installe-parce-qu-openbsd-etait-trop-mainstream
-
Merci. Je n'ai pas bien compris : l'introduction de mesures de sécurité assez décriées, c'était déjà en place sur OpenBSD et cela arrive dans FreeBSD ?
N'hésite pas à faire un comparatif des avantages / inconvenant de OpenBSD 7.3 vs FreeBSD 13.2 vs Linux.
Il s'agit de nouvelles mesures de sécurité introduites sur cette version et amenées à se développer sur OpenBSD.
Il n'y a rien de tel sur FreeBSD actuellement. Il y a néanmoins des secteurs actifs de recherche, notamment le travail autour des "capabilities" et de leur mariage à un cpu taillé pour, cela s'appelle CheriBSD. Cela se passe essentiellement à Cambridge (https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/). Cela semble d'intérêt pour les éco-systèmes bien au-delà de FreeBSD (Microsoft si j'ai bien compris).
Pour ce qui est de Linux je ne suis pas trop au courant des plans ni s'il y en a pour adresser ce type de sujet. Linux exploitera vraisemblablement des dispositions matérielles sur les nouveaux cpu pour du control flow integrity.
Néanmoins il faut noter qu'ici la tentative implique bien plus que le noyau. Si on veut un équivalent sur Linux, il faudra toucher le noyau, le compilateur, le linker, la libc, et trier dans le userland. On trouve donc plutôt des mesures sur des os complets: iOS, Android, MS.
Edit: grammaire
-
-pour le graphique, nvidia ce sera le minimum syndical, zéro accélération, c'est de l'affichage windows 98, ca fonctionnera, en résolution maximale pour ceux qui ont de la chance. Les autres devront aller sur du ati/amd
Les graphiques Intel intégrés (iGPU), qui fonctionnent si bien sous Linux ne fonctionne pas sous OpenBSD ?
-
N'hésite pas à faire un comparatif des avantages / inconvenant de OpenBSD 7.3 vs FreeBSD 13.2 vs Linux.
Imagine une personne qui connait un peu Linux et qui voudrait essayer BSD : Que lui conseiller ?
Peut-être séparer un usage serveur et usage desktop.
J'essaierai de mettre ceci en perspective mais probablement dans son propre fil de discussion.
-
Les graphiques Intel intégrés (iGPU), qui fonctionnent si bien sous Linux ne fonctionne pas sous OpenBSD ?
Intel et AMD fonctionnent bien sous OpenBSD. Il y a une adaptation DRM de ce qui est publié pour le noyau Linux, dans OpenBSD 7.3 c'est aligné sur Linux 6.1.15. Pas de quoi le transformer en console de jeu 3D gourmand pour autant.
Nvidia ne publie rien de "libre" ni doc ni code donc ce n'est pas utilisé. Il y a eu inclusion de Nouveau à un moment donné, je n'en connais pas l'état.
Il n'y a rien à attendre d'une utilisation de Nvidia sur cette plateforme contrairement à Intel / AMD.
-
Les graphiques Intel intégrés (iGPU), qui fonctionnent si bien sous Linux ne fonctionne pas sous OpenBSD ?
Intel et AMD fonctionnent bien sous OpenBSD. Il y a une adaptation DRM de ce qui est publié pour le noyau Linux, dans OpenBSD 7.3 c'est aligné sur Linux 6.1.15. Pas de quoi le transformer en console de jeu 3D gourmand pour autant.
Nvidia ne publie rien de "libre" ni doc ni code donc ce n'est pas utilisé. Il y a eu inclusion de Nouveau à un moment donné, je n'en connais pas l'état.
Il n'y a rien à attendre d'une utilisation de Nvidia sur cette plateforme contrairement à Intel / AMD.
pardon je me suis mal exprimé :
pour ce qui est des GPU, intel/amd/ati fonctionnent "plutot" bien, pas aussi bien que sous nux (qui a tous les lauriers et un peu de reconnaissance des fabricants de ce coté là)
pour nvidia, minimum syndical dans le sens où c'est son support sur openbsd : le fabricant n'a jamais coopéré et ne s'est impliqué dans le support de ce systeme. Déjà je sais meme pas si c'est bien pris en charge sous freebsd, j'ai eu peu l'occasion de tester ce dernier
ce que je veux dire c'est que si c'est du nvidia, avec une définition "normale" si l'affichage se fait c'est déjà un très bon résultat, mais ce sera du rendu LOGICIEL uniquement, en d'autres termes du 100%CPU en termes de charges. Du Vesa quoi. Nvidia c'est la pire des boites noires pour le logiciel libre, la plupart des distros nux se plient à intégrer les "blobs" binaires (càd en quelques sortes "boites noires, 100% opaques") dans leurs distri pour avoir ces cartes graphiques fonctionnelles, à défaut de perdre un grand nombre d'utilisateurs.
debian a été récemment pointé du doigt là dessus si je me trompe pas : les nouvelles versions (ou celles à venir) ne seront plus 100% lbres, et compteront parmi leurs composants des pilotes fermés/proprios (à l'instar des blobs binaires sur smartphone) pour nvidia, tellement en logiciel libre ca tient à peine la route (le "nouveau", aka driver nvidia libre, est bien loin de faire l'unanimité en termes d'adoption sous nux)
-
pour ceux que ca intéresse, il y a également le projet isotop, qui (ayant évolué), s'est mué en script post-installation d'openbsd, visant à installer/activer xorg/dwm comme environnement graphique par défaut, afin de permettre un usage openbsd comme environnement de bureau/laptop
c'est assez bien fait :
https://archiveos.org/isotop/
https://paedubucher.ch/articles/2020-09-05-openbsd-on-the-desktop-part-i.html
https://framagit.org/3hg/isotop/-/tree/master
https://vu.fr/iaVW (raccourcisseur, pour éviter de retaper le long lien dans le term)