nullisimo a écrit 173 commentaires

> Non, mais nouveau dans BSD :-)
Si tu commences comme ca, on va pas trop t'aimer ;-)

Sinon, fouiller dans les archives, peut-être que quelqu'un a déjà posé la question de savoir si c'était bien de développer linux sous bitkeeper...
Dans la famille, je reponds un truc qui n'a rien a voir, je file ce lien:
http://lists.freebsd.org/pipermail/freebsd-current/2004-August/0342(...)
Dans ce thread, il est question de l'utilisation "en interne" de perforce par FreeBSD. Les reponses de Robert Watson sont tres interressantes et on peut y voir un joli troll de la part de David Rhodus (transfuge de FreeBSD vers DragonflyBSD [1]).
Grosso modo, perforce ou bitkeeper offrent des possibilites (comme la duplication des portions de repository a moindre couts (en ressources)) que CVS ou subversion ne possedent pas forcement.

[1] http://gobsd.com/journal/3(...)

L'avantage n'est pas forcement a court terme. En effet, comme un application est de toute facon linke avec libregistry, ca faciliterait enormement la gestion de parc. Un mix de rendez et registry avec un backend LDAP/SQL/XML-RPC (non je deconne :p), offrirait une reelle alternative a windows dans la gestion de parc de workstations.

Beaucoup de soft libres ont une version payante sous windows. Ce n'est pas a mon avis un probleme, mais je pense que cela souleve un autre probleme : celui du rapport communaute/ego.
La plupart des personnes qui s'implique dans le libre le font aussi par quete de reconnaissance. Il est de plus en plus dur de se faire une place dans le monde du libre et souvent la recompense est plutot... ingrate :-) La compensation financiere est peut etre une solution a ce pb pour certaines personnes.
Enfin ce n'est qu'une hypothese...

http://uptime.netcraft.com/up/graph?site=www.ldlc.fr(...)

Pour limiter le nombre de commentaires, on impose aux trolleurs les plus actifs (les + "inutile-ises") d'offrir un livre o'reilly aux gagnants du mois ;-)

Purée !!
C'est impressionant les mecs !
Vous vous êtes engeulé comme ça toute la nuit !!!
Ca, c'est un troll qui devrait rester dans les mémoires de Linuxfr.
Et tout ca juste pour une histoire de compatibilite d'ABI ;-)
Windows conserve, au moins par major version une ABI compatible, mais pas forcement linux.
En effet, joli dialogue de sourds...

En fait le probleme doit se poser autrement.
Quand est-ce qu'un hebergeur proposera php4 + php5 en meme temps?
Il serait suicidaire de faire que du php5 ;-).
Pour le moment rares sont les hebergeurs qui proposent les deux. A ma connaissance, les modifs ont deja ete faites par un hebergur windows + PHP, mais pas encore sous "unix". Le jour ou une methode viable apparaitra, ca se rependra comme une trainee de poudre. Mais pour le moment, c'est une trop forte valeur ajoutee pour que ca traine sur les newsgroups ;-) (ca viendra vite)
En ce qui concerne la date, tu auras des offres rapidement chez les hosters a reputation "cutting edge", sinon, il faudra surement attendre qq mois.

Je les ai testees moi-meme. J'ai fait toute une serie de benchmarks sur le port d'apache2.
Tu as entre 40% et 65% de "boost" en plus, entre le apache2 "out-of-the-box" avec un kernel GENERIC, et ces 3 optimisations "simple".
Sur un athlon XP 2000, 512Mo SDRAM, sur une carte mere Elite avec la carte reseau integre (sis), apache 2 avec MPM=worker.
Avec httperf tu as:
Out-of-the-box: 570 req/s
Avec les points 1 et 2: 810 req/s
avec le scheduler ULE, tu perds 5% compare au scheduler 4BSD. je n'ai pas teste avec les dernieres modifs de jeff roberson, mais ULE devrait au moins egaler 4BSD maintenant.
Tu peux gagner 5-10 % avec posixsem (sous tres haute charge) et en modifiant le nb de threads max.
Pour info ces tests ont ete realise avec le patch originel de Paul Querna, avant le cleanup explicite (a jour dans le patch), ce qui devrait eviter qq memory leaks et eviter au process "root" de nettoyer (tu peux donc esperer un gain significatif).
Entre temps, la pile IP a ete nettoye (fine grained locking) donc apache devrait etre un peu plus reactif (niveau reseau).

References:
man accf_http
man kqueue
man polling
http://httpd.apache.org/docs-2.0/misc/perf-tuning.html(...) (*)
http://marc.theaimsgroup.com/?t=108650227500001&r=1&w=2(...)
code source d'apache 2 ;-)

(*): pour info "AcceptMutex pthread" sera supporte dans FreeBSD 6.x uniquement, car l'ajout pthread_mutexattr_setpshared() necessite un bump de la libc qui n'est plus possible depuis le code freeze de FreeBSD 5.0

portupgrade ;-)
# cd /usr/ports/sysutils/portupgrade
# make install clean

pour bien debuter :
http://www.onlamp.com/pub/a/bsd/2003/08/28/FreeBSD_Basics.html(...)

"How to play with apache2 port" ;-)

Le port d'apache2 est principalement oriente 5-CURRENT, car depuis fevrier (post 5.2.1), il y a eu pas mal d'amelioration (kse par defaut, fine grained locking, etc...)
Pour les FreeBSD < 5.3, avoir un MPM threade est inutile (en fait si ca fonctionne c'est grace a un gros hack ;-)).
Chercher dans "FreeBSD" dans:
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/STATUS(...)
Sous FreeBSD 5.2.1 tu peux toujours tester KSE et thr avec apache en definissant WITH_PTHREAD_LIBS={thr;kse} + WITH_MPM=worker (WITH_THREADS ajoute uniquement le support du threading dans apr).

Pour ceux qui veulent "accelerer" leur apache2 (sous FreeBSD):
1. Si la carte reseaux le supporte, ajouter "options DEVICE_POLLING" au kernel (man polling pour voir les cartes supportees)
2. ajouter comme knob lors du make WITH_EXPERIMENTAL_PATCHES. Ca rajoute le support pour kqueue + accf_http (*).
3. pour les + courageux ;) kldload sem (ou "options P1003_1B_SEMAPHORES") pour profiter de "posixsem" comme AcceptMutex (ca peut etre risque)
Rien qu'avec ca, sous haute charge, on peut esperer 40% de "perf" en plus ;-). (en fait ca reduit considerablement, les echanges userspace/kernelspace).

Une astuce (meme si ce n'est pas une solution) pour profiter d'un apache2 threade et de compiler php avec le support Fast_CGI (WITH_FASTCGI lors de la compil de php).

Un petit coup de coeur pour en finir avec apache ;-)
Pour ceux qui regrettent de ne pas avoir mod_accounting sous apache2, www/mod_log_config-st + www/mod_log_mysql peut le remplacer (en mieux meme ;-)

En ce qui concerne les demons FTP, il ya moftpd qui est pas trop mal.

(*) il existe l'equivalent sous linux (epoll), vous pouvez toujours recup les backport des patches (exp-apr-kqueue.patch) du ports pour test sous linux ;-)

Exactement.... au detail pres que les multiples failles dans SSH sont sorties dans la foulee, et donc c'est passe pour une seule et unique faille.
De plus, maintenant c'est "Only one remote hole in the default install, in more than 8 years!". Car les failles locales il y en a eu qq unes ;-)
(et je ne parlerai pas des autres comme celle d'apache...)

Tu utilises quelle version ?
(pour la suite je considere que tu utilises une 5.x)
Di tu as crees tes slices, c'est rape pour la suite ;-) Les partitions par defaut ne sont pas forcement correctement proportionnees, hihihi.
Tu doit etre face au principal probleme de sysinstall: ne pas pouvoir
creer un slice et les partoches en 1 seule fois ;-) Comme je n'ai jamais jouer avec depenguinator, ca va etre coton ;-) A premiere vue, tu arrives sur un shell, ca nous sauve la vie 2mn.
Quitte sysinstall, verifie que tout est demonte.

maintenant c'est parti ;-)
tu as /dev/ads0a et /dev/ads0e, nornmallement, tu devrais avoir /dev/ads0s1*.
mais bon, on va faire avec.
On commence avec une options de gros cochon ;-)
sysctl kern.geom.debugflags=16
En gros, ca te permet d'outrepasser les checks de manipulation des disques.
2. re-lance sysintall, selection Configure -> fdisk ; "a" pour use entire disk (si c'est ce que tu veux) ; "w" write -> Choix du bootloader ; "q" pour quit
Requitte sysintall (c'est un bug).

Install -> Custom -> Label.
Grosso modo met ces valeurs:
/ -> 1Go
/usr -> 10Go (pour jouer avec les ports)
/var 1Go
swap 1Go
le reste pour /home ;-)
"w" pour ecrire -> "q" pour quitter
Choisir "distribution" -> comme tu veux.
Media FTP et ce qu'il en suit....
Commit
et va boire un cafe ;-)
configuration finale (n'oublie pas de configurer un user sinon pas de ssh possible. car l'acces root est disabled by default !)
et on quitte sysintall tu mountes / sur /mnt et tu cree boot.config avec uniquement "-Dh" ca te permets d'avoir la console sur le port serie.

Sinon il existe une solution sans sysintall ou au pire je peux te faire un CD-bootable avec support serie ;-)

PS: si tu desires un port de brltty, on pourra s'arranger ;-)

En gros, c'est un chroot en mieux pour constuire les ports (tu peux aussi faire un simple chroot si tu veux).
cd /usr/src
make buildworld && make installworld DESTDIR=/mnt/monjail/
chroot /mnt/monjail/ /bin/csh
ca peut le faire aussi, mais ca risque de planter certains builds pour cause de non-devfs.
Pour en revenir aux jails, man 8 jail pour + de details + man rc.conf (/jail - pour trouver les bonnes options)
Tip: pas la peine de foutre un sshd dans le jail, un simple jexec <jail ID> /bin/csh te fera rentrer dans le jail ;-)

voila

mais apparemment il faut un fichier INDEX
pas forcement.
pour le creer (c'est long)
cd /usr/ports/ && make index
pour un build incremental (c'est + rapide), utilise sysutils/portindex.
C'est pas complique ;-)

Je crois que l'essentiel à été dit.
Il manque "BSD is dying" (et en gras s'il vous plait ;)

Quand j'emploi le terme de "make world" c'est une expression qui definie la procedure en entier ;-)

Sinon j'y ai pense, on peut toujours utiliser FreeBSD update de Colin Percival, pour faire des mises a jour binaires pour le base system. J'ai jamais teste, un jour peut etre...

Version courte et simple ;-)
- tu exportes /usr/ports/ via NFS
- Tu crees un jail (si tu es sous 5.x tu as un startup script)
- tu mount /usr/ports pour le jail
- cat /etc/make.conf <<EOF
DEPENDS_TARGET=package
USE_PACKAGE_DEPENDS=yes
FORCE_PACKAGE=YES
EOF
- mkdir /usr/ports/packages
- cd /usr/ports/www/apache2
- make package
et ca te crees le package et ceux de ses dependances, le tout dans /usr/ports/packages (avec la meme structure que les mirrors.)

Apres, tu peux faire un exports NFS ou un serveur FTP ;-)

voila
Accessoirement, tu peux config pkgtools.conf et lancer:
* portinstall/portupgrade -p
pour mettre a jour en compilant et en creant les packages

et sur la machine client, soit via NFS ou FTP.
portupgrade -aPP

et voila ;-)

Gros avantages, tu as tes packages, avec tes options a toi ;-)

Tu peux toujours construire les packages sur ta machine "puissante" (dans un jail par ex) et faire une upgrade via packages, via portupgrade sur la machine "lente". Ca marche tres bien ici (et meme ailleurs ;))

5-CURRENT (pas 5.2.1) + apache2 worker + patch kqueue :-)
A condition bien sur de bien vouloir tester tout ca et faire un joli rapport au maintainer d'apache2 qui n'attend que ca.[/contribute]

Les ports sont generalement rapidement mis a jour en cas de failles (les maintainers php, apache sont particulierement reactifs). Pour le systeme -> make world, qui prend du temps. En cas de failles de secu, la EOL des releases est de 1 ou 2 ans... voila :-)

dans 95% des cas le backport est simple... sauf si le code a change. Les distribs fixent genarelement leur kernel au lieu d'upgrade, mais je ne pense que ca soit forcement leur boulot.

Je vais faire part de mon experience personnelle :-)
Je pense que le probleme ne vient des failles ou des distributions, mais principalement du modus operandi des projets.
Actuellement, la mode est a la technique de "il y une faille de securite, je sors une nouvelle release plus tot que prevu". En tant que packager, il m'est souvent arrive d'avoir a upgrader en urgence un package, sous pretexte que la version precedente contenait une faille de secu, et parfois avec des resultats bizarre a l'arrivee.
De moins en moins de projet proposent des versions intermediaires ou des backports de patches pour les releases _stables_.
Les interdependances sont devenus nombreuses et/ou certains utilisateurs (admins dans mon cas) attendent une statibilite dans les packages.
J'ai 2 choix:
- backporter le fix
- mettre a jour la release
Dans la plupart des cas, faire un backport n'implique pas de changements massif, mais il m'est arrive de passer du temps a backport un patch car toutes les fonctions avaient change.
Plus je passe de temps dessus, plus la faille est exploitable.
En gros, il faut 12h pour que le fix soit commit (parfois c'est fait 1h apres, parfois le lendemain matin ;)). Ca laisse une fenetre exploitable.
Ce que j'essaye de faire le plus souvent est de backport le patch, faire un bump de la version, et mettre a jour, histoire de contenter les plus frileux.

My 2 cents.

FreeBSD 5.3 devrait intégrer GCC 3.4.2 (GCC 3.3 est utilisé actuellement)

gcc 3.4.2 vient d'etre integre:
gcc version 3.4.2 [FreeBSD] 20040728
il en resulte de forte pertubation dans le ports tree ;-)

A terme, IPFilter devrait être abandonné au profit du Packet Filter d'OpenBSD.
Pas forcement. Tout dependra de ce que veut fare Darren Reed a ce propos. Ce qui est (presque) sur, c'est que ipf 4.x sera present dans la 6-CURRENT et sera backporte dans la 5-STABLE.

les rumeurs disent que cette branche 5 devrait devenir la nouvelle -stable
C'est sur meme ;-)

Est-ce qu'il restera libre quand on y intégrera des drivers windows pour les cartes réseau !?
Libre a toi de "corrompre ton systeme" ou pas.
Et comment peut-on gagner 30% de performances d'un côté, et faire de l'émulation pour accéder au réseau derrière !?
Les 30% des gains sont du au fine-grain locking de la pile reseau.
Et FreeBSD n'a pas decide d'utiliser que des drivers windows ;-)
Quelles sont les cartes réseau qui ne sont pas supportées à l'heure actuelle ?
man est ton ami ;-)
Est-ce que ce projet s'inspire du projet ndiswrapper qu'on a vu apparître sous linux pour les cartes WIFI ?
C'est le meme principe, mais wpaul a commence a le coder en meme temps.

Sans rire, c'est une éxagération j'espére?
non, je modere meme ;-)
Y'a meme de mes relations qui ne me contactent pas quand y'a un job dans leur boite/departement, mais ils le font quand c'est pour chez le voisin... (et ils te font culpabiliser d'etre "chomeur" !)
En plus du cynisme de certaines boites, il faut jouer avec les ambitions/craintes de chacun...
Comme c'est beau la vie :-)