Suite à ce journal, suis enfin passé sous FreeBSD.
Juste deux conseils :
- Etre persévérant.
- Compiler le système (du kernel jusqu'aux ports) non pas avec les ports de gcc mais le gcc 4.2.1 fourni de base (trop de pb d'inclusions d'headers et j'en passe, les bugs sont connus mais pas tous résolus à moins de modifier soit même ...).
Sinon voilà maintenant que la bataille est finie je suis presque triste :), maintenant tout marche nickel chrome.
Journal Je suis passé sous FreeBSD ça y est !
29
déc.
2008
# PC-BSD
Posté par vida18 . Évalué à 2.
http://www.pcbsd.fr/
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Ubuntu
Posté par zebra3 . Évalué à 5.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Ubuntu
Posté par tuxsmouf . Évalué à -4.
[^] # Re: Ubuntu
Posté par Janfi . Évalué à 2.
Les barbus préfèrent les distros pour les vrais hommes !
# Un autre conseil
Posté par Mr Kapouik (site web personnel) . Évalué à 4.
En gros si tu cherche a utiliser autre chose que le gcc livrer par défaut, que tout le monde a testé et validé, il est normal que tu risques de rencontrer des problèmes non résolu.
Si on suit le handbook pour freebsd, la FAQ pour OpenBSD et la documentation pour NetBSD, on peut facilement paraitre pour un l33t H4X0r qui utilise du BSD tout les jours.
[^] # Re: Un autre conseil
Posté par David Carlier . Évalué à 2.
Tu as tout a fait raison sur ce point, c'est toutefois possible de compiler avec les ports de gcc mais faut modifier les sources, un peu contre productif comme solution je l'admets. Le handbook est top ça c'est clair.
[^] # Re: Un autre conseil
Posté par Metzgermeister . Évalué à 3.
[^] # Re: Un autre conseil
Posté par Gniarf . Évalué à 9.
et je ne parle même pas des "man pages are obsolete, use info" et autres "If we find that the things in this man page that are out of date cause significant confusion or complaints, we will stop distributing the man page" du projet GNU. ça, c'est pour vendredi.
# FreeBSD, c'est simple !
Posté par kowalsky . Évalué à 4.
En même temps, le plus dur, pour installer FreeBSD, c'est de booter sur le CD...!
Et puis recompiler tout le système, pourquoi pas, mais je vois pas l'interet si tu n'es pas sur une archi exotique.
[^] # Re: FreeBSD, c'est simple !
Posté par David Carlier . Évalué à 1.
- Le support de la carte son
- Et du coup j'en ai profité pour retirer les modules inutiles
Mais c'est vrai en dehors de ça ou d'une archi à part, ça sert pas à gd chose.
[^] # Re: FreeBSD, c'est simple !
Posté par Laurent Cligny (site web personnel) . Évalué à 3.
exemple:
kldload snd_<nom_du_driver_de_ta_carte_son>
et d'ajouter:
snd_snd_<nom_du_driver_de_ta_carte_son>_load="YES"
dans /boot/loader.conf
[^] # Re: FreeBSD, c'est simple !
Posté par David Carlier . Évalué à 2.
Ok je mourrai moins bête ce soir :)
[^] # Re: FreeBSD, c'est simple !
Posté par Aefron . Évalué à 4.
Bah, maintenant que tu n'as plus à recompiler ton kernel, et que ta vie va être plus simple, tu pourrais juste aller te coucher, ce soir !
[^] # Re: FreeBSD, c'est simple !
Posté par David Carlier . Évalué à 2.
[^] # Re: FreeBSD, c'est simple !
Posté par Fabimaru (site web personnel) . Évalué à 9.
[^] # Re: FreeBSD, c'est simple !
Posté par vladislav askiparek . Évalué à 10.
[^] # Re: FreeBSD, c'est simple !
Posté par IsNotGood . Évalué à 10.
[^] # Re: FreeBSD, c'est simple !
Posté par David Carlier . Évalué à 4.
[^] # Re: FreeBSD, c'est simple !
Posté par Antoine J. . Évalué à 8.
[^] # Re: FreeBSD, c'est simple !
Posté par David Carlier . Évalué à 2.
[^] # Re: FreeBSD, c'est simple !
Posté par totof2000 . Évalué à 3.
[^] # Re: FreeBSD, c'est simple !
Posté par David Carlier . Évalué à 2.
[^] # Re: FreeBSD, c'est simple !
Posté par Joris Dedieu (site web personnel) . Évalué à 1.
Et 12 Go de libre dans /usr :)
[^] # Re: FreeBSD, c'est simple !
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 4.
[^] # Re: FreeBSD, c'est simple !
Posté par Obsidian . Évalué à 9.
[^] # Re: FreeBSD, c'est simple !
Posté par David Carlier . Évalué à 4.
[^] # A propos ...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 8.
[^] # Re: A propos ...
Posté par David Carlier . Évalué à 7.
- Une séparation nette entre le système et les applis => ça m'a bien servi j'ai pu faire place nette dans les ports quand j'ai m**dé sans remettre en cause le système en lui même, super bon point.
- C'est mieux qu'une Gentoo car on peut avoir un système stable et en même temps les toutes dernières applis.
- D'ailleurs j'ai opté pour que tout mon système soit relativement "up-to-date" (RELENG_7 soit actuellement la 7.1-PRERELEASE) et je n'ai pas rencontré de pb majeurs lors du make world et make kernel. J'ai le souvenir d'avoir été plus ennuyé sous Gentoo.
- De la sécurité "out-of-the box" sans avoir à rajouter du grsecurity et autres.
- Pf plus efficace et surtout compréhensible qu'IPTABLES.
Ce que j'aime moins :
- Les applis tellement linux centrics qui obligent à installer l'ABI de compatibilité justement.
- En cas de crash avec le fs ext3, la récupération est souvent meilleure qu'avec ufs2 (sous Debian j'ai jamais eu de soucis dans ce cas en tout cas). J'ai globalement l'impression que FreeBSD est plus sensible au moindre dysfonctionnement => sur un vieux DD qui a bien fait son temps j'ai pu installer sans pb une Debian alors que sous FreeBSD il veut rien savoir (avec tout plein de msg d'erreurs).
- Niveau multimédia (au sens large), Linux lui est supérieur (sauf peut être le son).
PS : Mon avis vaut ce qu'il vaut je me trompe peut être sur certains points, ne suis pas admin de formation mais plutôt dév.
[^] # Re: A propos ...
Posté par briaeros007 . Évalué à 1.
C'est moi ou ca reste quand même relativement antinomique ?
Parce que si ce sont les toutes dernières, par définition ca fait depuis pas longtemps qu'elles existent, et donc qu'elles ont des bugs.
et je n'ai pas rencontré de pb majeurs lors du make world et make kernel. J'ai le souvenir d'avoir été plus ennuyé sous Gentoo.
Quand j'avais testé gentoo, j'avais pas eu de problèmes :P
- De la sécurité "out-of-the box" sans avoir à rajouter du grsecurity et autres.
Ah, y'a selinux toussa aussi de base ?
[^] # Re: A propos ...
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
Ça se discute... Elles risquent d'avoir plus de nouveaux bugs pas encore débusqués, mais elles n'ont plus les anciens bugs qui ont été corrigés. Tout dépend de la confiance que l'on accorde aux auteurs des logiciels, et de ce qu'il y a dans le changelog...
[^] # Re: A propos ...
Posté par Victor . Évalué à 3.
Dans gentoo c'est tout ou rien (ou alors c'est pas tout mais c'est galère :)
[^] # Re: A propos ...
Posté par briaeros007 . Évalué à 0.
Le "système" un peu plus conséquent c'est ... des applications et des librairies.
Donc on demande à ce que le système soit à jour sans être à jour ?
J'ai compris ce qu'il veut dire, mais j'avoue qu'il me reste une idée de vouloir tout et son contraire dans cette formulation ;)
[^] # Re: A propos ...
Posté par David Carlier . Évalué à 2.
[^] # Re: A propos ...
Posté par nullisimo . Évalué à 5.
la reflexion a double tranchant ;-)
Si on te dit qu'il y a comme equivalent (ou presque, car je ne connais pas assez SE linux pour comparer les deux) les Mandatory Access Control [1] et un demon d'audit, tu vas surement repondre que "oui, mais c'est pas integre comme sous Fedora". C'est effectivement le cas, c'est "inclus" mais pas "out of the box".
FreeBSD (comme la plupart des BSD) sont des OS "nus", c'est plutot la coherence qui prime sur l'integration (enfin c'est ma perception).
[1] http://www.freebsd.org/doc/handbook/mac.html
[2] http://www.freebsd.org/doc/handbook/audit.html
[^] # Re: A propos ...
Posté par IsNotGood . Évalué à 2.
Tu peux expliquer ? Parce ton truc me donne mal à la tête.
Je ne vois pas en quoi SeLinux dans Linux est "incohérent", ni en quoi un travail d'intégration peut nuire à la cohérence. De même, je ne vois pas comment faire un truc cohérent si c'est mal intégré.
En passant, Fedora a toujours été au "top" pour la sécurité :
http://fedoraproject.org/wiki/Security/Features
[^] # Re: A propos ...
Posté par kowalsky . Évalué à 2.
mis a jour de dbus, toussa toussa...
[^] # Re: A propos ...
Posté par IsNotGood . Évalué à 2.
Quand tu branches un périphérique ça ne te dérange pas de "./configure ; make ; su -c "make install" ; vi bidule.conf ; C_INCLUDE_DIR=/opt/ailleurs ./configure ; (encore) make ; make clean ; su -c "make dist_clean" ; make ; su -c "make install" ; test ; patch < qui_est_nécessaire ; wget nouvelle_version ; cvs co HEAD ; etc ; su -c "modprobe le_nouveau_module ; mount -t fs -o l'option_qui_va_bien_pour_périphérique_amovible /dev/mon_truc_usb /un_répertoire_à_déterminer" ; etc".
Chaqu'un son truc.
[^] # Re: A propos ...
Posté par kowalsky . Évalué à 8.
Moi ce qui m'a fait le plus "rire", c'est ton :
En passant, Fedora a toujours été au "top" pour la sécurité :http://fedoraproject.org/wiki/Security/Features
C'est quoi au top de la securité pour toi ?
L'update dbus qui empêche les updates ?
Le flou sur une possible prise de main sur les serveurs RedHat, ceux la même qui contenait tout les paquets ?
Ah non, au top, ça veut dire que je peux cliquer sur le system-config-firewall pour fermer ou ouvrir des ports ?
Ah non, au top, c'est peut être un beau panneau policycoreutils-gui ou tout le monde s'empresse de mettre le bestio à disabled !
Je précise que j'utilise Fedora quotidiennement et que c'est une très bonne distrib (son pire defaut, c'est peut être toi en fait...), mais le au top sur la sécurité, pas en ce moment quoi, attend un an ou deux que certaine chose soit oublié.
Et en passant, si quand je branche un périphérique je devait taper tout ça, je le mettrais dans un fichier...
enfin, chaqu'un son truc...
[^] # Re: A propos ...
Posté par IsNotGood . Évalué à -2.
Regarde Fedora (je n'ai pas envis de me faire chier avec cette question).
> L'update dbus qui empêche les updates ?
Super, un bug. Et pour contourner le bug il suffit de faire "su -c 'yum update'". Et c'est réglé. Oui, des bugs il y en aura toujours et je n'ai jamais dit le contraire. Il y en a d'autre qui disent avec qu'Ubuntu/Debian/Apt il n'y a jamais de problème, ce qui est du super-pipo.
> Le flou sur une possible prise de main sur les serveurs RedHat, ceux la même qui contenait tout les paquets ?
Ce n'est arrivé qu'une fois pour Red Hat/Fedora Quelque soit la qualité de l'OS, tu n'est pas à l'abrit de problème de sécurité. Les améliorations ne font que diminuer les risques, elles ne les supprime pas.
Pour le flou, c'est pour des raisons juridiques. Le moment venu, Red Hat donnera toutes les infos. La parole de Red Hat est rarement remise en cause.
En passant, qu'elles ont été les conséquences pour l'utilisateur ? Pratiquement aucune, seulement les mises à jours qui ont mis quelques semaines à revenir.
> mais le au top sur la sécurité, pas en ce moment quoi, attend un an ou deux que certaine chose soit oublié.
La politique de l'autruche...
Pour toi le top de la sécurité, c'est avoir la chance de se faire oublier. Ce n'est pas l'ajout de technologies qui diminuent les risques, c'est seulement "avoir la chance de se faire oublier". Ce n'est pas le boulot énorme sur SeLinux, qui en passant est maintenant utilisé majoritairement et non désactivé majoritairement ( http://smolts.org/static/stats/stats.html onglet SeLinux ). Partiquement tout ce qu'a fait Fedora sur la sécurité a été rempris par les autres. Tu ne trouves pas ça bizarre si pour toi ça n'apporte rien ? Certes ce n'est pas le cas de SeLinux, mais ça ne devrait pas trainer.
> son pire defaut, c'est peut être toi en fait...
Joli compliment pour Fedora. Merci de me donner tant d'importance.
> Et en passant, si quand je branche un périphérique je devait taper tout ça, je le mettrais dans un fichier...
T'es fort toi. Je me suis fais mouché.
Ben il y en a fait qui font des programmes pour que ça se fasse tout seul au-lieu que des milliers d'utilisateurs perdent des heures à ça. C'est mal ?
[^] # Re: A propos ...
Posté par Metzgermeister . Évalué à 4.
[^] # Re: A propos ...
Posté par nullisimo . Évalué à 5.
bref. Je vais expliquer ce qui me paraissait evident.
D'abord si je prend fedora comme exemple, c'est plutot positif, pour sa bonne integration justement.
c'est plutot la coherence qui prime sur l'integration
L'integration ca coute cher en ressources (code, temps, communication etc.). L'integration est secondaire chez FreeBSD, les ressources etant relativement limitees. Sans oublier que l'integration est deja une orientation, ce qui rend l'OS moins "universel".
Alors quitte a miser sur quelque chose, autant que ce soit un systeme le plus coherent possible, et le moins mouvant possible, pour que le travail d'integration, ainsi delegue, ne soit pas remis en cause a chaque (cycle de) release(s). C'est tout :)
PS: merci pour le lien,
[^] # Re: A propos ...
Posté par IsNotGood . Évalué à 4.
> L'integration ca coute cher en ressources (code, temps, communication etc.).
Pas forcément.
Un exemple d'intégration, est d'utiliser les gestionnaires de paquet au-lieu de fournir un .tar.gz. Ça fait du boulot, mais après tu gagnes beaucoup temps (idem pour le développeur).
On peut trouver d'autres exmples.
Faire un système puissant, n'empêche pas de faire modulaire. Fedora a Selinux, ce n'est pas un problème de virer SeLinux. Ce qui bouffe du temps, ce n'est pas d'"intégrer" SeLinux, c'est de faire qu'il soit utilie et utilisé (c-à-d intéressant pour l'utlisateur). Pour atteindre ceci, SeLinux doit être "intégré". Pas "intégré" dans le sens "inextricable du système", mais "intégré" dans le sens est utilisé, est facilement utilisable, ne perturbe pas, marche "out of the box" sans qu'on y pense, n'est pas contraingnant (ou le moins contraignant), etc.
Ce n'est pas de l"intégration pour l'intégration (ou pour rendre inextricable), c'est pour rendre utilie/utilisable. Ceci est le but de tout OS ! FreeBSD compris. Et tu n'arrives à intégré que si c'est cohérent, que s'il y a une structure solide permettant cette intégration !
> Sans oublier que l'integration est deja une orientation, ce qui rend l'OS moins "universel".
N'importe quoi. Tu oublies la modularité. Linux est probablement (voire indiscutablement) plus "universel" que FreeBSD. Si on ne parle que de Fedora, c'est la base de RHEL (utilisé en serveur très très haut-gamme utilisant tous les rafinements de SeLinux), c'est la base de OLPC, c'est utilisé sur clée USB, en live CD read-only, sur PS3, il y a la versions Gnome toutes options, la version légère XFCE, etc.
"Fedora" et ses logos (qui sont des marques protégées de Red Hat) sont bien intégrés à Fedora. Encore une fois, pas dans le sens inextricable. On peut les virer sans problème afin de faire sa propre distribution.
Toujours pour le côté universel, Fedora est utilisable par pratiquement tout le monde. Les admins qui veulent faire des trucs bien tordus avec lvm2, GFS2, Fedora Directory Server, FreeIPA, SeLinux, etc, le curieux qui veut jeter à oeil un GNU/Linux sans se prendre la tête, le développeur pointu qui a besoin d'une bécane pour travailler (Linus Torvalds utilise Fedora :-)), etc.
> Alors quitte a miser sur quelque chose, autant que ce soit un systeme le plus coherent possible, et le moins mouvant possible, pour que le travail d'integration, ainsi delegue, ne soit pas remis en cause a chaque (cycle de) release(s). C'est tout :)
Ceci c'est seulement la prise en compte des ressources limités de FreeBSD.
Si Linux/Fedora arrête de développer, il aura aussi ces mérites de FreeBSD...
Vas-tu nous expliquer que le développement c'est mal ?
Les ressources moindres de FreeBSD par rapport à Linux a des conséquences. Toutes ces conséquences ne sont pas forcément bonnes ni voulues.
Je veux bien admettre qu'elles ont leurs charmes (système plus simple, plus facile à maîtriser dans les détails, moins de remise en cause de l'existant, etc).
Mais ce sont des conséquences ! Je ne pense pas que FreeBSD demande moins de développeur, moins d'innovation, etc.
Enfin, si tu veux un système qui ne bouge pas ("moins de remise en cause de l'existant"), Linux est aussi bien placé. Mais prend une RHEL (ou Centos) ou une SLE.
[^] # Re: A propos ...
Posté par nullisimo . Évalué à 1.
Ceci c'est seulement la prise en compte des ressources limités de FreeBSD.
Mais je maintiens que l'integration, c'est un choix, et un choix ca fait plaisir ou ca fache.
Les problemes de ressources y'en a des kilos, au pif sysinstall, ou la dependance de pans entiers de FreeBSD a une seule personne (zfs, ule, toolchains).
N'empeche qu'avec ces "consequences" je peux gerer assez facilement (mais avec pas mal de travail) mon parc de serveurs (de FreeBSD 5.x a 7.x). Je ne suis pas lie a une version pour avoir mon bind 9.5.x ou apache 1.3, 2.0 ou 2.2 (and co), que j'ai pas forcement a me frapper un src.rpm pour avoir une options de compil particuliere, que je peux upgrader une machine sensible quasiment les yeux fermes parceque je sais que la compatibilite binaire est la pour me sauver (enfin pas toujours) ou que je me trimballe pas une regle iptables "temporaire" sans le savoir ;-)
[^] # Re: A propos ...
Posté par IsNotGood . Évalué à 1.
Ta concèption de l'intégration m'échappe.
Imaginons que je fasse un programme. Au début il n'est qu'en source et en .tar.gz.
Pour quelle raison je ne ferais pas le travail d'intégration qui consiste a écrire un fichier .spec pour rpm (ou le fichier .bidule pour deb) ?
Si je ne le fais pas, ce n'est pas car l'intégration c'est mal, mais pour d'autres raisons : je n'ai pas les compétences, je n'ai pas le temps, etc.
Refuser l'intégration pour refuser l'intégration, je ne comprend pas.
> Je ne suis pas lie a une version pour avoir mon bind 9.5.x ou apache 1.3, 2.0 ou 2.2 (and co)
Ça c'est un autre problème qui n'est pas lié à l'intégration. Fedora peut parfaitement fournir apache 1.3, 2.0 et 2.2 à la fois. Il n'y a pas de problème technique significatif.
Si Fedora ne le fait pas, ce n'est pas à cause de l'intégration. Fedora ne le fait pas car ce n'est pas dans sa philosophie (Fedora veut être très proche des développements en cours et il n'est pas dans ses objectifs de fournir du (futur) "has been"). De même, Fedora pourrait fournir plusieurs versions de python ou perl. Mais ce n'est pas dans la philosophie de Fedora. Les choses se passent ainsi avec Fedora :
- pour la prochaine Fedora, il est, par exemple, décidé de passer de perl 5 à perl 6
- Perl 5 est viré de la branche de développement, Perl 6 est ajouté
- tous les scripts qui ne marchent pas en perl 5 sont corrigés (idéalement en travaillant avec l'upstream).
- test via les différentes beta de la prochaine Fedora.
- sortie de la nouvelle Fedora uniquement avec perl 6 (et c'est fait exprès !)
Sur le moment ça peut paraitre beaucoup de boulot (et c'est beaucoup de boulot). Mais sur le long terme c'est plus efficace de qu'avoir à maintenir différentes versions de perl et de scripts qui utilisent différentes versions de Perl.
Enfin Fedora n'est pas une distribution qui "se suffit" en général. Son support est trop cours pour un usage en serveur sérieux. Nombres de contributeur à Fedora ont une RHEL/Centos en parallèle.
Enfin founir apache 1.3, apache 2.0, etc à la fois est maintenant limite sans intérêt avec la virtualisation. D'autant que c'est principalement pour gérer l'existant. Sur ma F10 toute fraiche, j'ai une machine virtuelle avec RHEL 3 (apache 2.0 mais surtout php 4). Ça me prend 256 Mo de ram. Machine virtuelle que j'avais aussi sous mon ancienne F8. RHEL 3 qui était avant sur un ancien serveur (un PIII). J'ai seulement copié le disque sur un périphérique loop, fait quelques ajustements, puis utilisé libvirt. Pour passer de F8 à F10, j'ai seulement copier l'image de la machine virtuelle. Et voila.
Sur mon F10 j'ai aussi une machine virtuelle Centos 5 pour test avant de mettre en production les modifications (mise à jour au autre) sur EC2.
[^] # Re: A propos ...
Posté par David Carlier . Évalué à 2.
[^] # Re: A propos ...
Posté par ciol13 . Évalué à 5.
Non, Fedora ne le fait pas, mais parce que son modèle de développement est complètement débile.
Fedora n'a pas plusieurs versions d'apaches, normal quand on sort en catastrophe une release tous les 6 mois pour ne durer que 13 mois ça ne sert à rien de garder la 1.3 puisque de toute façon on met tout à jour.
Fedora serait obligée de maintenir apache {1.3, 2.0, 2.2} x F8, F9, 10, Rawhide.
La vérité c'est que la façon de faire de FreeBSD est la plus logique, celle de séparer la base des applications tierces dans un système de port (qui permet notez le d'avoir le choix entre des binaires ou pas).
Fedora veut être très proche des développements en cours et il n'est pas dans ses objectifs de fournir du (futur) "has been")
Tu te contredis : apache 1.3, 2.0 et 2.2 sont toujours maintenus upstream.
Je pense que l'upstream est très content de ne pas maintenir des vieilles versions pour rien.
Et je ne vois pas ce qu'il y a d'has been d'avoir installé apache 1.3 voilà plusieurs années, d'avoir toujours des maj de sécu, avec une putain de base stable aussi depuis des années, et quand ça sera effectivement "has been" comme tu dis, on sera pas obligé de mettre à jour tout notre système mais simplement apache...
Quand à être plus proche des développements en cours, on est pas obligé de fournir un KDE 4 pas fini dans une distribution stable pour ça, ou de faire une rawhide inutilisable qui ne contient que des beta : cf le dépôt experimental pour Debian ou les paquets -devel de FreeBSD.
Enfin founir apache 1.3, apache 2.0, etc à la fois est maintenant limite sans intérêt avec la virtualisation.
Je saute la partie business loto, parce que dieu merci il y a encore quelques utilisateurs qui utilisent la pleine puissance brute de leurs matos sur de vrais OS.
[^] # Re: A propos ...
Posté par ciol13 . Évalué à 3.
Si Fedora avait une base séparée des applications (bref si c'était un OS et pas une distribution), il y aurait plus de contrôle sur les paquets importants (et mettre à jour son système par l'interface graphique c'est important pour le pékin moyen).
Mais la vérité encore une fois c'est que Fedora potentiellement peut mettre à jour tout et n'importe quoi, aussi bien la glibc qu'un jeu : elle n'a pas de modèle de développement clairement défini ( http://fedoraproject.org/wiki/UpdatesPolicy ).
[^] # Re: A propos ...
Posté par IsNotGood . Évalué à -1.
Quel homme ! J'en frissonne.
FreeBSD est à l'OS ce que la Harley-Davidson est aux motos. Un truc pour vieux tatoués qui aiment jouer les durs.
[^] # Re: A propos ...
Posté par Jerome Herman . Évalué à 7.
Euh non, bien au contraire. FreeBSD est une distrib pour admin qui n'ont pas envie de se faire chier une fois la machine installée. Il n'y a quasiment jamais besoin de recompiler le kernel, La sécurité est au top dès le début, le support UTF-8 est au top sur quasiment tous les packages, les mises à jour (excepté pour java certes) se font sans le moindre accroc. On dispose d'une pléthore d'outils pour bien séparer les privilèges (jail, acl+mac, auto-chroot etc.) et surtout quoi qu'on ait envie de faire il y a une doc qui décrit pas à pas comment le faire (et neuf fois sur dix cette doc est directement dans le man).
En plus la distrib est exceptionellement stable (au sens on casse pas les ABI/API du terme) il est rarissime qu'une méthode d'install ou un script de config qui a été écrit pour la 4.0 ne fonctionne pas sur la 7.1.
Comme OS de vrai root qui veut mettre les mains dans le camboui pour faire le kéké on a fait mieux...
[^] # Re: A propos ...
Posté par IsNotGood . Évalué à 2.
> En plus la distrib est exceptionellement stable (au sens on casse pas les ABI/API du terme)
Certes. Mais dans ce cas il ne faut pas comparer FreeBSD à Fedora ni même Linux, mais à RHEL ou SLE.
[^] # Re: A propos ...
Posté par Jerome Herman . Évalué à 4.
Euh faut pas pousser non plus :
SLE et RHEL sont des distributions payantes avec un fort support commercial lié. Elles sont soumises aux choix d'entreprises privées. Les solutions proposées, les packages maintenus et les types de patch apportés ne sont pas le fait d'une communeauté mais d'une entreprise qui doit aussi réfléchir à la prérénité et à la maintenabilité du truc dans une optique de rentabilité commerciale. On aura jamais dans RHEL ou SLE la possibilité d'installer une dizaine de versions différentes d'un même logiciel et de la configurer pour avoir exactement ce que l'on veut comme options dedans. Essayez de remplacer le RHDS par un OpenLDAP 2.4 avec gestion kerberos V5 Heimdal et un schema de gestion des users custom par exemple.
Par contre les *BSD ne travaillent pas main dans la main vaec Oracle ou IBM, ils n'iront jamais casser une ABI ou une API pour gagner 8% de perfs sur les opérations dans une appli proprio en mode cluster, et ils se foutent pas mal de savoir si la fermeture de telle ou telle faille de sécurité va avoir un impact sur des installations d'appli proprios.
En plus, très honnêtement les *BSD sont nettement plus stable (toujours au niveau ABI/API) qu'une RHEL ou une SLE (mais là encore ce n'est pas une question de compétence mais de choix)
[^] # Re: A propos ...
Posté par briaeros007 . Évalué à 5.
Il est pertinent où ? En remettant en cause un modèle de developpement qui en vaux bien un autre (ie qui correspond au but de la distrib) en disant juste qu'il est "débile" ?
En sortant des énormité (comme "normal quand on sort en catastrophe une release tous les 6 mois") ?
En "encensant" un truc, alors qu'il est juste complètement différent ("La vérité c'est que la façon de faire de FreeBSD est la plus logique," ... euh pas vraiment non, la façon de faire de FreeBSD est DIFFERENTE , et à des BUTS DIFFERENTS. Pour faire du bleeding edge et permettre au plus grand nombre de tester un ensemble de nouvelles technos, la façon de faire de fedora est plus logique par ex).
Quand à être plus proche des développements en cours, on est pas obligé de fournir un KDE 4 pas fini dans une distribution stable pour ça, ou de faire une rawhide inutilisable qui ne contient que des beta : cf le dépôt experimental pour Debian ou les paquets -devel de FreeBSD.
Pour les paquets "-devel" je ne sais pas, mais pour le dépôt experimental... il n'a pas vocation à être utilisé normalement. Le dépôt expérimental il est là pour les developpeurs, et/ou pour les paquets qui n'ont pas de raison d'être dans SID (pas de vocation à se retrouver dans une stable ou autre raison).
Le fait que kde4 y soit n'y est pour rien (d'ailleurs si tu veux des versions à jour, du prend pas les versions de experimental mais de kde42.debian.net)
Enfin fedora ne revendique pas une distribution "stable", Tu veux la distrib stable de "fedora", c'est RHEL/CentOS
Ps : est ce que proposer une base "stable" avec des logiciels potentiellement buggé car up2date est plus intelligent ? Ca répond juste à une problématique différente.
[^] # Re: A propos ...
Posté par IsNotGood . Évalué à 2.
Je n'en avais pas le courage...
> Enfin fedora ne revendique pas une distribution "stable"
En fait, oui. Ça dépend évidemment de ta définition de "stable". Si c'est stabilité de l'API, alors Fedora n'est pas stable.
Si elle ne revendiquait pas être stable (dans le sens qualité/fiabilité), le dernier problème avec DBus n'en serait plus un :-)
La mise à jour de DBus n'a pas été testée car c'était une mise à jour de sécurité (donc urgente) qui n'est pas passée par update-testing. Update-testing montre bien qu'il y a une organisation pour faire une distribution stable. Il y a eu des discussions pour éviter ce genre de mésaventure (si un newbi ne peut pas mettre à jour, c'est un grave problème de sécurité). Autre exemple, ext4 n'est pas par défaut dans F10 (ni accessible par défaut dans l'installeur). Pourtant tout est là (sauf un support dans Grub mais ça arrivera avec Grub 2) et, anecdotiquement, ça marche nickel chez moi.
On ne va pas se raconter d'histoire, de par ses objectifs et son contexte de développement (plein de nouvelles technos) ce n'est pas la distribution qui offre la meilleure "assurance qualité" (pour utiliser un euphémisme).
[^] # Re: A propos ...
Posté par ciol13 . Évalué à 2.
Je ne dis pas simplement qu'il est débile, j'argumente.
mais pour le dépôt experimental... il n'a pas vocation à être utilisé normalement. Le dépôt expérimental il est là pour les developpeurs, et/ou pour les paquets qui n'ont pas de raison d'être dans SID (pas de vocation à se retrouver dans une stable ou autre raison).
C'est exactement ce que je veux dire.
Hypocritement, Fedora dit "nous on contribue avec l'upstream parce qu'on a les dernières versions".
Or, ce n'est pas la seule façon de contribuer. Le dépôt experimental est fort bien pensé.
Qu'est-ce qui se passe avec Debian ? En gros debian -unstable est l'équivalent de Fedora -stable. Donc pas tous les utilisateurs de Debian sont des cobayes.
Ensuite, pour tester les versions beta (ce qui est plus important pour une distribution que de tester les versions déjà stable), la solution avec Fedora c'est Rawhide. Mais comme tout ou presque est en beta, c'est un enfer.
Avec Debian, ceux qui veulent tester une version non stable du noyau, peuvent le faire et seulement pour le noyau (en théorie...).
Enfin, moi Fedora je l'ai testée.
Et les machinkits, les pulsetrucs pas finis, les bidulemanagers, les "DO NOT EDIT THIS FILE", j'en veux plus.
[^] # Re: A propos ...
Posté par briaeros007 . Évalué à 2.
Dire "freebsd est plus logique" n'est
1°) pas de l'argumentation
2°) n'explique pas en quoi fedora est "debile".
Or, ce n'est pas la seule façon de contribuer.
Il n'y a jamais une façon unique. Jusque la rien ne montre que la façon de faire de fedora est "mieux" ou "moins bien" (d'ailleurs, mieux ou moins bien sur quel critère ?)
Le dépôt experimental est fort bien pensé.
Tellement bien que je l'ai viré pour mettre kde42.debian.net...
Experimental peut flinguer ton système si tu ne fais pas gaffe :P, et il est pas si à jour que ça (cf kde4)
Avec Debian, ceux qui veulent tester une version non stable du noyau, peuvent le faire et seulement pour le noyau (en théorie...).
Et je suppose que sous fedora, la même granularité doit être possible avec yum.
Enfin, moi Fedora je l'ai testée.
Et les machinkits, les pulsetrucs pas finis, les bidulemanagers, les "DO NOT EDIT THIS FILE", j'en veux plus.
C'est ton choix, mais rien qui permet de dire que c'est moins logique que d'autres.
Qu'elle ne te convient pas, c'est le cas (et moi aussi fedora ne me convient pas, enfin surtout yum qui est leeeennnnntttttt) et pourtant je dis pas que fedora c'est "débile" ;)
[^] # Re: A propos ...
Posté par IsNotGood . Évalué à 3.
Ouais mais tu ne l'as pas dit...
> Hypocritement, Fedora dit "nous on contribue avec l'upstream parce qu'on a les dernières versions".
Pourquoi "hypocritement" ?
C'est vrai, c'est la distribution qui contribue le plus en upstream. Dire le contraire c'est hypocrite.
Tu peux dire que Fedora est "prétentieux". Pourquoi pas.
> parce qu'on a les dernières versions".
En passant, ce n'est pas ce que dit Fedora. C'est l'inverse. Parce que Fedora veut travailler le plus possible en upstream, Fedora utilise les dernières versions (et les versions non encore sorties). C'est une conséquence, pas un but.
> Or, ce n'est pas la seule façon de contribuer. Le dépôt experimental est fort bien pensé.
Si c'est FreeBSD avec un dépôt expérimental, c'est bien pensé pour toi. Si c'est Fedora qui veut faire du développement, pour toi ce n'est pas logique.
C'est bête ce que tu dis.
Tu veux une distribution stable, il y a RHEL/Centos/etc, filles (ou fork) de Fedora. RHEL c'est génial, c'est rock-solid, pas de changement d'API/ABI (même pour le noyau) et il y a des ajouts de driver :
http://dag.wieers.com/blog/umts-to-the-rescue-red-hat-only-s(...)
I was also pleasantly surprised that the newer RHEL 5.3 Beta kernels (also 2.6.18) had no issues with those very recent e1000e and iwlagn drivers. Red Hat spent the effort to backport those drivers from 2.6.25+ kernels to a 2-year old kernel they will support for the next 5 years !
Oui, c'est génial. Sauf que RHEL n'apporte pratiquement rien en contribution upstream. Sauf que RHEL n'est pas du tout adapter aux développeurs rapides ou "dangereux". Et ce sont pratiquement les mêmes qui développent RHEL et Fedora. Les deux sont complémentaires. Fedora remplit des fonctions qui sont en contradiction avec les objectifs de RHEL (et vice versa).
Considéres que Fedora est le "dépôt expérimental", RHEL la version dite stable et c'est grosso-modo dans la même logique que FreeBSD.
Si tu trouves RHEL génial, n'oublie pas que RHEL est impossible sans Fedora. Ou alors ça serait une RHEL avec moins d'innovation, Red Hat qui travaille moins en upstream, peu d'espace pour contribuer à RHEL (Red Hat l'a dit et redit, pour contribuer à RHEL, le mieux est de contribuer à Fedora), etc.
Il y a une logique à tout ça. Mais tu as décidé de ne pas la regarder. Certes cette logique n'est pas évidante, mais boucoup beaucoup la voit (ce qui n'est pas très dure puisque ce n'est nullement masqué).
Fedora != RHEL car leurs objectifs sont différents (on peut dire de même avec Fedora et FreeBSD). L'une n'est pas mieux ou plus "logique" que l'autre, c'est différent.
> En gros debian -unstable est l'équivalent de Fedora -stable.
Non !
Le unstable de Debian est équivalent à Rawhide de Fedora !
Le stable de Debian est équivalent au "stable" de Fedora (les releases).
Comme je l'ai dis plus haut, si tu veux dire que Fedora "stable" est plus buggué que Debian "stable" (et il y a de bonnes raisons à ça), pas de problème.
> Donc pas tous les utilisateurs de Debian sont des cobayes.
Il y a les utilisateurs et les développeurs/testeurs/contributeurs chez Fedora. Les utilisateurs utilisent les "releases", les développeurs/testeurs/contributeurs utilisent Rawhide et update-testing. Par exemple F10 a ext4 (qui était déjà dans F9), il n'est pas accessible par défaut. C'est actuellement (et encore) uniquement pour les testeurs/développeurs. Donc les utilisateurs ne sont pas pris pour des testeurs puisqu'il y a manifestement une différence de "traitement".
> Ensuite, pour tester les versions beta (ce qui est plus important pour une distribution que de tester les versions déjà stable), la solution avec Fedora c'est Rawhide.
Marrant comme tu te contredis rapidement. Mais ici pour être dans le vrai.
> Mais comme tout ou presque est en beta, c'est un enfer.
Et ?
Le travaille de maintenance d'un paquet est "pépère". L'ajout d'une fonctionnalité isolée est "pépère" aussi. mais pour le développement il y a des phases où c'est le "bordel". Tous les développeurs savent ça. Par exemple pour le nouveau boot graphique de F10, il a fallu modifier le noyau, mkinitrd, grub, les scripts de boot, créer plymouth, modifier gdm et Xorg. Et notes bien que ceci n'a pas été fait dans la branche "stable" mais sur Rawhide. Le fait que Fedora n'est pas une distribution développée en continu (il y a la phase de développement "déchainé" sur 4 mois, puis 2 mois de test/affinage) lui permet de "foutre le bordel" (dans la branche Rawhide !).
Pour les distributions développées en continu (par exemple un peu comme Gentoo ou Debian) ça va prendre des plombes pour avoir un boot graphique avec KMS et plymouth (alors que les développements ont été faits...)
> Et les machinkits, les pulsetrucs pas finis, les bidulemanagers, les "DO NOT EDIT THIS FILE", j'en veux plus.
Très bien (pour ne pas dire tant mieux et bon débarras).
Personne ne t'a dit ici de passer à Fedora. Mais toutes les conneries que tu dis sur Fedora ça fini par gonfler passablement.
[^] # Re: A propos ...
Posté par ciol13 . Évalué à 2.
Faux.
Dans Debian -unstable, il n'y a que des versions stables de logiciel.
Les versions beta sont à prendre au choix dans -experimental.
Si on prend un exemple, Fedora va avoir dans Rawhide une version en développement de Gnome.
Debian -unstable aura la dernière version stable de Gnome (en théorie, ce n'est pas le cas en ce moment), et la version de développement sera (peut être) dans -experimental.
Si tu trouves RHEL génial, n'oublie pas que RHEL est impossible sans Fedora
Je trouve RHEL génial, je comprends parfaitement le rôle de Fedora, mais pour moi elle est pour l'instant complètement bancale.
[^] # Re: A propos ...
Posté par IsNotGood . Évalué à 1.
Tu chipotes.
Il y a des iso pour unstable ?
L'équipe sécurité s'occupe d'unstable ?
Les dépôts unstable sont activés par défaut lors d'une installation ?
Il y-a-t-il un processus qualité dans unstable ?
> Dans Debian -unstable, il n'y a que des versions stables de logiciel.
D'où le nom "unstable"...
> mais pour moi elle est pour l'instant complètement bancale.
Le "pour moi" veut dire "pour mon usage" ?
Fedora n'est pas du tout bancale. Que ça ne te convienne pas est autre chose. Ce qui ne te convient pas n'est pas forcément bancale.
[^] # Re: A propos ...
Posté par David Carlier . Évalué à 4.
Parce que si ce sont les toutes dernières, par définition ca fait depuis pas longtemps qu'elles existent, et donc qu'elles ont des bugs.
Je parlais des applis portées. Tu peux avoir un kernel RELEASE 7.0 avec juste des patchs sécu et à côté des applis récentes. C'est moins évident sur Linux (sous gentoo on peut plus ou moins s'en approcher celà dit mais c'est moins "naturel").
[^] # Re: A propos ...
Posté par briaeros007 . Évalué à 3.
Et voir aussi ce que je disais plus haut : le système est constitué d'applications. Ces dernières doivent t'elles être à jour ?
Comment gérer les dépendances au cas ou une partie du système (& applis) dépendent d'une librairie, et une autre de la version n+1 ? Tout recompiler pour la v n+1 ?
(si on aime pas compiler, on aurait pu parler de debian (et sans doute de fedora) où avec l'apt pinning, je vois pas trop en quoi c'est difficile d'avoir des applis à jour (ex kde 4.1) qui se met à jour (prio >100 et <500 pour experimental ) et d'avoir le reste de la distrib en lenny par ex ;))
Amha c'est plus un problème de connaissance et d'accès à l'information ;)
[^] # Re: A propos ...
Posté par William Steve Applegate (site web personnel) . Évalué à 4.
Les points que j'ai trouvé moins sympas que Debian :
- csup/portinstall/portupgrade, bah c'est moins convi qu'un aptitude (pas d'interface, 'faut modifier divers fichiers de conf', y a pas des fonctions comme l'effacement des dépendances devenues inutiles, etc.)
- 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'...
- 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©.
- Pas de /proc/sys. Oui, on peut rajouter quelques trucs genre /proc/cpuinfo et /proc/meminfo mais ça reste moins complet.
- 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.
- 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).
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.
Envoyé depuis mon PDP 11/70
[^] # Re: A propos ...
Posté par David Carlier . Évalué à 2.
Pour le reste par contre tu n'as pas entièrement tort sauf sur le chapitre des ports, tant qu'à comparer Debian et FreeBSD vaut mieux les comparer avec FreeBSD avec les packages "précompilés". Sinon pas eu de soucis de dépendances, pkgdb gére ça bien.
[^] # Re: A propos ...
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 8.
Oui, mais il parlait des dépendances devenues inutiles ; pour ça sous FreeBSD il faut installer le port pkg_cutleaves, ce n'est pas magique.
[^] # Re: A propos ...
Posté par David Carlier . Évalué à 2.
[^] # Re: A propos ...
Posté par William Steve Applegate (site web personnel) . Évalué à 3.
Envoyé depuis mon PDP 11/70
[^] # Re: A propos ...
Posté par briaeros007 . Évalué à 2.
Parce que par exemple on ne compte plus jamais le réutiliser etc...
Si il "suffit de désactiver", dans ce cas tu installer TOUS les logiciels puis tu désactive juste ceux que tu ne veux pas utiliser. Ce n'est pas comme ça que tu fonctionne ? :P
[^] # Re: A propos ...
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
On ne supprime rien du système de base. On le reconstruit en sans ce que l'on ne veux pas.
WITHOUT_SENDMAIL="YES" dans la make.conf
Puis reconstruire le monde sans sendmail
[^] # Re: A propos ...
Posté par briaeros007 . Évalué à 2.
refaire entièrement le système de base chaque fois qu'on souhaite le modifier, ça reste une philosphie complètement différente de linux.
[^] # Re: A propos ...
Posté par William Steve Applegate (site web personnel) . Évalué à 1.
>
> Puis reconstruire le monde sans sendmail
Bah, j'avais lu (à [http://unix.derkeiler.com/Newsgroups/comp.unix.bsd.freebsd.m(...)]) que ça n'effaçait pas le Sendmail déjà installé. Si ça a changé, c'est cool.
Envoyé depuis mon PDP 11/70
[^] # Re: A propos ...
Posté par Gniarf . Évalué à 4.
compare la taille entre elvis (un clone léger de vi) et un vim complet : ça se comprend.
[^] # Re: A propos ...
Posté par boq . Évalué à 6.
En tout cas http://www.freebsd.org/cgi/man.cgi?query=vi&apropos=0&am(...) me dit que c'est nvi :)
Tiens un petit comparatif pratique des spécificités de elvis, nvi, vim à l'usage des administrateurs systèmes confrontés à des environnements hétérogènes (les trucs que je trouve chiant quand je passe de l'un à l'autre, même si je suis encore un futur administrateur système ^^ ) (à ce propos, pourriez vous jeter un oeil à http://www.iut-fr.net/petitions/?petition=2 ? )
elvis:
http://elvis.the-little-red-haired-girl.org/
- niveau de undo choisi par l'utilisateur (par défaut un seul niveau: u undo, u redo || set ul=100 -> 100 niveau de undo: u undo, Ctrl+r redo )
- coloration syntaxique: assez limitée
- Par défaut dans: slackware (debian? il y a une version minimale de elvis par défaut mais le vrai éditeur par défaut est nano?)
malgré les apparences, elvis a beaucoup de features: support des sessions, support ftp et http, abréviations, fenêtres multiples, calculatrice ...
Il semble que la philosophie générale soit: comportement de merde par défaut mais qui peut facilement être changé si on prend le temps de lire la très abondante doc.
/!\ Attention piège, il y a une latence entre le moment ou on appuie sur la touche ESC, et son effet effectif (pas la peine de bourriner dessus donc -_-' ) Voir http://elvis.the-little-red-haired-girl.org/elvisman/elvisop(...) si vous voulez changer ce comportement.
nvi:
http://www.bostic.com/vi/ (make install marche pas (problème de Makefile je crois))
http://www.kotnet.org/~skimo/nvi/ (un peu plus récent mais le site est down:( )
- undo illimité (u undo, .(point) pour répéter le undo, re u pour changer de sens)
- coloration syntaxique: inexistante
- extensible en perl et tk
- Par défaut dans: les *BSD
nvi est un éditeur (très) simple et rapide. C'est le plus petit des trois. Il édite et c'est tout et il le fait bien et c'est ce qu'on lui demande.
Attention, pas d'utf8.
/!\ Attention piège, si vous commencez à entrer une commande (avec : ) et que vous changez d'avis, n'appuyer PAS sur la touche Echap ou les flèches, ça valide la commande!
Tips: :set verbose showmode pour afficher le mode courant.
vim:
http://www.vim.org/
- undo illimité (u undo, Ctrl+r redo)
- coloration syntaxique: illimité (vous avez ouvert beaucoup de fichiers dans vim qui n'avaient pas la coloration?)
- extensible dans son propre langage, beaucoup d'extension disponibles
- Par défaut dans: redhat/fedora et euh... tout le reste?
Vim quand à lui est vraiment featurefull, c'est aussi le plus gros des trois. Pas de piège particulier, un comportement un peu chelou avec le copier/coller et la souris dans l'interface console. (pas encore réussi à régler ça correctement)
Tips: pour s'initier, je trouve vimtutor très bien fait.
Sur ma distro:
elvis: 432K
nvi: 24K (uh? je viens de recompiler avec --disable-shared et --enable-static, ça fait 300K ??)
vim: 3.7M
Une dernière remarque: Vim est très permissif par rapport au vi originel, ce qui peut troubler quand on revient au fonctionnement plus strict des deux autres. Exemple: sous elvis et nvi, pour joindre deux lignes, pas la peine d'aller au bout de la première et d'essayer Suppr, ça ne marchera pas (C'est Maj+j pour ceux qui se le demandent). Ou encore, pas la peine non plus d'entrer en mode insertion pour effacer des bidules avec Suppr ou Backspace...
elvis et nvi peuvent paraitre relous mais au final, à un moment donné, on devient carrément plus rapide avec eux.
Aussi, pas de ~ de backup pour nvi et elvis.
Voilà, personnellement je joue plus souvent avec des fichiers de conf qu'avec du code source, et vi (toutes version confondues) est la rolls pour ça. Après si votre trip c'est Eclipse ou Visual Studio, bah vous avez sûrement décroché avant :)
Je ne connais pas l'éditeur par défaut de toutes les distros donc si vous trouvez intolérable que votre distro préférée n'aie pas été citée, ajoutez-la ;)
Un dernier lien VRAIMENT sympa: http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial(...)
À imprimer et coller sur votre clavier ^^
PS: pour les emacseux, j'utilise aussi parfois emacs... quand je veux jouer à tetris :)
[^] # Re: A propos ...
Posté par IsNotGood . Évalué à 2.
"Pire", il n'y a pas elvis ou nvi sur Fedora/Red Hat. Il n'y a que vim mais on peut installer la version minimum ou complète. Je crois que c'est la version minimum qui est installée par défaut.
[^] # Re: A propos ...
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
:set paste
:set nopaste
"*p
"+p
Je pense que ces quatre commandes résoudront tes problèmes (après avoir lu l'aide pour savoir ce que ça fait…)
[^] # Re: A propos ...
Posté par IsNotGood . Évalué à 1.
Pas vraiment. Le vim minimum fait moins de 700 ko (sans doc). Le vim complet (doc, coloration, etc) fait 18 Mo (l'exécutable fait 1,8 Mo).
Sachant qu'un vi compatible est indispensable, je trouve crétin de ne pas mettre le meilleur vi à cause de la taille.
Ceci dit, elvis est excellent (même si je ne l'ai plus utilisé depuis longtemps). Mais je trouve très bête de mettre la taille comme un critère important pour une installation par défaut.
[^] # Re: A propos ...
Posté par Psychofox (Mastodon) . Évalué à 2.
Dans le cas d'un système qui peut vouloir être installé dans de l'embarqué sur des cartes flash, chaque économie est
utile.
De plus personne n'empêche ceux qui en ont besoin d'installer vim, c'est l'affaire de 2 minutes.
[^] # Re: A propos ...
Posté par IsNotGood . Évalué à 3.
Et il faut aussi que j'ajoute la taille de la libc et du noyau ?
> Dans le cas d'un système qui peut vouloir être installé dans de l'embarqué sur des cartes flash, chaque économie est utile.
J'ignorais que FreeBSD était principalement utilisé dans systèmes les embarqués...
Rassures moi, il n'y a pas Xorg dans FreeBSD ? J'espère aussi que la documentation n'est pas installée car ça bouffe beaucoup de place. Idem pour les outils de développement.
[^] # Re: A propos ...
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
Et c'est ultra convivial^Wsimple à installer.
Puis bon, vi suffit amplement au départ pour les 2 fichiers de conf que t'auras de toute façon pas besoin de modifier.
De plus, debian et ubuntu ne filent même pas vim-full de base non plus. Quite à avoir un vim incomplet, je préfère un vi complet (et les utilsateurs d'emacs ne se plaignent pas que vim soit là de base)
[^] # Re: A propos ...
Posté par Patrick Lamaizière (site web personnel) . É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 !
[^] # Re: A propos ...
Posté par kowalsky . Évalué à 5.
On n'est pas là pour patcher openssl...Plus serieusement, c'est ce que j'aime avec le monde BSD, si je boss sur Apache ou Bind ou je ne sais quoi, j'en ressort avec des compétences Apache, Bind ou je ne sais quoi, au lieu de connaitre l'Apache Debian, RedHat ou je ne sais quoi...
Les BSD, ça forme les administrateurs !
[^] # Re: FreeBSD, c'est simple !
Posté par Joris Dedieu (site web personnel) . Évalué à 4.
Pour avoir une arbo des sources exactement correspondante au système installé. Et ensuite appliquer au cas par cas les patchs de sécurité qui te semblent pertinent sur cet arbre des sources.
Sur un système en prod c'est une façon de travailler qui évite d'être trop bourrin dans les mise à jour.
# Bonne nouvelle?
Posté par tfeserver tfe (site web personnel) . Évalué à 5.
[^] # Re: Bonne nouvelle?
Posté par David Carlier . Évalué à 8.
# Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Maintenant tu vas pouvoir crâner sur GCU Squad.
Posté par gaston . Évalué à 10.
[^] # Re: Maintenant tu vas pouvoir crâner sur GCU Squad.
Posté par Vincent (site web personnel) . Évalué à 7.
# Troll du Lundi??
Posté par blubliblo . Évalué à -3.
D'ailleurs est-ce que vous avez remarqué que le domaine trollfr.org pointait sur linuxfr.org?
[^] # Re: Troll du Lundi??
Posté par pikapika . Évalué à -1.
[^] # Re: Troll du Lundi??
Posté par IsNotGood . Évalué à 3.
[^] # Re: Troll du Lundi??
Posté par pikapika . Évalué à 0.
je te laisse deviner pour le dimanche
[^] # Re: Troll du Lundi??
Posté par IsNotGood . Évalué à 1.
[^] # Re: Troll du Lundi??
Posté par Calim' Héros (site web personnel) . Évalué à 5.
[^] # Re: Troll du Lundi??
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
http://livre.fnac.com/a1870929/Les-sales-blagues-de-l-Echo-I(...)
2,5 kg de finesse...
[^] # Re: Troll du Lundi??
Posté par tuxsmouf . Évalué à 3.
->[]
# bah le problème principal c'est le support de certains hardware
Posté par RB . Évalué à 6.
Aujourd'hui dans la grande majorité des cas on aura une expérience desktop plus faible sur un BSD avec un portable notamment. Par contre l'expérience sera plus constante également: je n'ai jamais eu autant de régression hardware avec linux que cette année.
Le problème étant aujourd'hui le support du multimédia: le son est un espèce d'OSS (bon c'est peut être pas plus mal :D), qui aura a priori par exemple du mal a supporté les sorties sons "modernes", c'est a dire que la différence entre une entrée et une sortie est gérée de manière software et/ou le fait de brancher des écouteurs qui switch avec la sortie haut-parleurs.
Également un support ACPI encore plus médiocre que dans linux.
Par contre, un gros efforts a toujours été fait (notamment chez OpenBSD) pour de bon drivers réseaux y compris wifi.
Donc a mon gout, je préfére linux en desktop mais j'hésite (et j'ai aussi utilisé avec beaucoup de plaisir FreeBSD et OpenBSD) avec les BSDs pour des serveurs.
[^] # Re: bah le problème principal c'est le support de certains hardware
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Elle me sert à Flash 9, donc c'est pas la mort, mais voilà quoi. Linux. pour moi, c'est avant tout un beau bordel où on casse ce qui marche, on distribue, et ensuite on tente de réparer.
Enfin, c'est mon impression volontairement trollesque des distros modernes.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.