PLuG a écrit 1016 commentaires

Relis mon mail.
quelques hints:
-je dis bien que ca marche si on ne respecte pas le x2
-je dis bien que le 2.4 swap plus tot que le 2.2 pour garder du mou
-je dis bien que tout ca est reglable dans /proc/sys

bon je veux bien que tu défendes ton OS préféré bec et ongles, MAIS LIS LES MESSAGES AVANT DE REPONDRE.

Et après pour les memes raisons, vous essaierez de faire en sorte que plus personne n'utilise les mots "frigo" et "frigidaire" a la place de réfrigérateur.
non mais c'est vrai, y a d'autres marques qui font du froid quand meme.

le terme est implanté. il est passé dans la langue.
Linux restera "Linux", et on sera obligé de préciser "OS Linux" ou "noyau Linux" pour savoir de quoi on parle.

CQFD

[vous pouvez reprendre une activité normale ...]

le bridge nouveau tout frais s'appelle ebtables, c'est l'equivalent d'iptables mais au niveau ethernet. http://users.pandora.be/bart.de.schuymer/ebtables/(...)

terthereal, c'est un binaire qui a les meme capacitées d'analyse que ethereal mais qui tourne en mode console (donc on peut faire grep / perl / ...).
pas aussi bien que le module libpcap de perl mais tellement plus rapide a mettre en place pour des besoins limités ...

un 2.4 recent parce que les corrections de bug et trou de secu sont quand meme interessants,
c'est la VM d'Andrea, pour laquelle tu es prié de filer au moins 2x la quantite de RAM sinon pas sur qu'il puisse swapper les pages comme il veut, alors qu'avant c'etait pas le cas (kernel 2.2)

que je sache cette particularité n'as pas changée du 2.4.0 au 2.4.20 ...

en pratique, je fais tourner des machines qui ne respectent pas cette loi. Mais elles sont clairement hors spec.
en pratique aussi, en passant d'un 2.2 a un 2.4 on remarque effectivement plus de consommation du swap. Le but est de swapper plus tot pour se premunir d'une carence grave de RAM ... c'est une bonne idée pour un serveur. Pour un portable qui ne lancera plus rien d'autre que mozilla+X11 c'est pas forcement optimal (vaudrait mieux consommer a 100% la RAM et ne pas swapper sur le disque lent).
bon on peut tuner tout ca dans /proc/sys pour essayer de retrouver un comportement plus proche du 2.2 mais c'est pas encore tout a fait ca.

bref je me repete, c'est l'évolution et elle est souhaitable. de toutes facons les P133 ca disparait de la nature, il est devenu facile de récuperer des PII pour faire des firewalls a la maison ... et ce sera de plus en plus comme ca (il fut un temps ou on recuperait des 486DX33 pour faire des routeurs ...).

Effectivement je m'appretais a poster un commentaire du genre.
Les developpeurs du noyau sont concentrés sur les problèmes sexy: faire tourner le noyau dans les moments difficiles.
Mais on se retrouve de plus en plus avec un noyau parametré aux petits oignons pour ces profils de serveurs et de plus en plus loins des petites machines.

Un exemple ?
Le noyau 2.4 consomme plus de swap, ce qui sur une machine avec un disque LENT n'est pas du tout une bonne idée.

le nouveau scheduleur en O(1) qui a défrayé la chronique est peut etre plus lent dans le cas général ? en tout cas il consomme surement des structures de data (hash ...) pour y arriver et donc plus de RAM ... bref c'est clair: ton P133 64Mo RAM gagne surement a tourner sur un bon vieux 2.2.x

Mais d'un autre coté, il faut bien évoluer. Et laisser tous les choix dans le kernel/config n'est pas faisable... et puis je fait tourner pas mal de config serveurs qui en profitent pleinement ...

je vais signaler des trucs a l'auteur.

son bouquin parle d'IP donc devrait couvrir non seulement ethernet mais pourquoi pas giga-ethernet (son mii-tool est limité au 100 full duplex, je crois qu'il existe des versions 1000FX-FD, sinon ethtool supporte le 1000 FX FD) , token-ring ...

les parties décrites pour le moment existent deja dans d'autres doc linux. par contre il n'a pas vraiment prevu de QoS (qui est moins souvent decrite), il ne parle pas des possibilités de bridge (on a depuis peu la possibilité de faire un vrai routeur/FW IP qui bridge et filtre les autres protocoles ...)
il faudrait aussi ajouter les systèmes de redondance de routeurs (vrrp), parler d'ethereal qui analyse les protocoles en plus de tcpdump qui se borne dans la majorité des cas a sniffer (je sais il analyse un peu SMB et d'autres ...) et surtout le meconnu tethereal qui est en mode console donc scriptable (pipé dans perl ...).

bref il risque de ré-écrire toutes les doc reseau linux qui existent avec un tel sommaire ...

Sur M6 ils avaient montré que les ondes de ton clavier ont beaucoup de chances de se propager dans le reseau electrique (a travers l'alim) et ils étaient capable "d'écouter" un de ces claviers de l'autre bout du batiment ...

de toutes façons ton voisin est déjà en train d'espionner ton écran a travers le mur via ses émissions radio-electriques (mais sur l'écran quand tu tappes un mot de passe ca affiche des étoiles *** alors qu'en écoutant le clavier ....).

bon ok, je te rassure j'ai appris tout ca aussi a l'ecole il y a longtemps. mais la question c'etait "pour un newbie". on peut (je l'ai fait :-)) penser qu'un newbie ne va pas se lancer dans une demonstration mathematique pour demontrer qu'un algo est meilleur qu'un autre. c'est bon a l'ecole/la fac/l'inria. dans la vie professionnelle, on te (me) demande de savoir "a peut près" vers quoi on se dirige, de reflechir si c'est normal (ton cas des matrices) et d'ameliorer si c'est pas suffisant. Le calcul, la demonstration mathematique, personne ne veut plus la lire :-( . par contre des mesures concretes sur des vraies données, ca oui ca interesse les gens .. bref j'ai voulu me mettre a la portée de ceusse qui posent la question (a priori si ils la pose c'est qu'il ne l'ont meme pas abordée en cours ...). Je me rends compte en lisant plus bas que vous etes partis direct vers les definitions précises ... comme ca y aura de tout :-)

bof dans la plupart des cas il suffit de reflechir en lisant l'algo. O(1) : facile l'algo ne depend pas du nombre de donnees en entree. c'est rare :-) O(n) : en general l'algo a besoin de parcourir (lire) les donnees en entree au moins une fois. O(n^2) : mauvais. en general l'algo possede deux boucles imbriquées qui dependent du nombre de donnees en entree. En general aussi, on s'arrete la et on note direct O(e^n) pour dire exponentiel (mauvais). en log(n), ton algo ne lit jamais toutes les données, il utilise une astuce (elles sont triées avant d'entrer par exemple, ou dans un hash de mauvaise qualité ...). bon c'est pas academique, mais le feeling ca le fait bien ;-)

Le problème, c'est que ce scheduleur doit essayer d'éviter les deadlocks entre les threads heuuu, pas vraiment non. Les dead lock entre threads c'est au programmeur de les prevoir (c'est d'ailleur le principal probleme de la programmation multi-thread et l'apparition des lock, semaphores, ...). le scheduleur a une tache simple :-) , decider qui tourne sur quel processeur. Quand un thread a besoin d'une ressource non disponible, il n'est plus elligible et n'aura donc pas le cpu. quand tu utilises "top", seuls les process/threads marqué d'un "R" sont "runnable". Seul ceux-ci font l'objet d'un arbitrage ...

oui mais alors des glissières "motard friendly" hein, pas des glissières comme sur la plupart des routes actuelles. Ce sont des vraies guillotines pour les motards ...
D'ailleur il y a des travaux prevus pour doubler les glissières (en mettre au ras de la route pour arreter gentiment les motards qui glissent) mais ca avance doucement ....

n'importe quoi, en sortie du reseau le TTL est celui par defaut de la machine (255,128 ou 64 selon l'OS utilisé). Pas de detection possible de la part de l'ISP.

J'ai commande une phatbox pour ma caisse (http://www.phatnoise.com(...) mais je ne l'ai pas encore recue).

Sur le forum, les dev expliquent qu'ils ont bientot une release alpha du firmware supportant ogg vorbis :
http://www.phatnoise.com/forum/showthread.php?s=&threadid=293(...)

cool :-))

Le probleme c'est que manager un service c'est loin de la technique. Et les bons techos en general ne veulent pas forcement gerer les conges/absences/notation/recrutement/rapports avec les autres branches (rh, compta ...)/budget/planning. Tout ca bouffe du temp que le techos aurai mieux utilisé a faire de la veille, voir a relire le code de son equipe.

Le top AMHA, c'est d'avoir un gestionnaire [un vrai] et un architecte [un vrai aussi] a la tete du service. Les 2 devant travailler de concert et se faisant mutuellement confiance pour leur partie respective du boulot.
En pratique, c'est souvent le gestionnaire qui passe le mieux au près de la direction et qui fini par tirer la couverture a lui :-(

statistiquement, combiens de managers lisent dlfp ?
tu es l'exception qui confirme la règle, le "décideur pressé" du futur, pour qui Linux ne représente pas une prise de risque inconsidérée ...

grace a toi, Linux progresse dans les Entreprises, et grace a toi l'immage meme du décideur pressé changera dans la communeauté Linux.
[cf mon poste plus haut sur le theme: les managers changent ...]

Oui mais cela va changer.

La première génération pionnière sous linux (des vieux donc) vont commencer a acceder a des postes de dirigeants. Ceux la seront beaucoup plus attentifs aux evolutions de Linux et aux suggestions de leurs equipes.

Ma vie: J'ai 30 ans, ai commencé Linux en ecole d'ingenieur [avant il n'existait pas] et me souviens des déboires du début. Je n'ai cesser de pousser Linux de partout ou je suis passé, avec plus ou moins de succès. Il faut dire que dans les premières années j'étais jeune donc moins crédible et moins expérimenté et Linux lui même était jeune.
Aujourd'hui je sais présenter le discours qui va bien a un DI pour faire avancer linux, je sais monter une maquette et mesurer les perfs pour montrer ce que le manchot a dans les pattes, et comme je suis vieux :-( je suis credible :-) ... et Linux passe a la TV ce qui ne gache rien.
Resultat: Je ne prends que les contrats qui débouchent sur du LL et je le vis bien :-)))

Bref, plus on avance, plus les mecs comme moi seront decideurs pressés et les choses seront BIEN différentes.

Sans oublier que quand "l'ignare" choisit linux, personne ne paye de voyage aux US a l'equipe dirigeante ... pas d'hotel, de golf, ni de visite de richmond ... Pas de cirage de pompes genre "Vous etes un des plus gros clients ..."

Bien sur "l'ignare" a une conscience professionnelle et ce petit bonus ne sera pas pris en compte lors des decisions :-)

la couche réseau de Linux est trop buggué pour des mesures fiables

C'est un appel au troll ca.
Tu aurais pu dire que la couche reseau BSD fait reference depuis des decennies, ca aurait ete plus fair-play et moins polemique.

D'un autre cote, maintenant que tu as trouvé des bugs, je suis sur que tu as envoyé les bugs report qui vont bien a la liste kernel , hein ?

La couche reseau de linux etait tres en retard il y a ... 2 ou 3 ans... et encore, on ne pouvait pas vraiment parler de "bugs" mais de problemes de perfs. Peux tu nous éclairer quand aux bugs detectés ??

j'insistais sur la taille car j'ai beaucoup lu que le .ogg donnait des fichiers plus petits, ce qui me semble faut. quand tu utilise "--abr 160" ou "-b 160", tu demandes au codeur de respecter un bitrate (moyen ou fixe, ou ce que tu veux) de 160kbps. 160kps ca signifie 160 kilo bits par seconde. donc pour un morceau de 10 secondes avec lame on va avoir: 160000 bits * 10 secondes == 1 600 000 bits et pour oggenc alors me dira tu ? 160000 bits * 10 secondes === pareil on a donc toutes les chances d'avoir des fichiers de la meme taille, INCROYABLE NON ! quand aux conclusions que tu tire de ton test, disons qu'avec de telles incomprehensions de ta part je ne leur accorde que peut de crédit.

sur mes serveurs redhat tu n'as pas
-webfetch [n'existe pas sur redhat]
-perl-DateManip [existe quand meme sur redhat]
-rpmtools [n'existe pas sur redhat]


De plus, mandrake a fait evoluer l'outil RPM avec des tags speciaux [non disponibles avec RPM sous redhat] dans les fichiers .spec, ce qui ne facilite pas le portage [sans le rendre tres complique non plus, c'est du detail mais disons qu'un simple rpm -bb xxx.spec ne suffit pas en general]

alors que apt4rpm s'installe sans rien ajouter ...

Tout a fait.

D'ailleur je suis surpris de lire tout cela (au dessus). On parle de serveurs qui n'ont pas de clavier ni d'ecran et seulement un port console.

Sur de tels serveurs aucun interet d'installer la couche graphique (serveur X11). Du coup aucun interet d'utiliser VNC non plus, un simple ssh suffit a traiter le probleme

Avantages:
- moins de boulot pour le cpu/la ram [pas de serveur X, pas de fontes, pas de ...]
- plus securisé que VNC
- moins d'espace disque gaspillé
...

Et ca c'est pas possible sous windows, les serveurs rackables sans clavier/ecran font tourner la gui pour rien ...

en fait plus haut j'ai parlé d'utiliser urpmi sur une redhat. C'est le nouveauté que je suis en train de mettre en place dans les procedures d'admin des machines chez mon client pour simplifier la gestion des RPM et l'installation des serveurs.

Sauf qu'il s'est avéré que urpmi est plein de dépendances propres a mandrake et que apt4rpm est plus simple a recompiler sur un systeme (pas de dependances farfelues). Donc pour les memes avantages je suis en train de tester apt4rpm

Je finis les tests demain, si vous etes encore la et que cela vous interesse je pourrai poster mes conclusions :-)

oui faut reprendre les bonnes idées ...

u alors par des déploiements de paquetages à distance - ça marche bien sous Windows

C'est marrant ce que tu racontes la, parceque normalement c'est le point fort des unix et de linux en particulier.

Franchement, je colle du linux le plus possible JUSTEMENT parce que je n'ai pas a lever mon cul de ma chaise pour les administrer :-)

en les reliant entre eux par le port serie, tu as meme accès a grub pour choisir le noyau a booter ou booter en mode single a distance [ssh sur un serveur en bonne marche et minicom pour acceder en console serie sur son voisin].
Je pense que tu ne te donnes pas les moyen de gerer correctement tes machines, et effectivement si on part mal cela finit par etre difficile.

La preuve ?
Dans ton post il semble que tu installe GCC sur un serveur pour upgrader SSL ...

Quand tu as plusieurs linux a gerer sur un site, d'abord il te faut des outils:
-si possible la meme distribution de partout
-une machine avec pas mal de disque, sous linux, pour TOI.
-Cette machine va downloader les mises a jour sur le net tous les soirs et comparer els nouveautées avec les packages installés sur tes serveurs. Au matin tu as la liste des choses a upgrader sur chaque machine qui t'attends, les packages sont sur ton serveur donc hyper rapide a propager sur les machines a upgrader ...
-Cette machine va te permettre aussi de re-compiler des produits a installer sur le reste du parc. Ces produits seront mis en RPM/DEB par toi afin d'etre pris en compte par la moulinette citée ci-dessus ...
-de plus depuis cette machine tu aura les medias A JOUR pour installer de nouveaux serveurs en reseau.
-ton compte sur cette machine aura des clefs ssh te permettant de gerer tout le parc sans passer ton temps a saisir des mots de passe ...

j'arretes la, mais il y a plein d'idées de ce genre a mettre en place avant de gerer un parc conséquent. Serieusement, si tu ne te lance pas au pif [genre tiens, un nouveau serveur, je vais y coller les cd de redhat dedans et hop ...], l'administration des serveurs linux demande trè peu de temps pour un résultat meilleur que sous windows AMHA.

exemple: la semaine dernière on a recu 8 nouveaux serveurs, le setup complet avec la mise en reseau n'a duré qu'une journée a deux personnes. Ok les services/applis etaient archi simples, mais dans la journée ca commence par je deballe les cartons, je rajoute les cartes raid et gigabit ...
l'installe d'un redhat selon moi:
-boot sur une disquette trafiquée avec un kickstart qui crée les filesystemes et installe le minimum + bonnes adresses IP et noms (5min pour adapter la disquette + 5 minutes maxi pour l'installation cd ou reseau).
-au reboot la machine est en reseau et administrable depuis ma "machine d'admin".
-un script me permet de paufiner la config (/etc/hosts, clefs ssh ....)
-installe des softs (urpmi ...) et première sauvegarde ...

Bon ok, mais faut arreter de faire le boulet aussi.

tu veux upgrader mysql, soit
1 - tu prends le RPM source de l'actuel, tu met le nouveau tar.gz des sources dedans et tu fabrique un RPM binaire qui va upgrader gentiment mysql [comme l'aurait fait redhat]
2 - tu supprime l'ancien et tu installe a partir des sources avec ./configure --prefix=/usr/local comme ca tu es sur de ne pas le melanger avec les morceaux de ta distrib.

honnetement, je ne comprends pas tout ces problemes. AMHA, le gros probleme c'est qu'il faut REFLECHIR avant d'upgrader n'importe comment ...