> huer un hymne national au début d'un match c une honte
Ouais mais c'est pas bien grave...
Je trouve, par ma part, honteux un état qui oblige le respect du drapeau et de l'hymne.
çà me fait penser aux parents qui veulent être respectés par leurs gamins et qui leurs foutent une bonne claque chaque foi qu'ils leur manquent de respect. Avec un tel "régime" les gosses ne déconnent plus et les parents ont l'impression d'être respecté. Alors que les gamins se disent :
- "nos parents: des connards".
Le respect çà se gagne mais çà ne s'impose pas.
> De toute manière ce qui importe ce n'est pas essentiellement la loi mais la manière dont elle est appliquée.
C'est un gros problème. çà va être à la tête du client encore (comme pour les occupation de cage d'escalier, etc...).
Il y a eu un incident équivalent pendant un france-algérie mais c'était sous Mittérant. Mittérant a changé le protocol en allant sur la pelouse saluer un par un tous les joueurs.
> Vu le type d'operation effectue, il est evident qu'un model multithreade est plus efficace pour ce type de soft.
Je doit conclure que tout les programmes qui ont l'algo :
1) lecture depuis le disque
2) decodage (traitement)
3 affichage (retour des informations)
son plus rapide s'ils sont "multi-threadés". Vivement un grep/sed/awk... multi-thread alors ?
> Faire sequentiellement de la lecture(qui revient a s'arreter et attendre que le systeme d'I/O complete la requete),
Oui et non.
Les lectures de disque sont lente mais ne consomme pas de cpu. De plus tu peux très bien faire des lectures non bloquante et c'est très très rapide.
Lorsque tu fais un read() non bloquant et qu'il n'y a pas de donné dans le cache, les données seront lues par le noyau plus tard alors que ton programme est "ailleur". A çà tu ajoutes un buffer, peut-être l'utilisation de select() et l'affaire est plié.
Actuellement mplayer utilise deux proces (et non deux threads !) :
- un pour la lecture
- un pour le décodade et affichage
Les deux proces sont utilisés uniquement si l'option -cache est spécifié. L'utilisation de deux proces est intéressante pour un fichier avi sur le réseau (http://....(...)) car le noyau ne peut pas "bufferiser" ce qui est sur le réseau.
> pour forcer le respect à des symboles tels que ceux là.
çà reste des symboles. 7 500 et 6 mois de prison pour un symbole, çà me fait mal cul. Si maintenant les gens mécontentes ne peuvent pas attaquer les symboles, ils vont attaquer quoi ?
> Le desing est plus propre
Il n'y a pas de raison à çà. La lecture de flux video est très séquencielle.
> tire parti au mieux des perfs du systeme.
Le temps de gestion des threads (verrouillage de ressources etc...) il faut bien le payer.
Apache 2 a gagné en perfo en utilisant les threads par rapport à Apache 1.3 car il économisait des fork() . Le fork() étant plus couteux sous windows, c'est sous windows que le gain de perfo est important.
Malheureusement, mplayer ne forke pas ...
Avec le 2.4.17 j'avais des valeurs de consomation de cpu ridicule. Par exemple pour un avi 720x576 j'avais 2 % de cpu utilisé (je n'ai aucune accélération video). Mais en utilisant une benckmark en parallèl à le lecture du fichier avi me montrait que mon cpu n'était pas dispo à 98 % pour le bench.
Lorsque je suis passé sous 2.4.18 j'avais enfin des valeurs cohérentes.
J'ai un XP 1600 avec une carte video ATI Rage pro IIC. Aucune accélération video n'est utilisé. En 1024x768 j'utilise 50 % du cpu. Donc le multi-threading n'est pas une priorité. Sauf pour faire tourner sur du hardware rare comme des bi-pIII ...
> c'est une version qui supporte les threads
GNU/Linux supporte les threads via Linux et la libc. Si je veux faire tourner un programme qui utilise les threads, il faut que je cherche un OS qui supporte les threads.
Et je ne peux pas faire tourner Apache 2 sur MPlayer même si selon toi MPlayer supporte les threads :-) . Si le fait d'utiliser quelque chose fait que tu le supportes alors on peut dire que MPlayer supporte les systèmes de fichier journalisé :-) .
Si MPlayer lit du quicktime, c'est bien MPlayer qui fait le boulot et c'est donc bien lui qui donne un support pour quicktime.
Je sais que l'on lit souvent :
- la plate-forme Linux est supporté par tel programme.
Ce qu'il faut comprendre dans ce cas, c'est que les développeurs supportent le programme sur cette plate forme.
D'ailleur on a souvent :
- "Unsupported plateforme but seems to work..."
Le problème des moteurs essences est qu'ils ont un moins bon rendement à mi-charge (lorsqu'on n'est pas pied au planché).
Les moteurs diesel sont des moteurs a mélange pauvre et ne nécessite pas de boîtier papillon qui "étrange" l'arrivée d'air et engendre un phénomène d'aspiration à l'échappement qui n'aide pas.
Si les moteurs diesels avaient un boîtier papillon, il serait toujours totalement ouvert.
Désolé mais emacs est une honte en terme de convivialité. Suffit de voire la rubrique "astuces" de linuxfr pour le comprendre. Avec des trucs comme :
- comment faire un copié/collé sous emacs.
- comment activer la coloration dans emacs.
- les 4000 combinaisons C-Alt-<esc>-<tab> ...
- etc...
J'utilise Xemacs (pour le développement C) qui est aussi compliqué. (X)emacs a de formidables fonctionnalités mais est définitivement trop compliqué et non abordable.
Tu vois mal le problème. Les voitures sont suffisament puissante à notre époque. Ce n'est pas parce que c'est un moyen de transport que le puissance est sans intérêt. Début du siècle précédent la puissance des véhicules étaient insuffisantes (quoique les routes, la culture ne permettait pas d'aller vite...). Les fusées ne sont que des moyens de transport et la puissance est très importante. Si un jour tu as la change d'utiliser un camping-car tu te plaindra souvent de leur faible puissance dans les montées.
> Pour un PC, la puissance est beaucoup plus utile que pour une voiture.
Toujours le même problème. Pour un usage bureautique tous les cpu sont assez puissants.
> faut comparer le couple !
Si tu as le couple en fonction de la vitesse de rotation, tu as la puissance en fonction de la vitesse de rotation.
> la puissance n'etant que le couple multiplié par la vitesse de rotation.
Si tu n'a que le couple tu ne conclus rien. Si tu n'as que la puissance, tu as quelques éléments.
Il y a une forte corélation entre la rapport puissance/poid et les accélérations d'un voitrure (1000 m départ arrêté par exemple).
De même, pour un carosserie donnée, il y a une forte corélation entre la puissance et la vitesse maxi.
Exemple :
Moteur diesel : 300 Nm ; 100 KW => Vmax = 200 km/h
Moteur essence : 200 Nm ; 100 KW => Vmax = 200 km/h
Imaginons un moteurs de 100 KW à 8000 tr/min et 150 Nm à 4000 tr/min. Prenons le même moteur mais qui tourne deux fois moins vite et qui a un couple deux foi plus élevé (100 KW à 4000 tr/min ; 300 Nm à 2000 tr/min).
Les moteurs une fois installé dans un véhicule donnerons EXACTEMENT les même performances. Le seul point particulier est que le moteur qui tourne deux fois plus vite va envoir une boîte de vitesse deux fois plus courte !
Les moteurs diesel à puissance équivalente d'un moteur essence offre souvent de meilleur reprise. Je semble me contredire. En fait, les moteurs diesel on souvent un courbe de puissance mieux répartie que le moteur essence. A 50 % du régime de puissance, les moteurs essence ont 50 % de leur puissance maxi. Pour les moteurs diesel, à 50 % de leur régime de puissance, il ont souvent 60 à 65 % de leur puissance maxi.
Faire croire qu'avec apt il n'y a aucun problème est réellement excessif.
Que fait "apt-get dist-upgrade" si apache passe de la version 1.3 à la 2.0 ?
apt met correctement à jour tes fichiers de conf.
Lors du passage de Linux 2.2 à 2.4, ton ficher /etc/modules.conf est correctement mise
à jour ?
S'il y a un mise à jour vers un nouvelle version major de PostgreSQL ou MySQL, toutes les données sont mise à jour ?
Si tu as un programme (hors de la distrib debian) qui utilise Gnome 1.0, que se passe-t-il lors d'un "dist-upgrade" qui tente d'installer Gnome 2.0 ?
C'était un complément d'information. Je ne voulais pas que les gens imagines la RH AS comme proprio et que cette nouvelle politique soit vue comme une tentative pour favorise une solution proprio.
> n'importe qui peut la reprendre à son compte pour la maintenir.
Il y a peut-être un marché actuellement. Mais je pense qu'à l'avenir, les entreprises qui ont besoin d'une solution avec un long support se tourneront vers une RH AS dès le début (ou un autre distributeur).
Je crois que tu idéalises les possibilités de mise à jour. Si tu as un serveur un peu personnalisé :
- conf d'apache un peu compliqué
- utilisation de proftpd et non de wu-ftpd
- plein de paramétrage spécifique dans /etc
- plein d'utilisateurs avec des $HOME/.gnome ou $HOME/.kde
- postgresql qui demande un dump/load (et n'y a pas de procédure automatique)
- etc...
Ben après la mise à jour tu as plein de *.rpmsave.
C'est vrai que globalement les mises à jour marche mais je n'y fais pas une confiance totale. Du moins il faut un système peu personnalisé.
> que je ne trouve pas trop embetant cette politique.
Moi si. J'utilise depuis longtemps RedHat et en général je garde une distribe durant 18 à 24 mois (4.2, 5.2, 6.2, 7.2, 8.0 (suite à crash file system)). Comme j'ai actuellement un 8.0 je suis un peu "obligé" de passer à une 8.2 dans un an.
Cette nouvelle politique est pour moi "embêtante". Rien de plus. Si çà permet à RedHat de faire du pognon, je ne vois aucun problème. Du moins tant que le pognon est réinvesti dans le free software (code GPL, ressources pour les développeurs, etc...).
Lorsque le RH 8.2 sort, il ne reste que 3 mois de support à la RH 8.0 alors qu'il n'y a pas de changement de version majeur (Et la RH 8.0 a un traitement de faveur car elle va disposer de 15 mois de support).
Il faut donc mettre à jour son système tous les deux releases mineur environ.
Considérons le cas de la 7.2 qui est mal placé (car c'est la 7.3 fini la série des 7.x). Avec l'ancienne politique de support, il n'y a plus de support lors de la sortie de la 8.0. Soit 15 mois dans ce cas. Donc, dans le pire des cas, l'ancienne politique de support est équivalente à la nouvelle.
Par contre, pour la Advanced Server, RH ne fourni pas gratuitement d'image iso ou de binaire.
La RH AS a les même conditions d'utilisation que la RH Linux. C'est-à-dire que tu peux la copier , etc...
[^] # Re: Les députés durcissent la loi Sarkozy, entre autres sur l'info
Posté par matiasf . En réponse à la dépêche Les députés durcissent la loi Sarkozy, entre autres sur l'informatique. Évalué à 5.
Ouais mais c'est pas bien grave...
Je trouve, par ma part, honteux un état qui oblige le respect du drapeau et de l'hymne.
çà me fait penser aux parents qui veulent être respectés par leurs gamins et qui leurs foutent une bonne claque chaque foi qu'ils leur manquent de respect. Avec un tel "régime" les gosses ne déconnent plus et les parents ont l'impression d'être respecté. Alors que les gamins se disent :
- "nos parents: des connards".
Le respect çà se gagne mais çà ne s'impose pas.
> De toute manière ce qui importe ce n'est pas essentiellement la loi mais la manière dont elle est appliquée.
C'est un gros problème. çà va être à la tête du client encore (comme pour les occupation de cage d'escalier, etc...).
[^] # Re: Les députés durcissent la loi Sarkozy, entre autres sur l'info
Posté par matiasf . En réponse à la dépêche Les députés durcissent la loi Sarkozy, entre autres sur l'informatique. Évalué à 1.
[^] # Re: Les députés durcissent la loi Sarkozy, entre autres sur l'info
Posté par matiasf . En réponse à la dépêche Les députés durcissent la loi Sarkozy, entre autres sur l'informatique. Évalué à 0.
Enfin c'est le souvenir que j'ai.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par matiasf . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 4.
Je doit conclure que tout les programmes qui ont l'algo :
1) lecture depuis le disque
2) decodage (traitement)
3 affichage (retour des informations)
son plus rapide s'ils sont "multi-threadés". Vivement un grep/sed/awk... multi-thread alors ?
> Faire sequentiellement de la lecture(qui revient a s'arreter et attendre que le systeme d'I/O complete la requete),
Oui et non.
Les lectures de disque sont lente mais ne consomme pas de cpu. De plus tu peux très bien faire des lectures non bloquante et c'est très très rapide.
Lorsque tu fais un read() non bloquant et qu'il n'y a pas de donné dans le cache, les données seront lues par le noyau plus tard alors que ton programme est "ailleur". A çà tu ajoutes un buffer, peut-être l'utilisation de select() et l'affaire est plié.
Actuellement mplayer utilise deux proces (et non deux threads !) :
- un pour la lecture
- un pour le décodade et affichage
Les deux proces sont utilisés uniquement si l'option -cache est spécifié. L'utilisation de deux proces est intéressante pour un fichier avi sur le réseau (http://....(...)) car le noyau ne peut pas "bufferiser" ce qui est sur le réseau.
[^] # Re: Infraction pour outrage au drapeau tricolore ou à l'hymne national
Posté par matiasf . En réponse à la dépêche Les députés durcissent la loi Sarkozy, entre autres sur l'informatique. Évalué à 4.
çà reste des symboles. 7 500 et 6 mois de prison pour un symbole, çà me fait mal cul. Si maintenant les gens mécontentes ne peuvent pas attaquer les symboles, ils vont attaquer quoi ?
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par matiasf . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 3.
1)
2)
3)
> Le desing est plus propre
Il n'y a pas de raison à çà. La lecture de flux video est très séquencielle.
> tire parti au mieux des perfs du systeme.
Le temps de gestion des threads (verrouillage de ressources etc...) il faut bien le payer.
Apache 2 a gagné en perfo en utilisant les threads par rapport à Apache 1.3 car il économisait des fork() . Le fork() étant plus couteux sous windows, c'est sous windows que le gain de perfo est important.
Malheureusement, mplayer ne forke pas ...
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par matiasf . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 1.
Lorsque je suis passé sous 2.4.18 j'avais enfin des valeurs cohérentes.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par matiasf . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 2.
J'ai eu des valeurs similaire avec 2.4.17 . Je n'ai plus retrouvé de telle valeur avec un 2.4.18.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par matiasf . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 2.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par matiasf . En réponse à la dépêche Document sur le développement de mplayer. Évalué à -5.
GNU/Linux supporte les threads via Linux et la libc. Si je veux faire tourner un programme qui utilise les threads, il faut que je cherche un OS qui supporte les threads.
Et je ne peux pas faire tourner Apache 2 sur MPlayer même si selon toi MPlayer supporte les threads :-) . Si le fait d'utiliser quelque chose fait que tu le supportes alors on peut dire que MPlayer supporte les systèmes de fichier journalisé :-) .
Si MPlayer lit du quicktime, c'est bien MPlayer qui fait le boulot et c'est donc bien lui qui donne un support pour quicktime.
Je sais que l'on lit souvent :
- la plate-forme Linux est supporté par tel programme.
Ce qu'il faut comprendre dans ce cas, c'est que les développeurs supportent le programme sur cette plate forme.
D'ailleur on a souvent :
- "Unsupported plateforme but seems to work..."
# MplayerXP fork de MPlayer avec support des threads
Posté par matiasf . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 5.
Sinon le multi-threading n'est pas très intéressant.
Si mplayer est lancé avec l'option -cache [nombre] il y a deux proces mplayer. Un pour loader la video et un autre pour l'afficher.
exemple :
$ mplayer -vo x11 -cache 65536 toto.avi
...
dans une autre console :
$ ps ax | grep mplayer
2359 pts/1 R 0:00 mplayer -vo x11 -cache 65536 toto.avi
2361 pts/1 S 0:00 mplayer -vo x11 -cache 65536 toto.avi
$ kill -SIGSTOP 2361
La video continue tant que le buffer n'est pas vide.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par matiasf . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 3.
Les moteurs diesel sont des moteurs a mélange pauvre et ne nécessite pas de boîtier papillon qui "étrange" l'arrivée d'air et engendre un phénomène d'aspiration à l'échappement qui n'aide pas.
Si les moteurs diesels avaient un boîtier papillon, il serait toujours totalement ouvert.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par matiasf . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 1.
[^] # Re: Développer pour Mozilla : livre en Open Content
Posté par matiasf . En réponse à la dépêche Développer pour Mozilla : livre en Open Content. Évalué à -1.
> - Compliqué pour qui ?
Désolé mais emacs est une honte en terme de convivialité. Suffit de voire la rubrique "astuces" de linuxfr pour le comprendre. Avec des trucs comme :
- comment faire un copié/collé sous emacs.
- comment activer la coloration dans emacs.
- les 4000 combinaisons C-Alt-<esc>-<tab> ...
- etc...
J'utilise Xemacs (pour le développement C) qui est aussi compliqué. (X)emacs a de formidables fonctionnalités mais est définitivement trop compliqué et non abordable.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par matiasf . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 1.
Tu vois mal le problème. Les voitures sont suffisament puissante à notre époque. Ce n'est pas parce que c'est un moyen de transport que le puissance est sans intérêt. Début du siècle précédent la puissance des véhicules étaient insuffisantes (quoique les routes, la culture ne permettait pas d'aller vite...). Les fusées ne sont que des moyens de transport et la puissance est très importante. Si un jour tu as la change d'utiliser un camping-car tu te plaindra souvent de leur faible puissance dans les montées.
> Pour un PC, la puissance est beaucoup plus utile que pour une voiture.
Toujours le même problème. Pour un usage bureautique tous les cpu sont assez puissants.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par matiasf . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 2.
Si tu as le couple en fonction de la vitesse de rotation, tu as la puissance en fonction de la vitesse de rotation.
> la puissance n'etant que le couple multiplié par la vitesse de rotation.
Si tu n'a que le couple tu ne conclus rien. Si tu n'as que la puissance, tu as quelques éléments.
Il y a une forte corélation entre la rapport puissance/poid et les accélérations d'un voitrure (1000 m départ arrêté par exemple).
De même, pour un carosserie donnée, il y a une forte corélation entre la puissance et la vitesse maxi.
Exemple :
Moteur diesel : 300 Nm ; 100 KW => Vmax = 200 km/h
Moteur essence : 200 Nm ; 100 KW => Vmax = 200 km/h
Imaginons un moteurs de 100 KW à 8000 tr/min et 150 Nm à 4000 tr/min. Prenons le même moteur mais qui tourne deux fois moins vite et qui a un couple deux foi plus élevé (100 KW à 4000 tr/min ; 300 Nm à 2000 tr/min).
Les moteurs une fois installé dans un véhicule donnerons EXACTEMENT les même performances. Le seul point particulier est que le moteur qui tourne deux fois plus vite va envoir une boîte de vitesse deux fois plus courte !
Les moteurs diesel à puissance équivalente d'un moteur essence offre souvent de meilleur reprise. Je semble me contredire. En fait, les moteurs diesel on souvent un courbe de puissance mieux répartie que le moteur essence. A 50 % du régime de puissance, les moteurs essence ont 50 % de leur puissance maxi. Pour les moteurs diesel, à 50 % de leur régime de puissance, il ont souvent 60 à 65 % de leur puissance maxi.
[^] # Re: Développer pour Mozilla : livre en Open Content
Posté par matiasf . En réponse à la dépêche Développer pour Mozilla : livre en Open Content. Évalué à 0.
En moins gros et moins compliqué.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par matiasf . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 3.
[^] # Re: mouais
Posté par matiasf . En réponse à la dépêche RedHat change de politique de support.. Évalué à 5.
Que fait "apt-get dist-upgrade" si apache passe de la version 1.3 à la 2.0 ?
apt met correctement à jour tes fichiers de conf.
Lors du passage de Linux 2.2 à 2.4, ton ficher /etc/modules.conf est correctement mise
à jour ?
S'il y a un mise à jour vers un nouvelle version major de PostgreSQL ou MySQL, toutes les données sont mise à jour ?
Si tu as un programme (hors de la distrib debian) qui utilise Gnome 1.0, que se passe-t-il lors d'un "dist-upgrade" qui tente d'installer Gnome 2.0 ?
etc...
etc...
[^] # Re: RedHat change de politique de support.
Posté par matiasf . En réponse à la dépêche RedHat change de politique de support.. Évalué à 3.
C'était un complément d'information. Je ne voulais pas que les gens imagines la RH AS comme proprio et que cette nouvelle politique soit vue comme une tentative pour favorise une solution proprio.
> n'importe qui peut la reprendre à son compte pour la maintenir.
Il y a peut-être un marché actuellement. Mais je pense qu'à l'avenir, les entreprises qui ont besoin d'une solution avec un long support se tourneront vers une RH AS dès le début (ou un autre distributeur).
[^] # Re: mouais
Posté par matiasf . En réponse à la dépêche RedHat change de politique de support.. Évalué à 10.
- conf d'apache un peu compliqué
- utilisation de proftpd et non de wu-ftpd
- plein de paramétrage spécifique dans /etc
- plein d'utilisateurs avec des $HOME/.gnome ou $HOME/.kde
- postgresql qui demande un dump/load (et n'y a pas de procédure automatique)
- etc...
Ben après la mise à jour tu as plein de *.rpmsave.
C'est vrai que globalement les mises à jour marche mais je n'y fais pas une confiance totale. Du moins il faut un système peu personnalisé.
> que je ne trouve pas trop embetant cette politique.
Moi si. J'utilise depuis longtemps RedHat et en général je garde une distribe durant 18 à 24 mois (4.2, 5.2, 6.2, 7.2, 8.0 (suite à crash file system)). Comme j'ai actuellement un 8.0 je suis un peu "obligé" de passer à une 8.2 dans un an.
Cette nouvelle politique est pour moi "embêtante". Rien de plus. Si çà permet à RedHat de faire du pognon, je ne vois aucun problème. Du moins tant que le pognon est réinvesti dans le free software (code GPL, ressources pour les développeurs, etc...).
[^] # Re: mouais
Posté par matiasf . En réponse à la dépêche RedHat change de politique de support.. Évalué à 6.
Actuellement RedHat est en phase de transition et la prolongation de support pour 7.[012] est un cadeau pour "faire passer la pillule".
Fesons une projection :
RH 8.0 : 9/2002
RH 8.1 : 3/2003
RH 8.2 : 9/2003
Lorsque le RH 8.2 sort, il ne reste que 3 mois de support à la RH 8.0 alors qu'il n'y a pas de changement de version majeur (Et la RH 8.0 a un traitement de faveur car elle va disposer de 15 mois de support).
Il faut donc mettre à jour son système tous les deux releases mineur environ.
Considérons le cas de la 7.2 qui est mal placé (car c'est la 7.3 fini la série des 7.x). Avec l'ancienne politique de support, il n'y a plus de support lors de la sortie de la 8.0. Soit 15 mois dans ce cas. Donc, dans le pire des cas, l'ancienne politique de support est équivalente à la nouvelle.
[^] # Re: RedHat change de politique de support.
Posté par matiasf . En réponse à la dépêche RedHat change de politique de support.. Évalué à 5.
La version Red Hat Advanced aussi. Les sourses sont dispos ici :
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/2.1AS/en/os/i386/(...)
Par contre, pour la Advanced Server, RH ne fourni pas gratuitement d'image iso ou de binaire.
La RH AS a les même conditions d'utilisation que la RH Linux. C'est-à-dire que tu peux la copier , etc...
[^] # Re: RedHat change de politique de support.
Posté par matiasf . En réponse à la dépêche RedHat change de politique de support.. Évalué à 3.
Sauf pour leur distribe Advanced Server qui est supporté jusqu'au 05/2005 (soit 3 ans depuis la date de sortie).
[^] # Re: pour Noël !
Posté par matiasf . En réponse à la dépêche Trop classe un bijou GNU(?)/Linux pour Noël !. Évalué à 2.