Reprise du message précédent :
Il y a un noyau lts sur [core]:
 
core/kernel26-lts 2.6.27.43-1
    The Linux Kernel and modules - stable longtime supported kernel package    suitable for servers

Hum, il y a un noyau LTS et il suffirait de bloquer les mises à jour de certains paquets.
 
Edit: Grillé.  

OK pour le kernel, mais bon, un OS c''est un ecosystème, pas uniquement un kernel. Et même en bloquant les MAJ, ça veut dire que tu fais les MAJ de sécurité sans forcément les isoler des MAJ fonctionnelles potentiellement instable, par exemple dans le cas d'un serveur (web ou autre). Bref, kernel LTS ou pas, j'ai l'impression que c'est une fausse bonne idée quelque soit l'approche. Et pourtant j'aime cette distrib.

Rien que pour moi qui fait un peu de dev Web sur mon desktop, c'est un peu la merde lorsque Apache ou PHP sont mis à jour avec des modifs parfois bien lourdes qui me font sauter mes scripts parce que des paramètres bougent dans les fichiers de conf.

dépôte bien la dernière shakra live sur usb
Mais je ne pige rien à shaman, pas moyen d'installer un paquet pour mon wifi, iwlwifi-5000-ucode, il se viande dans la mise à jour
goto dodo, verra plus tard.

C'est quelque chose que j'ai déjà remarqué : Shaman se plante parfois là où pacman passe sans soucis. J'ai l'impression que tous les cas de figure ne sont pas implémentés dans Shaman et que du coup, quand il arrive sur un cas non traité, il se fige (en lockant la base de paquets au passage ). Je suis repassé à pacman en CLI pour ça, je ne fais que mes recherches de paquets avec Shaman, sa présentation graphique m'étant bien plus claire.

Utiliser Arch en serveur c'est faire les mises à jours comme pour le desktop, le kernel LTS est simplement là pour diminuer la fréquence des reboot et pour plus de sécurité.
 
Personnellement je distinguerais 3 cas :
- un seul serveur à faible fréquentation, rebooter de temps en temps est tout à fait envisageable. À part cette vieille bouse de SMTP il n'y a pas vraiment de problème à être arrêté quelques minutes tous les mois par exemple ;
- plusieurs serveurs, tu peux les redémarrer un par un sans interrompre le service, pas de problème de ce côté là ;
- un seul serveur mais tu ne peux pas te permettre une interruption de service même pour quelques minutes, ici tu pourras éventuellement préférer une Debian ou même un BSD.

Le problème c'est plutôt que de temps en temps, une MAJ fout la merde. Quand c'est sur un desktop, on considère qu'on peut vivre sans telle ou telle chose pendant un ou deux jours le temps que le bug soit corrigé et diffusé. Sur un serveur, c'est autre chose. Certaines MAJ arrivent très vite dans Arch, même avec la phase testing, et parfois ça casse, ce qui est inadmissible pour un serveur ou en tout cas pas sous la forme de Arch à mon sens.
Autant que c'est limite inadmissible d'attendre deux ans pour avoir les MAJ d'un soft lorsqu'on utilise son poste en desktop avec Debian stable, d'où les branches testing, Sid et experimental.

 
C'est déjà le cas il me semble, lire la fin du 1st post    
 

 
Oui par contre celle-là je l'avais oubliée    
 

 
CTKArchLive, déjà présente dans le mighty 1st post    
 

 
Pareil, ayatollah de Arch inside, mais jamais pour du serveur.
 
Une branche stable de Arch, ça serait    
Mais si ça vient un jour, à mon avis ça arrivera par la communauté, du côté devs officiels ça n'a pas du tout l'air d'être dans les plans, même à long terme.
 
 

 
+1
 

 
+1, même si ça casse relativement peu souvent quand même, et si ça casse c'est que tu mets à jour le système, donc que tu es dispo pour réparer à ce moment là.  
Et normalement, avant de mettre à jour les gros trucs, on se renseigne sur les régressions éventuelles    
 
Mais sinon je suis d'accord, un serveur pour moi ça doit plutôt tourner sur de l'éprouvé qui bouge peu.

Un serveur sur internet c'est OpenBSD et rien d'autre.
Un serveur hors ligne qui a besoin de stabilite c'est Debian stable.
 
Donc forcement aucun interet pour Arch ou autre la.

Yes: Grace au mighty bug reportz de votre The_Katz, mplayer est now fourni avec vdpau support par défaut  

et pour les autres chipsets ? Ah oui c'est vrai, y a pas encore de décodage matériel suppporté

Sur un serveur tu installes beaucoup moins de trucs or ce qui casse le plus souvent c'est tout ce qui est en rapport avec la couche graphique ou avec le matériel.
 

L'intérêt que j'y vois c'est que je connais bien Arch or on travaille mieux avec ce qu'on connait.

Toujours est-il que l'étiquette hyper-réactive de Arch, qui induit un temps de test et un recul très court s'accommode très mal des règles de base de gestion d'un serveur de production. D'où des distribution rock stable telles que Debian stable qui a toujours trois ans de retard (me brûlez pas, j'exagère volontairement) mais ne compte qu'un nombre infime de bug.

Se former sur une distribution quand on connait déjà l'environnement Linux au sens large, c'est pas grand chose, et chaque distrib possède une communauté qui permet de s'en sortir très bien. La preuve, je suis passé de Debian à Arch sans aucun souci, juste avec le Guide du débutant, le Wiki et ce topic.

Idem, mais rien qu'imaginer une distro stable avec la conf et le système de paquets de Arch ...

Ah ben ça on est bien d'accord, mais ça viendra avec la création d'une nouvelle branche de Arch et pas avec des bidouilles sur l'actuel fonctionnement AMHA.

ya un projet de arch stable sur le forum officiel

Tu parles de ça ?
http://bbs.archlinux.org/viewtopic [...] =82423&p=1
http://www.archserver.org/

donc l'ajout de libs par défaut inutile pour les gens de disposant pas des cartes graphiques adéquates en somme ?

Mais clair ! Et on devrait aussi fournir un noyau par défaut aussi minimal que possible, tous ces drivers sont d'une telle inutilité pour le pékin moyen

Bah ça utilise soit le vdpau des drivers nvidia soit libvdpau, et ça marchera sur les autres cartes ... bah quand les autres constructeurs seront décidés a se sortir les doigts hein

non, pas "par défaut", pour compiler as-is tu as besoin de libvdpau effectivement, mais après ça reste une dépendance optionnelle selon que tu puisse/souhaite utiliser la sortie "vdpau" dans mplayer

Après si tu ne l'utilise pas, tu peux absolument te passer des drivers nvidia ou de libvdpau, mais le but est/était  que à l'install de mplayer le vdpau soit immédiatement séléctionnable pour les systemes compatibles.
Après tu l'utilise ou pas, comme la sortie opengl ou libcaca, rien n'est imposé

Et un interface graphique à Mplayer, y'a moyen ?
Je ne parles pas de [k,s]mplayer, hein. Mais de gmplayer.
---
Ni de mplayer-x : déprécié et ne se compile pas.

Ca arrive pour quand cette version alors ? link/source ?

il est possible de sélectionner la sortie vdpau dans gnome-mplayer

uniquement si mplayer est compilé avec le flag --enable-vdpau, ce qui n'était pas le cas jusqu'a présent et qui obligeait a modifier puis a compiler mplayer à la main

Gnome-player ne m'intéresse pas.

mplayer 30286-1 : http://www.archlinux.org/packages/ [...] 6/mplayer/
ftp://ftp.free.fr/mirrors/ftp.arc [...] pkg.tar.gz
 
Qqch comme ça

Ah tiens, plus moyen de monter ma clef usb. Je me prend une erreur à la con -_-
Ca marche à la fac (ubuntu) et sur le portable de ma compagne (Arch aussi).
La différence la plus évidente : j'ai fait un pacman-Syu il y a quelques heures (nouvelle kernouille, entre autres). Pas encore redémarré.

C'est normal alors
ça m'est arrivé aussi, ça tente de charger le module pour le materiel pour le kernel en cours  (donc la v -1 du dernier installé) et ça ne le trouve donc pas.
Dans dmesg tu dois avoir un "failed to find /modules/kernel_v(-1)/usbstor.so" ou un truc dans ce genre
Reboot et "it's works"

Arch Linux Mag' de Janvier    
 
http://ghost1227.com/newsletter/ALM-2010-Jan.pdf

J'espère que c'est bien ça. Moi, j'ai ça :

logiquement si mplayer est compilé avec le support vdpau, au moins la lib vdpau sera installé lors de l'installation de mplayer donc une lib supplémentaire pour rien au final

Non, c'est une dépendance optionelle apparement, qui certes est forcément obligatoire si tu veux utiliser la sortie vdpau

 
J'ai aucune dépendance optionnelle pour Mplayer de mon coté…

Honnètement ça ne me choque pas du tout : quand on voit que libcaca était déjà en dépendance, je ne vois pas pourquoi on se passerait de libvdpau qui apporte une fonctionnalité un tantinet plus utile

Certes, elle ne concerne pas tout le monde, mais finalement c'est un peu le cas de toutes les fonctionnalités, il faut bien à un moment décider arbitrairement lesquelles sont présentes par défaut.

VLC 1.1 : vers un meilleur support des GPU d'AMD pour la HD

 
Je n'ai pas Arch sous la main et j'ai une question: la bibli xvba est bien dispo non?

Pour ceux que ça intéresse Archlinux devrait aussi être disponible sur les RPS après la phase de test sur les dédiés.

si la lib est linké sur ton binaire, tu vas obligatoirement avoir besoin d'elle que tu utilises vdpau ou non.
Le plus simple pour le vérifier serait de faire un ldd sur le binaire de mplayer.
Je sais que je chipote un peu là car le poids de la lib est tout a fait superficielle, mais c'était pour illustrer le fait qu'une bonne idée initiale d'options de compilations peut entrainer des dépendances parfois non anodines (sans parler des erreurs de packaging où là des libs/binaires mal placés vont tirer x libraires...)

exact tu as raison
mon erreur à été que pendant les MAJ sur mes autres pc ( n'ayant je croyais pas la lib vdpau, ni nvidia) il ne me l'avais semble t'il pas demandé en dépendance. De ce fait j'ai pensé que c'était une dep optionelle tout bêtement

edit: effectivement, la lib vdpau est déja en dépendance depuis longtemps sur ffmpeg et le set gstreamer-bad entre autres, et donc installée sans que j'y fasse attention depuis un moment

Pour ceux qui recherch(ai)ent des live usb, il y a aussi Faunos (www.faunos.com).
Même si elle n'est plus active, il est toujours possible de l'upgrader et de s'en servir en live persistent (ou non, au choix).
Pour ceux qui doivent démarrer sur CD avant de passer sur la clé, j'ai expliqué la procédure ici (à adapter à votre cas) : http://forums.archlinux.fr/post21147.html#p21147