Tu vas peut être prendre ca pour un troll, mais même si j'ai beaucoup d'estime pour les *BSD, dpkg me manque toujours...
Non je suis d'accord qu'il y a beaucoup à faire pour améliorer les ports FreeBSD. Mais ce n'est pas une question de noyau ou de userland. C'est surtout une question de main d'oeuvre pour faire les paquets. Je ne vois pas ce qui empecherait de porter dpkg sous FreeBSD.
Donc une Debian avec noyau BSD, ca serait la seul façon pour moi d'avoir un BSD sur mes machines.
J'ai utilisé Mac OS X une bonne année et je suis plutôt déçu en fait.
C'est joli, ça fonctionne très bien mais je ne trouve pas ça si ergonomique au final.
Par exemple un truc con, c'est quand on travaille sur deux écrans, le menu de l'appli est toujours affiché sur l'écran principal ce qui impose des va-et-viens avec la souris pour y accéder. Plutôt chiant à l'usage.
Autre truc impossible de maintenir une fenêtre par dessus/dessous les autres. C'est pratique ça.
L'intégration entre les applis X11 et les applis native Mac n'est pas assez poussée, je n'ai pas réussi à associer claws-mail comme lecteur de mail par défaut (en y passant des liens mailto:). Impossible de mettre une appli X11 dans le dock sans passer par une bidouille.
Et qu'est ce qu'il reste si on enlève les applis X11 ? À mon avis pas grand chose...
Bref j'ai craqué et j'ai mis FreeBSD (même si le support matériel n'est pas aussi fonctionnel que sous Mac OS X ou Linux), et je retrouve avec joie Wind^H^HKDE et mes applis préférées.
Les scripts d'init sont appelés séquentiellement. Il n'y a pas d'équivalent de fastboot (que je sache).
Le problème de fastboot me semble quand même la complexité de gérer et de maintenir les dépendances ? Si c'est juste pour gagner une seconde ?
Il faut aussi que le noyau soit finement locké, pas très utile de lancer 50 fonctions en concurrence pour le même lock.
Il m'a semblé voir passer une tentative pour lancer les scripts d'init en parallèle sous FreeBSD mais de mémoire ça n'avait pas soulevé l'enthousiasme des foules.
Ça me semble faisable, les scripts sont ordonnés un peu à la manière de pinit de Mandrake (c'est le 'RCng' pompé chez NetBSD) par un outil rcorder(8)
Par exemple /etc/rc.d/nfsd
#!/bin/sh
# PROVIDE: nfsd
# REQUIRE: mountd
# KEYWORD: nojail
J'ai jamais compris les différences entre RELEASE et STABLE. Bêtement, je pensais que la version STABLE était la version stable, mais il semble qu'il s'agisse de la version de développement...
Me gouré-je ? Kékun pour expliciter ces différences ?
La branche (on parle de tag cvs, même si maintenant FreeBSD utilise svn) RELEASE ne reçoit que les mises à jours de sécurités ou corrections de gros bugs. Il n'y a pas d'autre modification. La branche STABLE reçoit des modifications qui ont été testées dans la branche HEAD (dite aussi CURRENT : la branche de développement). Une fois qu'un truc marche en CURRENT il est MFCed (merge from current) dans STABLE.
STABLE est censée être stable en gros. CURRENT n'est pas censée marcher et est pour les développeurs et les aventuriers, même si la politique actuelle semble d'avoir une CURRENT relativement stable.
Si on pouvait m'expliquer aussi les subtilités entre les différentes manières de maintenir à jour ou upgrader une FreeBSD et notamment ces sombres histoires de ports.
Tu as deux choses différentes : le système (ie le noyau et la base) et les ports.
Les branches STABLE / RELEASE (...) ne s'appliquent qu'au système. Il n'y a pas de version sur les ports, ça évolue en permanence.
Le système est mis à jour en mettant à jour les sources de la base (/usr/src) puis en recompilant le monde et le noyau. Les ports sont mis à jour : en mettant à jour l'arbre des ports (/usr/ports) et en recompilant les applis (ou avec des paquets binaires). Il y a aussi freebsd-update qui permet une mise à jour binaire du système (base + noyau)
J'avais essayé de suivre les batailles sur fr.comp.os.bsd, mais ça dérive facilement vers le troll ces histoires
Sûrement un coup des openBSDistes.
et mes questions (trop naïves ?) n'avaient pas reçu de réponse là-bas.
Je suis le seul qui soit surpris par le fait que Gnome soit en version 2.22 alors que la 2.24 est sortie il y a environ 3 mois ?
Lors de la préparation de la release, l'arbre des ports est gelé (hormis correction de bug) afin d'avoir un ensemble de paquets binaires qui marche pour la release.
Les ports ont été gelés vers septembre (de mémoire), seulement la release n'est sortie que maintenant d'où le décalage.
et bien j'aimerais savoir si il y a aussi un équivalent de make.conf dans les bsd. Spécialement sur DragonFlyBSD et NetBSD, les deux qui m'interressent le plus.
Tu as /etc/make.conf (FreeBSD et DragonFlyBSD -je supose) et /etc/mk.conf pour NetBSD
Depuis FreeBD 7, un nouveau fichier est apparu /etc/src.conf qui s'applique à la base (ie /usr/src/)
csup/portinstall/portupgrade, bah c'est moins convi qu'un aptitude (pas d'interface, 'faut modifier divers fichiers de conf'
Ben oui il faut modifier la conf. FreeBSD est neutre à ce point de vu : c'est à toi de configurer les applications avec les outils ou les fichiers fournies par l'appli. Je n'aime pas Debian pour ça, c'est beaucoup trop intrusif et en plus propre à Debian...
y a pas des fonctions comme l'effacement des dépendances devenues inutiles, etc.)
Si si y'en a même plusieurs (dans les ports) ...
- toujours au niveau de la gestion des logiciels, j'ai voulu désinstaller Sendmail (je dis bien « désinstaller » comme dans « purger définitivement de mon disque la chose impure », pas « désactiver dans le rc.conf »). Comme il fait partie du système de base, galère infâme qui se termine par des rm sauvages. Je préfère largement un bon `aptitude purge sendmail'...
Sous FreeBSD tu as un 'wrapper' pour le mail, (/etc/mailer.conf). Ce qui fait que c'est très simple d'utiliser postfix par exemple.
Tu as toute liberté pour configurer ça (même si changer le shell de root est déconseillé - voir le compte toor pour ça). Tu peux installer vim...
Ceci dit tcsh n'est pas si nul une fois configuré (j'utilise que ça). Et Bash est en licence GPL.
- Pas de /proc/sys. Oui, on peut rajouter quelques trucs genre /proc/cpuinfo et /proc/meminfo mais ça reste moins complet.
/proc est déprécié en faveur de sysctl. Je n'ai pas vraiment suivi pourquoi, il me semble que /proc posait des problèmes de sécu.
Le fait qu'il n'y ait pas de proc m'a jamais manqué...
- Les commandes qui n'ont pas les options auxquelles on est habitué ; c'est pénible de taper un `ps afx', ou un `netstat -elnptu' pour se faire dire que, nan, ça marche pas. Rajouter les coreutils GNU aide un peu, ceci dit.
C'est chiant ces commandes gnu qu'ont pas les mêmes options que tout le monde :)
- J'aurais aussi aimé des fichiers de conf' par défaut plus propres pour les programmes installés depuis les ports. Debian fait ça très bien (en particulier pour les « gros » logiciels, genre Postfix ou MySQL) et c'est sympa (oui, je peux très bien nettoyer la conf' moi-même mais je suis fainéant et j'aime bien qu'on me facilite la tâche).
Comme j'ai dit FreeBSD est très neutre de ce point de vue. Ce sont les fichiers de conf de postfix par exemple, qui mieux que les auteurs peuvent proposer des fichiers de conf ? Postfix c'est postfix quelque soit l'OS quand même !
C'est un des points que j'aime sous les BSD, les applications sont telles quelles, si il a bug c'est remonté et corrigé en upstream (sauf si c'est vraiment spécifique à la plateforme). Bref l'OS est là pour faire tourner des applications, ce n'est pas une distribution. On n'est pas là pour patcher openssl...
Tout cela est resté très superficiel. Je n'ai pas tenté de recompiler le noyau (le -GENERIC marchant très bien) ou de reluquer du côté de geom pour les disques, donc je peux pas trop juger. pf m'a paru très bien comme pare-feu en revanche (mais je suis désormais un /addict/ à NetFilter). D'ailleurs, si quelqu'un a une liste de fonctionnalités sympas spécifiques à FreeBSD, je serais preneur.
Geom est sympa dans le principe. Mais d'un point de vue utilisateur c'est relativement transparent. Il y a Netgraph qui est paraît-il génial mais j'ai jamais eu besoin. ZFS, Dtrace.
Perso je suis un addict des jails, je trouve ça génial et j'aurais du mal à m'en passer.
2/ Est ce simple d'avoir son propre serveur mail. question sécurité, filtre spam, toussa. Ça risque aussi de poser problème puisqu'il me faut une dispo 24h/24. d'ailleurs autre question si mon serveur redémarre et qu'on tente de m'envoyer un mail, l'expéditeur reçoit un mailer deamon ou ça retentera de le renvoyer ?
L'expéditeur devrait recommencer. Mais tous ne le font pas (incroyable le nombre de serveurs de mail administrés avec les pieds).
Le plus gros problème je pense est qu'un serveur sur une IP résidentielle a de forte chance d'être filtré et que tu auras besoin d'un smtp externe (celui de ton FAI par exemple). Ne pas oublier qu'un certain nombres de FAI filtrent le port 25 aussi...
Sans compter que bien sûr la machine tombe en panne quand tu es loin de chez toi.
Si tu ne souhaites pas te pendre la tête, un herbergement mail n'est pas cher (18 euro TTC/an).
C'est super si on finit par remplacer Windows, mais si c'est pour le remplacer par un truc aussi instable et bordéliquement géré, ça n'est pas vraiment mon idéal de futur...
Pas grave la communauté gratuite et serviable du libre répare les ubuntu cassés.
Je sais pas pour vous, mais au lug de mon coin c'est dingue le nombre de gens qui viennent parce que ça marche plus suite à une mise à jour.
Si Theo pense vraiment que GCC n'est pas maintenu upstream alors il doit vivre dans un monde parallèle au notre. Un monde ou IBM, Red Hat, Novell, Bull, Google, l'INRIA, et de nombreuses autres entreprises et universités ne contribuent pas au développement de GCC (allez donc voir les affiliations des auteurs des articles des différents GCC summits).
Dire qu'on soutient PCC car on trouve que GCC n'est pas maintenu c'est grotesque.
Gcc a laissé tomber des architectures toujours maintenues dans OpenBSD, de ce point de vue on peut pas dire que gcc est maintenu.
Je t'invite à lire les commentaires de Marc Espie sur gcc.
"Le plus impressionnant est selon moi les perfs du module matériel AES, openssl dispose d'un engine lui permettant d'utiliser le padlock de via, à quand un patch pour le geode ?"
Jamais : le cryptage avec le via padlock est fait par des instructions étendues du processeur, l'approche utilisée sur le Geode LX est complètement différente.
Même s'il est intégré au processeur, le bloc de sécurité AES est vu comme un périphérique PCI, on y accède en faisant du DMA entre la mémoire et le périphérique.
Pour accéder au matériel, OpenSSL utilise un périphérique cryptodev qui fait le lien entre le userland et le matériel dans le noyau. C'est ce qu'apporte l'Open Crypto Framework (OCF). Sous les BSD, OCF est aussi utilisé en interne par le noyau (pour IPsec par exemple).
J'ai fais pas mal de tests de perf avec OpenSSL sous FreeBSD (j'ai porté le driver glxsb d'OpenBSD sous FreeBSD). Ce qui me chagrine le plus dans le bloc de sécurité c'est la lenteur des interruptions pour déterminer la fin du codage. Du coup il faut utiliser un horrible busy-wait et tester la fin en lisant les registres. Beurk !
- sans le matériel:
1m11.57s real 1m7.69s user 3.34s sys
- avec le matériel en utilisant les interruptions (oui c'est plus long en temps réel)
1m27.08s real 1.58s user 6.85s sys
- avec le matériel et un busy wait.
18.41s real 1.51s user 16.75s sys
- avec le matériel et un busy wait, mais qui tourne dans un thread noyau (pour éviter de bloquer dans l'OCF). C'est la version actuelle du driver FreeBSD.
21.11s real 1.57s user 6.41s sys
Je suis preneur de mesures faites sous Linux.
J'ai aussi fait des essais sur IPsec en aes-128-cbc + hmac_md5, en faisant des pings flood simultanés à partir d'une autre machine "ping -f -s 3000". Sans le matériel, la machine est à genou avec 5 ping, top ne tourne plus. Avec le matériel, je peux faire 8 ping flood sans aucun soucis (je n'ai pas essayé plus loin). Top:
CPU: 0.0% user, 0.0% nice, 33.5% system, 12.5% interrupt, 54.1% idle
Je n'ai pas fait de benchmark d'Ipsec, OpenBSD annonce du 30Mbit/s mais sans en dire beaucoup plus :
http://www.onlamp.com/pub/a/bsd/2007/11/01/whats-new-in-bsd-42.html
Enfin bref il y a quand même un net gain de perf, et puis c'est présent sur le processeur alors autant s'en servir.
Pour le générateur de nombre aléatoire pas grand chose à dire, je l'ai testé avec le module rndtest (FIPS 140-2) de FreeBSD et j'ai eu une dizaine d'échecs en quatres jours, mais toujours avec des valeurs très proches de l'intervalle autorisé:
Tu as plusieurs cartes mère à base de processeur Geode LX qui partagent à peu près les mêmes trucs: un processeur Geode LX + un "companion chipset" CS5536.
Le CS5536 est un "chipset à tout faire" qui intègre entre autre :
- un contrôleur IDE jusqu'à UDMA100
- un contrôleur USB 2
- audio AC97
- clavier PS2
- UART
- GPIO
Tout ça est normalement bien reconnu sous Linux en libre.
Si la carte propose du SATA, il est fourni derrière l'IDE par un chipset convertisseur est n'est donc pas du vrai SATA, c'est le cas pour les soekris net5501.
Perso j'utilise une soekris net5501 avec un disque en SATA sous FreeBSD-Current comme serveur à tout faire. C'est pas une bête de course mais ça fonctionne bien.
Dans le contexte de l'époque (juillet 2003), FreeBSD accouchait dans la douleur de FreeBSD 5.1 (juin 2003). La branche 5 n'a commencé à marcher qu'à partir de la 5.2 voir 5.2.1 (Février 2004).
Pour ce qui était de la stabilité chez moi ça marchait plutôt bien, ama mieux que la branche 4 au moins au niveau de la couche USB et CAM.
Vu les résultats obtenus sous FreeBSD 7, je me demande si M.Dillon ne s'est pas mis le doigt dans l'oeil, évidemment ça a été long et compliqué pour arriver à un bon résultat.
Y'a quand même de bons trucs dans DragonFly.
Pour finir on parle du "Giant Lock" sous FreeBSD (pas BKL)
[^] # Re: Intérêt ?
Posté par Patrick Lamaizière (site web personnel) . En réponse à la dépêche Deux cœurs BSD chez Debian. Évalué à 1.
la traduction :
– NDIS directement dans le noyau ;
Merci pour le lien.
Pour NDIS ils disent en fait que c'est intégré aux sources du noyau de base, pas que c'est directement dans le noyau.
C'est un des avantages de FreeBSD, il ne faut pas choisir son kernel à 4 décimales prêt.
Visiblement il n'y a pas que le noyau d'utilisé, il doit y avoir les outils userland associés (pfctl, zfspool, ...) et peut-être la libc FreeBSD ?
les pixels au peuple !
[^] # Re: Intérêt ?
Posté par Patrick Lamaizière (site web personnel) . En réponse à la dépêche Deux cœurs BSD chez Debian. Évalué à 1.
Tu vas peut être prendre ca pour un troll, mais même si j'ai beaucoup d'estime pour les *BSD, dpkg me manque toujours...
Non je suis d'accord qu'il y a beaucoup à faire pour améliorer les ports FreeBSD. Mais ce n'est pas une question de noyau ou de userland. C'est surtout une question de main d'oeuvre pour faire les paquets. Je ne vois pas ce qui empecherait de porter dpkg sous FreeBSD.
Donc une Debian avec noyau BSD, ca serait la seul façon pour moi d'avoir un BSD sur mes machines.
Tu n'auras pas un BSD tu auras une Debian.
les pixels au peuple !
# Intérêt ?
Posté par Patrick Lamaizière (site web personnel) . En réponse à la dépêche Deux cœurs BSD chez Debian. Évalué à 5.
Si on veut utiliser le noyau FreeBSD autant utiliser FreeBSD directement, c'est libre et pas cher.
les pixels au peuple !
[^] # Re: ffmpeg
Posté par Patrick Lamaizière (site web personnel) . En réponse au journal test de llvm. Évalué à 1.
> Pour BSD.
FreeBSD semble s'orienter vers LLVM pour le système, il y a des travaux en cours (la raison c'est que la GPLv3 de gcc c'est *MAL*).
http://wiki.freebsd.org/BuildingFreeBSDWithClang
les pixels au peuple !
# besoin d'un tutoriel Ada pour newbie total de 15 ans
Posté par Patrick Lamaizière (site web personnel) . En réponse au message besoin d'un tutoriel Ada pour newbie total de 15 ans. Évalué à 3.
http://fr.wikibooks.org/wiki/Programmation_Ada/FAQ/
Bon courage.
les pixels au peuple !
# scoop
Posté par Patrick Lamaizière (site web personnel) . En réponse à la dépêche OpenBSD pour EeePC (901/1000). Évalué à 4.
Faut croire que si, si on en fait une dépêche.
Hé les gars, OpenBSD supporte un truc plus moderne qu'une machine sparc ou les ordinosaures de Miod.
Incroyable !
les pixels au peuple !
# Mac OS X
Posté par Patrick Lamaizière (site web personnel) . En réponse au journal Retour d'expérience du monde d'apple. Évalué à 6.
C'est joli, ça fonctionne très bien mais je ne trouve pas ça si ergonomique au final.
Par exemple un truc con, c'est quand on travaille sur deux écrans, le menu de l'appli est toujours affiché sur l'écran principal ce qui impose des va-et-viens avec la souris pour y accéder. Plutôt chiant à l'usage.
Autre truc impossible de maintenir une fenêtre par dessus/dessous les autres. C'est pratique ça.
L'intégration entre les applis X11 et les applis native Mac n'est pas assez poussée, je n'ai pas réussi à associer claws-mail comme lecteur de mail par défaut (en y passant des liens mailto:). Impossible de mettre une appli X11 dans le dock sans passer par une bidouille.
Et qu'est ce qu'il reste si on enlève les applis X11 ? À mon avis pas grand chose...
Bref j'ai craqué et j'ai mis FreeBSD (même si le support matériel n'est pas aussi fonctionnel que sous Mac OS X ou Linux), et je retrouve avec joie Wind^H^HKDE et mes applis préférées.
les pixels au peuple !
[^] # Re: Avec ce lien
Posté par Patrick Lamaizière (site web personnel) . En réponse au message SmartEiffel 12r8. Évalué à 1.
http://SmartEiffel.loria.fr et http://gforge.inria.fr/projects/smarteiffel
Peut-être veut-tu reprendre d'ancien projet non compatible avec la branche 2.x .
Oui c'est un vieux projet et je suis scotché à la 12.
Je n'ai aucune intention de migrer sur un compilateur qui cassera peut-être tout lors du passage en V3, j'ai déjà donné...
Merci quand même. Pour info on trouve encore la version 12r7 sur le ftp de FreeBSD (dans les distfiles).
les pixels au peuple !
[^] # Re: bsd ??
Posté par Patrick Lamaizière (site web personnel) . En réponse à la dépêche L'évolution de Fastboot. Évalué à 2.
Le problème de fastboot me semble quand même la complexité de gérer et de maintenir les dépendances ? Si c'est juste pour gagner une seconde ?
Il faut aussi que le noyau soit finement locké, pas très utile de lancer 50 fonctions en concurrence pour le même lock.
Il m'a semblé voir passer une tentative pour lancer les scripts d'init en parallèle sous FreeBSD mais de mémoire ça n'avait pas soulevé l'enthousiasme des foules.
Ça me semble faisable, les scripts sont ordonnés un peu à la manière de pinit de Mandrake (c'est le 'RCng' pompé chez NetBSD) par un outil rcorder(8)
Par exemple /etc/rc.d/nfsd
#!/bin/sh
# PROVIDE: nfsd
# REQUIRE: mountd
# KEYWORD: nojail
OpenBSD utilise le "vieux" style de script rc.
les pixels au peuple !
[^] # Re: Release vs Stable
Posté par Patrick Lamaizière (site web personnel) . En réponse à la dépêche Sortie de FreeBSD 7.1. Évalué à 10.
Me gouré-je ? Kékun pour expliciter ces différences ?
La branche (on parle de tag cvs, même si maintenant FreeBSD utilise svn) RELEASE ne reçoit que les mises à jours de sécurités ou corrections de gros bugs. Il n'y a pas d'autre modification. La branche STABLE reçoit des modifications qui ont été testées dans la branche HEAD (dite aussi CURRENT : la branche de développement). Une fois qu'un truc marche en CURRENT il est MFCed (merge from current) dans STABLE.
STABLE est censée être stable en gros. CURRENT n'est pas censée marcher et est pour les développeurs et les aventuriers, même si la politique actuelle semble d'avoir une CURRENT relativement stable.
Si on pouvait m'expliquer aussi les subtilités entre les différentes manières de maintenir à jour ou upgrader une FreeBSD et notamment ces sombres histoires de ports.
Tu as deux choses différentes : le système (ie le noyau et la base) et les ports.
Les branches STABLE / RELEASE (...) ne s'appliquent qu'au système. Il n'y a pas de version sur les ports, ça évolue en permanence.
Le système est mis à jour en mettant à jour les sources de la base (/usr/src) puis en recompilant le monde et le noyau. Les ports sont mis à jour : en mettant à jour l'arbre des ports (/usr/ports) et en recompilant les applis (ou avec des paquets binaires). Il y a aussi freebsd-update qui permet une mise à jour binaire du système (base + noyau)
J'avais essayé de suivre les batailles sur fr.comp.os.bsd, mais ça dérive facilement vers le troll ces histoires
Sûrement un coup des openBSDistes.
et mes questions (trop naïves ?) n'avaient pas reçu de réponse là-bas.
Dommage fr.comp.os.bsd est plutôt bien fréquenté.
les pixels au peuple !
[^] # Re: Gnome et KDE périmés ?
Posté par Patrick Lamaizière (site web personnel) . En réponse à la dépêche Sortie de FreeBSD 7.1. Évalué à 8.
Lors de la préparation de la release, l'arbre des ports est gelé (hormis correction de bug) afin d'avoir un ensemble de paquets binaires qui marche pour la release.
Les ports ont été gelés vers septembre (de mémoire), seulement la release n'est sortie que maintenant d'où le décalage.
les pixels au peuple !
# [gentoo/BSD] différence compilation gentoo vs *BSD?
Posté par Patrick Lamaizière (site web personnel) . En réponse au message [gentoo/BSD] différence compilation gentoo vs *BSD. Évalué à 1.
Tu as /etc/make.conf (FreeBSD et DragonFlyBSD -je supose) et /etc/mk.conf pour NetBSD
Depuis FreeBD 7, un nouveau fichier est apparu /etc/src.conf qui s'applique à la base (ie /usr/src/)
les pixels au peuple !
[^] # Re: A propos ...
Posté par Patrick Lamaizière (site web personnel) . En réponse au journal Je suis passé sous FreeBSD ça y est !. Évalué à 2.
Ben oui il faut modifier la conf. FreeBSD est neutre à ce point de vu : c'est à toi de configurer les applications avec les outils ou les fichiers fournies par l'appli. Je n'aime pas Debian pour ça, c'est beaucoup trop intrusif et en plus propre à Debian...
y a pas des fonctions comme l'effacement des dépendances devenues inutiles, etc.)
Si si y'en a même plusieurs (dans les ports) ...
- toujours au niveau de la gestion des logiciels, j'ai voulu désinstaller Sendmail (je dis bien « désinstaller » comme dans « purger définitivement de mon disque la chose impure », pas « désactiver dans le rc.conf »). Comme il fait partie du système de base, galère infâme qui se termine par des rm sauvages. Je préfère largement un bon `aptitude purge sendmail'...
Sous FreeBSD tu as un 'wrapper' pour le mail, (/etc/mailer.conf). Ce qui fait que c'est très simple d'utiliser postfix par exemple.
- les choix par défaut (un vi assez /featureless/, tcsh plutôt que bash, etc.) sont assez lourdingues. Au moins, mettre ViM comme $EDITOR par défaut serait Bien©.
Tu as toute liberté pour configurer ça (même si changer le shell de root est déconseillé - voir le compte toor pour ça). Tu peux installer vim...
Ceci dit tcsh n'est pas si nul une fois configuré (j'utilise que ça). Et Bash est en licence GPL.
- Pas de /proc/sys. Oui, on peut rajouter quelques trucs genre /proc/cpuinfo et /proc/meminfo mais ça reste moins complet.
/proc est déprécié en faveur de sysctl. Je n'ai pas vraiment suivi pourquoi, il me semble que /proc posait des problèmes de sécu.
Le fait qu'il n'y ait pas de proc m'a jamais manqué...
- Les commandes qui n'ont pas les options auxquelles on est habitué ; c'est pénible de taper un `ps afx', ou un `netstat -elnptu' pour se faire dire que, nan, ça marche pas. Rajouter les coreutils GNU aide un peu, ceci dit.
C'est chiant ces commandes gnu qu'ont pas les mêmes options que tout le monde :)
- J'aurais aussi aimé des fichiers de conf' par défaut plus propres pour les programmes installés depuis les ports. Debian fait ça très bien (en particulier pour les « gros » logiciels, genre Postfix ou MySQL) et c'est sympa (oui, je peux très bien nettoyer la conf' moi-même mais je suis fainéant et j'aime bien qu'on me facilite la tâche).
Comme j'ai dit FreeBSD est très neutre de ce point de vue. Ce sont les fichiers de conf de postfix par exemple, qui mieux que les auteurs peuvent proposer des fichiers de conf ? Postfix c'est postfix quelque soit l'OS quand même !
C'est un des points que j'aime sous les BSD, les applications sont telles quelles, si il a bug c'est remonté et corrigé en upstream (sauf si c'est vraiment spécifique à la plateforme). Bref l'OS est là pour faire tourner des applications, ce n'est pas une distribution. On n'est pas là pour patcher openssl...
Tout cela est resté très superficiel. Je n'ai pas tenté de recompiler le noyau (le -GENERIC marchant très bien) ou de reluquer du côté de geom pour les disques, donc je peux pas trop juger. pf m'a paru très bien comme pare-feu en revanche (mais je suis désormais un /addict/ à NetFilter). D'ailleurs, si quelqu'un a une liste de fonctionnalités sympas spécifiques à FreeBSD, je serais preneur.
Geom est sympa dans le principe. Mais d'un point de vue utilisateur c'est relativement transparent. Il y a Netgraph qui est paraît-il génial mais j'ai jamais eu besoin. ZFS, Dtrace.
Perso je suis un addict des jails, je trouve ça génial et j'aurais du mal à m'en passer.
Tu as http://ivoras.sharanet.org/freebsd/freebsd7.html pour ce qui est apparu dans la branche 7 (tout n'est pas fini, ZFS reste expérimental)
Et http://ivoras.sharanet.org/freebsd/freebsd8.html pour la branche de développement FreeBSD-CURRENT.
Ce qui nous montre que BSD is diying.
les pixels au peuple !
# Cake automnal
Posté par Patrick Lamaizière (site web personnel) . En réponse à la dépêche Cake automnal. Évalué à 10.
Est-ce qu'on peut remplacer le fouet par les doigts agiles d'un utilisateur d'Emacs ?
les pixels au peuple !
# Serveur mail. local ou pas ?
Posté par Patrick Lamaizière (site web personnel) . En réponse au message Serveur mail. local ou pas ?. Évalué à 1.
De nom il y a Galacsys http://www.galacsys.net/courrier-electronique-professionnel.(...)
Qui a l'air sérieux (je crois même qu'on peut faire de l'uucp ou de l'etrn si on demande - mais peut-être pas pour ces prix).
2/ Est ce simple d'avoir son propre serveur mail. question sécurité, filtre spam, toussa. Ça risque aussi de poser problème puisqu'il me faut une dispo 24h/24. d'ailleurs autre question si mon serveur redémarre et qu'on tente de m'envoyer un mail, l'expéditeur reçoit un mailer deamon ou ça retentera de le renvoyer ?
L'expéditeur devrait recommencer. Mais tous ne le font pas (incroyable le nombre de serveurs de mail administrés avec les pieds).
Le plus gros problème je pense est qu'un serveur sur une IP résidentielle a de forte chance d'être filtré et que tu auras besoin d'un smtp externe (celui de ton FAI par exemple). Ne pas oublier qu'un certain nombres de FAI filtrent le port 25 aussi...
Sans compter que bien sûr la machine tombe en panne quand tu es loin de chez toi.
Si tu ne souhaites pas te pendre la tête, un herbergement mail n'est pas cher (18 euro TTC/an).
les pixels au peuple !
[^] # Re: Communauté Ubuntu
Posté par Patrick Lamaizière (site web personnel) . En réponse à la dépêche Test d'Ubuntu 8.10 Intrepid. Évalué à 5.
Pas grave la communauté gratuite et serviable du libre répare les ubuntu cassés.
Je sais pas pour vous, mais au lug de mon coin c'est dingue le nombre de gens qui viennent parce que ça marche plus suite à une mise à jour.
les pixels au peuple !
[^] # Re: Alternative ?
Posté par Patrick Lamaizière (site web personnel) . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 10.
Dire qu'on soutient PCC car on trouve que GCC n'est pas maintenu c'est grotesque.
Gcc a laissé tomber des architectures toujours maintenues dans OpenBSD, de ce point de vue on peut pas dire que gcc est maintenu.
Je t'invite à lire les commentaires de Marc Espie sur gcc.
http://undeadly.org/cgi?action=article&sid=2007091519520(...)
les pixels au peuple !
# Happy Halloween
Posté par Patrick Lamaizière (site web personnel) . En réponse à la dépêche OpenBSD 4.4 , The Trial of the BSD Knights. Évalué à 6.
1) BSD is dying ?
2) Le diablotin BSD ?
2) Les openBSDistes qui font peur ? (paraît qu'ils mangent les petits nenfants).
Bref je me demande quoi, c'est sûrement pas un hasard.
les pixels au peuple !
[^] # Re: A double tranchant...
Posté par Patrick Lamaizière (site web personnel) . En réponse au journal Quelle est la valeur d'une distribution Linux ?. Évalué à 8.
D'ailleur -de source officieuse- ils seraient en train d'écrire un outil SCOcount pour compter les lignes appartenant à SCO.
les pixels au peuple !
# Geode AES
Posté par Patrick Lamaizière (site web personnel) . En réponse au journal Que vaut vraiment l'AMD Geode LX 800 ?. Évalué à 4.
Jamais : le cryptage avec le via padlock est fait par des instructions étendues du processeur, l'approche utilisée sur le Geode LX est complètement différente.
Même s'il est intégré au processeur, le bloc de sécurité AES est vu comme un périphérique PCI, on y accède en faisant du DMA entre la mémoire et le périphérique.
Pour accéder au matériel, OpenSSL utilise un périphérique cryptodev qui fait le lien entre le userland et le matériel dans le noyau. C'est ce qu'apporte l'Open Crypto Framework (OCF). Sous les BSD, OCF est aussi utilisé en interne par le noyau (pour IPsec par exemple).
J'ai fais pas mal de tests de perf avec OpenSSL sous FreeBSD (j'ai porté le driver glxsb d'OpenBSD sous FreeBSD). Ce qui me chagrine le plus dans le bloc de sécurité c'est la lenteur des interruptions pour déterminer la fin du codage. Du coup il faut utiliser un horrible busy-wait et tester la fin en lisant les registres. Beurk !
Pour crypter un fichier de 361 Mo:
/usr/bin/time -h openssl enc -e -aes-128-cbc -in file -out /dev/null
-k abcdefghijk -nosalt
- sans le matériel:
1m11.57s real 1m7.69s user 3.34s sys
- avec le matériel en utilisant les interruptions (oui c'est plus long en temps réel)
1m27.08s real 1.58s user 6.85s sys
- avec le matériel et un busy wait.
18.41s real 1.51s user 16.75s sys
- avec le matériel et un busy wait, mais qui tourne dans un thread noyau (pour éviter de bloquer dans l'OCF). C'est la version actuelle du driver FreeBSD.
21.11s real 1.57s user 6.41s sys
Je suis preneur de mesures faites sous Linux.
J'ai aussi fait des essais sur IPsec en aes-128-cbc + hmac_md5, en faisant des pings flood simultanés à partir d'une autre machine "ping -f -s 3000". Sans le matériel, la machine est à genou avec 5 ping, top ne tourne plus. Avec le matériel, je peux faire 8 ping flood sans aucun soucis (je n'ai pas essayé plus loin). Top:
CPU: 0.0% user, 0.0% nice, 33.5% system, 12.5% interrupt, 54.1% idle
Je n'ai pas fait de benchmark d'Ipsec, OpenBSD annonce du 30Mbit/s mais sans en dire beaucoup plus :
http://www.onlamp.com/pub/a/bsd/2007/11/01/whats-new-in-bsd-42.html
Enfin bref il y a quand même un net gain de perf, et puis c'est présent sur le processeur alors autant s'en servir.
Pour le générateur de nombre aléatoire pas grand chose à dire, je l'ai testé avec le module rndtest (FIPS 140-2) de FreeBSD et j'ai eu une dizaine d'échecs en quatres jours, mais toujours avec des valeurs très proches de l'intervalle autorisé:
glxsb0: rndtest: zeros interval 3 failed (723, 542-708)
723 pour 708
glxsb0: rndtest: ones interval 1 failed (2336, 2343-2657)
2336 pour 2343
Alors je pense que c'est bon, enfin j'espère c'est pas facile à dire.
les pixels au peuple !
# geode LX
Posté par Patrick Lamaizière (site web personnel) . En réponse au message Serveur perso silencieux. Évalué à 4.
Tu as plusieurs cartes mère à base de processeur Geode LX qui partagent à peu près les mêmes trucs: un processeur Geode LX + un "companion chipset" CS5536.
Le CS5536 est un "chipset à tout faire" qui intègre entre autre :
- un contrôleur IDE jusqu'à UDMA100
- un contrôleur USB 2
- audio AC97
- clavier PS2
- UART
- GPIO
http://www.amd.com/files/connectivitysolutions/geode/geode_lx/33238G_cs5536_db.pdf
La vidéo est directement intégrée sur le CPU. Le CPU contient aussi un générateur de nombre aléatoire et un moteur cryptographique AES en 128 bits.
http://www.amd.com/files/connectivitysolutions/geode/geode_lx/33234F_LX_databook.pdf
Tout ça est normalement bien reconnu sous Linux en libre.
Si la carte propose du SATA, il est fourni derrière l'IDE par un chipset convertisseur est n'est donc pas du vrai SATA, c'est le cas pour les soekris net5501.
Perso j'utilise une soekris net5501 avec un disque en SATA sous FreeBSD-Current comme serveur à tout faire. C'est pas une bête de course mais ça fonctionne bien.
les pixels au peuple !
[^] # Re: Les .PBI
Posté par Patrick Lamaizière (site web personnel) . En réponse à la dépêche Le grand saut pour PC-BSD 7.0. Évalué à 1.
GAG c'est bien.
les pixels au peuple !
[^] # Re: Les .PBI
Posté par Patrick Lamaizière (site web personnel) . En réponse à la dépêche Le grand saut pour PC-BSD 7.0. Évalué à 1.
Après un pbi n'embarque pas tout non plus, par exemple KDE et X sont (heureusement) installés dans une "base" utilisée par les pbi.
Quant au ports freebsd, il est parfois nécessaire de se creuser la tête et de mettre la main dans les Makefile... Pas pour des débutants, ama.
NetBSD c'est encore pire, la mise à jour d'un port commençait par le déinstaller. Je crois qu'il y a eu des progrès ceci dit.
les pixels au peuple !
# BSD : EuroBSDCon 2008 à Strasbourg
Posté par Patrick Lamaizière (site web personnel) . En réponse à la dépêche EuroBSDCon 2008 à Strasbourg. Évalué à 6.
Pas les moyens moi...
les pixels au peuple !
[^] # Re: Revisionnisme?
Posté par Patrick Lamaizière (site web personnel) . En réponse à la dépêche La version 2.0 de DragonFlyBSD est disponible. Évalué à 3.
Pour ce qui était de la stabilité chez moi ça marchait plutôt bien, ama mieux que la branche 4 au moins au niveau de la couche USB et CAM.
Vu les résultats obtenus sous FreeBSD 7, je me demande si M.Dillon ne s'est pas mis le doigt dans l'oeil, évidemment ça a été long et compliqué pour arriver à un bon résultat.
Y'a quand même de bons trucs dans DragonFly.
Pour finir on parle du "Giant Lock" sous FreeBSD (pas BKL)
les pixels au peuple !