Le 1er septembre 2016, PC-BSD s’est effacé devant TrueOS, étiquette réservée jusque‐là à la gamme serveur. Au‐delà d’un simple changement de nom, ce système conçu au‐dessus de FreeBSD change de philosophie.
Le système passe en publication continue (rolling release), en suivant la branche current de FreeBSD, et installe le bureau Lumina au lieu de KDE 4.
Base
Désormais, le système suit la branche CURRENT de FreeBSD, aussi nommé « fil du rasoir » et non plus la branche de production, RELEASE. Notez que seules les images 64 bits sont proposées.
… Ce qui permet, certes, au système de bénéficier des pilotes et autres améliorations les plus récents, mais l’expose ainsi aux bogues[1].
ZFS dès le boot
Ce choix est pondéré par l’utilisation des « ZFS boot environnement » (dont nous avions brièvement causé lors de la sortie de FreeBSD 10.3), qui vont permettre au système de revenir sur un état précédemment sauvegardé à l’aide des instantanés ZFS.
De fait, TrueOS ne propose plus qu’un seul système de fichiers, ZFS, et met en avant le chargeur de FreeBSD plutôt que GRUB. L’intégration de ZFS et de ses environnements de démarrage ont été intégrés dans ce dernier.
En cas de coup dur, vous pouvez même réinstaller le système sans perdre vos données, à condition de ne pas avoir chiffré vos pools ZFS.
Pare‐feu
C’est IPFW qui surveille le réseau.
Compatibilité Linux
Curieusement, la compatibilité Linux n’est activée qu’en 32 bits.
Empaquetage
Outre cette politique, TrueOS remplace OpenSSL par LibreSSL et utilise pkgng pour les ports comme pour la base.
Cela signifie d’une part que le format pbi est abandonné et que les utilisateurs d’un FreeBSD natif peuvent utiliser le dépôt TrueOS facilement. Toutefois, afin de vérifier les options activées pour la construction, elles peuvent être différentes de celles des dépôts FreeBSD. Les ports seront compilés exclusivement à l’aide de CLang.
D’autre part, l’usage de pkg pour la base unifie l’outil de mise à jour, freebsd-update, a été retiré, ce qui fait de TrueOS un système en rolling release.
Vernis
Autre changement majeur, l’environnement Lumina est installé en lieu et place de KDE 4.
Lumina est un environnement léger développé par l’équipe de TrueOS au dessus de Qt5, Fluxbox et du compositeur compton ; l’équipe est aussi en charge de pcdm1, le nouveau gestionnaire de connexions qui remplace slim.
Le but est de proposer un environnement de bureau compatible à 100 % avec BSD et qui limite les dépendances, sans doute motivé par l’accent trop prononcé mis sur GNU/Linux par d’autres environnements.
TrueOS complète ce bureau, qui n’intègre que très peu d’applications, par ses interfaces de configuration et outils « maison » ainsi qu’une petite sélection de logiciels (navigateur Web, logiciel de messagerie IMAP, afficheurs).
Le manuel en fait le tour.
Installation
L’installation du système est simple et permet de petites variantes comme le chiffrement de vos disques par geli.
Vous pourrez rapidement configurer votre système à l’aide de SysAdm qui remplace l’interface de configuration précédente et surtout qui propose une administration à distance via une API basée sur des sockets Web.
Surtout, l’interface graphique AppCafé va vous permettre d’installer rapidement vos logiciels favoris ; tant l’offre logicielle, au premier démarrage, est vraiment pauvre.
Résumé et impressions
TrueOS est encore à l’état de bêta, la migration des outils venant de PC-BSD est toujours en cours.
Voici donc le tout dernier FreeBSD orienté Desktop qui repose sur la version 12, alors qu’à l’heure où j’écris ces lignes, la version 11 est toujours au stade Release Candidate (RC3).
L’offre logicielle réduite de l’environnement lumina pourrait éloigner les utilisateurs habitués à des distributions très complètes dès l’installation.
Mais, cette faiblesse est compensée par une interface d’installation d’applications sans équivalent sur un FreeBSD original et des outils d’administration adaptés à FreeBSD et à ZFS. Ainsi, la légèreté et la rapidité de l’ensemble pourraient attirer de nouveaux utilisateurs ; surtout si on le compare à son prédécesseur.
TrueOS permet une expérience utilisateur intéressante, à la fois interface bureautique-domestique et système en développement constant.
Bref, un usage à la fois en mode « tounafond » (CURRENT) et « mêmepasmal » (ZFS environments).
-
qui n'est toujours pas dans l'arbre des ports FreeBSD, par contre. ↩
Aller plus loin
- Journal à l’origine de la dépêche (431 clics)
- L’annonce officielle (209 clics)
- Bureau Lumina (989 clics)
# Reserved
Posté par David Demelier (site web personnel) . Évalué à 10.
Ça y va fort au niveau des ®. Il y en a partout, même pour les applications. Je trouve pas ça très professionnel.
TrueOS®
SysAdm™
AppCafe®
Je connais PC-BSD depuis longtemps et j'en suis toujours autant sceptique. Traductions automatique de leur pages (complètement à côté de la plaque). Un des développeurs principal dénigre GNOME en conférence en disant "it sucks", pas très fairplay. Puis ils réecrivent des outils spécifiquement pour PC-BSD. Ça serait mieux de contribuer des backends pour NetworkManager, packagekit, le bluetooth plutôt que de recoder une appli tierce pas du tout intégrée au desktop.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Reserved
Posté par David Marec . Évalué à 9.
On pourrait discuter de la pertinence de suivre une branche CURRENT, de l'intégration en tout ZFS, de l'abandon des pbi, du choix de fluxbox au dessous de Lumina etc…
Mais non, il semble plus important de ricaner sur les traductions automatiques du site Web.
Les développeurs de GNOME ont tirés les premiers: C'est systemd ou démerdez-vous.
Dans ce contexte, il est parfaitement compréhensible qu'ils développent leur propre bureau; là, ils seront à l'abri des surprises.
Sous un FreeBSD, utilisons les outils natifs de FreeBSD; et s'ils font des UI au dessus de pkgng, ifconfig etc. tant mieux. Elles sont, au contraire, adapté à leur /desktop/ et au système qui tourne dessous. Il va falloir m'expliquer l'intérêt de packagekit au dessus de pkng.
D'autant que packagekit dépend de policykit; Ah non, en fait de polkit, son successeur avec une API différente.
Après avoir couru après hald, policikit, consolkit, polkit, udev et compagnie, ces machins abandonnés à peine portés, contourné des APIs dédiées et conçues uniquement pour et autour linux, il est temps de dire «stop», AMHA.
Car contrairement à ce que j'ai lu dans les commentaires, porter/patcher/bricoler pour contourner les dépendances à systemd et à udev (ah non, l'un a bouffé l'autre depuis), c'est loin d'être trivial.
De mon point de vue, systemd a été conçu pour ne pas être porté sur un autre système.
# Troll systemd
Posté par Mimoza . Évalué à 6.
Sur leur page d'acueil on trouve :
Autant leur volonté de rendre les BSD plus sexy est bien, mais ce genre de phrase fait tache.
# SystemD la cause de la discorde...
Posté par abriotde (site web personnel, Mastodon) . Évalué à -1.
Non, ça se comprends. Le problème viens en partie de SystemD largement adopté sous les OS Linux et réfuté sous BSD plus puriste. C'est compliquer à expliquer mais en gros SystemD s'éloigne des règles UNIX et surtout les applications qui tournent avec SystemD ne sont pas facilement compatible sans SystemD d'installé. Or Gnome et KDE sont plus implémenté pour tourné avec SystemD donc plus ou moins incompatible pour tourner sans. Du moins il faut des patch… Et ça les puriste n'en veulent pas. Ils considèrent SystemD comme une erreur et veulent s'en défaire.
Le problème est vraiment complexe car si les puriste exagèrent dans le fond ils ont raison de sonner l'alarme car il y a des problèmes de fond possiblement du côté de SystemD.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: SystemD la cause de la discorde...
Posté par GG (site web personnel) . Évalué à -2.
Tu crois que l'adoption à été volontaire?
Je vais te révéler quelque chose : L'adoption à été contrainte.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: SystemD la cause de la discorde...
Posté par Maclag . Évalué à 3.
C'est que Lennart a son propre réseau de gros bras et il a menacé les familles des mainteneurs, sinon, personne n'aurait jamais soutenu systemd!
[^] # Re: SystemD la cause de la discorde...
Posté par whity . Évalué à 10.
zut, c’est lundi, pas vendredi…
Tu veux dire, comme pallier l’absence d’API de configuration pour tout un tas de paramètres du système ?
Rien que quelque chose comme « savoir si l’ordinateur est en phase d’éteignage » est une merde infâme et non portable dans le monde UNIX. systemd (qui est bien plus qu’un système d’init) a au moins le mérite d’apporter une solution.
Accessoirement, il est tout à fait possible de fournir des services dbus compatibles avec les APIs systemd pour faire tourner les bureaux qui en ont besoin. Le truc, c’est que bien souvent, la pratique est compliquée car on se rend compte que les services demandés ne sont pas disponibles sur le système (cf l’exemple de savoir si on est en phase d’éteignage / de mise en veille / etc), ou en fait posent des problèmes de sécurité si mal implémentés, etc.
La réalité, c’est que si systemd s’impose, c’est parce qu’il simplifie grandement la vie de ses premiers utilisateurs : les programmeurs. Qui l’imposent à leurs utilisateurs en retour, parce que ça leur simplifie la vie.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: SystemD la cause de la discorde...
Posté par Misc (site web personnel) . Évalué à 4.
Ça simplifie aussi la vie des distributeurs, et des utilisateurs. Encore une fois, c'est bien plus simple d'écrire un fichier de service, ça te donne un accès simple à des fonctions du kernel des plus utiles, etc.
Par exemple, y a 4 jours, j'étais avec un collègue en train de regarder sur la meilleur façon de pas prendre tout le temps cpu quand on lance la vérification des mises à jours sur les machines des utilisateurs sous RHEL Desktop.
La solution qu'on a fini par prendre (après 3 hacks à base de cpulimit), c'est d'utiliser systemctl set-property sur le démon de packagekit. Emballé, c'est pesé, une ligne pour changer le quota CPU, une autre pour revenir à ce qu'on avait avant.
Pas de magouille à trouver le pid de yum et packagekit à coup de ps et de grep (et grep -v grep), de création et déplacement de cgroups, etc.
[^] # Re: SystemD la cause de la discorde...
Posté par benja . Évalué à 2. Dernière modification le 27 septembre 2016 à 23:40.
Par curiosité, quel est la propriété qui a fonctionné pour vous ?
Je viens d'essayer CPUQuota=20% sur une debian. Malheureusement, 1) ça ne modifie pas le quota d'un daemon déja lancé, de plus j'ai obtenu un message comme quoi il fallait exécuter un systemctl daemon-reload, donc cela ferait donc trois commandes a exécuter: set-property, daemon-reload et restart (à minima deux, la deuxième étant "reboot"…) 2) ça ne semble pas fonctionner, tout simplement :-/
[^] # Re: SystemD la cause de la discorde...
Posté par David Marec . Évalué à 1.
Sous Freebsd, il existe rctl.
Sinon, nice / renice suffit en général.
Et ça permet de plus utiliser le CPU s'il n'est pas trop sollicité par ailleurs.
[^] # Re: SystemD la cause de la discorde...
Posté par benja . Évalué à 2.
Sympa le rctl, et ça supporte aussi les jails ! Et ça a l'air d'une simplicité, à comparer au bazard que c'est du côté linux entre lxc,libvirt,nspaw,sytemd,openvz, etc. /me rêve que quelqu'un resynchronise le code jail de dragonfly…
[^] # Re: SystemD la cause de la discorde...
Posté par Misc (site web personnel) . Évalué à 2.
C'était avec CPUQuota. On a utilisé set-property et --runtime, sur systemd 219.
[^] # Re: SystemD la cause de la discorde...
Posté par David Demelier (site web personnel) . Évalué à 4. Dernière modification le 27 septembre 2016 à 09:48.
C'est systemd, comme tout daemon unix. sshd, httpd, ftpd, dhcpd, dhcpcd, ntpd, etc.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: SystemD la cause de la discorde...
Posté par Anthony Jaguenaud . Évalué à 8.
Mince, je croyais qu’il fallait écrire :
C'est systemd, comme tout daemon unix. systemd, systemd, systemd, systemd, systemd, systemd, etc.
Bon, voila comique de répétition, tout ça…
Je suis déjà parti :-p -->[]
[^] # Re: SystemD la cause de la discorde...
Posté par benja . Évalué à 2.
Bien que, techniquement, ça n'est pas un daemon…
[^] # Re: SystemD la cause de la discorde...
Posté par David Demelier (site web personnel) . Évalué à 2.
https://www.freedesktop.org/wiki/Software/systemd/#spelling
git is great because linus did it, mercurial is better because he didn't
[^] # Re: SystemD la cause de la discorde...
Posté par benja . Évalué à 1. Dernière modification le 28 septembre 2016 à 19:54.
https://en.wikipedia.org/wiki/Daemon_%28computing%29#Creation
[^] # Re: SystemD la cause de la discorde...
Posté par David Marec . Évalué à 6.
On peut quand même s'interroger sur la pertinence d'une rubrique systemd ( et d'autres de ses modules ) chez freedesktop.org …
C'est c'la, oui.
[^] # Re: SystemD la cause de la discorde...
Posté par David Demelier (site web personnel) . Évalué à 3. Dernière modification le 29 septembre 2016 à 11:03.
Excellent, j'y avais jamais pensé.
Posée sur la mailing list systemd, ça doit faire une bonne bombe ça.
Cela dit, il y a des points vrais. systemd unifie les scripts pour toutes les distributions (enfin dans la mesure du possible). Et permet aussi d'unifier la configuration du système.
Je me rappelle encore sous Gentoo, /etc/conf.d, sous Debian c'est des fichiers différents, dont le /etc/network. Sous redhat on utilisait des commandes system-config-* (IIRC).
git is great because linus did it, mercurial is better because he didn't
# Et ZFS
Posté par abriotde (site web personnel, Mastodon) . Évalué à -1.
Ce qui m'étonne c'est que BSD très puriste bien souvent, adopte ZFS à la licence controversé et surtout tenu par Oracle. Ubuntu a été le premier a franchir la ligne jaune et je vois maintenant que FreeBSD s'y est mis…. Je redoute le moment ou le tigre tapis bondira…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Et ZFS
Posté par whity . Évalué à 5.
La licence de ZFS (la CDDL) est libre, reconnue par l’OSI.
Le fait qu’elle soit incompatible avec la GPL (ce qui est la source de la non inclusion de ZFS dans le noyau linux) est plus lié à des détails juridiques techniques qu’autre chose. Mais c’est une licence libre, il n’y a pas de tigre caché sous le tapis.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Et ZFS
Posté par peikk0 . Évalué à 5.
ZFS sous FreeBSD c'est depuis la 7.0 en 2008, ce n'est absolument pas nouveau.
[^] # Re: Et ZFS
Posté par David Demelier (site web personnel) . Évalué à 5.
Tu veux dire FreeBSD.
OpenBSD n'adoptera jamais ZFS. Sur NetBSD c'est en travaux mais rien de concret en ce moment. Et Dragonfly a son propre HAMMER.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Et ZFS
Posté par benja . Évalué à 1. Dernière modification le 28 septembre 2016 à 19:59.
Une référence ? N'y-a-t'il pas non plus un projet d'implémentation fuse, ce qui pourrait pallier une non-intégration officielle ?
[^] # Re: Et ZFS
Posté par David Marec . Évalué à 2.
Les deux entretiens de développeurs OpenBSD, publiées ce site:
Oups, j'ai cru qu'il s'agissait d'OpenBSD; au temps pour moi.
[^] # Re: Et ZFS
Posté par benja . Évalué à 1. Dernière modification le 29 septembre 2016 à 00:55.
Ok merci !
Donc pour résumer, sous Linux il existe déjà un pilote "natif" qui ne sera jamais intégré et un pilote fuse aux performances moindres, sous FreeBSD il y a un pilote natif qui fonctionne bien (et à priori aussi via fuse), sous NetBSD il y a un pilote natif en développement et, à priori, un support via fuse, sous OpenBSD, à priori, il pourrait aussi y avoir un support via fuse. C'est correct ?
(Sous DragonFly, si je ne me trompe pas, fuse n'est actuellement pas fonctionnel mais il y a eu un volontaire qui s'est porté connu pour le rendre).
[^] # Re: Et ZFS
Posté par Loïc Blot (site web personnel) . Évalué à 2.
A noter que sous Linux le driver DKMS utilise une couche d'émulation solaris/BSD <=> Linux sur le VFS, donc on perd un chouille en performances par rapport à ces derniers en natif.
Veepee & UNIX-Experience
# torrent
Posté par EauFroide . Évalué à 1.
Le seul et unique tracker qu'ils ont mis avec leur torrent est "impossible a contacter".
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: torrent
Posté par cluxter . Évalué à 2.
J'ai remarqué que c'était un problème récurrent avec les torrents. Je regrette le temps où eMule était la référence car on y trouvait absolument tout, et bien que les performances globales étaient moins bonnes que les torrents, il y avait toujours à un moment donné une source de disponible, ce qui permettait tôt ou tard de télécharger le fichier. Il n'y avait rien de plus facile pour re-seeder un fichier : il suffisait de le mettre dans le répertoire de partage. Aujourd'hui avec un torrent je ne sais même pas comment on fait pour re-seeder, le peu que j'ai essayé j'ai trouvé ça trop contraignant pour ce que ça m'apportait (grosso modo : rien).
[^] # Re: torrent
Posté par EauFroide . Évalué à 1.
Avec les torrents mal posté.
Télécharge un film via torrent et tu verra qu'au moins 10 trackers sont utilisé**1. A mon avis celui qui a fait le torrent pour cette distro avait soit la flemme soit n'a jamais vraiment utilisé le réseau torrent.
Il y a aussi la DHT mais elle est plus lente et tout le monde ne l'active pas.
**1 sauf chez T411 qui bousille le système
Oui P2P/F2F sont plus facile. Torrent a tenté de s'en rapprocher grâce aux liens magnet mais ce n'est pas encore aussi facile que juste taper les fichiers dans un répertoire partagé.
Mais tu as encore Retroshare qui fonctionne bien dans le monde F2F et qui possède l'avantage d'être compatible avec un système de liens (tu partage le lien, la personne l'ouvre avec retroshare et ça télécharge le fichier sans devoir chercher).
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: torrent
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 1.
Il y a Gnutella aussi, qui propose un système de recherche en P2P et utilise pour télécharger les fichiers… le protocole HTTP. Il fallait y penser :)
[^] # Re: torrent
Posté par barmic . Évalué à 4.
Ouai j'ai l'impression que ça amuse bien les utilisateurs, mais ça ne me fait pas plus rêver que ça. Est-ce qu'il gère correctement la reprise du téléchargement ? La gestion fine du débit ? La possibilité de télécharger depuis plusieurs sources ? etc
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: torrent
Posté par xcomcmdr . Évalué à 2. Dernière modification le 27 septembre 2016 à 14:30.
Les années 2000 ont appelée, elles veulent que tu leurs rendent leurs protocoles antédiluviens.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: torrent
Posté par David Marec . Évalué à 4.
Sinon, on peut aussi récupérer les images via ftp ou cvs.
Il reste de l'UUCP quelque part ?
[^] # Re: torrent
Posté par cluxter . Évalué à 0.
Ca ne veut pas dire que c'est un protocole obsolète.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.