IsNotGood a écrit 5009 commentaires

> Le premier téléphone fonctionnant sous l'OS tant attendu Google Android serait pour bientôt.

Je m'en fous

> Entièrement libre

Faut le dire très très vite.

x264 est génial.
Mais, il bouffe aussi pas mal de cpu pour décoder.
Le codage (qualité et débit) dépend des options. Il y a même un mode sans perte (qui bouffe beaucoup de bande passante).

Je n'utilise plus que ça.

Ubuntu veut concurrencer Red Hat et Novell, mais c'est les autres qu'Ubuntu tue. Et pour quoi ? Ubuntu^WCanonical est toujours en perte.

> c'est pas faux mais hors-sujet ici

Pas vraiment.
Par exemple l'excellent Alan Cox bosse upstream mais répond aussi au support de Red Hat.
Une grande partie des développeurs Red Hat fait aussi du support.
Certe Alan Cox ne va pas répondre pour ton problème de compte RHN ou de configuration de carte réseau. Mais pour des grands comptes qui ont des problèmes pointus ou des besoins de conseils, ou pour IBM qui n'arrive pas à faire marcher correctement une bécane avec RHEL, il peut intervenir. Le patch sera dans RHEL et biensûr en upstream.

Le support ce n'est pas qu'avoir des bimbos qui répondent au téléphone. C'est l'expertise, la compétence. Avoir des développeurs upstream est très important.

> Si je n'avais accepté que des missions ou je connaissais tout de A à Z, je ne sais pas ce que je boufferais aujourd'hui (et ma famille avec).

C'est ta démarche, risquer mais nécessaire. Il faut l'assumer (oui, c'est dur, bon courage).

> j'aurais mieux fait de faire cela avec une Debian

Ce qui est désagréable avec toi, c'est que tu dis "Debian c'est mieux", seulement car tu ne connais pas RHEL.
Il y a plein d'admin RHEL/Fedora qui n'ont pas envis de se prendre une Debian "dans la gueule" car ils ne connaissent pas Debian. Il y a plein d'admin RHEL qui ont dû s'aventurer sur Debian temporairement et ils n'en sont pas sorti très fière. Mais ils ne vont pas vomir Debian pour autant.

En passant, une RHEL est supporté 7 ans minimum (ce que ne fait pas Debian). Et avec compatibilité source et binaire (sauf quelques gros paquet comme Firefox, OOo). Rares sont ceux qui le font.
Beaucoup de bug noyau/libc/etc sont corrigés par Red Hat. Certes, tu vois ces corrections dans Debian rapidement, mais Debian n'est souvent pas en mesure de les faire. Et ce boulot c'est bien du support (même si tu peux l'avoir gratuitement dans une CentOS, c'est du boulot de support de RHEL).
Parce que le support de RHEL est fort, Ubuntu veut la synchronisation avec RHEL (car Ubuntu n'arrive pas à fournir le même support que RHEL, Ubuntu veut récupérer le boulot de RHEL).

Tu as eu une mauvaise expérience avec RHEL. OK, ça t'as refroidi et tu fuis RHEL. Je te comprend.
Mais de la à vomir sur RHEL et son support, puis conclure "Debian c'est mieux", c'est fort de café.

> Tout à fait... sauf qu'aucune des distros à base de RPM que j'ai essayées n'implémente la désinstallation automatique des dépendances inutiles

Quel est l'intérêt ?
Gagner un peu de place sur le disque dur et c'est tout.

Enfin comment tu fais pour savoir si un paquet est inutile ou non avec le chargement dynamique des libraries ?
Prend le plugin flash, c'est une librairie, personne en dépend (en tout cas tu ne peux pas le détecter automatiquement). Tu fais quoi, tu le vires automatiquement ?
Certes, tu peux faire une "usine à gaz" qui regarde ce que l'utilisateur a explicitement demandé d'installé. Mais pour l'installation par défaut, tu fais quoi ? Tu considères qu'il n'a explicitement rien demandé ou qu'il a demandé explicitement tout ce qui est dans l'installation par défaut ?
RHEL/Fedora utilisé les groupes (abstraction hors de rpm). Lorsqu'un utilisateur demande l'installation d'un groupe, tu considères que l'utilisateur a explicitement demandé tous les paquets du groupe ?

Prenons le problème avec plus de distance. Si un paquet est installé et n'est pas utilisé, il ne dérange personne (à quelques excèptions comme les programmes avec suid).
Regardes du côté de Windows, 99 % des postes ont l'installation par défaut...
Contrairement à Windows, sous Linux il n'y a pas de programme qui s'exécute et qu'on ne peut virer. Si c'est un service, on peut le désactiver, si c'est un applet Gnome, on peut la virée, etc.
Donc les paquets en trop ne dérange pas sauf pour la place disque, voire la durée de mise de jour.
Cette "finesse" de désinstallation n'a pas de sens en entreprise. Un poste peut être utilisé par plusieures personnes et dans ce cas le poste ne va pas être aux petits oignons pour une seule personne. Si une personne a besoin d'un programme qui n'est pas installé, l'admin installe le programme. Et si la personne part, ben l'admin laisse l'application car il a autre chose à foutre que d'économiser quelques Mo et car l'application sera peut-être utilisée par un autre.

> mais c'est quand même une habitude tenace dans le "clan RPM"...

Il y a des raisons/explications légitimes.

N'importe quoi.
Et regarde pour d'autres fonctionnalités, rpm les a depuis bien avant deb (triggers, signatures, etc).

Du côté de deb on a des fanatiques aveugles, du côté de rpm des pragmatiques ennuyeux. J'ai choisi mon camp...

> Et enfin, pourquoi, oui, pourquoi Red Hat n'a pas développé une meilleure gestion des paquets ?

Parle technique (et non troll) et dit ce qu'il manque à rpm (vs deb).
En passant, il y a aussi apt-get pour rpm...

Oui, il faut être nul pour installer phpMyAdmin.
Un bon admin n'installe pas ce genre de truc.
Un bon admin RHEL n'installe pas phpMyAdmin.
Un bon admin RHEL sait qu'il existe plein de dépôt RHEL/Fedora et sait adapter un paquet Fedora à RHEL.
Un bon admin RHEL sait que RHEL est pour le support ET l'assurance qualité. Ce bon admin préférera peut-être une Fedora, mais il sait, bien que les similitudes soient nombreuses entre RHEL et Fedora, que ses deux distributions n'ont pas la même cible.

Plus globalement, on a ici un mec qui connait mieux Ubuntu que RHEL...
C'est tout.

Puis les gus qui disent que le support de RHEL est mauvais, ben il y a quoi à côté alors qu'on compare RHEL à Ubuntu ?
Du support à la Ubuntu pour RHEL, ça existe. C'est Centos et autres clônes.

Non. C'est seulement parfois une conséquence.
Tu parles du "bazard".

Il y a KDE 4.1 dans testing de F9. Donc sera en mise à jour de F9 dans quelques jours.

> C'est historique

Comme les mainframes.

> Ça dépend de l'offre. Il y a une offre avec un nombre illimité de guest. Il n'y a pratiquement que Red Hat qui fait ça...

En passant, ça inclus aussi les RHEL en guest.
Le prix est alors très attractif.

Pour l'aspect cloud/grid, Red Hat le fait aussi et notamment avec aws (ec2/s3) d'Amazon.

Avec plein d'approximation on dit n'importe quoi.

> 40% cher que Novell SuSE

Pour quelle offre ?

> Egalement, la limitation à 4 virtualisation par poste

Ça dépend de l'offre. Il y a une offre avec un nombre illimité de guest. Il n'y a pratiquement que Red Hat qui fait ça...

> le fait d'utiliser obligatoirement Xen

Red Hat supporte Xen actuellement. Comme Red Hat ne supporte que ext3. Red Hat ne va pas "supporter" 50 versions de virtualisation (ou de FS) s'ils ne sont pas capables de réellement les supporter.
Si tu as un problème, Red Hat ne va pas répondre "on attend le bon vouloir du développeur upstream".

En passant, Red Hat est actuellement le plus gros contributeur à KVM et l'un des plus gros pour Xen. Et Novell ?

> n'ont fait qu'anéantir l'offre de Redhat

Et aussi le fait de ne pas coucher MS...

> vous trouverez une magnifique correction .... dans la RHE4 facturée 400€" ARRRGGGG!

Faut arrêter de dire n'importe quoi.
1- Le support d'une version est de 7 ans minimum donc 4 minimum de support complet
2- Le support complet de RHEL 4 et 5 a été allongé d'un an
3- Tu paies une souscription, elle donne accès à TOUTES les versions d'RHEL. Bref, passer de RHEL 3 à 4 est gratuit

> Maintenant il est clair que quand on a les moyens, leur support est efficace

C'est justement ce que vend Red Hat.

> Remarque typique d'un ancien windowsien.

J'ai exclusivement GNU/Linux chez moi depuis plus de 10 ans...

> et donc plus ma freemem est basse, mieux je me porte

Tu veux dire que plus il y a de mémoire pour le cache et mieux tu te portes. C'est n'est pas la même chose. Sinon je te conseille de passer à 128 Mo.

> un assignement du copyright qui leur permet virtuellement de faire ce qu'ils veulent y compris rendre le code non-libre.

Le code libre reste libre. Le problème est que celà permet à Sun (et uniquement Sun) de changer la licence (pour *leur* branche) et d'ajouter du non-libre. C'est un droit exclusif pour Sun.

M'enfin, Novell qui fait la morale ... alors que Novell fait des accords "exclusifs" MS...

> Est ce que linux est arrivé au summum des possibilités que le hw permet ?

Veux-tu savoir si Linux met à genoux tout hw comme Vista le fait ?

> (et en plus ils ne figent pas tout !).

Mouaif...
RHEL et Fedora n'ont rien à voir sur ce point. Avec RHEL il y a garantit (donc engagement de la part de Red Hat) d'être compatible binaire ET source pour une version majeur (ici RHEL 4). Il y a quelques exceptions pour la bureautique (Firefox, Thunderbird, OOo). Par exemple RHEL 4.7 utilise toujours un noyau 2.6.9 (comme RHEL 4.0). Ce n'est pas du tout le cas pour Fedora où il n'y a pas de garantit de compatibilité pour une même version de Fedora même si cette dernière a une durée de vie très courte par rapport à RHEL. C'est la conséquence du mode de développement communautaire de Fedora.
Parce que Red Hat "fige" ses versions majeurs, Red Hat est dans l'obligation de proposer plusieurs distributions en même temps. Actuellement RHEL 3, 4 et 5 (RHEL 2.1 vient juste de ne plus être supporté).
Cette RHEL 4.7 n'est pas vraiment une nouvelle distribution. Ceux qui mettent à jour, comme il se doit, leur distribution RHEL 4 (via up2date ou yum), ont aujourd'hui une RHEL 4.7.

Sans vouloir faire offense à Nils Ratusznik, je crois qu'il a raté le principal.
Le support de RHEL a plusieurs niveaux. Au début il y a un support complet (correctifs de sécurité, correctifs de bug, ajout de nouveaux drivers, ajout de nouvelles fonctionnalités, etc). A la fin il y a seulement les correctifs de sécurité.
Pour RHEL 4 et RHEL 5, Red Hat a décidé d'allonger d'un an le support complet (d'où RHEL 4.7 et 4.8).
Donc RHEL 6 sortira bien plus de deux ans après RHEL 5. Les nouvelles versions majeurs seront plus rares mais elles seront supportées plus longtemps (Red Hat s'engage à supporter au moins 7 ans chaques distributions).

Ceci montre que Red Hat est très à l'écoute de ses clients entreprises. Red Hat ne sort pas de version majeur de distribution s'il n'y a pas un fort besoin. Ceci a le mérite de réduire les coûts pour les entreprises (les migrations sont toujours très coûteuses pour un système critique : tests, adaptations, etc).

Ceci montre aussi la maturité de GNU/Linux. GNU/Linux répond aujourd'hui a la majortié des besoins des entreprises (du moins pour le serveur) et il n'est plus indispensable de chercher à mettre à disposition des entreprises les dernières évolutions technologiques du libre.

Alors que Red Hat sort une nouvelle distribution majeure "lorsque c'est nécessaire", Ubuntu a déjà annoncé que la prochaine LTS sortira en avril 2010...

Deux approches différentes. Ubuntu veut créer des opportunités à de nouveaux partenaires, Red Hat veut soigné ses clients actuels et leurs investissements.

Toi et le logiciel LIBRE, ça fait deux.

Prend Java, certe la situation n'est pas idéal, mais des membres de Red Hat et gcj participe. Ils ont l'information dès qu'elle est dispo. Ils peuvent participer à l'évolution. C'est n'est plus un team fermé de Sun qui définit Java, c'est tout le monde. Tout ceux qui veulent/peuvent participer et tout le monde et sur le même pied d'égalité.

Pour C#, ce n'est pas compliqué, c'est MS et que MS.

Tout est dans le titre.

Où sont ceux qui disaient que la justice américaine et ses jury sont du n'importe quoi ?

> Ca fait bizzare quand la fenêtre de VLC se redimensionne toute seule

Idem pour mplayer
Exemple avec ARTE (tnt) :
[PP] Using external postprocessing filter, max q = 6.
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
VO: [xv] 720x576 => 768x576 Planar YV12
VDec: vo config request - 720 x 576 (preferred colorspace: Planar YV12)
[PP] Using external postprocessing filter, max q = 6.
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [xv] 720x576 => 1024x576 Planar YV12

Même DirectShow le fait...

> Vive le 16/9

Et dire qu'un géni comme Kubrick a fait des films en 4:3 ou 1,67 ou...
Je sens que dans quelques années on va redécouvrir les mérites du cadrage en 4:3.
Le 16:9 n'est pas mieux que le 4:3 (et vice versa).

> Comment tu rogne légèrement sur les coté avec ta TV ou décodeur tnt ?

C'est à l'émission de la télé que c'est fait. C'est France 2 qui le fait par exemple. Pour le herzien (beaucoup de télé en 4:3) France 2 rogne. Pour la TNT, France 2 passe en 4:3 ou 16:9 en fonction de l'émission/film. Les décodeurs TNT gèrent ça.
Je n'en suis pas absolument sûr pour France 2, mais TF1 passe du 4:3 et du 16:9 sur la TNT (idem pour ARTE et M6).