M a écrit 2988 commentaires

Mais arrête de raconter n'importe quoi, il est *évident* qu'il est important de préserver le maximum de diversité, et qu'il ne faut pas réduire les cultures à une palette alors qu'on a tout le spectre à disposition !
Ca me rappel un discours que j'ai entendu sur un reportage ARTE il y a quelque temps.

J'ai pu le truc en tête, mais c'était assez abérant. C'etait du style :
sous pretexte de conservé la diversité, il fallait cloner ces espèces ou essayer de les introduire ailleurs.
Avec le clonage on élimine les mécanismes de sélection naturel (et donc de diversification puisse qu'on reproduit le même individu) et en les introduisant ailleurs on bouleverse des eco systèmes (et on peut faire disparaître d'autre espèce du milieux).

Donc oui il faut préserver le maximum de diversité, mais pas faire n'importe quoi, avoir une vision global à l'échelle de la planete et sur le long terme.

Le probleme de NUT c'est qu'il faudrait qu'il sorte un jour :
nut (comme snow (codec video à ondelette)) ont beau etre tres prometteur, le soucis c'est qu'ils ont été concu par une ou deux personnes, mais depuis plus grand chose (et personne ne bosse vraiment dessus).

Peut-être est-ce l'interprète. A-t-on des informations sur l'identité de la dame qui chante ? Auquel cas, ses droits ont expiré avant 1910 (les droits voisins ne durant pas aussi longtemps qu'aujourd'hui à l'époque, je prends large).
Oui mais le fait de scanner, numériser la chanson (ie de faire des transformation dessus) ont fait acquérir des droits à ces personnes.

C'est la même chose pour les documents scanné de la bnf qui ont parfois des licences.

Comme quoi c'est mieux de faire des navigateur proprio comme opera : on se fait pas griller tout de suite :)

C'est juste que la partition Linux est embarquée dans un fichier de la partition windows, à priori, donc juste un bootloader et un driver de fs un peu particuliers en gros j'imagine.
Pour le bootloader celui ci s'interface avec le bootloader de windows, ce qui permet de ne pas modifier le MBR.
Ensuite le bootloader sait recupere le kernel et l'initrd sur la partition windows et apres le rootfs est monté en loopback depuis la partition windows.

C'est effectivement assez pratique pour tester sans tout casser ni avoir les pb de lenteur des live cd.

Ben gallium est encore en développement et aucune carte ne marche de manière stable dessus.

Même intel ne sait pas s'ils resteront sur mesa-dri ou passeront sur gallium [1].

Et puis mesa-dri n'est pas prêt de disparaître vu le nombre de carte qu'ils supporte (et le boulot que ca serait de tous les porter).

Ca me rappel les drivers ralink qui utilisait la stack wifi dernier cri (qui n'était pas dans le noyau) alors que d'autre continuait à développer sur l'ancienne : les drivers ralink était très compliquer à utiliser.

[1]
http://article.gmane.org/gmane.comp.video.mesa3d.devel/10087
If existing DRI drivers
get to continue living side-by-side with gallium stuff, then until
gallium proves to be a significant win for our chipsets we can go ahead
and ignore it, it sounds like.

Oui et j'espère que bzr ne suivra pas le même chemin que hurd.

Une dépêche de seconde page est deja parru a ce sujet il y a quelques semaines. [1]

Il en était ressortit qu'il restait beaucoup de travail à faire avant d'avoir quelque chose d'utilisable.


[1] https://linuxfr.org//2008/02/16/23702.html

plus d'info sur http://lwn.net/Articles/272853/

Apparemment Bazaar a été choisi par rms car c'est un projet GNU, pas parce que c'est celui qui répond le mieux au cahier des charges...

Je suis t'a fait d'accord avec toi (et je comprend pas ton moinsage).
Il faut mieux mettre un firewall sur le point d'entrée que se reposer sur la configuration de chaque machine (d'autant plus qu'on peut vouloir autoriser des données à circuler sur le réseau local, sans qu'elles en sortent).

Au passage avec l'ipv6 on nous vante la fin les problème propre au nat. Mais bon par exemple pour sip, si le routeur a un parfeu qui bloque les flux entrant qu'on soit en ipv4 ou ipv6, on aura toujours besoin de truc comme stun ?

c'est que jffs2 met un temps pas possible a monter les "grosses" cartes
Et il te bouffe plein de RAM.

Et que logfs n'est toujours pas sorti en stable ...
Y a aussi ubifs a surveiller

Oui c'est tout à fait ça.

D'ailleurs, sans plug-in additionnel, VDR ne peut pas décoder le MPEG-2, il utilise le décodeur hardware de la carte satellite.
De même il n'a pas notion de multi-client par défaut et il faut rajouter un plugin.
Le problème étant que tout les plugins VDR sont plus ou moins bien maintenu et stable.

Par exemple l'archi client/server avec vdr-streamdev est assez bugé, et le local n'a pas moyen propre de s'éteindre.

PS : y a aussi mplayer qui sait sortir sur la sortie TV de la carte satellite.

c'est que la gestion de la mémoire dans un naviguateur devient aussi complexe que dans un système d'exploitation (avec des problème de fragmentation de mémoire et donc des algo de plus en plus complexe à implementer) et que donc sans une attention portée la dessus, pas de salut.
C'est la libc qui implémente en grande partie l'allocateur mémoire, pas le kernel qui ne fournit qu'un tas (avec brk, sbrk, mmap). Au passage vu que le kernel maîtrise la mmu, même si la mémoire physique est fragmenté, il peut la faire apparaître contiguë en virtuel (au appi).

Pour ceux qui connaisse MythTV :
- est ce qu'il est capable de sortir sur une carte dvb-s FF.
- est qu'il y a moyen de gérer plusieurs clients (un en local, d'autre via le réseau).
- est ce qu'il est capable de programmer le pc pour se réveiller automatiquement (pour un enregistrement par exemple) en utilisant /proc/acpi/alarm par exemple. Ou encore d'éteindre le pc, quand il n'y a plus de client actif.
- est ce qu'il gère le diseqc et permet de voir la qualité du signal

Pour le moment j'utilise VDR et malgré certains défauts j'ai toujours pas trouvé de logiciel équivalent.

Un même "multiplex" permet de transmettre jusqu'à 6 chaînes en même temps, multiplexées sur un seul canal.
Il peut transmettre autant de chaîne que la bande passante le permet.
C'est peut etre 6 sur la TNT, mais c'est plus sur le sat.

oui un code pin est censé être nécessaire pour établir une connexion.
Sauf que des fois pour faciliter la vie de l'utilisateur, les fabriquants de téléphoner le font sauté...

Ce qui est un signe que l'architecture est pourrie: le rendu de l'aperçu devrait être fait dans un autre processus..
Pas forcement besoin d'avoir d'un autre processus :
- soit l'utilisation d'un code robuste qui gère les cas foireux (ils peuvent facilement valider leur code avec plein du fichier random)
- soit l'utilisation d'un langage de haut niveau qui gère des exceptions

Firefox se plante quand un plugin se plante ce qui n'est pas normal pour beaucoup de plugin, qui devraient être dans des processus séparés.
Je suis pas sur que ca soit toujours posible (notament pour des questions d'incrustation dans le navigateur).

Je sais pas si c'est prevu, mais un mode photocpieur serait assez pratique. Ca serait un mode ou l'on sélectionne le scanneur/l'imprimante(et éventuellement leur paramètres), puis on appuie sur un bouton ca scane et ca imprime.

C'est assez pratique pour "photocopier" des documents pour les personnes qui maîtrise pas trop l'informatique.

Il y a quand même l'option -std= de gcc
Sauf que ca ne verifie pas tout si je me souviens bien.

et également dans la glibc, il y a un certain nombre de define qui définissent ou non certaines fonctions (cf /usr/include/features.h).
Idem c'est tres vite limité.
Par exemple certaines fonctions POSIX ont des extensions linux sans garde fou (ie define a definir).

Il n'y a pas non plus de séparation ISOC/POSIX.

D'un autre coté quand on voit ce qui ce passe chez un certain microsoft c'est gère mieux :
- Ils sont pas foutu d'avoir un compilo qui s'approcherait des standards C.
- ils ont des includes pas standard qui font que des compilos comme gcc (mingw) ne peuvent pas forcement bien les parser et à cause de leur licence on ne peut pas les patcher.
- leur libc est à l'image de leur compilo.
Bref c'est que du bonheur de faire du code portable en prenant en compte windows (ca me rappel le code html pour ie).

Pour le couple gcc/glibc, ce que je regrette c'est que les gens ne se rende pas forcement compte de ce qui est standard et ce qui ne l'est pas.
Et malheureusement, je crois pas qu'il existe de moulinette qui donnerait la conformité du code (ISOC, POSIX, BSD, extension gcc, extension glibc, extension linux, ...).

oui mais il donne sur x86 des binnaires plus lent que les precedentes version de gcc...

et pour des chiffres regardes http://sourceforge.net/forum/forum.php?thread_id=1830216&(...)


Times for decoding a 1440x1080 Dirac stream (with inter) of 3880 frames:

- CPU only implementation: 2671126.326 ms = about 1.5fps
- GPU accelerated implementation: 188548.063 ms = about 21fps

These timings were done by gstreamer on this machine:
CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5200+
GPU: Geforce 8800GTX

Faut-il encore que ton gpu supporte le dirac (ou soit programmable pour le faire). Et ton P3-450 doit avoir une vielle carte graphique ?

Et puis Schrödinger a déja du code "cuda" pour tourner sur les gpu nvidia (avec le pilote proprio je suppose).

Ben essayes la bibliothèque Schrödinger qui est censé être plus optimisée.

Mais bon ça n'empêche pas que ce type de codec (dirac ou snow) sont très gourmand. C'est utile pour de l'archivage sans perdre trop de qualité, pour du realtime ca devient plus chaud.

Pour JPEG-2000, les brevets pesant dessus n'ont pas aidé...