M a écrit 2996 commentaires

Parce que malheureusement les mmu des cpu marche par niveau :
- le code user ne peut pas faire tourner du code superviseur (kernel)
- le code superviseur à tout les droit (un peut comme root sous les unix).

Et pour des question de perf, quand un process user fait une transition vers le monde kernel on garde le meme mapping mmu.

Je profite de ce journal pour savoir si vous connaissez un logiciel qui permet faire des schémas cinématiques 2D et de les simuler ?

Il y a bien openmeca qui semble correspondre, mais le site à l'air mort....

Le modem adsl non, mais tout le reste oui (que ce soit un modem usb directement connecté au pc, ou un routeur avec openwrt).

Au passage tu ne peux pas non plus reflasher le "modem" de ta livebox, tu peux juste changer son firmware et/ou driver (ce que tu peux faire sur ton pc)...

Je ne vois rien de très étonnant à ce qu'OpenOffice.org Writter mette plus de temps à démarrer qu'Abiword
Sauf abiword devient une grosse bouse sur les gros document et ce fait torcher par openoffice.
J'avais fait un test sur un document de plus de 300 pages. Et ben openoffice démarait en 30s, abiword mettait plutôt dans les 5 minutes (voir plus).

ça a l'air d'être de plus en plus une usine à gaz...
Yep, surtout a une époque lointaine X était portable sur plein d'unix. Avec des dépendances sur udev, la 3D qui dépend de gem, ttm, kms on est en train de faire un truc linux only.

Et puis vu que ça change tout les 4 matins imposible de savoir ou il faut configurer le bousin si ca marche pas comme on veut.

Oui, mais je journal est trompeur pour les personnes ne parlant pas anglais :
Flash pas OpenSource à cause d'H264
Il semblerait donc que H264 et ses brevets soient un frein majeur aux Logiciels Libres. Si Adobe ne peut libérer Flash pour cette raison

C'est pas comme si les autres codecs utilisé par flash n'était pas eu aussi couvert de brevets...

Pour les perf, clang n'est pas toujours au niveau de gcc : http://multimedia.cx/eggs/compiler-smackdown-2010-1-64-bit/

Surtout qu'il a encore du mal avec l'asm inline...

Je sais pas, mais bon il y a déjà pas mal de bouquin sur le net. Entre les auteurs classiques qui sont tombés dans le domaine publique et certains sites pas tres officiel qui diffuse les best seller du moment.

Apres faut dire que pour le moment c'est hardcore de lire un bouquin sur un écran, mais dès que des readers seront répendu, je leur prédits un bel avenir en téléchargement (par forcement en p2p vu la taille d'un bouquin).

gni ? Si tu développes un logiciel permettant d'encoder/décoder du H264 sans t'acquitter de la licence ... pas les développeurs du code en question.
S'ils sont dans un pays ou les brevets logiciel ne sont pas reconnu, rien ne leur interdit de publier un logiciel open source (même si MPEG dit le contraire).

Si MS ajoute dans ses clauses que tu ne doit pas utiliser de logiciel open source, est ce que tu vas le faire ?


Et puis regarde ce qui c'est passé avec le MP3, MPEG2 et MPEG4 (h263). Je ne connais aucun developpeur qui a eu des problèmes. Le groupe MPEG ne s'attaque pas aux développeurs (qui n'ont pas d'argent), mais au grosse boite l'utilise (solution open source ou non). Effectivement ça pourrait être mozilla...

1) tu as manqué le smiley
2) tu peux utiliser ffmpeg en ayant acquitté la licence h264, tout comme tu peux utiliser une version piraté d'un codec dont la licence n'a pas été payé.
Il n'y a aucun rapport entre des solutions libre (ffmpeg, x264) et l'acquittement des licences mpeg.

Les royalties sont fixés en fonction du volume d'utilisateurs, avec une limite basse et une limite haute, comme ça pas de jaloux !
Donc si tu es le seul utilisateur tu ne paie rien (on est en dessous de la limite basse) :)


Si vous utilisez une implémentation du codec H264 qui ne fait pas partie de la liste des licenciés [2] (vous pouvez vérifier GStreamer, FFMpeg, x264 n'y sont pas),
faux : des entreprises utilisent ces logiciels et paye des licences. Par exemple chrome et ffmpeg. Idem pour x264.

Ben tout de manière le comportement par defaut de kqemu était de virtualiser seulement l'userland [1] qui n'utilise pas d'instruction privilégié (faut juste gérer les transition user<->kernel).


[1]
-kernel-kqemu
Enable KQEMU full virtualization (default is user mode only)

Mais on2 fait aussi des décodeurs hardware/software pour d'autres techno : MPEG 4, h264, ...

Bref le rachat de on2 peut avoir plein de raison.

Il suffit de trouver quelqu'un qui veut bien s'en occuper et supprimer les limitations qui bloquaient le développement de KVM, comme par exemple la gestion des adresses sur 32 bits (même sur x86_64), limitant la taille des machines virtuelles à 4G.
Sachant que la plupart des x86_64 ont le support matériel, c'est pas trop gênant pour kqemu.

Par contre, ne peut ont pas avoir un mode de kvm soft pour x86 ?
La même chose semble avoir été fait pour ppc : http://www.linux-kvm.org/page/PowerPC

Current development is aimed at running 440 Linux kernels as guests on 440 Linux host. Since the 440 processor does not implement virtualization hardware support, this is done via "trap and emulate" of privileged instructions executed inside the guest.

Y a mieux : un gagnant de l'ioccc a utilisé cpp pour calculer des nombre premiers.

http://www.ioccc.org/years.html#2004_vik2

1- Ouvrir le schema de l'application. Ici ça sera /etc/gconf/schemas/desktop_gnome_background.schemas
Ce fichier n'existe pas chez moi, pourtant j'ai des applis qui utilisent gconf

C'est clair que c'est atrocement compliqué et totalement hors de portée
La preuve je suis bloqué au 1.

On peut très facilement imaginer pourquoi c'est difficile à implémenter: gestion des conflits, réconciliation, état incohérents etc. Si le sujet t'intéresse, tu peux proposer un patch je pense.
Si on veut faire un truc aussi complexe autant utilisé une base de donné de type sqlite

Tu peux nous proposer une solution fonctionnellement équivalente et beaucoup plus simple
Un truc plus simple :
- des fichiers de conf classique clef valeur (comme sshd_config) par exemple.
Ce fichier contient des commentaires et les valeurs par défaut : la doc est dans le fichier de config [tout du moins pour les fichiers globaux, pour les fichiers user c'est discutable de dupliquer la doc]
- un démon optionnel peut vérifier si les fichiers sont modifiés (via ionotify) et signalé au appli correspondante quel doive relire le fichier de config. La notification peut se faire par signaux (les fameux SIGHUP), ou alors un mécanisme plus complexe.
- si tu veux vraiment gérer les confits, tu peux mettre ces fichier sur un gestionnaire de revision : le fichier est pris en compte une fois que tu l'a commité. En bonus tu gagne un historique qui peut te permettre de récupérer une version qui marchait.

PS : Question pour la route comment tu modifies les paramètres gconf de gdm ?
PS2 : Comment tu lances un appli qui dépend de gconf dans une sandbox (limité à un process, isolé du reste du système).

Et le mieux c'est les projets qui font des scripts avec XML comme fontconfig [1].
M'enfin l'étape au dessus c'est des trucs à la gconf, où c'est tellement complexe qu'on ne peut pas l'éditer à la main.


[1]

<code>
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<!--
If the font still has no generic name, add sans-serif
-->
<match target="pattern">
<test qual="all" name="family" compare="not_eq">
<string>sans-serif</string>
</test>
<test qual="all" name="family" compare="not_eq">
<string>serif</string>
</test>
<test qual="all" name="family" compare="not_eq">
<string>monospace</string>
</test>
<edit name="family" mode="append_last">
<string>sans-serif</string>
</edit>
</match>
</fontconfig>
</code>

Au passage pour avoir des couleurs correctes, j'ai du configurer le gamma.

Les valeurs correctes était dans un profile de couleur du fabriquant (icm).
Et ben qu'elle galère pour trouver un outil qui puisse le lire. Merci iccdump de argyll

Ensuite la configuration du gamma à l'air de varier suivant le driver xgamma, xrandr, nvidia-settings, ...

À moins que tu aies des problèmes de vue, peut-être devrais-tu essayer de t'habituer à de telles résolutions ?
Ben oui je suis un peu myope.
Et pour avoir essayé de travailler à de forte résolution, je me suis choppé des mal de tête.

Ca ne résout pas tout par exemple firefox [1] ne scale pas les éléments en pixel. Ca peut sembler logique sauf que le développeur web n'a pas forcement pensé à ce que donnerait le rendu sur un écran à fort DPI.

Ensuite certains terminaux (rxvt, xterm) ne s'adapte pas.
Idem mon WM icewm a l'air de s'en foutre.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=512522

C'est sur que c'est plus grand : la hauteur (y) est la même, et le 16/9 est plus large (x).

C'est pas si simple que ça : suivant les applis l'info peut être récupéré ailleurs [1]. Par exemple dans gconf pour les appli gnome... Xft.dpi est aussi utilisé.

Ensuite le pb, c'est que pas mal de truc sont codé en pixel (page web, icone, ...)


[1] http://scanline.ca/dpi/

opps je voulais poster dans un forum. Tant pis.

Cela aura le mérite de lancer le débat sur l'indépendance de la résolution qui a l'air d'arriver dans les autres OS (Windows 7 et MacOSX).

Dans les slides de la conf, ils dissent que le chiffrement est optionnel est choisi par la base (ie pas ton téléphone)