benoar a écrit 4238 commentaires

Ca me fait marrer ces entreprises qui misent leur sécurité sur les DRM, parce que dans ce cas là, ils disent qu'on peut distribuer les fichiers DRMisés à des partenaires auxquels on n'a pas vraiment confiance (fuite de la part d'un employé, etc ...). Mais dans le schéma présent, _toute_ la sécurité repose sur la confiance en PTC ! Puisque c'est eux qui détiennent les "secrets" du DRM. Bref, un seul acteur à corompre afin de pouvoir lire tous les fichiers produits par leur "wildfire" ....
Les DRM ne résolvent pas les problèmes, ils ne font que les déplacer en changeant qui a le pouvoir sur les données qu'ils "protègent" ... Et bien sûr, ça ne sera pas vous !

Je ne suis pas un utilisateur forcené de Gentoo, mais cette distribution est pas mal pour tester ce genre de chose, et elle est très customisable. Par exemple, en ayant bien paramétré son ROOT pour compiler dans un système "séparé" , en disant que $TARGET pointe vers le répertoire où sera construit la cible :

# sur la cible
export USE="minimal make-symlinks"
ACCEPT_KEYWORDS="**" emerge baselayout-lite
USE="-static" emerge glibc busybox
# dans l'hote
emerge gentoo-sources
# dans les sources du kernel
make menuconfig
make
mkdir $TARGET/boot
INSTALL_PATH=$TARGET/boot make install
INSTALL_MOD_PATH=$TARGET make modules_install

Et voilà, on a un système comme Saevia. Après, ça demande un tout petit peu plus de boulot pour en faire un live-cd, mais on peut déjà tester ce système dans qemu (ou même, sans kernel, dans un chroot).

Cela permet d'avoir un système bien testé (même si baselayout-lite est encore en développement, cf le ACCEPT_KEYWORDS) basé sur une distro un minimum maintenue. Et l'esprit de Gentoo, c'est de bien connaître son système aussi, on pourra donc se baser sur toutes les docs l'accompagnant (et qui existent en français: http://www.gentoo.org/doc/fr/handbook/ )

Heu .... t'as lu son discourt ? Il parle justement de lui, entre autres ...

C'est vrai qu'ici on voit passer pas mal de modèles intéressants. J'ai quand même retrouvé une référence dont on avait pas parlé depuis longtemps : Efika.
http://www.pegasosppc.com/efika.php
Malheureusement, pour le prix, ça fait un peu léger :
- MPC5200B PowerPC SoC up to 400MHz
- 128MB DDR RAM
- 1PCI slot
- 44 pin IDE connecteur (pour un disque 2,5")

Sur leur "store", je ne trouve qu'une version avec boitier, alim, carte vidéo "ATI", et disque de 60Go pour 280€ (375$)

Normalement ta distro prend en charge toute seule les galères d'initrd/ramfs. Pas la peine de se prendre la tête avec. Ou alors regarde un peu du coté du paquet chargé de créer l'initrd justement (je n'ai plus le nom en tête, mais chaque distro utilise le sien), ya moyen de configurer sa "simplement" si ça ne marche pas sans bidouiller.

Oui en général, mais ça dépend de l'utilisation : ça ne va pas pour se faire un /home en flash ...

Si c'est ce que dit NeoX, c'est peut-etre a cause du temps que met le kernel a détecter ton périph USB : il y a une option pour lui dire d'attendre un peu avant de monter la partition root, c'est "rootdelay=XX", avec le temps en seconde. Essaye avec 10s d'abord, et allonge/raccourci en fonction du résultat.

Oui c'est facile : dans le fichier de conf de GRUB, au lieu d'avoir "root=/dev/hdaX" (c'est à dire le nom de périph de ton disque), tu mets "root=/dev/sdaX", indiquant que c'est ta clé USB (met le numéro de partition adéquat).
Par contre, comme je précisais plus haut, si tu plantes ton système sur ton disque au point de ne plus avoir de kernel accessible, ça ne marchera pas ...

... unionfs qui devra bien écrire sur une partition d'un certain type, comme jffs/logfs. Je ne vois pas en quoi ca change le probleme .... ?!

Oui, donc faut que ton systeme ait encore un kernel qui fonctionne. Roof avait l'air de dire que c'est en cas de secours, donc a priori quand ton systeme est dans un état pas terrible, et ou tu n'as peut-etre plus de kernel "correct" sur ton disque IDE. Enfin, je peux me tromper, je ne sais pas ce qu'il veut exactement.

Dans le genre truc bien inutile ....
Je vois bien un kevin raconter "Ouai, j'ai bloqué les ping vers ma connexion, comme ca je suis invisible depuis le réseau !"...

http://www.ifixit.com/Guide/Mac/Mac-Mini-PowerPC/Mass-Storag(...) ?

Si ton BIOS ne sait pas booter sur de l'USB, ce n'est pas possible.
Ou alors faut bidouiller a mort avec du kexec et kboot, mais c'est pas gagné d'avance ...

C'est du GPL, tu peux recompiler avec le support IPv6, non ?

Oui ça serait effectivement intéressant : je ne savais pas que Free ne proposait aucune option "basique" pour interdire les connexions entrantes par exemple. C'est vrai que ça pourrait être utile.

La freebox est par défaut (= comme ça chez 90% des gens qui n'ont jamais osé changer) en mode bridge, donc ton ordi est "directement" connecté au net, sans NAT. Pourtant, ça a l'air de déranger personne. Et tu sais quoi ? C'est peut-être justement parce que c'est ce que tout le monde veut, et que si on pouvait connecter plusieurs bécanes derrière sa freebox sans NAT, ce serait génial : c'est ce qu'offre IPv6.

Oui c'est une possibillité, mais pour un usage "desktop" c'est moyen : le seul truc qui fait du bruit dans mon ibook (sous debian, donc la bidouille est faisable), c'est le disque dur. Le remplacer par une grosse flash serait bien, mais les pb d'usure font que je me pose des questions...

Ha ok ... Mais je trouve ca "dangereux" d'appeler un vg "vg", ca peut porter a confusion ... Dans bcp de tutos, ils sont nommés "vg_xxxx".

D'ailleurs, le résultat d'un petit :
pvdisplay
vgdisplay
lvdisplay
pourrait aider.

Ya un truc bizarre dans ta config : c'est /dev/mapper/vg-root qui est monté comme une partition ??!!
Normalenemt, tu crées des LV dans ton VG, et c'est ceux-la que tu montes. A mon avis tu t'es gouré dans ta manip, et je ne sais franchement pas comment un truc comme ca peut marcher correctement ...
Je pense que si t'utilises tout le VG comme une partition, il a du écraser la liste des LVs présents, et c'est pour ca qu'ils sont "invisibles". Apres, que t'arrives a avoir des données cohérentes dessus .... je ne comprend pas. Pour moi, ton / aurait du écraser toutes les autres partitions que tu as fait ...

Puisqu'il y a l'air d'avoir des spécialistes ici, j'aimerais savoir si quelqu'un a une réponse claire a mes questions :

- Effectivement, les mémoires "flash" en général s'usent tres vite quand on écrit toujours au meme endroit
- MAIS, certains types de cartes implémentent du "wear leveling" en hard (genre les SD, il me semble)
- MAIS, ce n'est jamais indiqué clairement : par exemple, qu'en est-il des CF ? Et des autres ?
- Enfin, les cartes faisant du wear leveling en hard devraient donc pouvoir gérer facilement les FS pas faits pour. Or, vu le nombre de SD que j'ai vu foirer apres tres peu de temps, qui étaient, comme d'habitude, formattées en FAT32, ca me parait louche.

Bref, toutes ces histoires font qu'on ne sait jamais quoi faire, c.a.d. quel FS mettre dessus, et quelle utilisation avoir.

L'autre probleme, lorsqu'on souhaite utiliser un FS fait pour la Flash (en dehors du fait que généralement elles sont présentées sous forme de périph block, et qu'ils faut bidouiller par 2 modules mtd différents qui va la faire repasser en char, puis encore en block ...), c'est que jffs2 met un temps pas possible a monter les "grosses" cartes, alors qu'aujourd'hui ce qui est intéressant c'est justement d'avoir 4Go en Flash pour pas trop d'euros. Et que logfs n'est toujours pas sorti en stable ...

Sans live-cd, je trouve toujours ca plus pratique d'ajouter
... init=/bin/sh
avec son bootloader dans les arguments passés au kernel lors du boot.
Après, un petit
mount -o remount,rw /
passwd
Et hop, on réinitialise le mdp root ...

Tu peux toujours installer linux sur ton Mac pour éviter d'avoir a subir les politiques bizarres de certains éditeurs de logiciels ...
J'étais dans le meme cas que toi, a galérer avec une 10.3 ou les logiciels récents commencaient a se faire rare, et en passant a Debian, bah ... j'ai toujours des logiciels avec 3 ans de retard \o/
Troll a part, ca fait 2,5 ans, et ca tourne toujours aussi bien.

qemu ?

Tiens c'est marrant je viens de découvrir le mot-clé "restrict".
Justement, j'allais demander comment gcc réglait les problemes d'aliasing, et j'ai ma réponse.
Mais alors, il va falloir apporter quelques modifications au code existant afin qu'il soit automatiquement vectorisé : on le voit meme dans les exemples cités plus haut, il faut mettre du "restrict" assez souvent ...