benoar a écrit 4244 commentaires

  • [^] # Re: Quel rapport ?

    Posté par  . En réponse au journal des drm dans la cao. Évalué à 3.

    Je n'aime pas du tout ta manière de changer la problématique de départ exprès pour que ça aille dans le sens ou tu peux avoir raison.

    Le problème de départ est : sur le joli PDF fourni dans ce journal, PTC raconte (pour résumer) que grâce à leur DRM, dans un contexte où l'externalisation est du plus en plus utilisée, on peut envoyer des fichiers à des sous-traitants auxquels on ne fait pas confiance en ne leur donnant que les "droits" strictements nécessaire à leur travail.

    Donc :

    Les clefs ils les recoivent du serveur.
    Et ça change quoi ? Le client a la clé quand même ...

    Quand a utiliser/copier les donnees, c'est pour l'instant la ou le bat blesse niveau DRM, les solutions sont assez bancales.
    Ce n'est pas bancal, c'est "defective by design" ! Un ordinateur est fait pour copier/manipuler de l'information. Le seul moyen de l'en "empêcher" c'est de "cacher" sa méthode en utilisant une méthode "secrète". Bref, du DRM bête et méchant.
    Quant à ton "pour l'instant", je pense que tu fais allusion à TCPA ? Alors là, oui, effectivement, ce sera possible, mais personnellement, je n'ai pas envie d'acheter une machine qui n'est pas sous mon contrôle.

    Je ne vois vraiment pas en quoi corrompre PTC va changer quoi que ce soit. Tu as besoin de PTC pour quoi exactement ? Pouvoir copier les donnees alors que tu n'etais autorise qu'a les lire ? Pas besoin de PTC pour ca mon cher, un simple appareil photo suffit...
    C.f. l'introduction de ce commentaire, n'essaye pas de dévier de la problématique : faire une photo d'une pièce, oui ça se fait depuis des lustres, et je pense même qu'aujourd'hui ça ne sert plus à grand chose. Par contre, avoir tout le source du fichier de modélisation, pour n'avoir qu'à le filer à une machine qui va tout faire toute seule ensuite, ça c'est plus intéressant.
    En gros, t'essayes de minimiser les conséquences d'un truc que t'essaye de défendre depuis le début, sauf que tu t'es rendu compte que c'est bidon .... (enfin, je pense que tu le sais, mais que tu aimes bien avoir des trolleurs en face de toi parce que tu sais qu'ils auront des arguments bidons ... mais quand il faut vraiment débattre, je ne vois pas en quoi tu peux justifier la présence d'un DRM pour la "protection", c'est simplement absurde, et tout le monde le sait)
  • [^] # Re: Quel rapport ?

    Posté par  . En réponse au journal des drm dans la cao. Évalué à 3.

    OK, admettons que le serveur est géré par celui qui l'achète.
    Comment empêcher les clients de copier/utiliser les données comme ils veulent, sachant qu'ils ont les documents _et_ les clés pour les déchiffrer, tout ça dans un logiciel proprio ? Dont le mécanisme de déchiffrage est forcément un truc "secret", puisque le client a déjà tout pour lire le document (données + clés) ? Et bien on utilise un DRM à deux francs. Et le client qui a corrompu PTC, comme il a déjà le document et les clés, et bien il fait ce qu'il veut des données "protégées".
    Bref, tout se rapporte à la confiance en l'éditeur.
  • [^] # Re: Quel rapport ?

    Posté par  . En réponse au journal des drm dans la cao. Évalué à 2.

    Ouai alors après on peut débattre de ce que sont les DRM "en général", mais j'en ai vu pas mal qui n'utilisaient pas du tout de chiffrage.
    Si c'est du chiffrage, comme tu dis, le soft "demande à un serveur", donc du moment que t'as corrompu PTC (et donc leur serveur), tu peux avoir les clés de n'importe qui. Et comme indique baud123, de toutes façons, même avec du chiffrage, on te file le contenu chiffré _et_ la clé. Toute la sécurité est basée sur le système qui permet de stocker la clé et déchiffrer "discrètement" le contenu (i.e. utiliser une méthode proprio). Bref, au final, tout repose sur le secret. La clé de chiffrage c'est juste histoire de faire joli pour le marketing. On en revient toujours aux mêmes arguments qu'avaient présenté je ne sais plus quel mec connu à ta boite il y a quelques années ...
  • # Pas très utile, mais ...

    Posté par  . En réponse au journal Fallait pas que ça plante.... Évalué à 3.

    Faudrait peut-être savoir si t'es vraiment en runlevel 1 ou si t'es seulement sur l'initrd de démarrage. C'est un shell busybox ?
    Sinon, pour ton problème de LVM, je dirais soit c'est parce que t'es dans l'initrd et que tu n'as que les outils très basiques pour LVM (genre faut charger un module et utiliser je sais plus quelle commande avec je sais plus quelle option), soit c'est un bête "/usr/sbin est pas dans ton PATH".

    PS: bon, ça devrait être dans un forum, mais bon, c'était bien raconté ...
  • [^] # Re: Quel rapport ?

    Posté par  . En réponse au journal des drm dans la cao. Évalué à 4.

    Bah, dans ce "livre blanc", ils parlent surtout de DRM "classiques" avec format proprio et systèmes de protection a deux francs. Dans tout le document, il n'y a que 2 fois le mot "cryptage" (donc en plus ils font une faute), qui est employé très vaguement. Donc franchement, pour moi c'est surtout leur DRM dont ils font la pub, et ce n'est surement pas du chiffrement individuel.
  • [^] # Re: c'est quoi ca ?

    Posté par  . En réponse au message Pilote 7600GT Nvidia sous Debian etch 4.0. Évalué à 2.

    Bon alors déjà, c'est très dur de te lire avec toutes les fautes, et ensuite, on peut pas deviner ce que tu fournis dans ton paquet avec si peu de description ! Si tu souhaites "aider" les gens, il faut être un peu plus didactique.

    Ensuite : N'UTILISEZ PAS CE SCRIPT. Il touche (tout en root, bien sûr) à votre source.list, votre xorg.conf, etc .... Bref, si vous faites absolument confiance à v1nux, pourquoi pas, mais, c'est une mauvaise idée.

    Ce n'est pas une critique "méchante", v1nux ! C'est juste que ce n'est pas vraiment une manière "normale" de faire sous linux. Je pense qu'il existe des méthodes un peu plus orthodoxes ...
  • [^] # Re: Quel rapport ?

    Posté par  . En réponse au journal des drm dans la cao. Évalué à 6.

    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 !
  • # Pareil sous Gentoo

    Posté par  . En réponse à la dépêche Présentation du système Saevia. Évalué à 4.

    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/ )
  • [^] # Re: A remettre en perspective ...

    Posté par  . En réponse au journal Traduire le discours d'Obama. Évalué à 2.

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

    Posté par  . En réponse au journal Mini serveur (Linutop, Norhtec, Koolu, Embeddedpc) ?. Évalué à 3.

    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$)
  • [^] # Re: Mais...

    Posté par  . En réponse au message grub booter sur sda1. Évalué à 2.

    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.
  • [^] # Re: To wear or not to wear level ?

    Posté par  . En réponse au journal Interrogation à propos d'une carte compact flash. Évalué à 2.

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

    Posté par  . En réponse au message grub booter sur sda1. Évalué à 2.

    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.
  • [^] # Re: hooouuuuu !

    Posté par  . En réponse au message grub booter sur sda1. Évalué à 3.

    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 ...
  • [^] # Re: To wear or not to wear level ?

    Posté par  . En réponse au journal Interrogation à propos d'une carte compact flash. Évalué à 2.

    ... 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 .... ?!
  • [^] # Re: Pas possible

    Posté par  . En réponse au message grub booter sur sda1. Évalué à 2.

    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.
  • [^] # Re: toujours pas de firewall ?

    Posté par  . En réponse au journal Nouveautés ipv6 chez Free. Évalué à 5.

    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 !"...
  • [^] # Re: Quel est le bon seuil ?

    Posté par  . En réponse au message Petit soucis de bad block. Évalué à 2.

  • # Pas possible

    Posté par  . En réponse au message grub booter sur sda1. Évalué à 2.

    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 ...
  • [^] # Re: En parlant d'IPv6....

    Posté par  . En réponse au journal Nouveautés ipv6 chez Free. Évalué à 2.

    C'est du GPL, tu peux recompiler avec le support IPv6, non ?
  • [^] # Re: toujours pas de firewall ?

    Posté par  . En réponse au journal Nouveautés ipv6 chez Free. Évalué à 4.

    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.
  • [^] # Re: toujours pas de firewall ?

    Posté par  . En réponse au journal Nouveautés ipv6 chez Free. Évalué à 10.

    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.
  • [^] # Re: To wear or not to wear level ?

    Posté par  . En réponse au journal Interrogation à propos d'une carte compact flash. Évalué à 2.

    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...
  • [^] # Re: Un VG monté comme un FS ??!!

    Posté par  . En réponse au message Le mystère des systèmes de fichier cachés. Évalué à 4.

    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".
  • [^] # Re: Un VG monté comme un FS ??!!

    Posté par  . En réponse au message Le mystère des systèmes de fichier cachés. Évalué à 3.

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

    pourrait aider.