bubar🦥 a écrit 6967 commentaires

petit récitificatif : exemple à la fin pas bon :
Amarok sur Xine attaque alsa direct (ou Dmix...) et non pas arts/esd/phonon/pulseaudio
désolé

Xrun : système interne de retours de statistiques de surcharge Alsa. Grosso modo, un Xrun c' est ce qui survient quant la charge sur le serveur de son est trop importante.

Cela peut avoir plusieurs raisons, la plus courante est une mauvaise adéquation entre les capacités de la machine (puissance procésseur) et le travail demandé au serveur de son.
Soit un évènement dépasse le "cahier des charge" du temps réel (par exemple ici 42 millisecondes tolérées pour mon duron 900)
Soit encore une mauvaise configuration de jack (ou d' une application tierce, au hasard...ktts. Ou d' un autre serveur, au hasard...esd)
Soit enfin d' une mauvaise configuration de la priorité et de la mémoire dédié pour l' audio.

Le résultât est que Jack râle (c' est le moins que l' on puisse dire) et que soit une latence est crée soit un évènement est "jetter dehors".
Ce n' est pas très grave lors d' une utilisation de bureau, mais cela devient très génant en utilisation studio : si un évènement sonore de kde pête un Xrun lorsque le guitariste enregistre sa balade dans Ardour...

C' est pourquoi la plupart des gens "squizzent" tout ce qui est arts/esd/phonon/pulseaudio, pour assurer Jack (mais se privant de quelques goodies ma foi fort agréables, au hasard... Amarok sur xine). Ces privations ne sont plus nécessaires sur 2007 (le seul Xrun est le démarrage de arts... basta... même sur mon pauv' duron 900)

Vi tout à fait, c' était peut-être mal formulé ?
Dmix est intégré à Alsa offcourse (au passage freebob -carte son firewire- devrait suivre le même chemin et être prochainement intégré au projet alsa)
Ce qui est différent, c' est sa pré-configuration.
je n' ai rien eu besoin de faire pour que tout soit vraiment mixé (hors sur toutes les distributions que je connaisse, mdv y compris, il fallait souvent ajuster asoundrc à la main, la version de alsa / du kernel n' y changeait rien. Même sur les distributions type ccrma ou apodio) Je ne suis pas sûr mais cela doit être dû à un effort d' auto-configuration précis...

gnii ?
les Xruns sont surtout importants (ch****) quant on utilise Jack et le temps-réel. Si tu es en configuration ""de base"" d' un bureau multimédia, encore heureux que tu n' ai pas de Xrun !
Au vu de ta configuration, tu serais plus concerné par les intégrations, type Dmix out-of-the-box, plugin flash routé out-of-the-box, etc etc (désolé, merci de m' excuser si j ai un peu insisté sur les Xruns, c' est vrai que cela ne concerne que peu de personnes, peu de configs)

j ai omis ceci : vu que Dmix est complètement intégré, une retombée est que Amarok en utilisant Xine est mixé en même temps que Jack... et en même temps que tout le reste...
du coup, sur 2007 je peux de nouveau utiliser amarok sans arrêter Jack !!
bref j avoue de pas encore être remis de cette intégration globale des diverses solutions, ensemble, pour le son, c' est vraiment le Big panard :D

Pareil.
pc-impact est très fréquenté, donc très fréquenté aussi par des "boulets" ...
mais ce sont des forums ma foi sympathiques, avec quelques personnes très intéressantes, un site assez complet.
j' aimerai pas être administrateur et/ou modérateur des forums pci : faut un bonne dose de courage et de patience. Et hop des fleurs à ceux et celles qui le sont ;)

info pour les fanas de musiques et de son :
le kernel multimédia, avec le tempsréel en module, est toujours disponible. (PAM est fournis dans sa dernière version et pré-configuré de base pour le group audio...)
et un kernel RT preemption on acid (vanilla 2.6.18 + patch Ingo Molnar rt3) est disponible désormais dans la bonne crémerie..

-> un coup de urpmi suffit ;)

Une nouveauté du genre "sous le capot" est l' intégration du son dans la 2007 :

J' utilise habituellement Jack comme serveur de son. Et je compile toujours un kernel vanilla avec le patch realtime de Sir Molnar.
J' utilise Kde comme bureau.
Je n' ai donc pas une configuration optimale pour le "son" classique d' un bureau mulimédia courant (mais pour des besoins particuliers). Par exemple Arts est routé vers Jack, pour des raisons de conforts lors d' usages courants. Un son ou une voix d' avertissement lié au client irc de kde par exemple, sera la source de nombreux Xrun alsa... Et c' est ainsi pour toutes applications utilisant arts, celui ci étant routé vers jack, même avec une configuration au mieux de arts, celui ci causera des Xrun à alsa..
c' est pas vraiment confortable

Je dois donc arrêter arts lorsque j utilise Ardour, Lmms ou RoseGarden. (dommage je perds la voix qui me prévient "someone ask you in the channel")

Pour une animation flash dans une page web, anim qui sort du son, c' est encore pire. Le lecteur Flash, proprio, cherche toujours à attaquer Oss... alsa propose aoss, couche de compatibilité, ouf... Mais ce lecteur flash demande quant même un accès exclusif (la carte son courante ne possédant pas de mixer hardware).. Ce qui fait que je dois choisir : arrêter le serveur Jack pour écouter quelque chose dans une anim flash.
Pas vraiment confortable non plus.

Pour cette carte son dépourvue de vrai mixer hardware, le projet Alsa propose Dmix, qui permet de bénéficier d' un mixeur logiciel de bas niveau. Mais il faut bien avouer que sa configuration avec le(s) fichiers(s) asoundrc n' est pas des plus agréable pour l' utilisateur...
pas confortable, encore une fois...

Donc j' ai besoin de jongler entre la marche/arrêt de Jack, la configuration de Dmix, et cette saleté de lecteur flash qui veut oss/aoss...
tout ceci fonctionne mais ce n' est pas très "user-friendly"...
et pour du "son du vrai" je coupe tout sauf Jack...

Quoi de neuf sur la 2007 alors ?

je configure arts pour router vers jack
je configure mplayer (et donc son plugin web) pour router vers jack
xmms / audacity : pareil, vers jack.
Et rien de plus...

Et là : surprise !!!

1. Aucun Xrun alsa quant arts route vers jack !!
2. Dmix est complétement intégré et configurer comme jamais. pas besoin de se soucier de asoundrc
3. La musique venu d une anim flash est illico mixée (quelle route !! flash soundwrapper (rerouter) vers arts lui même routé vers jack ... et aucun Xrun !)
4. Passer du bureau graphique vers une tty(x) n' est plus source de Xrun ! on jongle comme on veut entre tty sans xrun!
5. le plugin mplayer dans konqueror/epiphany/ff roxe sévère ; aucun temps d' attente, le son est routé nickel vers jack.

Bref, je n' ai jamais vu une telle intégration sonore fonctionner aussi bien out-of-the-box !! et même dans le cas d' utilisation de Jack en serveur principal !! c 'est Royal ! (pourtant j en connais des distros... et même les spécialisées "son")

Pour la toute première fois je n' ai pas à faire de sacrifice sur telle appli ou de choix entre telle et telle solution : tout est mixé illico et roxe !
je peux enfin bosser avec Ardour et lmms sans soucis, tout en ayant le plaisir d' entendre les voix d' avertissement kde "new messages are incoming" "someone ask you..", et avec en plus une anim flash qui me sort du son... Tout ça en même temps, sans Xrun et out-of-the-box !

merci aux GNUs & LAUD pour ces solutions
merci à Mandriva pour cette magnifique intégration (et aux drakxtools qui me simplifient la vie !)

clapclapclap !!!

+10 d un coup on peut pas ?

pour le "notificateur de mises à jour" d' abord merci de faire la distinction, c' est si courant que les gens confondent "mises à jour" et "notifications de bureaux pour la disponibilité de mises à jour". Ces notifications nécessitent un serveur spécial qui est beaucoup sollicité... donc un coup. voilà, cqfd, c est tout. Un flux rss "security team" est disponible et les mises à jour sont toujours accessibles à tous.

Concernant les offres Club,
n' hésites pas à demander directement que le forum""club"" qui est ouvert à tous. (suffit d' ouvrir un compte gratos sur https://my.mandriva.com )
différentes personnes te répondront en toute franchise sur les différences réelles et le niveau d' engagement. (ça serait un peu long et un peu "pub" que je le fasse ici)

Pareil pour les offres plus professionnelles : en s' entraidant on se retrouve vite dans cette "jungle de propositions" (qui souligne surtout une adaptabilité "nickel" aux besoins de l' entreprise, ce qui nous déroute, nous utilisateurs) N' hésites pas à demander et à lire les demandes déjà formulés : le forum répond sans détours! (et les gens de mandriva aussi, parfois directement)

>> Peu d'info de disponible. Du moins je n'en ai pas trouvé.

c' est pas de l' information, mais j' ai vu des screenshots ici (bon c est juste des screenshots et rien d' autres)
http://club.mandriva.com/xwiki/bin/view/bubar/Cs4

Bonjour

Le noyau Linux sur Mandriva n' est pas complié pour le support NTFS en écriture. (seul celui utilisé par l' installateur est prévu pour avoir certaines facilitées, mais limité par sécurité)

Le support NTFS (ce système de fichier bizaroide qui a choisi de fragmenter à mort pour gagner un peu en rapidité au bout de 2 ans d' utilisation sur un système qu on ghost tout les six mois.. bref une stupidité)
donc le support NTFS à "grandi", pour résumé, voici ce qu' on peut faire avec :

lecture des fichiers / lecture des fichiers compresses (type .cab) / classement des repertoires. / fonction Mmap pour la memoire / lecture en boucle des fichiers de montage / ecrasements des donnees existantes / tronquer des fichiers / etendre des fichiers

on ne peut changer les droits sur les fichiers, mais quelqu ils soient on peut modifier les fichiers.

Télécharges les sources du noyau, et coche l' option "write ntfs support" dans la configuration du noyau, puis compile un ouveau noyau avec cette option activée. Boote dessus. Voilà

Attention : il est très fortement recommander de bien défragmenter le ntfs avant toute opérations externes dessus.

l' utilisation la plus courante est d' avoir une partition fat32 permettant de facilement transférer des données (et accès écriture en plus de lecture) entre windos et linux.
Une autre solution est d' utiliser un ""fake""-filesystem de type réseau, comme Samba.

ps : au fait, ton message irait plutôt dans "mandriva" que ici ;)

have fun :D

2-le son
tu parles de plusieurs comptes utilisateurs différents.
il ne s' agit donc pas d' un problème noyau, ni d' un problème dmix-alsa. Mais plus probablement du fait qu' un des utilisateurs ne se trouvent pas dans le groupe audio. vérifie le groupe "audio" pour chacuns des utilisateurs avec drakuser (ou par le fichier définissant à quels groupes appartiennent quels users)

3-Kscd
erreur classique, avec un message qui est un faux positif. Il ne s' agit pas d' une erreur de droit comme il le dit, mais d' une erreur de chemin. Essaye l' autre chemin usité, dès fois, par kde :
system:/media/hdc
(normalement celui que tu indiques est le bon sur kde 3.5.4)
Ou aussi, tu peux mettre en dur
/mnt/cdrom
(par exemple, ajuste avec le tiens)

voilà voilà
en espérant que cela te dépanne

bonjour,

il y a là plusieurs problèmes disctincts :

1-lilo :
lorsqu' on change lilo, on s' assure de toujours le ré-actualiser immédiatment après (commande lilo, cela permet de s' assurer de la validité du changement, d' éviter une faute de frappe)
j' avoue ne pas lire ce lilo.conf (il est tard, mes yeux fatiguent etc 'est assez illisible là !)
mais si quel que soit ton choix dans lilo, uname -rv annonce toujours le même kernel, alors le label ne correspond plus au noyau (deux labels différents pointent vers la même image)

par drakconf il est possible de changer tout cela en graphique, cela évite des bidouilles qui s' avèrent après coup un peu ch**** si elles sont allées un peu loin (sans aller jusqu' au bout)

note annexe concernant lilo.conf : normalement tu as le fichier lilo.conf~ à côté de l' original, qui correspond au dernier fichier avant la dernière modifications, fait une diff entre les deux.
normalement, voici comment devrait se présenter un lilo.conf (enfin pas complet because le mien est à rallonge !! désolé)

[root@athing /]# cat /etc/lilo.conf
# File generated by DrakX/drakboot
# WARNING: do not forget to run lilo after modifying this file

default="2.6.18-rt3"
boot=/dev/hda
map=/boot/map
keytable=/boot/fr-latin1.klt
menu-scheme=wb:bw:wb:bw
prompt
nowarn
timeout=100
message=/boot/message
image=/boot/vmlinuz
label="linux"
root=/dev/hda5
initrd=/boot/initrd.img
append="acpi=ht resume=/dev/hda11 splash=silent"
vga=791
image=/boot/vmlinuz
label="linux-nonfb"
root=/dev/hda5
initrd=/boot/initrd.img
append="acpi=ht resume=/dev/hda11"
image=/boot/vmlinuz
label="failsafe"
root=/dev/hda5
initrd=/boot/initrd.img
append="failsafe acpi=ht resume=/dev/hda11"
image=/boot/vmlinuz-2.6.17-2mdv
label="2.6.17-2"
root=/dev/hda5
initrd=/boot/initrd-2.6.17-2mdv.img
append="acpi=ht resume=/dev/hda11 splash=silent"
vga=788
image=/boot/vmlinuz-2.6.17.realtime
label="2.6.17.realtime"
root=/dev/hda5
initrd=/boot/initrd-2.6.17.realtime.img
append="acpi=ht resume=/dev/hda11 splash=silent"
vga=788
image=/boot/vmlinuz-2.6.17.realtime8
label="2.6.17.realtime8"
root=/dev/hda5
initrd=/boot/initrd-2.6.17.realtime8.img
append="acpi=ht resume=/dev/hda11 splash=silent"
vga=788

Vérifies donc tes labels et vers quoi pointent exactement chacun (image et initrd)

ok pour "sécurité c' était bien qq chose comme sûreté que je voulais employé.

ok également pour "le temps de traitement peut très bien être important, ça dépend du système à piloter", ma phrase en ne parlant que de "minima" était réductrice. (bien que le minima soit plus souvent recherché)

mais une question sur le temps réel "mou" : tu le dit adapté au traitment audio et/ou numérique : alors pourquoi sur un rt mou j ai des xrun bien plus souvent que sur un rt dur ? (et sans entrer dans un "bah tel patch est pas bon" loin de moi l' idée de juger ces travaux)
En plus de nombeux exemples de solutions professionnelles en Vidéos sont RT dur (et pas seulement en diffusion/streaming, mais aussi en étalonnage, ce qui m' a d' ailleurs étonné)

dernier mot
" flag NEED_RESCHED (positionné lors du traitement d'une interruption par ex) est testé et s'il est positionné, on fait appel au scheduler.). Ensuite, il y a beaucoup d'autres choses à modifier afin d'obtenir un noyau RT dur, et c'est ce à quoi se démène Ingo et Ted (préemption des spinlocks, etc.). Bref..."
tu aurais pas écrit une doc sur le sujet ou un bon rtfm à me pointer ? (même si c' est pas en rapport direct avec le son, cela m' intéresse fortement)
Merci

(oui bien sûr je pensais, au début du commentaire au patch dyntick)
Eric L >> Régler la fréquence d'horloge à 1000Hz n'est pas forcément une bonne idée car le temps passé à gérer l'interruption du timer prend une part non négligeable du temps processeur

hum très intéressant. faudra que je me penche, plus, sur ce sujet précis et que je fasse des tests entre 2 noyaux sur mon tit matos. Aurais tu un bon rtfm à me pointer ?

question hardware :
Ma prochaine carte mère sera celle-ci (enfin quant j aurais du pognon) :
http://www.radisys.com/products/datasheet_page.cfm?productda(...)
et pour la carte son, j hésite entre une française très bien supporté par Linux:
http://www.digigram.com/pdf_manual/soundcards_comparison_cha(...)
et une autre dont les (au moins un) dev. de la boite participe directement upstream a Alsa :
http://audioscience.com/internet/products/sound_cards/asi661(...)
(pour changer des hammerfaul et autres grandes classiques du nux...)

Eric L : >>Le noyau de Linux est préemptible (avec l'option qui va bien selectionnée lors de la config)
-> il ne s' agit pas de la même chose, je pense que tu le sais. C' est un module temps-réel (un linux security module) ce qui est différent d' un kernel preemption on acid

grosso modo par défaut on est en "temps partagé"... L' ordonnanceur a pour but un partage des ressources équitables entre les process. On peut jouer sur la priorité d' un process parmis l' ensemble grâce à la "nice"

sur un système dit temps-réel, on aura des taches qui auront un comportement dans des notions précises de temps défini. Le vrai terme "système temps-réel" pourrait être "système prédictible". C' est à dire que l' écriture, le traitement et la restitution de l' information sont effectuées dans un temps si faible que l' on nomme cette information comme étant "information préservée".

Maintenant sur Linux, il y a plusieurs solutions de "temps-réel" (terme un peu fourre tout de manière générique mais on devrait définir par lui des choses plus précises, ici). Et tuons de suite le troll "ouaihg je joue a WoW en temps réel c est plusse mieux ça va plusse vite"... Non : un système temps réel, en consacrant de hautes priorités (et une mémoire dédiée) à certaines tâches, réduit les ressources disponibles pour l' ensemble. Un système temps-réel sur un bureau, comme le dit Eric L, est synonime d' amoindrissement des ressources pour l' utilisation bureautique et mulimédia classique du comput'...

Il existe deux types de temps-réel :
le temps-réel dur et le temps réel mou.

Les deux solutions présentées par défaut dans tout kernel sont toutes des "temps-réel mous". C' est à dire qu' une certaine souplesse ai accordé aux tâches ayant pourtant accès à la priorité temps-réel (c' est à dire concrètement qu' il n' est pas interdit qu' elles dépassent 25millisecondes sir 25 est la définition du système rt)
1. le patch "preemptif" de Mr Love : il agit sur l' ordonnanceur et réduit le temps de réponse de manière systématique. (c' est également la solution de MontaVista, pour lequel Mr Love travaillait)
2. le patch "low-latency" de Mr Morton : il agit seulement sur des points précis du noyau, alors appelés "points de preemption" et ne s' occupe que de latence sur ces noeuds là.

Quant au patch de Sir Molnar, il transforme le noyau linux en noyau preemption on acid (c' est à dire en noyau à capacités temps-réel dur). Un watchdog (dont Eric L parle également ici) tournant en temps-réel se chargeant de la sécurité. Et c' est bien ce patch (peut-être amputé de son horloge) qui pourrait peut être rejoindre les 2 précédents et être intégré par défaut, et accessible du coup sur tout kernel de toutes distrib, juste en recompilant ! (pour notre plus grand bonheur)

Une fois ce type de noyau préparé, l' administrateur doit indiquer au système de sécurité quels utilisateurs et/ou groupes d' utilisateurs auront droit d' accès à ces capacités. Sur une distribution "moderne" (aucune idée de troll) c' est bien sûr PAM qui s' en charge. (et sur une distrib vraiment moderne et pas seulement à la mode, c' est pré-configuré /troll!)

Voilà voilà.

on pourrait parler du fameux Xenomai et de son micro-noyau hyperviseur qui fait tourner le noyau linux en tache. (Xenomai issu de de rtai lui même issu de rtlinux)
ou encore "flamer" sur wince, annoncé comme révolutionnaire (windows c.e embarqué et temps-réel) mais... personne en veut, encore plus depuis qu' ils ont ouvert leurs sources... le machin est cantonné aux gadgets genre téléphone portables... mort de rire :)


note inutile : ze devrais sortir dans pas longtemps un howto (bien humble) sur comment transformer facilement sa mandriva en diva-linux, pour péter les solutions actuelles grâce au travail des LAUD ... Et mettre en avant la qualité actuelle des solutions de traitment du signal audionumérique sous GNU/Linux... (troll : Apple ils vont pleurer longtemps pour le port Jack sur osX ;-) ? le site .com est sorti pourtant /troll) Si des gens lisant ceci sont éventuellement intéressés, ils peuvent m' envoyer un message privé. Toutes corrections/relectures/engueulades/merci/conseils/éclairage-de-gurus sont les bienvenues.

utf8 :) marrant
pas ce problème ici, sur aucune console tty ou emulateur de term
une distro tout en utf8
2.6.18-rt3 #blabla
ncurses 5.5

Note : je parle de SuSe et de Mandriva exprès : SLERT est annoncé... (salle de marché, etc etc)
Et Mandriva est totalement pré-configurée pour le Son (il faut juste se faire le kernel)
du côté de RedHat (the master of) c est RedHawk.. et en trollant on peut se demander ce que penses Concurent-soft de la possible intégration par défaut de ce patch.

(les autres projets, hyperviseurs, sheduleurs et autres choix de micro noyaux ne seront pas impactés, mais concurent-soft et certains fournisseurs de services..si certainement)

on peut retenir aussi "priority inheritance" ...

le temps-réel avance petit à petit, et il n' est pas exlu que " ... soon real-time could become more widespread. Seiler believes Molnar's patch will be accepted soon into the mainstream Linux kernel"

ce qui serait vraiment Royal. S' il était complètement intégré (complètement, je ne sais pas puisqu' une horloge hrt à fait son apparition en juin, et qu' il -me- semble que le patch de Sir Molnar en a une aussi, donc... bon bref l' essentiel ;) ) cela permettrai de très facilement avoir un kernel "preemption on acid".

Même en partant d' un kernel patché à mort comme celui d' une mandriva ou d' une suse ! Il suffirait de choisir l' option "full preemption" (comme aujourdhui on peut choisir entre la preemption volontaire et "outofbox", plutôt que le choix par défaut, dit "server"). -aussi les options "rtc clock par défaut et en dur" et 1000hz bien sûr.. au fait hpet on garde ou pas ? ;) - Un kernel comme celui d' une SuSe ou d' une Mandriva, bien complet, avec full support hardware, mais en realtime complet juste en recompilant (et en mettant au diapason PAM pour l' audio) = le bonheur total...

Bon je veux pas envoyer de pathfinder sur Mars, c' est sûr. Ni faire des missiles intelligents. Non plus hacker mon futur aldebaran-robotics... non juste pouvoir avoir un kernel qui permette de faire du son, sans lag aucun, parfaitement prévisible, et au dessus de tout ce qui se fait aujourdhui...

Les GNU de LAUD se défoncent pour faire des applis de feu (ardour, rosegarden, jamin.... toutes les autres). Un tel kernel serait la cerise sur le gateau. Facilement accessible pour tous puisque l' option serait intégrée par défaut (et non plus prendre le patche sur people~mingo et l' appliquer au vanilla, mais se servir direct des kernels de nos chères distribs).

Gain co-latéral ? que, enfin, Jack, décolle et s' impose... (pas seulement pour les pro du son)
/troll : parcequ' y en a marre des arts / esd / phonon / pusleaudio .... /troll

(et hop...)

diamond roxe -> ok
l' été 2005 ils avaient publié un minmag nommé "rtfm" avec quelques autocollants dedans.
Ca serait sympa de retrouver l' autocollant RTFM dans un de leurs mags quelconque...

pour les abrutis comme moi qui l' avait collé à l' exterieur de leur voiture (colle au dos du sticker et pas pensé au scotch) il a pas tenu longtemps sous la pluie...

okok je re-sort

ha tiens il est bien ce sondage :)
dommage : à la question "gnu/linux magazine quant..."
réponse manquante : "quant j ai du pognon"

bon okok je sors

Pareil ici.

dans la série linux+dvd, la seule rubrique de correcte c' est la "parole aux distro et au noyau".. mais cela ne fait qu' une petite page.
Tout ces magazines sont truffés d' énormes bourdes orthographiques et fautes de frappes (on se dirait sur un forum où on tappes vite sans se relire...)
Mais il n' y pas que ça, en cherchant bien on trouve de vraies grosses boulettes, du style apt-get est le gestionnaire de paquet par défaut de fedora... si si... Des comme ça y en a des tonnes dans linux+dvd...
(bon il y a quant même certains articles très bien fait et certaines interviews très intéressantes. Mais dans l' ensemble ça sent la mauvaise copie de howto, les articles pas finis, les fautes et les énormités)

Et attendez, elles sont pas venues vous démarcher sur le ML de vos lugs ? ici on a eu droit à du spam "écrivez pour linux+dvd", gratos bien sûr... et tout pour leurs pommes. Ils prennent pas un peu les GNU et users-gnu pour des cons.. non si peu. (quant je pense que linux-forum paye jusqu' à 300 euros l' article) ...

Donc je pratique aussi le même filtre que toi.
je jettes un oeil quant même, voir si un article est vraiment intéressant -> rien acheté de cet éditeur depuis avril...

les dépêches purement commerciales seront rejetées.
j' espère que c' est toujours le cas.

Et de noter qu' il s' agit là d' une annonce de Release Candidate, sur laquelle sera basée une version 100% libre d' une nouvelle version de cette distribution GNU/Linux (et 100% libre, pas sur le papier qui l' accompagne.. mais dans les faits vrais et réels) -> Il ne s' agit donc pas d' une dépêche commerciale

Et pour l' aspect modération pur : il ne semble pas avoir eu vent d' une demande de dépêche sur la Corporate Server 4, qui est sortie hier -pourtant ça vaudrait la news, mais cela ne rentre pas dans le cadre de linuxfr- )

Les gens comme Warly et Blino (c' est pas le dpt marketting, eux, ce sont des developpeurs ! et Warly a choisi de demander une annonce pour cette RC et pas une autre version!) sont bien les mieux placés pour nous donner des nouvelles de Mandriva, vous ne croyez pas, objectivement ? Tant que cela reste dans le cadre de linuxfr !

perso j' espère que l' objectivité et la rigueur continuerons. (Pour les paranos pire que moi... ben qu' il passe leur serveur sous Obsd, ça fait plus de bien que les trolls.)

ps : en seconde page il y a une annonce purement commerciale. Pourquoi ne pas allez dessus pour troller ? là, ça y sera justifé !