Bonjour,
J'utilise en plus d'une Gentoo, une Debian Etch en stable (pléonasme? je ne me retrouve jamais dans ces branches :/ ).
Sous Debian, j'ai mis un noyau à la vanille (mmh) en 2.6.26 configuré aux ptits... chocolats (car l'oignon c'est assez moyen :) ).
Donc, dans le noyau, je n'ai pas activé l'option présentée comme dépréciée concernant l'ACPI et sa gestion des événements.
Qu'est-ce que cela implique? Et bien, sur un ordi portable c'est assez problématiquefâcheuxennuyeux en terme... d'utilisation disons, les petits utilitaires - "applets" - habituelles continuent* à converser avec /proc/acpi/event alors que le support tend à être abandonné.
Je n'ai donc pas le support des touches multimédias, pour la gestion de la luminosité je dois y aller à la main, idem pour la gestion d'énergie.
En gros, tout ce blablah pour avoir la réponse à : Que faire?
Changé de branche? Plan bidouille?
Voilà, merci
*fatalement, vu que j'utilise une distro basée sur l'ancienne gestion avec un noyau récent
Forum Linux.debian/ubuntu Utiliser /sys pour la gestion d'énergie/événement?
25
oct.
2008
# Pour une version récente du noyau
Posté par NickNolte . Évalué à 1.
Sinon, je suis relativement un ancien-nouveau (!sic) sous Debian, j'aimerais en savoir un peu plus sur ce qu'implique d'utiliser une branche un peu plus "à jour" au quotidien.
Je ne veux pas être à "la page" nécessairement, mais j'aimerais juste avoir une chose fonctionnelle jusqu'aux ongles.
Ce qui serait possible avec une distro post-2.6.26.
merci
[^] # Re: Pour une version récente du noyau
Posté par NickNolte . Évalué à 1.
Tout simplement à cause du pilote - libre malgré tout - pour mon périfèrique WiFi.s/périfèrique/périphérique/g
Je me disais bien qu'il y avait un soucis lorsque j'écrivais ce mot.
[^] # Re: Pour une version récente du noyau
Posté par Aefron . Évalué à 4.
Les touches multimedia, je n'en sais rien, mais pour la gestion de la luminosité, sur mon laptop (Vaio), c'est inclus dans le noyau binaire (sonypy, ou quelque chose comme ça), et je gère ça via KPowerSave (et ça marche bien). Itout pour la gestion d'énergie.
Quand je suis passé de Gentoo à Etch, je compilais moi aussi mes noyaux aux oignons, mais finalement, j'en suis venu à utiliser les noyaux binaires de Debian, que je trouve personnellement très bien : je n'ai pas compilé un noyau depuis bien un an et demi (enfin, si, pour inclure des patches trouvés sur l'interface de bugreport de Debian, mais en ne changeant rien d'autre aux sources du paquet, car ça ne m'a jamais été nécessaire).
Je boote un peu plus lentement, à la limite... certes, certes. Mais c'est toujours ça de moins à maintenir moi-même.
> Sinon, je suis relativement un ancien-nouveau (!sic) sous Debian, j'aimerais en savoir un peu plus sur ce qu'implique d'utiliser une branche un peu plus "à jour" au quotidien.
Pour Testing, davantage de mises à jour (pas seulement des mises à jour de sécu - c'est du "rolling-release"... bon, vu qu'en ce moment elle est gelée pour devenir la prochaine Stable, c'est très calme), et quelques bugs (comme un grub qui ne démarre plus, ce qui a été le seul truc à vraiment m'ennuyer cette année, même si ça ne m'a pas ennuyé plus de 5 minutes, un grand merci au live-cd minimal de Gentoo, dont je fais toujours grand usage) en prime.
Pour Sid, pareil, sauf que plus vite, et avec plus de bugs, plus rapidement corrigés. Il y a un délai de quarantaine entre Sid et testing (de 2 à 10 jours, selon la gravité du bug - si vraiment ça prend trop de temps, tu peux toujours formuler une requête pour réduire le délai de quarantaine, en envoyant un mail au sujet du bug ; l'issue de la requête dépendra du mainteneur, comme partout).
Maintenant, si tu sais trifouiller, sauf exception, tu ne devrais pas avoir de problèmes à te sortir tout seul des quelques panades.
Pour les paquets d'Experimental, là, par contre, ça porte généralement très bien son nom... j'en utilise de temps en temps (surtout en ce moment, avec Sid qui se concentre avant tout à préparer les mises à jour pour Lenny), mais surtout pour voir à quoi va ressembler le proche avenir - ça reste souvent à la limite (pas forcément du bon côté) de l'utilisable.
En comparant avec des distros ultra-bleeding-edge (chut-chut, pas de nom), j'en suis venu à avoir une règle très personnelle (qui n'engage donc que moi) : si ça n'est pas dans Debian Sid, ce n'est pas vraiment prêt à être utilisé.
> Je ne veux pas être à "la page" nécessairement, mais j'aimerais juste avoir une chose fonctionnelle jusqu'aux ongles.
Ce qui serait possible avec une distro post-2.6.26.
Si Sid est très instable (plusieurs dizaines de mises à jour par jour est courant), et Testing beaucoup moins (quelques mises à jour quotidiennes seulement), je suis de ceux qui pensent que les deux sont très fonctionnelles ; et oui, j'irais jusqu'à dire jusqu'au bout des ongles (à condition de savoir reconfigurer un petit truc par-ci-par-là de temps en temps, surtout pour Sid - j'utilise deux Sid, Workstation et Laptop, et une Testing, HTPC... plus plein de serveurs en Stable, ou Testing, si elle est gelée).
Les deux sont en 2.6.26, pour l'instant. Quand Squeeze (la prochaine "testing", et donc, l'après-prochaine stable) émergera, je pense qu'on verra très vite 2.6.27 dans Sid (si ce n'est pas déjà fait d'ici là), et peu après, dans Squeeze.
Sinon, pour les branches :
- Experimental : ultra-bleeding-edge, en constante ébullition, pour préparer l'intégration dans Unstable (pas tout le temps) ;
- Unstable : passage obligé pour l'intégration aux branches moins instables (instable signifie que les paquets ne sont pas figés à leur version actuelle - ça peut être instable, et pour autant, fiable - comme ça peut ne pas l'être) ; elle s'appelle toujours Sid ;
- Testing : "rolling-release" vers la prochaine stable - figé toutes les quelques années pour donner la prochaine stable ; son nom est habituellement décidé par le dictateur bienveillant qui s'en va avant qu'elle ne sorte ; l'actuelle est Lenny, et la prochaine, Squeeze ;
- Stable : les versions des paquets ne bougent plus, sauf pour les mises à jour de sécurité, ce qui vient des dépôts tagués "versatile" (anti-virus et cie) et le AndAHalf (depuis Etch, pour un nouveau noyau, et des choses du genre, seulement si l'on en a besoin) ; l'actuelle est Etch, la prochaine Lenny (puis suivra Squeeze, un moment après qu'elle soit figée) ;
- Old stable : l'ancienne stable, supportée un an après la sortie de la stable actuelle ; l'actuelle est Sarge (plus supportée), la prochaine est Etch.
Sinon, c'est quoi, ta carte wifi, pour avoir besoin d'un >2.6.26 ? Une Atheros à ath9k ? Il me semble que ce soit le seul modèle à être entré si récemment dans Vanilla (à part peut-être pour la dernière série de chips Intel, que je n'ai jamais encore vu en vrai), mais je peux me tromper...
[^] # Re: Pour une version récente du noyau
Posté par NickNolte . Évalué à 1.
Sinon, la "Testing", peu impore la version de Debian, elle s'appelle "Sid"? c'est cela?
Chaque branche ne porte pas un nom de personnages différents j'éspère!
Concernant ma puce WiFi, c'est une Atheros ar5007machintruc qui est malheureusement reconnue comme une ar5006machintruc et qui dés lors ne fonctionne pas.
J'ai fais l'acquisition de l'ordi qui en est équipé aux alentours de la sortie de la version 2.6.23 du noyau linux.
À cet époque, seul un ndiswrapper foireux pouvait me maintenir à flot.
Finalement, quelques temps après - assez court d'ailleurs - il eut finalement un support 64 bits dans le pilote venant de Madwifi, HAL n'était pas encore libre.
"Malheureusement", je dois toujours passer les sources externes au noyau, c'est de toute façon et ce depuis longtemps ma politique pour ce qui est du "son", "graphique", "wifi" , je compile toujours en "module".
C'est pour cette raison entre autre, que je n'utilise jamais le noyau d'une distros - déjà pour rappelle la version stable Etch est en 2.6.18 °_° - car il arrive toujours un moment où tu doives te farcir la besogne car le correctif n'est pas dispo dans la distro mais l'est dans le projet source, ou que tu doives passer par un pilotes proprios (puce graphique).
Enfin voilà, concernant mon soucis, j'ai activé l'option dans le noyau et joue encore avec l'ancien model, je n'ai pas trop envie de me farcir une migration de branche, même si tout n'est pas rose, car j'ai goûté à de chouettes trucs sur ma Gentoo, la version stable de Etch est ma foi, très très bien.
[^] # Re: Pour une version récente du noyau
Posté par Aefron . Évalué à 2.
La branche Testing s'appelle actuellement Lenny, et conservera son nom quand, comme chaque branche Testing, elle deviendra la branche Stable... ainsi qu'elle gardera son nom quand, comme chaque branche Stable, elle deviendra la branche Old-Stable. Elle gardera même son nom quand elle cessera d'être supportée (on ne va quand même pas se mettre à taguer les tombes, si ?).
Sinon, AR5007, c'est ath5k, le driver libre, normalement... je n'ai réussi à la faire marcher "correctement" qu'à partir d'un noyau 2.6.26, soit celui de Lenny... et encore, c'est seulement en client (pas de mode "point d'accès" avec ath5k pour l'heure), et il faut trifouiller un peu (j'avais d'ailleurs fait un journal [1] pour ça).
Et le fait que le driver ne soit pas encore parfait (le débit est un peu juste quand je mate la TV en direct via MythTV : systématiquement, quand il y a une dominante noire, genre un générique de fin, j'ai des saccades - pourquoi seulement lorsqu'il y a une dominante noire ? Je n'en sais rien, et ça me saoule...).
Autrement, dans quelques mois [2], Lenny devient la nouvelle Stable... et puisqu'elle est figée, on peut considérer qu'elle est dors-et-déjà à 99% stable. Bon, après, c'est à toi de voir : Etch sera supportée encore un an après que Lenny soit déclarée Stable.
Tu peux aussi tester un noyau AndAHalf [3], soit un 2.6.24 : ce n'est même pas du backport, ça fait partie de Etch.
Ou alors, un backport de 2.6.26 [4], moins officiel, mais inclus dans les dépôts quand même.
[1] http://linuxfr.org/~Aefron/27191.html
[2] http://linuxfr.org/poll/send,172.html
[3] http://packages.debian.org/search?suite=default§ion=(...)
[4] http://packages.debian.org/search?suite=etch-backports&a(...)
[^] # Re: Pour une version récente du noyau
Posté par Aefron . Évalué à 2.
Sous Gentoo, j'aimais bien compiler les modules en dur : ça me permettait de virer le support pour le chargement des modules à chaud, et ça enorgueillissait le parano en moi...
... mais bon, arrivé un moment, surtout avec le wifi, et certains truc qui ne peuvent plus toujours être compilés autrement qu'en module... ça et la flemme, je me suis calmé.
[^] # Re: Pour une version récente du noyau
Posté par NickNolte . Évalué à 1.
Merci
# acpi ?
Posté par bubar🦥 (Mastodon) . Évalué à 3.
regarde par là :
http://acpica.org
Cdlt
[^] # Re: acpi ?
Posté par NickNolte . Évalué à 1.
Tu ne mérites même pas que je gaspille de mon aura à te moinsser. :p
[^] # Re: acpi ?
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Peux tu expliquer un peu, pointer des liens, plutôt que ton simple "ridicule" ?
[^] # Re: acpi ?
Posté par NickNolte . Évalué à 1.
Je me pose, dés l'origine de mon fil, en temps que simple utilisateur et non programmeur, qu'est-ce tu veux que je fasse d'un site qui présente les spécifications ACPI à des fins d'implémentation?
Un lien?
Plutôt, une citation du site:
Welcome to acpica.org, a web site for ACPICA developers, where the ACPICA source is distributed. You are invited to contribute to the discussion on our mailing list.[^] # Re: acpi ?
Posté par bubar🦥 (Mastodon) . Évalué à 3.
hum, excuse moi.
Cdlt
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.