40 Go de sources ? Soit un milliard (environ) de lignes de codes, faisons un petit calcul mental pour vérifier la validité de cette info :
MS, il me semble que c'est 60.000 personnes dans le monde (200 en France), la force de développement (2/3 des effectifs) étant basée en Inde, les autres étant consacrés aux activités commerciales, R&D, activités de traduction, RH et juridique.
Donc on a en gros 40.000 ingénieurs dans l'équipe de développement. Et comme chacun sait sur une équipe de 10, y en a en réalité 4 qui crachent du code pour de vrai, les autres servant à "architecter", à analyser, à spécifier, à organiser ou à contrôler. Donc sur 40.000, on a en réalité 16.000 pondeurs de code.
Après sur ces 16.000 développeurs, tous ne sont pas consacrés au système d'exploitation : certains sont sur la suite bureautique, d'autres sur le Visual Studio, d'autres enfin sur la X-box/MSN/ :o) Sur la partie OS (+IE+servers+...), on a donc qu'entre 1/4 et 1/3 des développeurs. On va dire 5.000 développeurs à la louche.
5.000 développeurs qui auraient pondu 1 milliard de lignes de code, ça fait 200.000 par personne. Le début du dev de NT a commencé vers 93 il me semble, et 2000 est sorti en 99. Chaque développeur aurait eu une production annuelle de plus de 20.000 lignes, soit plus d'une centaine de lignes par jour. Ils sont en forme les ptits gars !!
Si MS n'a jamais jeté son code mort, 40 Go c'est plausible. Ca expliquerait peut-être que mon Win2K me bouffe tant de place. Il faudra peut-être leur conseiller d'investir dans un système genre CVS, ils feraient des économies de place.
Pour revenir au problème de "ce qu'on peut trouver dans le code", ce qui me ferait le plus plaisir ne serait pas qu'il y ait du code GPL pompé allègrement, mais plutôt que l'on trouve des backdoors volontaires avec des commentaires genre "/* Merci de ne pas effacer cette méthode même si elle n'est pas décrite dans les specs -- L'équipe commerciale MS */". Ce serait énorme !!
T'as vérifié si t'avais un uptime correct ? Si en faisant un top y avait pas un process qui bouffait tout le CPU ? Si t'as bien défini une zone de swap :o) ?
Quelques idées pour "benchmarker" son PC :
- hdparm (mais t'as l'air bien en UDMA100)
- glxgears (le laisser tourner en plein écran pour voir les stats)
- la recompilation du noyau (au delà de 5 minutes, c'est que ça va pas)
De toute façon, csound n'a pas le même but que des trackeurs, ça ne sert à rien de les comparer sur le plan du plus simple ou du plus "simpatique", c'est comme comparer KWord et vi si je puis me permettre :o)
csound permet simplement une autre approche de la production de son et en particulier la production musicale, puisqu'il permet de maîtriser réellement la synthèse sonore (autant pour la reproduction de sons existant que pour la création de nouveaux sons).
Le fait que les morceaux prennent moins de 50ko n'est pas le but initial, ce n'est juste qu'une conséquence. Celle-ci se montre toutefois d'un intérêt notable, et la norme Mpeg-7 (si je ne m'abuse) l'intègre ou compte l'intégrer pour décrire l'environnement musical du film ou du reportage encodé.
Enfin, pour les effets offerts par les trackeurs, rien ne t'empèche à partir d'un programme csound d'ajouter un post-traitement avant diffusion de l'oeuvre finale.
Les deux systèmes incluent en effet un séquenceur pour décrire la partition de musique, ce n'est pas là la principale différence.
Là où csound explose les trackeurs, en effet, c'est que les trackeurs se basent sur des échantillons (son échantilloné ou création d'échantillons de manière très basique) alors que dans csound on décrit les sons par leurs propriétés physiques (formes des ondes, synthèses additives, synthèses soustractives).
Par exemple, pour un son de "gong" de 20 secondes, un trackeur aura besoin de 1760 ko pour décrire le son en bonne qualité, alors qu'en csound la description des 5 harmoniques et des enveloppes suffisent (quelques cacahuettes d'octets).
De plus, csound permet une meilleure restitution lors des changements de fréquences (pour changer la note) qu'un trackeur (extrapolations = pertes d'information) puisqu'à chaque "compilation" l'échantillon final est recalculé.
Maintenant, je crois que csound manque de moyens en terme de convivialité, car je ne connais comme interface que vi ou emacs ... si quelqu'un en connait des vrais (en gtk ou qt par exemple), je suis preneur !!
[^] # Re: Le code source de Win NT4 et Win 2000 sur l'Internet
Posté par Olivier Rioland . En réponse à la dépêche Le code source de Win NT4 et Win 2000 sur l'Internet. Évalué à 2.
MS, il me semble que c'est 60.000 personnes dans le monde (200 en France), la force de développement (2/3 des effectifs) étant basée en Inde, les autres étant consacrés aux activités commerciales, R&D, activités de traduction, RH et juridique.
Donc on a en gros 40.000 ingénieurs dans l'équipe de développement. Et comme chacun sait sur une équipe de 10, y en a en réalité 4 qui crachent du code pour de vrai, les autres servant à "architecter", à analyser, à spécifier, à organiser ou à contrôler. Donc sur 40.000, on a en réalité 16.000 pondeurs de code.
Après sur ces 16.000 développeurs, tous ne sont pas consacrés au système d'exploitation : certains sont sur la suite bureautique, d'autres sur le Visual Studio, d'autres enfin sur la X-box/MSN/ :o) Sur la partie OS (+IE+servers+...), on a donc qu'entre 1/4 et 1/3 des développeurs. On va dire 5.000 développeurs à la louche.
5.000 développeurs qui auraient pondu 1 milliard de lignes de code, ça fait 200.000 par personne. Le début du dev de NT a commencé vers 93 il me semble, et 2000 est sorti en 99. Chaque développeur aurait eu une production annuelle de plus de 20.000 lignes, soit plus d'une centaine de lignes par jour. Ils sont en forme les ptits gars !!
Si MS n'a jamais jeté son code mort, 40 Go c'est plausible. Ca expliquerait peut-être que mon Win2K me bouffe tant de place. Il faudra peut-être leur conseiller d'investir dans un système genre CVS, ils feraient des économies de place.
Pour revenir au problème de "ce qu'on peut trouver dans le code", ce qui me ferait le plus plaisir ne serait pas qu'il y ait du code GPL pompé allègrement, mais plutôt que l'on trouve des backdoors volontaires avec des commentaires genre "/* Merci de ne pas effacer cette méthode même si elle n'est pas décrite dans les specs -- L'équipe commerciale MS */". Ce serait énorme !!
[^] # Re: Pour renommer des fichiers avec des chiffres
Posté par Olivier Rioland . En réponse au message [Terminal] Pour renommer des fichiers avec des chiffres. Évalué à 1.
ls -A | awk '{num=printf("%4.4d",NR);system("echo "$1 " " num ".jpg")}'
Ainsi les fichiers s'appelleraient '0001.jpg', '0002.jpg' ...
OK, ça limite à environ 10000 photos, mais c'est juste pour le principe ...
# Re: Optimisation et linux
Posté par Olivier Rioland . En réponse au journal Optimisation et linux. Évalué à 1.
Quelques idées pour "benchmarker" son PC :
- hdparm (mais t'as l'air bien en UDMA100)
- glxgears (le laisser tourner en plein écran pour voir les stats)
- la recompilation du noyau (au delà de 5 minutes, c'est que ça va pas)
Enfin bon, y a surement plein d'autres trucs ...
[^] # Re: Csound désormais en LGPL
Posté par Olivier Rioland . En réponse à la dépêche Csound désormais en LGPL. Évalué à 2.
csound permet simplement une autre approche de la production de son et en particulier la production musicale, puisqu'il permet de maîtriser réellement la synthèse sonore (autant pour la reproduction de sons existant que pour la création de nouveaux sons).
Le fait que les morceaux prennent moins de 50ko n'est pas le but initial, ce n'est juste qu'une conséquence. Celle-ci se montre toutefois d'un intérêt notable, et la norme Mpeg-7 (si je ne m'abuse) l'intègre ou compte l'intégrer pour décrire l'environnement musical du film ou du reportage encodé.
Enfin, pour les effets offerts par les trackeurs, rien ne t'empèche à partir d'un programme csound d'ajouter un post-traitement avant diffusion de l'oeuvre finale.
[^] # Re: Csound désormais en LGPL
Posté par Olivier Rioland . En réponse à la dépêche Csound désormais en LGPL. Évalué à 2.