un_brice a écrit 1165 commentaires

C'est pas vraiment le sujet et le propriétaire c'est mal mais... est-ce que quelqu'un saurais s'il est possible d'executer des applications propriétaires OpenGL 32 bits avec un driver nVidia 64 bit ? Et si il y une couche de compatiblité disponible quelque part ?

Autre grande nouvelle ! Après vérification, il semble que l'on pourras enfin déclarer les tampons en lecture non executable !! (mode 2)
On dirais que les x86 reprennent un peu de leur retard !

Le truc qu'il faut se dire c'est que même si pour l'instant c'est pas le top (mauvais rapport qualité/prix) ils ont interêt à lancer la techno maintenant pour qu'elle soit réellement disponible pour le grand public quand les 4Gos montreront leurs limites (ça à déjà commencé), que les calculs de jeux vidéos se feront avec plus de précision, que l'espace disponible seras suffisant (pour compenser les pertes), que le bus système et le CPU auront du mal à gagner en frèquence (on a de plus en plus de mal à monter en frèquence semble-t'il, alors autant essayer de trouver d'autres moyens (cf les nouveaux x86 haut de gamme, qui ont la même frèquence mais plus de cache ou l'hyperthreading)).

D'ailleurs les doc du portage Debian sur Sparc 64bits indiquent que seul le noyau a vraiment besoin d'etre compilé pour 64bits le reste du système ne profitant pas d'un gain important par rapport a la perte de place.

J'ai un peu l'impression qu'il disent ça pour tout les CPUs depuis l'aparition du 386 ^.^ .

et arretez de sortir gentoo a tord et a travers. La debian est depuis bien plus longtemp portée sur de multiples architectures (au moins 10)

Le fait est que Gentoo est officiellement disponible pour am64 en version stable, au contraire de Debian (à ma connaissance).

De toutes manières, y'a deux sortes de gens: ceux qui pèsent le pour et le contre des mises à jours et ceux qui aiment optimiser.
Les permiers sont sous Debian et sont moins concernés que les seconds dans le cas présent ("nouvelle" architecture moins maitrisée qui procure un gain théorique et non évalué des performances).
Les seconds sont sous Gentoo (LFS?), et ils savent que cette distrib est faite pour eux. Et cette news auss -_^.

Si tu parle de la barre de menus en haut de l'écran, c'est pas neuf (mais plus facile à trouver), par contre je vois pas comment tu fait pour rendre la barre des taches transparente (à moins que ça ne consiste à afficher le burreau en fond de barre).
Je crois que le support réel de la transparence viendras avec QT4 non ? (ça seras KDE4 aussi?)

Tu peut lancer autant de serveur X que tu veut de burreaux diffèrent simultanément.
Et ça te permet même de mettre deux utilisateurs diffèrents sur deux écrans diffèrents d'une même machine !

À l'inverse l'export display marche depuis bien longtemps sous XFree, et on pouvait aussi redimensionner l'affichage, mais pas le bureau, ce que de toutes manières je ne fait pas et n'apprécie pas qu'un soft fasse (ni sous win, ni sous X) car ça fout le bordel dans mes icones.

C'est une fonction qui n'est utile que pendant l'installation initiale de la distrib. Et même quand bien on aurrait voulu le faire à un autre moment, la contrainte de relancer X n'est pas très importante.

Compression Video max theorique

Je sais que c'est pas vraiment le sujet mais... comment a-t'on fait pour obtenir ce nombre ?

Y'a pas une histoire comme quoi la LEN faisait sortir les échanges de courrier éléctonique du domaine de la correspondance privée ?

Le pédeuxpé c'est mal.

Enfin selon la taille de la partition

Oui car le système ne permet de gérer qu'un nombre limité de blocs, pour pouvoir accèder tout l'espace il a fallu les agrandir...
Et justement, je crois que sur les disques récents (>30Go), les blocs font 32ko.

mais que font les copines de geek ?!

Elle pleurent la distrib. Une copine de geek c'est forcément un peu geek.

Tu pense vraiment que le nom "Mandrake" est un plus ?
Je vois pas en quoi. A mon avis c'était Redhat (Mandrake en était juste un dérivé à la base) -> Chappeau -> Magicien.
C'est comme Debian, ils jouent avec des noms de Toystory, mais c'est pas ce truc en image de synthèse qui a fait leur réputation.

De toutes manières, Mandrake c'est des gentils. Alors tais toi.

Est ce que Disney a fait un procès à Debian pour nommer les distribs des noms des personnages de Toy Story

Ça pourrait arriver d'ailleurs non ?

D'ailleurs je crois que c'est l'OpenGroup qui détient la marque "Unix", pas SCO.
http://www.opengroup.org/(...)

j'ai bien peur que tout ça soit à peu près aussi coûteux que les changements de contexte user/kernel quand on utilise un process normal en mode user.

En fait ce que je propose ça serait des sortes de processus privilégiés, qui auraient la possibilité d'accéder au hardware mais n'utiliseraient pas la mémoire virtuelle et toutes ces choses, pour des raisons de performances.
Pour ce que je connais du système, et en supposant que les mécanismes hardware de protection mémoire soient suffisement flexibles, ça consisterait à mettre en place un espace "kernel", un "espace utilisateur", un espace "kernel bis" et un espace "utilisateur bis".
L'espace "kernel bis" serait l'espace kernel normal sauf que les mécanisme de protection mémoire seraient activé. L'espace "utilisateur bis" serait la partie de l'espace mémoire auquel les membres de "kernel bis" auraient accès.
En cas d'IRQ, au moment de choisir le handler, on activerais la protection mémoire suivant que l'appel est destiné à "kernel bis" ou non.
On perdrais quelque chose comme un cycle ou deux par appel système libres (tester un flag) et cinq cycles par appel système pas libre (tester le flag et activer la protection).

Je précise que les ordres de grandeur son le fruit de mon imagination, qu'il est 3:50 et que je ne connais pas bien la manière dont la protection mémoire est implantée sur les x86. Ceci dit, à la réflection je crois qu'elle consiste à mettre en place 3 anneaux dans lesquels les membres des anneaux supérieurs ont accès à tous les anneaux inférieurs. Ça permettrait pas de protéger l'espace utilisateurs des modules propriétaires, donc aucun intérêt -_-. Mais je suis pas sûr, et je sais pas ce qu'il en est sur les autres architectures.

Sans aller jusqu'au micro noyau, on pourrais peut être tenter d'introduire une protection de la mémoire (espace noyau et utilisateur) contre les modules propriétaires.
Il faudrait ensuite introduire dans l'espace utilisateur des librairies qui seraient marquées comme "infectables" et qui feraient le lien entre les applications et les drivers (dans le cas de nvidia on pourrais mettre cet attribut sur les librairies OpenGL et le driver XFree86 (ça supposerais quand même d'exécuter les drivers de Xfree dans un espace délimité mais c'est faisable à mon avis)).

Je crois que le problème serait surtout de permettre aux drivers proprio d'utiliser les fonctions du noyau, qui ne sont pas limitées dans leur espace d'application. Pour ce que j'en sais, les fonctions les plus bas niveau sont maintenant gérée par une couche d'abstraction. Peut être que se contenter de n'autoriser que l'appel dans cette couche des fonctions s'appliquant au hardware que le pilote dit gérer permettrait d'assurer cette protection ? Il resterait probablement une ou deux fonctions génériques et utilisées par tous les pilotes, mais appliquer sur ces quelques fonctions un contrôle de sécurité pour les appels des modules proprios me parait déjà moins impossible et surtout moins couteux en terme de performances.
Surtout que maintenant le noyeau peut préempter voir forcer le déchargement des maichants pilotes.

Enfin, je dis ça, mais j'ai jamais touché au noyo... c'est juste mon imagination fertile de cette heure là du matin -_^.

Je vérifie rien, je lis les commentaires.
Et j'avais également remarqué que celui-ci était en double.

Au passage, si tu parles de "dénoncer", c'est parce que tu sais qu'on peut te le reprocher ? Perso je m'en fout, même si j'aime pas le redondance. Pour résoudre le problème, si tu pense que t'as une bonne raison de te répéter, justifie toi la prochaine fois.

M'enfin dis en plus sur ton cas. De mémoire je crois qu'on peut agrandir les partoches XFS sans risques de pertes et sans démontage (avec grow_xfs).

Non. Sauf si elle est montée en lecture seule mais même là... t'as une certaine probabilité de kernel oops, en fonction des opérations que effectue je pense. Pense à arrêter le plus de programmes possibles auparavant.

Voui, et même beaucoup plus si ils ont encore des partoches dans leur superbe FS breveté, j'ai nomé Fat32 (32ko je crois sur les disques actuels ?).

T'as qu'une license non?

Un core posé là pourrait être celui d'un autre utilisateur... sinon la boite en question serait mainsoft.com .

J'avais trouvé un torrent, pensant que c'était un fake je l'ai téléchargé (logique ça non?), et bein c'en était pas un. "rm -f" était là heuresement -_^.

Envoie peut être le fichier aux gars de OpenOffice, ça pourras les intéresser (bon évidement si c'est confidentiel...).
Vérifie quand même auparavant que ça provienne pas d'un problème de polices.