Si nous voulons comparer les différents OS grand public (Windows Linux
MacOS) il faut les comparer sur les différents points qui intéressent
les gens. A savoir le système d'exploitation, la logithèque,
l'installation de ladite logithèque, le jeu, la pérénité de la machine
et la sécurité.
Système d'exploitation (gestion du hardware et IHM)
- Windows : gère un grand nombre de matériel (directement out of the box
ou avec des drivers supplémentaires). L'IHM est agréable mais faiblement
configurable. Les options avancées sont très difficiles à atteindre et
très peu documentées. Le système est monolithique et dispose d'un
héritage du passé assez lourd à porter. Aujourd'hui encore, un problème
sur un logiciel peut compromettre tout le SE.
- Linux : gère un grand nombre de matériel (out of the box). Le matériel
non supporté d'origine est assez difficile à supporter a posteriori
(sauf en ce qui concerne les cartes NVIDIA à cause du driver
propriétaire non inclus en standard). L'IHM est agréable (KDE, Gnome,
...), hautement configurable et peut être remplacé par une autre
facilement. Les fonctions avancées sont accessibles au minimum en CLI et
très bien documentées.
- MacOS : gère 100% du matériel Apple (facile évidemment) et de nombreux
périphériques soit out of the box ou via les drivers du fabricant. L'IHM
est, à mon sens, la plus aboutie mais est très peu configurable. Les
fonctions avancées sont disponibles en ligne de commande mais très peu
documentée.
Logithèque
- Windows : abondante. Certains logiciels métiers ne sont disponibles
que sur cet OS.
- Linux : abondante mais la plupart des logiciels métiers ne sont pas
portés nativement. Soit il existe un pendant open source (reprennant
l'essentiel mais pas les spécificités), soit il est possible de le faire
tourner via Wine, soit il n'y a pas de solutions.
- MacOS : abondante. Certains logiciels non disponibles sous Linux le
sont sous MacOS (exemple la suite Adobe, ...). Il est également possible
de nombreux logiciels disponibles sous Linux via Fink ou MacPorts.
Installation de la Logithèque
- Windows : de nombreux supports (CD, DVD, téléchargement, Windows
Update, ...). De nombreuses méthodes aussi. La désinstallation pose
souvent problème (vestige des logiciels installés, ...). Je dirais que
c'est assez brouillon.
- Linux : généralement tout passe par le gestionnaire de paquets. Le
système est assez souple et gère les dépendances. La désinstallation est
presque toujours parfaite. Il est également possible de se passer du
gestionnaire de paquets mais alors on en perd les avantages
(installation à partir des sources, ...).
- MacOS : pour les applications natives, généralement tout se passe en
glisser/déposer. Pour les sources, elles sont aussi nombreuses que sous
Windows. La désinstallation se fait également par glisser/déposer. Pour
les softs sous Macports/Fink le système est moins bon que sous Linux.
Le jeu
- Windows : tout les gros jeux sortent sous Windows. Sur PC, Windows est
l'OS disposant du plus de jeux.
- Linux : une partie des jeux (faibles mais reprenant quelques gros hits
quand même) sortent nativement. Une partie fonctionne avec Wine. Une
partie ne fonctionne pas sous Linux.
- MacOS : même chose que sous Linux avec un peu plus de portages directes.
Pérénité
- Windows : gros soucis sur un windows utilisé longtemps et sur lequel
de nombreuses installations/désinstallations ont eu lieu. Toutefois, un
Windows installé proprement et sur lequel on installe juste ses
logiciels une seule fois est pérène depuis Windows 2000. Toutefois cela
empêche de passer sereinement de Office 2003 à 2007 par exemple. Par
contre les mises à jour installées ne génèrent en général pas de
problème. Une mise à jour de l'OS vers une version suivante (2000 -> XP
ou XP -> Vista) ne se passe généralement pas très bien.
- Linux : aucun soucis quand on utilise des versions stables.
- MacOS : aucun soucis.
Sécurité
- Windows : le système monolithique et la gestion des droits
"particulière" de Windows le rende assez perméable out of the box.
Toutefois, un admin compétant peut le sécuriser convenablement.
- Linux : pas de soucis de sécurité.
- MacOS : pas de soucis de sécurité.
Pour les 3 OS, il est évident qu'ils ne sont pas 100% secure et que des
failles peuvent être trouvées (escalation de privilèges, ...).
Aucun OS ne peut se prévaloir de satisfaire 100% des besoins de tous les
utilisateurs. Chacun doit donc choisir son OS en fonction de ses besoins.
6 mois sur les 5 ans (et encore!) qu'a duré la game ST, c'est pas négligeable.
A+ JF
JKB
Le 17-10-2008, ? propos de Re: Windows/Linux tout ça, Eric Masson ?crivait dans fr.comp.os.linux.debats :
JKB writes:
'Lut,
La question est surtout : pourquoi laisser à la discrétion de l'OS ce qu'on peut faire simplement en hard ?
Euh, le suspend to disk des machines apm n'était pas du hard, mais une fonction du bios.
Oui, enfin, lorsque je disais hard, il fallait comprendre "indépendant du matériel".
Pour la migration de ces fonctions vers l'os, on peut entrevoir une raison économique, qui est la réduction des coûts de développement du hard.
Et des emmerdes avec certains matériels ou certains OS. Il est _impossible_ de régler le rétro-éclairage sur mon Toshiba P200 sans se taper en root des commandes du style echo 5 > /proc/omnibook/whatever. Jusqu'à preuve du contraire, l'écran doit êrte géré par une couche inférieure à l'OS, tout comme le suspend to ram. J'ai galéré avec eComStation sur ce genre de problème et franchement, l'ACPI et consorts, ce n'est pas une évolution.
L'acpi n'est pas en soit une mauvaise idée, il faudrait juste que les dsdt livrées par les fabricants de CM se conforment à la norme plutôt qu'être simplement "validées" par le le compilateur le plus naze du marché...
C'est encore un autre problème.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 17-10-2008, ? propos de
Re: Windows/Linux tout ça,
Eric Masson ?crivait dans fr.comp.os.linux.debats :
JKB <knatschke@koenigsberg.fr> writes:
'Lut,
La question est surtout : pourquoi laisser à la discrétion de l'OS
ce qu'on peut faire simplement en hard ?
Euh, le suspend to disk des machines apm n'était pas du hard, mais une
fonction du bios.
Oui, enfin, lorsque je disais hard, il fallait comprendre
"indépendant du matériel".
Pour la migration de ces fonctions vers l'os, on peut entrevoir une
raison économique, qui est la réduction des coûts de développement du
hard.
Et des emmerdes avec certains matériels ou certains OS. Il est
_impossible_ de régler le rétro-éclairage sur mon Toshiba P200 sans
se taper en root des commandes du style echo 5 >
/proc/omnibook/whatever. Jusqu'à preuve du contraire, l'écran doit
êrte géré par une couche inférieure à l'OS, tout comme le suspend to
ram. J'ai galéré avec eComStation sur ce genre de problème et
franchement, l'ACPI et consorts, ce n'est pas une évolution.
L'acpi n'est pas en soit une mauvaise idée, il faudrait juste que les
dsdt livrées par les fabricants de CM se conforment à la norme plutôt
qu'être simplement "validées" par le le compilateur le plus naze du
marché...
C'est encore un autre problème.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 17-10-2008, ? propos de Re: Windows/Linux tout ça, Eric Masson ?crivait dans fr.comp.os.linux.debats :
JKB writes:
'Lut,
La question est surtout : pourquoi laisser à la discrétion de l'OS ce qu'on peut faire simplement en hard ?
Euh, le suspend to disk des machines apm n'était pas du hard, mais une fonction du bios.
Oui, enfin, lorsque je disais hard, il fallait comprendre "indépendant du matériel".
Pour la migration de ces fonctions vers l'os, on peut entrevoir une raison économique, qui est la réduction des coûts de développement du hard.
Et des emmerdes avec certains matériels ou certains OS. Il est _impossible_ de régler le rétro-éclairage sur mon Toshiba P200 sans se taper en root des commandes du style echo 5 > /proc/omnibook/whatever. Jusqu'à preuve du contraire, l'écran doit êrte géré par une couche inférieure à l'OS, tout comme le suspend to ram. J'ai galéré avec eComStation sur ce genre de problème et franchement, l'ACPI et consorts, ce n'est pas une évolution.
L'acpi n'est pas en soit une mauvaise idée, il faudrait juste que les dsdt livrées par les fabricants de CM se conforment à la norme plutôt qu'être simplement "validées" par le le compilateur le plus naze du marché...
C'est encore un autre problème.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Kevin Denis
Le 17-10-2008, JKB a écrit :
Il suffit qu'il fonctionne sous Windows Mobile... Le problème n'en
^^^^^^^^^^^^^^ Si on sortait un peu du dualisme primaire linux/windows?
Pourquoi ?
Si linux ne faisait qu'être seulement mieux que windows, il n'irait pas loin. Je veux un _bon_ système. Pas seulement un système meilleur que windows.
Ok. Je caricature un peu alors. Linux est un gros veau incapable de booter dans un temps correct, alors il lui faut une béquille matérielle?
La question est surtout : pourquoi laisser à la discrétion de l'OS ce qu'on peut faire simplement en hard ?
L'unique réponse est le coût du hard. Aujourd'hui, ils suppriment même les boutons permettant de régler la luminosité des écrans et le réglage se fait en soft. Vieux lien: http://ddccontrol.sourceforge.net -- Kevin
Le 17-10-2008, JKB <knatschke@koenigsberg.fr> a écrit :
Il suffit qu'il fonctionne sous Windows Mobile... Le problème n'en
^^^^^^^^^^^^^^
Si on sortait un peu du dualisme primaire linux/windows?
Pourquoi ?
Si linux ne faisait qu'être seulement mieux que windows, il n'irait
pas loin. Je veux un _bon_ système. Pas seulement un système meilleur
que windows.
Ok. Je caricature un peu alors. Linux est un gros veau incapable de booter
dans un temps correct, alors il lui faut une béquille matérielle?
La question est surtout : pourquoi laisser à la discrétion de l'OS
ce qu'on peut faire simplement en hard ?
L'unique réponse est le coût du hard.
Aujourd'hui, ils suppriment même les boutons permettant de régler la
luminosité des écrans et le réglage se fait en soft.
Vieux lien: http://ddccontrol.sourceforge.net
--
Kevin
Il suffit qu'il fonctionne sous Windows Mobile... Le problème n'en
^^^^^^^^^^^^^^ Si on sortait un peu du dualisme primaire linux/windows?
Pourquoi ?
Si linux ne faisait qu'être seulement mieux que windows, il n'irait pas loin. Je veux un _bon_ système. Pas seulement un système meilleur que windows.
Ok. Je caricature un peu alors. Linux est un gros veau incapable de booter dans un temps correct, alors il lui faut une béquille matérielle?
La question est surtout : pourquoi laisser à la discrétion de l'OS ce qu'on peut faire simplement en hard ?
L'unique réponse est le coût du hard. Aujourd'hui, ils suppriment même les boutons permettant de régler la luminosité des écrans et le réglage se fait en soft. Vieux lien: http://ddccontrol.sourceforge.net -- Kevin
Toxico Nimbus
etourmi a écrit :
sans parler de l'image d'un os d'amiga qui démarrerait en 4 secondes qui est bien marrante.. je vois mal comment un amiga peut lire une image stockée sur une disquette en 4 secondes
Non, sur un disque dur. Sinon, la commande pour démarrer le Workbench tient sur le secteur de démarrage d'une disquette.
etourmi a écrit :
sans parler de l'image d'un os d'amiga qui démarrerait en 4 secondes qui est
bien marrante.. je vois mal comment un amiga peut lire une image stockée sur
une disquette en 4 secondes
Non, sur un disque dur. Sinon, la commande pour démarrer le Workbench
tient sur le secteur de démarrage d'une disquette.
sans parler de l'image d'un os d'amiga qui démarrerait en 4 secondes qui est bien marrante.. je vois mal comment un amiga peut lire une image stockée sur une disquette en 4 secondes
Non, sur un disque dur. Sinon, la commande pour démarrer le Workbench tient sur le secteur de démarrage d'une disquette.
Toxico Nimbus wrote:
Non, sur un disque dur. Sinon, la commande pour démarrer le Workbench tient sur le secteur de démarrage d'une disquette.
oui donc sur les amiga de fin de vie et ni sur les 500 et 1000 qui representaient la grande majorite du parc amiga le grand public amiga n'avait pas de hd donc parler d'un boot de 4s sur amiga en omettant que c'est a partir d'une image et a l'aide d'un disque dur, c'est faire de la desinformation
Toxico Nimbus wrote:
Non, sur un disque dur. Sinon, la commande pour démarrer le Workbench
tient sur le secteur de démarrage d'une disquette.
oui donc sur les amiga de fin de vie et ni sur les 500 et 1000 qui
representaient la grande majorite du parc amiga
le grand public amiga n'avait pas de hd
donc parler d'un boot de 4s sur amiga en omettant que c'est a partir d'une
image et a l'aide d'un disque dur, c'est faire de la desinformation
Non, sur un disque dur. Sinon, la commande pour démarrer le Workbench tient sur le secteur de démarrage d'une disquette.
oui donc sur les amiga de fin de vie et ni sur les 500 et 1000 qui representaient la grande majorite du parc amiga le grand public amiga n'avait pas de hd donc parler d'un boot de 4s sur amiga en omettant que c'est a partir d'une image et a l'aide d'un disque dur, c'est faire de la desinformation
Stéphane CARPENTIER
<etourmi> wrote:
apprends déjà à configurer ton client de news pour avoir un charset correct
Son charset est correct. Si ton lecteur est trop naze pour le lire, ce n'est pas ici qu'il faut te plaindre.
-- Stéphane
Pour me répondre, traduire gratuit en anglais et virer le .invalid. http://stef.carpentier.free.fr/
<etourmi> wrote:
apprends déjà à configurer ton
client de news pour avoir un charset correct
Son charset est correct. Si ton lecteur est trop naze pour le lire, ce n'est
pas ici qu'il faut te plaindre.
--
Stéphane
Pour me répondre, traduire gratuit en anglais et virer le .invalid.
http://stef.carpentier.free.fr/
apprends déjà à configurer ton client de news pour avoir un charset correct
Son charset est correct. Si ton lecteur est trop naze pour le lire, ce n'est pas ici qu'il faut te plaindre.
-- Stéphane
Pour me répondre, traduire gratuit en anglais et virer le .invalid. http://stef.carpentier.free.fr/
Stéphane CARPENTIER
Pale Frenier wrote:
Kevin Denis wrote:
> Il y a quelques projets en ce moment qui tentent d'accélerer tout ça, > comme le "one second X" dont le but est aisement compréhensible, ou > le 5s boot. http://www.youtube.com/watch?v=s7NxCM8ryF8 (oui, > c'est _très_ rapide).
J'avoue ne pas très bien voir, dans mon utilisation de l'informatique, l'utilité de ces projets.
Mais comme on dit, il doit bien y avoir des gens que ça démangent, sinon personne ne bosserait dessus.
Tu as des gens dont l'ordinateur est allumé 24 heures sur 24. Pour d'autres, il n'est allumé qu'à la demande. Si tu as besoin de 5 minutes pour lancer l'ordinateur, l'utiliser une minute puis l'éteindre, tu risques de ne pas l'utiliser dans ce cas précis.
-- Stéphane
Pour me répondre, traduire gratuit en anglais et virer le .invalid. http://stef.carpentier.free.fr/
Pale Frenier wrote:
Kevin Denis wrote:
> Il y a quelques projets en ce moment qui tentent d'accélerer tout ça,
> comme le "one second X" dont le but est aisement compréhensible, ou
> le 5s boot. http://www.youtube.com/watch?v=s7NxCM8ryF8 (oui,
> c'est _très_ rapide).
J'avoue ne pas très bien voir, dans mon utilisation de l'informatique,
l'utilité de ces projets.
Mais comme on dit, il doit bien y avoir des gens que ça démangent, sinon
personne ne bosserait dessus.
Tu as des gens dont l'ordinateur est allumé 24 heures sur 24. Pour d'autres,
il n'est allumé qu'à la demande. Si tu as besoin de 5 minutes pour lancer
l'ordinateur, l'utiliser une minute puis l'éteindre, tu risques de ne pas
l'utiliser dans ce cas précis.
--
Stéphane
Pour me répondre, traduire gratuit en anglais et virer le .invalid.
http://stef.carpentier.free.fr/
> Il y a quelques projets en ce moment qui tentent d'accélerer tout ça, > comme le "one second X" dont le but est aisement compréhensible, ou > le 5s boot. http://www.youtube.com/watch?v=s7NxCM8ryF8 (oui, > c'est _très_ rapide).
J'avoue ne pas très bien voir, dans mon utilisation de l'informatique, l'utilité de ces projets.
Mais comme on dit, il doit bien y avoir des gens que ça démangent, sinon personne ne bosserait dessus.
Tu as des gens dont l'ordinateur est allumé 24 heures sur 24. Pour d'autres, il n'est allumé qu'à la demande. Si tu as besoin de 5 minutes pour lancer l'ordinateur, l'utiliser une minute puis l'éteindre, tu risques de ne pas l'utiliser dans ce cas précis.
-- Stéphane
Pour me répondre, traduire gratuit en anglais et virer le .invalid. http://stef.carpentier.free.fr/
Samuel Colin
Dixit Kevin Denis :
Le 16-10-2008, JKB a écrit :
est pas un. Dans un tel système, on devrait avoir un système style le "suspend to ram" des vieux Toshiba. J'avais ça sur mon PII/333 (un 4060 XCDT) et il mettait un dixième de seconde à être utilisable.
Ok. Je caricature un peu alors. Linux est un gros veau incapable de booter dans un temps correct, alors il lui faut une béquille matérielle?
Rebooter à chaque usage un eeePC me semble une ineptie.
Et pourquoi donc? Parceque l'eeepc met longtemps à démarrer? Le laisser en veille mange de l'énergie. S'il bootait effectivement en 5s, la question d'un suspend to RAM ne se poserait pas.
Je sors de mon lurkage habituel pour mentionner ce lien: http://lwn.net/Articles/299483/ (en anglais) qui indique qu'en bidouillant un peu (bon, plus qu'un peu) le noyau et init il est possible de booter en 5 secondes. Et je retourne à mon lurkage.
Dixit Kevin Denis :
Le 16-10-2008, JKB <knatschke@koenigsberg.fr> a écrit :
est pas un. Dans un tel système, on devrait avoir un système style
le "suspend to ram" des vieux Toshiba. J'avais ça sur mon PII/333
(un 4060 XCDT) et il mettait un dixième de seconde à être
utilisable.
Ok. Je caricature un peu alors. Linux est un gros veau incapable de booter
dans un temps correct, alors il lui faut une béquille matérielle?
Rebooter à chaque usage un eeePC me semble une ineptie.
Et pourquoi donc? Parceque l'eeepc met longtemps à démarrer?
Le laisser en veille mange de l'énergie. S'il bootait effectivement en
5s, la question d'un suspend to RAM ne se poserait pas.
Je sors de mon lurkage habituel pour mentionner ce lien:
http://lwn.net/Articles/299483/
(en anglais) qui indique qu'en bidouillant un peu (bon, plus qu'un peu)
le noyau et init il est possible de booter en 5 secondes.
Et je retourne à mon lurkage.
est pas un. Dans un tel système, on devrait avoir un système style le "suspend to ram" des vieux Toshiba. J'avais ça sur mon PII/333 (un 4060 XCDT) et il mettait un dixième de seconde à être utilisable.
Ok. Je caricature un peu alors. Linux est un gros veau incapable de booter dans un temps correct, alors il lui faut une béquille matérielle?
Rebooter à chaque usage un eeePC me semble une ineptie.
Et pourquoi donc? Parceque l'eeepc met longtemps à démarrer? Le laisser en veille mange de l'énergie. S'il bootait effectivement en 5s, la question d'un suspend to RAM ne se poserait pas.
Je sors de mon lurkage habituel pour mentionner ce lien: http://lwn.net/Articles/299483/ (en anglais) qui indique qu'en bidouillant un peu (bon, plus qu'un peu) le noyau et init il est possible de booter en 5 secondes. Et je retourne à mon lurkage.
Eric Masson
JKB writes:
Oui, enfin, lorsque je disais hard, il fallait comprendre "indépendant du matériel".
Euh, du soft, non ?
Et des emmerdes avec certains matériels ou certains OS.
Du fait de dsdt buggées ou d'absence de support d'une partie de celle-ci par l'os en question.
Il est _impossible_ de régler le rétro-éclairage sur mon Toshiba P200 sans se taper en root des commandes du style echo 5 > /proc/omnibook/whatever. Jusqu'à preuve du contraire, l'écran doit être géré par une couche inférieure à l'OS, tout comme le suspend to ram.
Mouaif, c'est quand même l'os qui est le plus à même de déterminer ce dont il a besoin comme ressources, et la possibilité de les activer désactiver directement au travers d'appel de methodes acpi est amha une approche qui se tient.
Ce qui est amha le plus dommageable, c'est que, comme d'hab, le boulot ait été fait à moitié avec des implémentations méchamment buggées, ce qui rend le taf des devs d'os libres un tantinet compliqué...
-- (fufe) Ca deconne, domage... votre service est vraiment super! J'arrive vraiment pas a envoyer ma candidature sur votre site: il me fait a chaque fois error, pourquoi? Il y a t'il une limite de chrcter? -+-JF - <http://www.le-gnu.net> - Souvent limité, jamais égalé -+-
JKB <knatschke@koenigsberg.fr> writes:
Oui, enfin, lorsque je disais hard, il fallait comprendre
"indépendant du matériel".
Euh, du soft, non ?
Et des emmerdes avec certains matériels ou certains OS.
Du fait de dsdt buggées ou d'absence de support d'une partie de celle-ci
par l'os en question.
Il est _impossible_ de régler le rétro-éclairage sur mon Toshiba
P200 sans se taper en root des commandes du style
echo 5 > /proc/omnibook/whatever.
Jusqu'à preuve du contraire, l'écran doit être géré par une
couche inférieure à l'OS, tout comme le suspend to ram.
Mouaif, c'est quand même l'os qui est le plus à même de déterminer ce
dont il a besoin comme ressources, et la possibilité de les activer
désactiver directement au travers d'appel de methodes acpi est amha une
approche qui se tient.
Ce qui est amha le plus dommageable, c'est que, comme d'hab, le boulot
ait été fait à moitié avec des implémentations méchamment buggées, ce
qui rend le taf des devs d'os libres un tantinet compliqué...
--
(fufe) Ca deconne, domage... votre service est vraiment super! J'arrive
vraiment pas a envoyer ma candidature sur votre site: il me fait a
chaque fois error, pourquoi? Il y a t'il une limite de chrcter?
-+-JF - <http://www.le-gnu.net> - Souvent limité, jamais égalé -+-
Oui, enfin, lorsque je disais hard, il fallait comprendre "indépendant du matériel".
Euh, du soft, non ?
Et des emmerdes avec certains matériels ou certains OS.
Du fait de dsdt buggées ou d'absence de support d'une partie de celle-ci par l'os en question.
Il est _impossible_ de régler le rétro-éclairage sur mon Toshiba P200 sans se taper en root des commandes du style echo 5 > /proc/omnibook/whatever. Jusqu'à preuve du contraire, l'écran doit être géré par une couche inférieure à l'OS, tout comme le suspend to ram.
Mouaif, c'est quand même l'os qui est le plus à même de déterminer ce dont il a besoin comme ressources, et la possibilité de les activer désactiver directement au travers d'appel de methodes acpi est amha une approche qui se tient.
Ce qui est amha le plus dommageable, c'est que, comme d'hab, le boulot ait été fait à moitié avec des implémentations méchamment buggées, ce qui rend le taf des devs d'os libres un tantinet compliqué...
-- (fufe) Ca deconne, domage... votre service est vraiment super! J'arrive vraiment pas a envoyer ma candidature sur votre site: il me fait a chaque fois error, pourquoi? Il y a t'il une limite de chrcter? -+-JF - <http://www.le-gnu.net> - Souvent limité, jamais égalé -+-
JKB
Le 17-10-2008, ? propos de Re: Windows/Linux tout ça, Eric Masson ?crivait dans fr.comp.os.linux.debats :
JKB writes:
Oui, enfin, lorsque je disais hard, il fallait comprendre "indépendant du matériel".
Euh, du soft, non ?
Euh oui, fatugué, toussa...
Et des emmerdes avec certains matériels ou certains OS.
Du fait de dsdt buggées ou d'absence de support d'une partie de celle-ci par l'os en question.
Il est _impossible_ de régler le rétro-éclairage sur mon Toshiba P200 sans se taper en root des commandes du style echo 5 > /proc/omnibook/whatever. Jusqu'à preuve du contraire, l'écran doit être géré par une couche inférieure à l'OS, tout comme le suspend to ram.
Mouaif, c'est quand même l'os qui est le plus à même de déterminer ce dont il a besoin comme ressources, et la possibilité de les activer désactiver directement au travers d'appel de methodes acpi est amha une approche qui se tient.
Ce qui est amha le plus dommageable, c'est que, comme d'hab, le boulot ait été fait à moitié avec des implémentations méchamment buggées, ce qui rend le taf des devs d'os libres un tantinet compliqué...
N'empêche que pour faire fonctionner un suspend2ram depuis un OS/2 des familles ou un Solaris, c'est aujourd'hui très compliqué, alors que sur mon vieux Toshiba, c'était réglé par le bios.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 17-10-2008, ? propos de
Re: Windows/Linux tout ça,
Eric Masson ?crivait dans fr.comp.os.linux.debats :
JKB <knatschke@koenigsberg.fr> writes:
Oui, enfin, lorsque je disais hard, il fallait comprendre
"indépendant du matériel".
Euh, du soft, non ?
Euh oui, fatugué, toussa...
Et des emmerdes avec certains matériels ou certains OS.
Du fait de dsdt buggées ou d'absence de support d'une partie de celle-ci
par l'os en question.
Il est _impossible_ de régler le rétro-éclairage sur mon Toshiba
P200 sans se taper en root des commandes du style
echo 5 > /proc/omnibook/whatever.
Jusqu'à preuve du contraire, l'écran doit être géré par une
couche inférieure à l'OS, tout comme le suspend to ram.
Mouaif, c'est quand même l'os qui est le plus à même de déterminer ce
dont il a besoin comme ressources, et la possibilité de les activer
désactiver directement au travers d'appel de methodes acpi est amha une
approche qui se tient.
Ce qui est amha le plus dommageable, c'est que, comme d'hab, le boulot
ait été fait à moitié avec des implémentations méchamment buggées, ce
qui rend le taf des devs d'os libres un tantinet compliqué...
N'empêche que pour faire fonctionner un suspend2ram depuis un OS/2
des familles ou un Solaris, c'est aujourd'hui très compliqué, alors
que sur mon vieux Toshiba, c'était réglé par le bios.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 17-10-2008, ? propos de Re: Windows/Linux tout ça, Eric Masson ?crivait dans fr.comp.os.linux.debats :
JKB writes:
Oui, enfin, lorsque je disais hard, il fallait comprendre "indépendant du matériel".
Euh, du soft, non ?
Euh oui, fatugué, toussa...
Et des emmerdes avec certains matériels ou certains OS.
Du fait de dsdt buggées ou d'absence de support d'une partie de celle-ci par l'os en question.
Il est _impossible_ de régler le rétro-éclairage sur mon Toshiba P200 sans se taper en root des commandes du style echo 5 > /proc/omnibook/whatever. Jusqu'à preuve du contraire, l'écran doit être géré par une couche inférieure à l'OS, tout comme le suspend to ram.
Mouaif, c'est quand même l'os qui est le plus à même de déterminer ce dont il a besoin comme ressources, et la possibilité de les activer désactiver directement au travers d'appel de methodes acpi est amha une approche qui se tient.
Ce qui est amha le plus dommageable, c'est que, comme d'hab, le boulot ait été fait à moitié avec des implémentations méchamment buggées, ce qui rend le taf des devs d'os libres un tantinet compliqué...
N'empêche que pour faire fonctionner un suspend2ram depuis un OS/2 des familles ou un Solaris, c'est aujourd'hui très compliqué, alors que sur mon vieux Toshiba, c'était réglé par le bios.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
