Le système d'exploitation FreeBSD est arrivé dans sa dixième cuvée. Cette version très attendue apporte notamment la gestion de l'affichage par le noyau (Kernel Mode Setting) pour les pilotes AMD et l'hyperviseur bhyve.
Sommaire
Matériel
Le Raspberry Pi est désormais pris en charge, et de manière générale le support des architectures ARM a été amélioré.
L'architecture ARM supporte désormais les Superpages, améliorant les performances et la scalabilité du système.
Au passage, un nouvel outil est apparu, Crochet, développé par Tim Kientzle. Il permet de construire des images FreeBSD amorçables pour différents modules embarqués comme le Raspberry Pi, les BeagleBones et quelques autres encore.
L'instruction RDRand des processeurs Intel est désormais supportée. Celle-ci permet de générer des nombres aléatoires directement depuis le CPU. Elle est présente dans les processeurs Ivy Bridge et supérieurs.
Stockage
Le système de fichiers ZFS supporte désormais la commande TRIM (qui était déjà supportée par UFS) et la compression LZ4 (backportée sur 9.2). LZ4 est un algorithme de compression particulièrement rapide qui augmente les performances de 50 à 80% par rapport au défaut LZJB pour un ratio de compression plus élevé (jusqu'à 10% sur de larges blocks). La fonctionnalité NOP-write a également été importée d'Illumos. Celle-ci permet de ne pas réécrire les données si le checksum des nouvelles données est identique à celui des anciennes.
UFS de son côté reçoit le support de l'extension de système de fichiers à chaud sur des partitions montées en écriture. Les nouveaux systèmes de fichiers créés bénéficieront également de meilleures performances lors d'un fsck.
FUSE fait son entrée dans le système de base (précédemment un module noyau était disponible dans les ports).
Une nouvelle pile iSCSI implémentée dans le noyau est disponible.
Système
Une étape dans l'abandon de GCC a été franchie, FreeBSD 10 (pour les architectures i386 et amd64) est intégralement compilé à l'aide de LLVM/CLang. Cette bascule est due à une volonté de libérer la base de FreeBSD de la licence GPL v.3 qui régit les versions récentes de GCC. Remercions au passage Chris Lattner, initiateur et mainteneur de CLang, employé d'Apple. Les autres architectures continuent d'utiliser GCC (4.2.1).
Il est toujours possible de compiler le système avec GCC en passant une option dans le src.conf.
L'installeur permet désormais l'installation du système sur des volumes ZFS
FreeBSD 10 intègre désormais nativement la gestion des initiateurs et cibles iSCSI
Réseau
FreeBSD supporte désormais 65536 tables de routage au lieu de 16.
L'implémentation des interfaces virtuelles carp(4) a été réécrite.
Affichage
Les pilotes graphiques libres Intel et AMD n'étaient plus compatibles avec FreeBSD car ils nécessitent un support de l'affichage géré par le noyau (Kernel Mode Setting ou KMS). Il fallait donc fonctionner avec le pilote VESA ce qui était assez pénible (résolution incorrecte et aucun support de la 2D ou 3D). Avec FreeBSD 9.1 il était possible d'utiliser KMS pour les pilotes Intel mais de manière limitée.
FreeBSD 10 prend désormais en charge KMS pour les cartes graphiques AMD, permettant d'utiliser l'accélération 2D et 3D matérielle des puces graphiques de celles-ci. Pour Nvidia il faut toujours utiliser le pilote propriétaire qui n'exploite pas KMS. Concernant Intel, le support était déjà partiel à partir de la version 9.1 mais bien incomplet. FreeBSD 10 apporte des améliorations sur ce point.
Virtualisation
FreeBSD est connu depuis longtemps pour son système de jails, apparu sous FreeBSD 4 (2000). Cela permet de créer d'autres instances de FreeBSD, partielles ou complètes tout en restant sur la même machine physique. On peut ainsi créer des conteneurs systèmes très facilement, à l'instar des conteneurs LXC sous Linux. Combiné avec le linuxulator, il est même possible, avec quelques limitations, de créer des jails Linux.
Mais pour apporter la prise en charge des autres systèmes d'exploitation et outrepasser certaines limites, FreeBSD se dote désormais d'un véritable hyperviseur. Bhyve (BSD Hypervisor, anciennement BHyVe) est un hyperviseur dit de type 2 (qui s'exécute à l'intérieur d'un système d'exploitation à part entière), libre de tout héritage. Il va rapidement être désigné comme un concurrent à Linux-KVM et utilise déjà des périphériques VirtIO.
Bhyve requiert un CPU Intel avec le support VT-x et EPT. Il est actuellement capable de booter toute version de FreeBSD supportant VirtIO (8.4+) ainsi que GNU/Linux et OpenBSD. Le support de UEFI/BIOS n'étant pas encore implémenté, cela limite le nombre d'OS utilisables, toutefois ce support est une priorité pour le projet.
De fait, Bhyve est encore récent et ne supporte pas toutes les fonctionnalités classiques des hyperviseurs, qui sont prévues dans les versions futures, telles que le suspend/resume ou la live migration. Quelques limitations sont également présentes, comme le nombre de vCPU qui ne peut dépasser 16.
Par ailleurs, FreeBSD 10, tout comme FreeBSD 9.2, intègre des pilotes VirtIO ce qui lui permet de fonctionner de manière optimale dans un hyperviseur Linux-KVM ou VirtualBox (et très bientôt bhyve).
Enfin, beaucoup de pilotes Hyper-V ont été intégrés, permettant notamment un meilleur support des périphériques spéciaux et interaction avec l'hyperviseur (périphériques SCSI, synchronisation horloge, signal d'arrêt, migration à chaud).
Performances
Le pare-feu Packet Filter a été réécrit afin d'utiliser un système de verrous plus fin, améliorant sensiblement ses performances sur des machines multi-cœurs.
Applications
Le système de paquets de FreeBSD est désormais basé sur pkgng. Les anciens outils pkg_* ont été retirés.
Si vous souhaitez passer de FreeBSD 9.X à FreeBSD 10.X, il est suggéré d'installer pkg, puis de taper la commande pkg2ng avant de faire la mise à jour vers FreeBSD 10.
FreeBSD abandonne Bind au profil de LDNS et Unbound. Bind pourra toujours être installé en passant par les ports. Cette décision est l'aboutissement d'un long débat car il s'agit d'un changement important dans les habitudes des utilisateurs (une violation de la POLA) cependant le consensus s'est rapidement établi autour du fait que
- seul un resolver était nécessaire dans le système de base,
- Bind pose trop régulièrement des problèmes de sécurité, un remplaçant à la commande
host(1)était un préalable absolu. Vitaly Magerya a donc implémenté un remplaçant de host basé sur ldns.
Sécurité
Le périphérique de nombres aléatoires random(4) est devenu plus sélectif, utilisant des sources qualifiées de « haute qualité ». Certaines sources jugées douteuses suite à des suspicions de surveillance de la part de certains gouvernements (mode paranoïa) ont été retirées.
Pourquoi choisir FreeBSD ?
Note : ce paragraphe a été ajouté à titre informatif, nul désir de troller. On ne peut affirmer objectivement que FreeBSD est supérieur ou inférieur à Linux. Les deux peuvent remplir les mêmes fonctions. Mais FreeBSD se démarque tout de même sur certains points :
- Les jails qui sont matures et intégrés au système, tandis que sur Linux on ne sait pas quelle solution est vraiment pérenne (exemple : Xen retiré de la majorité des distributions, puis finalement intégré dans l'upstream du kernel. OpenVZ déprécié puis finalement en cours d'adaptation pour fonctionner en upstream aussi, etc).
- La présence d'outils comme NanoBSD pour construire une image read-only du système très facilement.
- Certains barbus préfèrent le système d'init et de configuration à l'ancienne.
- Possibilité d'avoir une base stable avec des logiciels additionnels dans leur dernière version, ce qui allie les avantages du stable et du rolling release.
- Le système de fichiers ZFS, très exigeant mais idéal pour du stockage de fichiers en datacenter.
- Le système de ports, apprécié par certains barbus également, permet de passer ses propres options de compilation. Poudriere permet aussi de se faire très simplement un serveur de compilation de ports et un dépôt pkgng.
Conclusion
FreeBSD10 apporte beaucoup d'innovations et un souffle nouveau, autant pour les desktops que les serveurs.
Aller plus loin
- Explications concernant le remplacement de GCC (non officiel) (396 clics)
- Crochet (173 clics)
- Superpages ARM (102 clics)
- iSCSI targets & initiators (71 clics)
- Le projet FreeBSD (860 clics)
- Le projet Bhyve (192 clics)
- Notes de version FreeBSD10 (143 clics)
# après linux, il y a freebsd
Posté par homer242 (site web personnel) . Évalué à 3.
ah, j'ai une freebsd 9.2 à mettre à jour alors :) Sympa toutes ces nouveautés !
[^] # Re: après linux, il y a freebsd
Posté par Joff54 . Évalué à 2.
Et poudriere va t'aider à pré-compiler tes packages pour la 10.0 avant ton upgrade :) Quel pied ce poudriere !
[^] # Re: après linux, il y a freebsd
Posté par Enj0lras . Évalué à 4.
ou alors tu peux utiliser les paquets pré-compilés.
# Par rapport à quoi?
Posté par ʭ ☯ . Évalué à 2.
Il y a tellement des éléments que tu donnes qui sont dans des distributions Linux que ta démarque me semble vaine. La seule démarque pour moi est de s'éloigner du Bazar des distributions en s'approchant de la Cathédrale d'une seule distribution pour les satisfaire tous.
En pratique, FreeBSD n'est pas conseillable pour une utilisation familiale ou professionnelle en poste de travail multi-fonctions, de même que beaucoup de distributions Linux. Il reste du coup cantonné à un usage serveur où il excelle, et geek pour expérimenter/avoir autre chose sur sa machine.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Par rapport à quoi?
Posté par MTux . Évalué à 10. Dernière modification le 21 janvier 2014 à 15:43.
Même si mon but n'était pas de créer un troll, reprenons les points :
Du coup je pense que ce que j'ai écrit n'est pas vain :)
[^] # Re: Par rapport à quoi?
Posté par ʭ ☯ . Évalué à 4.
Je disais qu'il y a l'équivalent de ci de là :
J'ai bien compris que tu ne voulais pas troller, et suis d'accord que tes mentions ne sont pas vaines. Mais il me semble qu'il est bon de reconnaître ses propres œillières, et tes arguments sont " la crémière est plus belle chez nous ", et pas " on a du beurre et pas vous ".
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Par rapport à quoi?
Posté par défense . Évalué à 8.
Oui enfin tu as beau sortir des arguments que tu veux, la sortie de FreeBSD 10 montre bien que la GPL est un échec.
La preuve, EMACS est un logiciel sous GPL et provoque de l'arthrite, alors qu'un logiciel vraiment libre (comme Vim, bien qu'il soit truffé de publicités ougandaises) est une référénce dans le monde libre.
En plus Stallman sent des aisselles.
[^] # Re: Par rapport à quoi?
Posté par l_fs . Évalué à 4.
[^] # Re: Par rapport à quoi?
Posté par lolop (site web personnel) . Évalué à 7.
Comme pour tout développement qui n'est pas abandonné ou passé en correction de bugs seulement.
FreeBSD n'est pas plus "fini" que Linux, mais il a une démarche plus stable dans le temps, et aussi moins de personnes pour y apporter des nouveautés ou des restructurations profondes, ceci aide un peu à cela.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Par rapport à quoi?
Posté par zebra3 . Évalué à 5.
Presque. La version 1.0 est passé en beta2 il y a quinze jour, la finale devrait bientôt sortir et être conseillée.
Au passage, j'ai découvert récemment docker, une surcouche de LXC à la Proxmox, ça a l'air prometteur.
Citons aussi Ubuntu qui intègre LXC dans AppArmor, ce qui rend son utilisation beaucoup plus secure.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Par rapport à quoi?
Posté par vrm (site web personnel) . Évalué à 1.
LXC est "production ready" depuis peu effectivement, et très simple à utiliser avec docker.
Même si certains fournisseur de PaaS l'utilise en prod, ca n'a surement pas encore la maturité des jails.
[^] # Re: Par rapport à quoi?
Posté par geb . Évalué à 2.
Effectivement, openVZ et LXC sont pas finis. Mais linux-Vserver marche tres bien chez moi, et ce depuis des années.
Et en parlant de pas fini: la paille et la poutre… parce que bon, un système de conteneurs qui sait pas limiter la RAM, le CPU, le disque (avec un quota, pas un volume/partition dédié(e)) par conteneur…
[^] # Re: Par rapport à quoi?
Posté par sheldoncooper . Évalué à 6.
pour la partie CPU/RAM
tu as rctl(8) pour ca:
http://www.freebsd.org/doc/handbook/security-resourcelimits.html
mais ce n'est pas active par defaut.
et pour les quota ZFS peut s'en charger. En revanche aucun mecanisme a ma connaissance pour limiter les I/O.
[^] # Re: Par rapport à quoi?
Posté par Bapt (site web personnel) . Évalué à 5.
cpuset(1) pour les CPUs
rctl(8) pour les autres resources.
En revanche c'est vrai qu'il n'y a rien de natif pour les disques hormis utiliser zfs.
[^] # Re: Par rapport à quoi?
Posté par xcomcmdr . Évalué à 2.
NanoBSD : http://stackoverflow.com/questions/7711017/is-there-something-similar-to-nanobsd-in-linux ?
L'init basique : si basique veut dire simple et compréhensible, je préfère systemd à SysV et similaires et leurs scripts. Si basique veut dire limité, j'en ai pas besoin.
Stable + rolling release : Manjaro, ou Ubuntu avec des PPAs, Debian avec du pinning…
Les ports :
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Par rapport à quoi?
Posté par anaseto (site web personnel) . Évalué à 9.
S'il faut dire ça en une phrase, je dirais que basique veut dire ici limité tant que ça reste simple et compréhensible. Par exemple, sous la vm avec OpenBSD que j'ai (j'ai pas de FreeBSD mais ça ressemble peut-être) les scripts d'init sont tous du genre (donc moins de 10 lignes, voire souvent 3 lignes exactement) :
et tous utilisent un script commun
rc.subrqui fait 200 lignes. Le système d'init semble guidé par/etc/rc, script d'un peu plus de 500 lignes. Donc, je dis peut-être des bêtises (les système d'init c'est pas un de mes grands intérêts), mais ça m'a l'air aussi simple qu'on peut espérer niveau implémentation et maintenance si on ne veut que les fonctionnalités start-stop-restart-reload, et il y a moins de chance qu'il y ait un bug dans 700 lignes de shell que dans une centaine de millier en C, d'où l'intérêt.Ceci dit, si t'as besoin d'un boot en parallèle ou que sais-je et utilisant des technologies plus complexes ce n'est sans doute pas ce qu'il faut, d'où l'intérêt de systemd aussi (voire d'autres systèmes comme openrc pour ceux qui sont mitigés dans leurs besoins et priorités).
Ça trolle souvent sur les systèmes d'init, mais j'ai quand même l'impression qu'au final le choix de système d'init devrait juste être déterminé par les besoins spécifiques de chacun, de l'utilisation qu'il en fait, et de ses priorités. Et si l'utilisateur n'a pas d'avis par rapport à ses besoins c'est que n'importe lequel des deux fera l'affaire.
[^] # Re: Par rapport à quoi?
Posté par Firwen (site web personnel) . Évalué à -4.
Donc si je suis ta logique, c'est mieux de segmenter les systèmes d'init au lieu d'avoir une solution générique et performante ( genre systemd au hasard ) juste que pour l'admin système flemmard d'apprendre autre chose que bash puisse continuer à jouer.
Implacable logique effectivement.
[^] # Re: Par rapport à quoi?
Posté par Enj0lras . Évalué à -3.
Embrace and extend. Bienvenue chez MicrosoftW les partisans de systemd.
[^] # Re: Par rapport à quoi?
Posté par xcomcmdr . Évalué à 8. Dernière modification le 24 janvier 2014 à 12:13.
Ça n'a rien à voir.
La stratégie Embrace, extend and extinguish c'est :
Or,
Embrace : les systèmes d'init n'ont jamais été 100% compatibles entre eux (essaie d'utiliser un script pour upstart avec OpenRC pour rire).
Extend : systemd ne propose pas d'extensions propriétaires, mais quelque chose de différent et de libre, et propose une couche de compatibilité avec l'existant.
Extinguish : Il y a un nouveau système d'init tous les 4 jours… Ce qui fait que Debian a le choix entre pas moins de 4 systèmes d'init, tous incompatibles entre eux.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Par rapport à quoi?
Posté par gnumdk (site web personnel) . Évalué à 4.
Et combien de ligne de code en C dans ton shell?
[^] # Re: Par rapport à quoi?
Posté par anaseto (site web personnel) . Évalué à 1.
J'ai regardé, ça fait 20 mil SLOC de C pour ksh (avec sloccount), donc petit pour un shell mais non négligeable. En suivant le même raisonnement, on peut aussi inclure gcc ou clang dans les deux cas, qui explosent facilement tout le reste, et on en conclut que la complexité du système d'init sera de toutes façons noyée dans le reste donc peu importe. Pourtant, ce raisonnement ne me semble absolument pas pertinent, voilà essentiellement pourquoi : le shell et gcc sont testés beaucoup plus amplement, pour des utilisations plus diverses et variées, depuis plus longtemps, et de toutes façons on ne pourra pas s'en débarrasser : pour le compilateur de C c'est clair, et pour le shell, je te laisse le soin d'inventer une évolution réaliste des systèmes à l'héritage Unixien qui nous permette de s'en passer, bonne chance!
[^] # Re: Par rapport à quoi?
Posté par xcomcmdr . Évalué à 4.
Avec des raisonnements pareils, autant éviter toute évolution ou nouveau développement.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Par rapport à quoi?
Posté par Zylabon . Évalué à 3.
Si tu veux pas de bugs, oui, c'est l'idée.
Please do not feed the trolls
[^] # Re: Par rapport à quoi?
Posté par barmic . Évalué à 3.
Non si tu ne veux pas de bug faut se tenir éloigné des ordinateurs (ou alors simplement ne rien faire avec).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Par rapport à quoi?
Posté par Zylabon . Évalué à 3.
Pour certaines applications on a pas le choix, il y a trop de calculs à faire.
Please do not feed the trolls
[^] # Re: Par rapport à quoi?
Posté par Frank-N-Furter . Évalué à 4.
Depending on the time of day, the French go either way.
[^] # Re: Par rapport à quoi?
Posté par Zylabon . Évalué à 2.
Il en faudrait un paquet de chinois pour contrôler la poussée d'une fusée ^
Please do not feed the trolls
[^] # Re: Par rapport à quoi?
Posté par anaseto (site web personnel) . Évalué à 5.
Loin de moi l'idée de sous-entendre ça, vu le goût que j'ai pour les nouveautés, la recherche, etc… qui sont de très bonnes choses. Mais ça n'enlève pas que dans certains contextes tu n'as tout simplement pas besoin des nouvelles fonctionnalités apportées, ou que pour ton cas elles marchent moins bien que ce que tu as déjà, et enfin, si la stabilité est une des priorités on a le droit de vouloir utiliser un système plus simple et basique et qui a eu plus de temps pour mûrir, je ne pense pas qu'il y ait un mal à cela, ni que ça soit un frein à toute évolution, c'est juste que tout le monde n'innove pas sur les mêmes choses.
Il faut des gens pour tester les nouveaux systèmes d'init, d'autres pour tester les nouveaux langages (c'est plus le genre de chose qui m'amuse par exemple), d'autres le dernier tiling wm ou les dernières innovations des gros desktops, etc… ça veut pas dire qu'on doit tous tout tester maintenant, ni peut-être jamais, et que même si on teste une nouveauté on n'utilise pas aussi parallèlement d'autres bons vieux trucs qui marchent aussi.
[^] # Re: Par rapport à quoi?
Posté par barmic . Évalué à 5.
C'est je pense ce qui a échappé à pas mal (au moins au début) : « Pourquoi passer à quelque chose que je ne connais pas alors que la solution actuelle me convient ? »
Quand on est sur un PC fixe avec une utilisation qui n'a au final pas beaucoup évolué depuis le début des années 90, c'est sur que l'évolution ne sert à rien, mais si tu es dans un environnement embarqué et que tu lance pas les même services en fonction de si tu as une connexion wifi, 3/4G ou pas du tout et si tu est sur batterie, sur secteur ou que ta batterie a un niveau de charge inférieur à un seuil donné,… alors je te garantis que les OpenRC, Sysvinit, rc.d et autres ne te sont d'aucune utilité. C'est dommage parce que c'est aujourd'hui le marché en haute progression (PC portable, téléphone mobile et tablette).
Et comme souvent alors plus de possibilités permet d'imaginer de nouvelles utilisation. Par exemple la capacité de systemd à connaître l'état des deamon pourrait permettre à des solution de supervision de s'auto-configurer ou de reposer sur systemd pour remplacer ou améliorer certaines sondes.
Je ne dis pas qu'il faut passer à systemd, personnellement je n'en ai pas besoin et je n'en aurais pas besoin de si tôt (je me fou de l'init que j'utilise, c'est à mon avis un peu plus simple de faire du systemd propre que du sysvinit, mais à part ça). Je dis juste que c'est un peu plus que des besoins très spécifiques et/ou marginales.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Par rapport à quoi?
Posté par anaseto (site web personnel) . Évalué à 1.
Je suis d'accord, et je suis sûr aussi que si autant de code a été écrit pour systemd c'est parce qu'il y avait des besoins réels.
Peut-être, c'est sûr que ce n'est pas le système d'init d'OpenBSD qui va te permettre de faire ce genre de choses. Mais en l'occurrence tu trouveras que les gens OpenBSD n'ont réalisé encore aucune solution de supervision parce qu'ils considèrent que c'est impossible de virtualiser correctement les différentes architectures de manière fiable, et qu'ils conseillent plutôt des solutions moins parfaites en théorie, et moins pratiques, comme le chroot, ou la simple séparation des privilèges. Je ne dis pas que c'est forcément une bonne solution, je pense personnellement que la virtualisation est très utile, mais leur point de vue semble compréhensible aussi, et du coup leur objectif étant de rester simple, et OS à vocation pare-feu entre autres, sans doute que leur système d'init est suffisant pour leur objectif.
[^] # Re: Par rapport à quoi?
Posté par barmic . Évalué à 3.
On a pas du parler de la même chose par supervision je pensais à des trucs comme Nagios, Shinken ou autre. Je pense que tu veux parler d'hyperviseur.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Par rapport à quoi?
Posté par anaseto (site web personnel) . Évalué à 1.
Oui, tu as raison, j'ai confondu les deux termes. Faut dire que hyper ~ super et vision ~ viseur ;) D'ailleurs c'est vrai que j'avais pas trop vu la logique de ta phrase du coup, je devais pas être très réveillé.
[^] # Re: Par rapport à quoi?
Posté par MTux . Évalué à 6.
Proxmox est une distribution Linux qui se base sur deux choses : KVM (upstream certes, mais pas la même chose du tout que les jails) et OpenVZ (pas upstream).
NanoBSD ce n'est pas une distribution Live. c'est un ensemble de scripts qui te permettent de générer ton propre système embarqué.
[^] # Re: Par rapport à quoi?
Posté par Loïc Blot (site web personnel) . Évalué à 5.
Tu oublies de parler de crochet, un nouvel outil qui est apparu permettant de générer des images automatiquement pour des systèmes embarqués (Raspberry PI, Beagleboard…) sous FreeBSD :)
Veepee & UNIX-Experience
[^] # Re: Par rapport à quoi?
Posté par MTux . Évalué à 2. Dernière modification le 22 janvier 2014 à 12:08.
Crochet est mentionné dans la dépêche il y a même un lien.
Mais personnellement je ne l'ai jamais utilisé.
[^] # Re: Par rapport à quoi?
Posté par Loïc Blot (site web personnel) . Évalué à 1.
Ah oui, je suis bête, je l'avais mentionné, mes excuses :)
Veepee & UNIX-Experience
[^] # Re: Par rapport à quoi?
Posté par Astaoth . Évalué à 2.
Et avec des binaires au lieu de compiler à la main, tu as quoi ?
Emacs le fait depuis 30 ans.
[^] # Re: Par rapport à quoi?
Posté par Joff54 . Évalué à -5.
Pleins dépendances inutiles (et donc de l'espace disque).
[^] # Re: Par rapport à quoi?
Posté par Sufflope (site web personnel) . Évalué à 1.
Gentoo toujours, qui permet de télécharger les paquets précompilés si on veut.
[^] # Re: Par rapport à quoi?
Posté par Astaoth . Évalué à 3.
Y a pas de dépôts de binaires officiel, et il n'y en aura jamais (cf le wiki officiel de Gentoo).
Emacs le fait depuis 30 ans.
[^] # Re: Par rapport à quoi?
Posté par zebra3 . Évalué à 1.
Debian avec du pinning ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Par rapport à quoi?
Posté par xcomcmdr . Évalué à 0. Dernière modification le 23 janvier 2014 à 16:51.
Ubuntu avec des PPAs/pinning, Manjaro ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Par rapport à quoi?
Posté par défense . Évalué à 3.
En attendant, vserers et openVZ sont matures et très performants. Sous Solaris il y a les zones.
Quant-à XEN, que tu mentionnes par ailleurs, c'est complètement différent. Comme KVM et virtualbox, il s'agit plus que d'un simple container.
D'après le wiki Gentoo (première distrib prise au hasard) :
De ce que j'en comprends, systemd est optionnel. Ça doit être pareil pour d'autres distrib GNU/linux (je ne parles même pas de solaris ni de Debian GNU/kFreeBSD).
Bref, j'ai surtout l'impression que c'est du FUD. Ou bien que tu connais très mal l'univers de GNU/Linux, ce qui te permet d'affirmer que l'herbe est plus verte ailleurs.
Je ne reviens pas sur les autres points, l'ami zezihno a déjà répondu.
[^] # Re: Par rapport à quoi?
Posté par l_fs . Évalué à 1.
OpenVZ, performant ? sur du kernel 2.6 peut être… mais quand t'es obligé de monter sur du >= 3.8, ça commence à craindre…
Vserver, n'est pas inclus dans debian, par exemple… Contrairement aux jails FreeBSD…
L'alternative à XenServer, FreeBSD n'en a pas de viable pour le moment. Mais est-ce réellement un problème ?
[^] # Re: Par rapport à quoi?
Posté par défense . Évalué à -1.
http://packages.debian.org/squeeze/linux-image-2.6-vserver-686
[^] # Re: Par rapport à quoi?
Posté par l_fs . Évalué à 1.
Ouah du 2.6 !!!
[^] # Re: Par rapport à quoi?
Posté par défense . Évalué à -3.
Mais c'est inclus.
En fait quand tu disais que ce n'était pas inclus dans Debian, tu voulais dire que ce n'était inclus que dans Debian stable, et pas dans testing et unstable.
Parce que c'est vrai que la stable, ça ne compte pas. C'est pas ce qu'on utilise sur un serveur mutualisé en prod. On met du sid ou de l'expérimental.
[^] # Re: Par rapport à quoi?
Posté par l_fs . Évalué à 5.
parce que Squeeze c'est la stable debian ? C'est pas Wheezy ?
Cadeau
[^] # Re: Par rapport à quoi?
Posté par l_fs . Évalué à -1.
Et En Prime
[^] # Re: Par rapport à quoi?
Posté par MTux . Évalué à 4.
vserver et openvz ne sont pas "upstream".
Alors que les jail dans FreeBSD oui.
Seul LXC est upstream sur Linux.
Et Xen je ne le compte pas, pour moi c'est vraiment pas pareil.
[^] # Re: Par rapport à quoi?
Posté par Thomas Bourdon (site web personnel) . Évalué à 7.
As-tu déjà regardé le système d'init de slackware par exemple ? Il n'utilise que de simples scripts bash parfaitement lisibles et personnalisables à souhait. Il n'y a même pas d'outil d'init à proprement parler, que des scripts.
[^] # Re: Par rapport à quoi?
Posté par xcomcmdr . Évalué à -2. Dernière modification le 22 janvier 2014 à 09:41.
On a déjà dit que les scripts c'était nul pour l'init (langage bash difficile à maîtriser, au moins deux processus par service - 1 pour l'instance de bash, 1 pour le fork() -, pas de support pour l'évènementiel, beaucoup de code répété, …).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Par rapport à quoi?
Posté par Patrick Lamaizière (site web personnel) . Évalué à 2.
C'est sûr que si tu utilises bash pour faire un script RC sous FreeBSD tu dois t'attendre à des migraines et des nervous breakdown comme on dit de nos jours.
les pixels au peuple !
[^] # Re: Par rapport à quoi?
Posté par xcomcmdr . Évalué à 0.
Le commentaire auquel je répondais parlait de slackware (qui n'est pas un BSD) et de scripts bash pour l'init.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Par rapport à quoi?
Posté par Enj0lras . Évalué à 5.
Tu peux aimer systemd, c'est ton droit, mais de là à raconter n'importe quoi…
Il n'y a qu'un seul processus :
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.
[^] # Re: Par rapport à quoi?
Posté par xcomcmdr . Évalué à 1. Dernière modification le 02 février 2014 à 10:03.
Dans tous les cas, utiliser les shell scripts pour contrôler les daemons ça donne ce résultat :
;-)
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.
Et comme ce n'est pas du code, il y a beaucoup moins de risques d'erreurs.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Par rapport à quoi?
Posté par Enj0lras . Évalué à 0.
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.
[^] # Re: Par rapport à quoi?
Posté par Maclag . Évalué à 4.
On n'est pourtant pas vendredi, si?
[^] # Re: Par rapport à quoi?
Posté par MTux . Évalué à 5.
J'imagine mal debian s'isoler sur upstart alors que 99,9% des distributions vont utiliser (ou utilisent déjà) systemd.
On ne sait pas quel est l'avenir de ubuntu quand on voit les mauvais choix stratégiques (smartphone, mir…).
[^] # Re: Par rapport à quoi?
Posté par ariasuni . Évalué à 3.
Upstart c’est basique? D’après ce que j’ai compris, pas tant que ça.
Sans compter l’intégration avec Plymouth.
Notons d’ailleurs que l’argument de nécessiter dbus sera bientôt obsolète (que ça soit pour Upstart ou systemd), car dbus sera intégré dans le noyau Linux (projet kdbus).
Nan mais c’est vrai que que souvent les développeurs de Debian prennent les décisions sur un coup de tête…
D’ailleurs, un avis en faveur d’Upstart sur le wiki Debian.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Par rapport à quoi?
Posté par zen . Évalué à 2.
Coté Debian le choix se fera visiblement entre Upstart et Systemd. Le débat est en cour et un journal parle du sujet :
http://linuxfr.org/users/misc/journaux/des-nouvelles-de-debian-et-de-systemd
[^] # Re: Par rapport à quoi?
Posté par Doug Le Tough (site web personnel) . Évalué à 7.
Cette manie d'oublier Slackware… Linux ce n'est pas que Debian/*buntu/RedHat.
[^] # Re: Par rapport à quoi?
Posté par Anthony Jaguenaud . Évalué à 5.
Cette manie d’oublier gentoo… Linux ce n’est pas que Debian/*buntu/RedHat/Slackware ;-)
# Il me semblait que Capsicum était maintenant activé par défaut
Posté par reno . Évalué à 7.
Ce qui me paraissait un gros point au niveau sécurité, maintenant je ne l'ai pas vu dans les release note alors j'ignore si c'est le cas..
[^] # Re: Il me semblait que Capsicum était maintenant activé par défaut
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 8.
Oui, c’est bien activé, et mentionné dans la release note (le lien est donné dans la dépêche).
[^] # Re: Il me semblait que Capsicum était maintenant activé par défaut
Posté par Xavier Teyssier (site web personnel) . Évalué à 8.
Et pour ceux qui se posent la question, Capsicum a déjà été détaillé dans une dépêche Linuxfr.
J'en cite un extrait : En deux mots, il s’agit de permettre aux applications de faire tourner certaines parties de leur code dans des « sandboxes » (bacs à sable) aux droits très restreints, gérés finement, avec la possibilité de recevoir ou de déléguer dynamiquement une partie de ces droits.
[^] # Re: Il me semblait que Capsicum était maintenant activé par défaut
Posté par Enj0lras . Évalué à 4.
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.
[^] # Re: Il me semblait que Capsicum était maintenant activé par défaut
Posté par Bapt (site web personnel) . Évalué à 6.
Pourtant c'est le cas, l'API/ABI a été modifié une dernière fois avant la release FreeBSD 10 pour justement ne plus bouger et être l'implémentation de référence, maintenant le userland peut être converti, beaucoup d'outils ont déjà été converti.
[^] # Re: Il me semblait que Capsicum était maintenant activé par défaut
Posté par Enj0lras . Évalué à 5.
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.
# Quelques autres changements
Posté par Enj0lras . Évalué à 5.
Principalement tirés de : https://wiki.freebsd.org/WhatsNew/FreeBSD10
logiciels par défauts
plateforme
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
[^] # Re: Quelques autres changements
Posté par Ambroise . Évalué à 2.
Pour BIND, c'est uniquement pour la partie récursive/cache.
Ils ont pas poussé NSD ou Knot ?
[^] # Re: Quelques autres changements
Posté par Joris Dedieu (site web personnel) . Évalué à 5.
Non, il y a eu un consensus autour du fait qu'un serveur autoritaire n'avait pas sa place dans le système de base (pas plus qu'un serveur imap ou http …).
[^] # Re: Quelques autres changements
Posté par Joff54 . Évalué à 3.
Pourquoi ne pas faire la même chose pour Sendmail ? Parce que la suppression de Bind, c'est aussi pour des problèmes de sécurité régulier (je ne jette pas la pierre à Bind, c'est le succès dira t-on).
Remplacer Sendmail par un Ssmtp (ou similaire) serait aussi judicieux dans ce cas.
[^] # Re: Quelques autres changements
Posté par Enj0lras . Évalué à 2.
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.
[^] # Re: Quelques autres changements
Posté par geb . Évalué à 2.
Pratique pour ne pas être emmerdé avec les bounces ;)
# image FreeBSD pour Raspberry Pi ?
Posté par TBTB . Évalué à 2.
Où trouver une image récente pour Raspberry Pi ?
Est-il obligatoire d'utiliser Crochet pour ça ?
[^] # Re: image FreeBSD pour Raspberry Pi ?
Posté par Joris Dedieu (site web personnel) . Évalué à 5.
C'est documenté sur https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi
On trouve des images sur http://www.db.net/downloads/ mais il n'y a effectivement pas d'image binaire officielle.
# Nombres aléatoires
Posté par Almacha (site web personnel) . Évalué à 5.
Après avoir lu la news sur le nouveau Linux 3.13 et en particulier cet article http://blog.cloudflare.com/ensuring-randomness-with-linuxs-random-number-generator je croyais que dans un générateur de nombres aléatoires, une mauvaise source ne pouvait pas diminuer la qualité, car de toute façon on fait un XOR. A la limite, ajouter une source parfaitement déterministe ne provoquerait simplement aucune amélioration de l'entropie.
Pourquoi est-il donc plus sécurisé d'enlever certaines sources de basse qualité alors ? FreeBSD ne fait pas de XOR comme Linux ?
[^] # Re: Nombres aléatoires
Posté par patrick_g (site web personnel) . Évalué à 10. Dernière modification le 22 janvier 2014 à 22:23.
Houlala…tu prends des risques en lançant le sujet :-)
Pour résumer les trois épisodes de la saga :
1) FreeBSD annonce que, suite aux révélations de Snowden, ils vont réduire le rôle des générateurs d'entropie implémentés en hardware (HW RNGs) car ils n'ont plus confiance en Intel ou en Via.
2) Un journaliste inconscient demande à Theo de Raadt (leader d'OpenBSD) si ils vont faire pareil que FreeBSD. Theo en profite pour passer le projet FreeBSD au lance-flammes en disant que ce sont des brèles qui ne connaissent rien à la sécurité. Que dans OpenBSD, et aussi dans Linux, cela fait des années (le commit sur le générateur Via date de 2003) qu'on n'accorde aucune confiance exclusive aux HW RNGs et qu'on se contente de les considérer comme une source d'entropie comme une autre qu'on mixe au sein de l'entropy pool.
Theo se demande même pourquoi les gens de FreeBSD, pendant des années, n'ont pas suivi les bonnes pratiques cryptographiques. Il lance même une accusation vraiment grave : "They must have chosen a few years ago to do this wrong, intentionally. Perhaps that decision was made by their Californian developers, the ones who work fairly close to that NSA building."
3) Marshall Kirk McKusick, un des grands manitous du monde UNIX et un des développeurs FreeBSD répond à Theo. En résumé il explique que ce choix avait été fait à l'époque pour des raisons de performances parce que les HW RNGs sont très rapides et consomment peu de CPU.
Il confirme donc parfaitement les critiques de Theo avec cette phrase en forme d'aveu : "Specifically, FreeBSD 9.2 shipped using 'rdrand' support enabled by default. If you have an Intel CPU supporting this feature, Yarrow will not be used for /dev/random: all randomness comes straight from the CPU's built-in random number generator."
Dans FreeBSD 9.2 on était donc complètement dépendant du générateur aléatoire rdrand d'Intel. A partir de FreeBSD 10.0 l'entropie générée par ce module sera envoyée dans Yarrow (le générateur cryptographique de nombres pseudo-aléatoires de FreeBSD).
C'est donc certes un progrès pour FreeBSD mais ça arrive avec 10 ans de retard sur ses concurrents libres ;-)
C'est pourquoi je me permets de rigoler un bon coup en lisant cette phrase dans l'article d'ITWire : "McKusick said FreeBSD remained committed to staying on the leading edge of cryptographic engineering."
Leading edge ? Mouarf !
# ZFS dés l'installation.
Posté par Kwiknclean . Évalué à 3.
Voilà enfin ce que j'attendais, /racine natif en ZFS (bien qu'expérimental si j'en crois le menu d'installation), orné du nouvel algo de compression LZ4 … je sens que je vais me gaver.
J'attends la fin de l'installation de ma VM de test pour voir si j'arrive à reproduire mon environnement existant (Ubuntu Server/ZFS/LxC), vers quelque chose du genre ZFS/Jails.
Et à moi les joies de la sauvegarde système par snap ZFS, et la compression, les réplications block vers des machines distantes rhaaaa : )
Niveau "virtualisation" c'est toujours autant le bazar en revanche y en a partout.
Je suis un peu plus inquiet sur les fonctionnalités que propose les Jails par rapport aux LinuXConteneur, le niveau de virtualisation est-il "le même" ?
J'entends par là Jails n'est il pas qu'un super chroot, qui ne virtualise pas du tout en fait, qui chroot façon stéorïde et qui autorise uniquement des "VM" BSD ?
Les LxC bon c'est pas mal, mais ça sent quand même le produit pas trop mature je trouve, mais je commence à m'y faire, coupler à des slices ZFS ça envoie juste du petit pâté pour la sauvegarde ou la migration des conteneurs.
OpenVZ bon ça c'est en fonction de la distribution, c'est très sympa (sur les distro Noyo 2.6 … ),Ubuntu server plébicite beaucoup plus LxC, je ne souhaite pas installer Debian 6.0 et mon test avec CentOS 6.3 m'a montré quelques bizarreries avec ZFS (niveau montage)
KVM,Vserver,Xen et compagnie ne me présente pas d'intérêt (trop lourds).
Sinon quelqu'un aurait un commentaire éclairé à faire par rapport à ça : FreeBSD Jails Security
[^] # Re: ZFS dés l'installation.
Posté par neil . Évalué à 4. Dernière modification le 22 janvier 2014 à 22:15.
De fait, ça a toujours très bien marché sans utiliser l’installeur graphique, au moins en version 8.x et 9.x. Installeur qui est un tantinet inutile vu le peu de commandes nécessaires à l’installation.
Pour le fameux blog de BSD FUD, tu pourras trouver quelques réponses en ligne.
[^] # Re: ZFS dés l'installation.
Posté par Bapt (site web personnel) . Évalué à 7.
Ton lien final c'est juste du n'importe quoi, lit un peu le reste des articles sur ce site et tu comprendras qu'il n'y a absoluement rien a tirer de ce site.
(Par exemple selon se site j'ai volée le code d'apt, violé la license, et viré toutes les parties que je ne comprennais pas)
[^] # Re: ZFS dés l'installation.
Posté par Patrick Lamaizière (site web personnel) . Évalué à 4.
Ce site m'a fait marrer, je ne vois pas comment on peut le prendre au sérieux plus de 5 secondes :)
Mais bon, tu ne mérites pas ça :)
les pixels au peuple !
[^] # Re: ZFS dés l'installation.
Posté par Bapt (site web personnel) . Évalué à 5.
Au contraire ça veut dire que pkgng est pas mal si des gens pensent que j'ai piqué le code de apt :), ce site me fait rire aussi. A chaques fois, j'attends avec impatience la nouvelle news :)
[^] # Re: ZFS dés l'installation.
Posté par Patrick Lamaizière (site web personnel) . Évalué à 5.
Oui les jails ce n'est pas de la virtualisation, c'est du "confinement". Un chroot mais qui va plus loin que le confinement au niveau disque (et n'a pas les soucis de chroot en terme de sécu), confinement de root, confinement des processus, et confinement réseau.
C'est tout, l'avantage c'est que ça a très peu de coût en terme de performance.
les pixels au peuple !
[^] # Re: ZFS dés l'installation.
Posté par barmic . Évalué à 2.
Mis à part les problèmes du chroot, c'est fonctionnellement à peu près équivalents aux namespace linux, non ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ZFS dés l'installation.
Posté par Patrick Lamaizière (site web personnel) . Évalué à 4.
je ne connais pas trop linux, concernant les jails le papier d'origine de PHK est toujours d'actualité pour le principe http://phk.freebsd.dk/pubs/sane2000-jail.pdf
Y'a eu des améliorations depuis (ipv6, jail sans IP, réseau virtualisé) mais c'est toujours ça.
les pixels au peuple !
[^] # Re: ZFS dés l'installation.
Posté par Joff54 . Évalué à 3.
Je ne connais pas non plus les namespace Linux, mais pour faire simple, c'est un chroot disque, un chroot réseau (partiel, une interface appartient toujours à son hôte), un chroot mémoire. Il y a encore quelques limites techniques mais elles sont rares (nfs ne fonctionne pas dans une jail).
Si tu veux avoir un pile réseau complête, tu peux rajouter l'option VNET. Dans ce cas peut dire que la carte réseau n'appartient plus à l'hôte mais plutôt à la jail. Si tu veux partager la carte entre jail et l'hôte, faut faire du bridge (et utiliser netgraph, mais la ca dépasse mes compétences).
Moi, je ne me sers que des jails sans VNET, ca suffit amplement.
Le plus chiant, c'est les mises à jour des jails, c'est pas aussi pratique que l'OS hôte. Mais la encore, on trouve de très bon outils (en SH je crois), qui nous aident.
J'ai pas l'impression qu'il y ait eut des nouveautés en 10.0
[^] # Re: ZFS dés l'installation.
Posté par neil . Évalué à 4.
Tu peux aussi faire tourner du « Linux » en jail FreeBSD
# Je voulais tester et je suis tomber sur ce brûlot
Posté par rmosca . Évalué à -1.
Freebsd, un système d’exploitation obsolète et dangereux?
Du coup, je reste perplexe… Je me doute bien que la réalité n'est pas si terrible, mais ça fait peur
[^] # Re: Je voulais tester et je suis tomber sur ce brûlot
Posté par Bapt (site web personnel) . Évalué à 6.
J'utilise FreeBSD en desktop tous les jours, sur mon laptop aussi, et pire je suis sur du CURRENT (aka la version de dev) sur le portable, et j'en suis très content :)
[^] # Re: Je voulais tester et je suis tomber sur ce brûlot
Posté par Patrick Lamaizière (site web personnel) . Évalué à 4.
Oui mais là tu es un aventurier :) Ceci dit je l'utilise en desktop tous les jours chez moi et au boulot et j'en suis content aussi (même si je peste régulièrement sur les ports cassés)
Au taf j'ai tenté une Ubuntu dans un moment de folie et j'en suis vite revenu. Je dois être trop vieux.
les pixels au peuple !
[^] # Re: Je voulais tester et je suis tomber sur ce brûlot
Posté par xcomcmdr . Évalué à 2.
C'est plus Ubuntu qu'il faut tenter, c'est Archlinux (ou Xubuntu si on préfère *buntu). ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Je voulais tester et je suis tomber sur ce brûlot
Posté par Enj0lras . Évalué à 5.
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.
[^] # Re: Je voulais tester et je suis tomber sur ce brûlot
Posté par Enj0lras . Évalué à 5.
Sinon, une réponse plus sur le fond :
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.
[^] # Re: Je voulais tester et je suis tomber sur ce brûlot
Posté par Joff54 . Évalué à 1.
Il confond pas avec OpenBSD ??.
Pour moi FreeBSD, c'est plutot les perfs (a comparé avec NetBSD pour la portabilité et OpenBSD pour la sécu.)
C'est comme pour les Linux, c'est juste une question d'utilisation.
[^] # Re: Je voulais tester et je suis tomber sur ce brûlot
Posté par David Demelier (site web personnel) . Évalué à 3.
Je sais pas si on peut beaucoup parler de performances avec FreeBSD. En toute honnêteté, FreeBSD est légèrement moins réactif qu'un Linux pour ma part. Les compilations sont un poil plus longues et la réaction des environnement graphiques aussi.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Je voulais tester et je suis tomber sur ce brûlot
Posté par MTux . Évalué à 5.
En gros le mec a eu une mauvaise expérience en desktop parce que son matériel n'était pas correctement supporté. Et il en profite pour chier sur tout le projet parce que quelqu'un (je me demande bien qui) lui a fait croire que c'était l'OS idéal, prêt à l'emploi du genre OS X.
[^] # Re: Je voulais tester et je suis tomber sur ce brûlot
Posté par David Demelier (site web personnel) . Évalué à 2.
Il en a le problème le gars. Wifi, USB, carte graphique, carte son. En fait rien ne fonctionne sur son PC :-). Soit c'est un gros PEBKAC soit il a vraiment un matos désuet.
Pour ma part, seul l'ACPI (mise en veille) me pose problème. Tout le reste fonctionne :-).
git is great because linus did it, mercurial is better because he didn't
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.