on va peut-être finir par avoir une réconciliation Gnome-KDE !
Bof les projets Gnome et KDE ont jamais vraiment ete en guerre. Il y a meme u paquet de trucs qui ont ete fait de consors et ce depuis le debut. C'est surtout les utilisateurs qui se trollent les un les autres par forums interposes.
Je sais que ca ne posera pas de reel probleme, amais sincerement a ton avis qui va gagner ?
Sur la plupart des distribs on aura plutot un couple firebird/firebird-browser ou plutot un couple firebirdSQL/firebird.
C'est ca qui me chiffonne un peu. Compte tenu du fait que FirebirdSQL risque d'interresser beaucoup moins de gens que Phoenix la reponse "ergonomique" est la seconde. Ce n'est pas franchement sympa pour un projet qui a fait un sacre boulot depuis des annees.
Kha
La je pense quand meme que ca risque de poser des problemes. Bien que le couple Firebird/Thunderbird sonne bien a l'oreille, je pense que d'appeler Phoenix Firebird nuiera vraiment a Firebird SQL.
Le point le plus simple est le suivant : si je fais un apt-get firebird, un emerge firebird ou que sais-je encore qu'est ce que je vais installer ?
Techniquement il faudrait que ce soit Phoenix, ce qui entraine que pour installer FirebirdSQL il va falloir utiliser un autre nom, et je comprend que ca puisse en enerver certains. Ca fait pas tres longtemps que Firebird est sorti de l'ombre d'interbase. Il s'est fait un nom et on va le lui prendre.
Sur les forums mozilla il y a le cas du developpeur qui se voit deja en train de se prendre la tete a expliquer a ses clients qu'il installe firbird et firebird sur un serveur. La plupart des "decideurs" perdent 90 points de Q.I des qu'on parle de Linux (certains passent dans le negatif) ca va encore simplifier les choses.
Il y aura confusion. Ca ne sera pas forcement tres grave (encore que sous une distrib par sources se retrouver a compiler phoenix alors qu'on voulait juste upgrader firebirdSQL ca peut casser les pieds pas mal) mais ca sera la. Et puis a l'heure actuelle Firebird (bien qu'il s'ameliore de jours en jours) est un produit de deuxieme ligne, et phoenix un produit phare. Imaginons que firebird passe en produit phare (et il en a tout a fait les moyens). Le snon inities risquent quand meme de se retrouver un peu perdu.
Par contre en ce qui concerne la demande faite sur le site de firebird d'envoyer des emails aux responsable sc'est tout a fait justifie. Une des excuses de Mozilla est de dire que les gens se moquent du SGBDR qu'ils utilisent. Si ils recoivent 6000 mails de gens qui disent "non moi je veux firebird et ca a de l'importance pour moi" ils l'auront bien cherche, c'est pas tres louable comme methode, mais ca n'enfreint en rien la nethiquette.
Kha
1) Tu considères qu'un site est responsable d'un spam (« à éviter » ?) alors qu'il ne peut s'agir que du lieu d'où l'adresse à été pompée.
Ben oui mais c'est assez pratique de connaitre les sites ou on ne peut pas s'inscrire en toute tranquilite. Je me moque que le site ait revendu mon dresse mon email, ou ce soit fait pomper ses emails a son insu. Pour moi le resultat est le meme. De plus ce n'est pas professionnel de laisser l'email d'un client vous filer entre les pattes. On se demande toujours ce qui peut arriver aux autres informations que l'on a laisse sur le site.
2) T'es obligé de toi même ajouter une règle par spam... fastidieux.
Ben ca arrive pas si souvent que ca en fait, je n'ai pas l'habitude de laisser des adresses emails (meme jetables) n'importe ou. Et puis entre ca et du spam le choix est vite fait. surtout qu'en fait je n'ai qu'une seule regle (mail box doesn't exist) dans laquelle je rajoute un mot clef a chaque fois (pas de quoi pleurer, ca prend 30 secondes chrono en main).
Kha
If you hold the unix shell to your ear, can you hear the C ?
(Pour les non-rôlistes, CROC est le gars qui à pondu le système de règles et le background d'INS/MV.)
Je crois que le terme exact est "vole". Il y a encore un mec qui pleure avec chaque nouvelle edition, et qui se tape la tete contre les murs d'avoir envoye les regles de son jeux a CROC.
Ceci dit INS/MV reste un bon jeu, mais l'idee et le premeir set de regle ne sont pas de CROC.
Kha
N'ecrasez pas les opposums
(sans interet majeur vis a vis de linux, merite des -1, considere comme un troll sur pas mal d'autres listes de diffusions etc.)
Personellement j'utilise un catch all pour me defendre du spam. Ca ne marche pas trop mal. A part certaines adresse que je laisse en "clair" comme sur linuxfr, la plupart du temps quand je doit laisser une adresse email sur un site pour une raison X ou Y (devellopeur=je veux des docs=je m'inscrit partout), je laisse une adresse de la forme nospam_lesite@mondomaine.org.
Derriere si je me prend du spam sur cette adresse je sais que lesite est a eviter. Je met en place une regle "unknown mailbox" et generalement le spam se calme tout seul.
Un truc que je fais aussi pas mal dans les desinscription c'est de faire tourner un robot en perl qui desisncrit une persone toute les 5 minutes . Si c'est une vraie desinscription ca ne change rien, par contre si c'est une collecte d'email deguisee, la base devient completement inutilisable en moins de 48h. C'est un systeme assez efficace et assez facile a mettre en place. Mais il faut bien verrifier que les noms de domaines utilisees n'existent pas. Generalement passe 16 lettres on est assez tranquille.
J'ai reussi a tout faire fonctionner sauf le port USB central et le lecteur memory stick integre(qui plante au boot en entrainant avec lui le port USB...). Par contre je grave des DVD, je capture en raw et en video depuis ma camera DV et l'ACPI tourne au poil.
Je suis sur un kernel 2.5.67 pour avoir toutes les fonctions ACPI, et j'utilise Window Maker et Fluxbox comme wm principaux. Le DRI est un peu bancal (modules beta oblige) mais les extensions GLX tournent bien. KDE deconne un peu quand le DRI est actif, il a donc sa propre configuration X.
Je suis sous Gentoo (pas taper) avec comme flags pentium4 pour le march et -O2 (je vois pas l'interet d'un O3 sur PIV, surtout vu qu'il est encore un peu bugge).
Par contre les logiciels fournis de base sont une vrai plaie, impossible de se les faire rembourser, et il sont speficiques Sony donc impossible de les revendre ou de les donneri (GRRRR...).
Sinon je suis vraiment tres content de la bete. Je situe mon niveau vis a vis de linux a intermediaire, et avec la Gentoo j'ai eu quelques ennuis a tout monter (aussi je voulais que TOUT fonctionne en meme temps). J'ai entendu dire que sur des modeles similaires la Mandrake 9.1 s'installait comme un charme.
Ben oui mais la c'est un bios, on a bien un systeme d'entree-sortie basique (ie fourni de base) non ? La notion de bios n'est en aucun cas limitee aux ordinateurs.
La difference majeure entre firmware/FLASH, EEProm ou EProm et bios et la suivante :
EProm : effacable programable rom : C'est un support memoire ROM qui est programmable et effacable, EEprom : electriquement effacable, Flash : effacable par segment (on est pas oblige d'effacer toute la prom a chaque fois). Il s'agit ici d'une composante materielle. Apres je met ce que je veux dessus, un programme, des donnees, un melange de tout ca... Ca me regarde.
Firmware : Interface logicielle ayant pour but de simplifier ou d'authoriser l'acces a certaines parties materielles. Les firmwares sont mis en place des qu'un simple controlleur d'entrees/sorties hardware ne fait plus le poid. Le firmware a la particuliarite d'etre integree a l'element de hardware dont il permet le pilotage.
Bios : Extension du Firmware, les Bios sont des logiciels capables de transformer une interaction sur l'interface en une commande ou en une suite de commandes adaptees. La difference majeure entre un bios et un firmware c'est qu'un bios est capable de s'initialiser tout seul et de mettre a dispotion ses fonctionalites dans l'environement dans lequel il se trouve de lui meme. Une carte graphique, une carte SCSI, un watchdog possedent des bios. Par contre un lecteur CDrom ou un disque dur (meme SCSI) possedent des firmwares. Si un systeme s'initialise tout seul grace a un programme, alors on peut considerer se programme comme un bios.
L'archeos s'allume et fonctionne quand on met des piles dedans et que l'on appuie sur le boutton, il contient donc bien un bios.
1. Pour les threads, la compatibilite etant toujours assure via la norme posix thread le probleme ne se pose meme pas (xfree ne fait pas dans les internes des implementations).
Tout a fait vrai pour les applis (en theorie hein, on va pas parler des exceptions type wine), par contre completement faux pour le hardware, surtout dans si le noyau preemptif devient le standard. La gestion de thread dans une application OpenGL acceleree qui est par exemple multifenetres (donc plusieurs fenetres accelerees), risque de changer pas mal. En fait le probleme n'est pas XFree en lui meme mais plutot les differents drivers. Cote XFree c'est les drivers GLX et DRI qui m'inquietent un peu. Mais d'un autre cote c'est aussi les drivers qui font la force d'XFree. L'initialisation et la relache du mode DRI sont aussi loin d'etre evident, et une fois de plus comme on jongle avec du hardware d'un cote, c'est pas evident de changer.
Pour faire simple si une ancienne application demande a creer des threads ancien format le wrapper fait son office et tout va bien. Par contre si une nouvelle application demande a creer des threads nouveaux formats avec des fonctions qui font appel a un driver ancien format, la je ne sais pas trop ce qui se passe et comme c'est XFree qui fait tampon ...
2. Pour le noyau, les besoins en APIs de Xfree/DRI/AGP* sont assez minimaux: du genre allocations de DMA, communications PCI, ... donc la aussi la question de l'evolution ne se pose meme pas.
Oui si on part du principe que des fonctions de type transparences hard, T&L, shaders, couleur en flottant et j'en passe ne sont pas interressantes ou doivent etre integralement releguees a X. Perso j'aime bien l'idee de pouvoir me servir de la puissance de calcul de ma CG sans pour autant avoir une session XFree ouverte(il y a un paquet de clusters Maya qui partagent mon opinion).
3. Pour l'openGL, tout le probleme vient du fait que l'API a tres mal vieillit pas rapport, par exemple, aux evolutions de D3D. Pour gerer ce qu'entrevoit les premiers drafts de l'openGL2.0 il faudra pas mal de modifs mais ca ne sera pas en gardant l'ancien principe de developpement de Xfree86 que ca sera possible.
Ah non, OpenGL ca veillit super bien. Le seul truc est de savoir pourquoi ca a ete fait au depart. OpenGL a ete pense comme un generateur d'etats, et n'a pas du tout ete oriente temps reel a la base. Dire que OpenGL a du retard sur D3D c'est comme de dire qu'Acrobat writter est encore loin derriere Word. C'est vrai qu'Acrobat writter comme traitement de texte c'est assez leger. Mais c'est pas fait pour ca.
De plus l'architecture extremement souple d'OpenGL lui permet souvent d'etre au contraire plutot en avance sur D3D d'un point d evue global meme si l'ARB a plutot du retard, je suis bien d'accord.
Le seul probleme avec OpenGL 2.0 c'est surtout qu'on ne sait pas ce qui va etre utilise et/ou implemente. Avant la gueulante de Carmac il ne serait venu a l'idee d'aucun fabriquant de CG de faire des couleurs en flottant. De meme la fonction Render to Render (permet de refaire passer une image completement a travers le pipeline) n'a jamais ete utilisee, ou implementee, ca rend justement la mise en place de Mesa comme nerf de la guerre un peu delicate a l'heure actuelle.
C'est vrai que la meilleure facon d'avoir un systeme propre, rapide, modulaire et avec autant de "bonbon pour les yeux" que l'on veut est de passer par OpenGL. Mais en ce moment ca me parait un peu casse-gueule.
Je ne sais pas mais la j'ai comme un doute, le projet XFree ressemble un peu a tout et n'importe quoi en ce moment. Entre DRI qui ne rentre pas dans XFree, les systemes de thread et de modules en plein chamboulement, des drivers qui poussent comme des champignons (la je parle pour moi, sur mon ATI j'ai un plus de douzes drivers differents), et la norme OpenGL qui est en train de subir une restructuration complete alors que les fabriquants de cartes graphiques parlent d'emuler toutes les fonctions T&L via les shaders. Sans compter certains support d'acces "raw" aux fonctions videos evoluees (capture firewire avec preview par exemple).
Je n'ai rien contre un fork de XFree, en fait ca fait meme un moment que j'attendais ca (d'accord je suis carrement aigri par la liste de "gentilles" reponses que j'ai recu de la part de ce projet) mais pas maintenant. Sincerement, le moindre changement dans XFree entrainne des prises de tete pendant des heures (essayez de compiler les drivers Radeon du CVS au nouveau format de module pour voir). Et la on est en train de parler d'une reecriture complete. Donc soit il y a un grand pas en arriere, avec support minimaliste des fonctions 3D, et la c'est jouable mais qui va etre interresse par un nouveau projet qui ne propose que des fonctionnalites en moins (meme si l'architecture est belle). Soit il y a un grand pas en avant, a savoir on impose des normes nouvelles en profitant du fait que l'on ait pas de support a apporter aux anciennes versions, mais a ce moment la combien de projet vont devoir etre reecrit ou du moins etre adapte.
Bien que XFree soit stable d'un point de vue programme, il est plus qu'instable d'un point de vue projet. et je pense sincerement que c'est pas du tout le moment de faire un fork. Pas avant un an, histoire d'attendre que les choses se tassent, et que l'on sache un peu mieux ou l'on va en matiere de carte graphique, d'OpenGL, de noyeau et de threads.
Attention quand meme, si il est vrai que la technique du BSA a ici echoue, elle n'en reste pas moins redoutbale.
Les gens du BSA ne viennent pas juste dire "vous etes en infraction, voici l'amende", ca n'a aucun interet pour eux. Leur technique c'est de dire c'est soit 100 000$ d'ammendes, soit vous regularisez toute vos licenses et vous vous engagez a n'utiliser que des produits et logiciels de nos clients a chaque fois que c'est possible, et ce pendant 3 ans.
Quand on sait que le support WinNT par MS s'arrette en aout, on comprend pourquoi ils deviennent vachement actif en ce moment. Parceque le nombre d'entreprise capable de dire "OK on paie l'ammende et au revoir Windows" est quand meme vachement reduit, surtout en ce moment.
Y'en a, comme ça, qui se prennent pas pour le centre du monde ; )=
Allons, allons tout le monde sait bien que la seule facon correcte de se servir de linux c'est en Gnome2 avec Galeon beta et le dernier kernel patche par Alan Cox. Mort a tous ceux qui utilisent KDE 3.0.2.25 en theme noia 2.32 sur un kernel 2.5.64 !
La bonne nouvelle c'est qu'en plus des trolls Gnome/KDE on aura bientot les trolls Karamba/Slicker.
"améliorer" le DMCA au point qu'il soit interdit d'utiliser, de vendre ou de posseder des technologies qui dissimulent la source ou la cible de communications électroniques
extrapolons un peu :
Le broadcast devient interdit (je ne connais meme pas ma cible, pour ce qui est de la dissimuler c'est top) et par extension tout le systeme DHCP tombe a l'eau. Le reseau tele cable (MPEG2=communication electronique, meme si c'est juste de la diffusion) doit s'assurer que chaque chaine sache qui la regardait et a quel moment.
Toutes les formes de relaying, tunneling, masquarading etc. sont interdites, les systemes de routages doivent etre en 1--1 dites au revoir au clustering.
Non seulement les firewalls mais tout systeme de DMZ passe a la trappe. Les systemes de redirection de paquets sont interdits.
Transporter une disquette ou n CD grave d'un point A a un point B (ca peut etre considere comme un "moyen de communication electronique") devient illegal, par extension la possession d'une disquette ou d'un cd gravable aussi.
Et le plus beau : les satellites doivent avoir un moyen de savoir qui recoit les informations qu'ils emettent, sans quoi toute personne qui
possede une technologie dependante des satellites est hors la loi (pas grave c'est juste la tele, le telephone, la radio etc.)
simple question : dans une optique serveur le / a 128 Mo ca me parait un peu juste, alors que dans une optique workstation c'est le /usr de 1,3Go qui me parait limite.
C'est vraiment une config que tu utilise ou c'est la juste pour tester les back-up/restore ?
et au passage a l'heure d'hiver c l'inverse, si on y a pas pensé, certaines tournent deux fois !
Oui j'ai connu un damin qui s'etait trouve vachement malin de mettre le changement d'heure dans la Cron pour plus y penser, tres drole... la date sur l'ordi a pas bouger pendant pres de 36 heures, week end oblige.
désolé, mais c'est la norm TCPA qui prévoit que les BIOS devront réaliser un digest de l'OS loader
Ca ca m'interresse comme info, tu as les sources STP ? Je vois assez mal comment le bios pourrait faire un digest de l'OS loader (ni meme savoir quand il a a faire a un OS Loader) et la norme EFI des nouveau bios INTEL risque de ne carrement pas aider.
Je conviens qu'il n'y a quasiment rien a ajouter au bios pour qu'il serve d'outil de DRM, avec ou sans TCPA.
Par contre le fait qu'il y ait du TCPA ou non sur un ordi ne change rien a ce qu'il faut ajouter au bios pour le transformer en outil DRM.
les clés de cryptage seront différentes sur chaque machine: les rendre publique ne servira à rien
Par rendre publique je voulais dire deplacer dans une entite independante du PCR.
tout le monde n'aura pas 2 TPM pour faire des manipes
Ben en fait si a peu de chose pres. Pour que ce genre d'operation serve a quelque chose il faut que tout les ordis soient equipes. Donc on risque de voir fleurir des PC avec TCPA partout.
les connexions permanentes à Internet couplées avec le mécansime d'identification d'OS à distance suffisent à ce que les clés de crypto ne soient pas stockées du tout dans ton ordinateur:
Et vu que TCPA est un coffre a clef et qu'il ne permet pas d'identifier un OS, en quoi est il mele a tout ca ?
un BIOS vicieux pourrait faire ceci: détection d' un OS loader encrypté de MS. Décryptage à la volé de cet OS loader qui contient de clés de cryptage seules connues de MS. Utilistion de ces clés en conjonction avec les informations de boot TCPA garantissant que le premier OS booté est bien un OS MS, pour crypter des fichiers en ayant la certitude qu'ils ne seront pas lisibles par un autre OS. Il est deja capable d'identifier un OS Loader, de le decrypter tout seul. Je suppose que ton OS Loader n'est pas sur le MBR mais sur la partition ammorcee (Donc techniquement on est deja apres loin du POST), le decrypter a ce moment la assure au bios que l'OS qui va etre boote est bien Windows. Dans le cas ou ton OS loader est sur le MBR alors on ne peut booter que Windows (le fait de faire du multiboot changerait surement la signature de l'OS Loader).
Donc un bios qui sait faire tout ca, il n'a pas besoin de TCPA pour bloquer des infos aux autres OS eventuellement installes sur la machine.
Une fois de plus dans ce cas la c'est le bios qui fait le boulot. C'est le bios qui fait le digest de l'os loader (si c'est la puce TCPA qui le fait on est sur qu'il sera different suivant les plateformes). Et c'est ensuite le bios qui decide en fonction de la sequnce de boot si il doit reveler ses informations ou non. En d'autres termes le bios devient capable d'implementer DRM sans TCPA. Donc oui dans ce cas on a un PC DRM, non ce n'est pas grace ou a cause de TCPA.
a différence est que une fois booté, l'OS certifié pourra utiliser TCPA pour s'assurer de la signature du BIOS, pour s'assurer de la signature de l'OS loder, etc...
Oui mais si le bios est deja capable de planquer des clefs ou des tokens a un OS, il n'a plus besoin de TCPA pour fiare du DRM, il peut le faire tout seul. C'est clair que si on un systeme qui est deja pret pour le DRM, on peut en plus mettre du TCPA dedans, mais de la a dire que TCPA aide le DRM il y a un gouffre.
Cependant les messages postés ici sur linuxfr ont bien montré qu'il était possible d'utiliser le PCR pour faire du controle de type DRM
C'est justement ca qui m'ennuit, je ne sais pas si c'est possible, mais je ne pense pas que tu connaisses de methodes qui permette d'utiliser TCPA pour faire du DRM. N'oublie pas que
-Toute clef qui est migrable peut etre recupere independament du fait qu'elle appartienne a un TPM ou pas
-Toute clef qui interagit avec l'exterieur est miggrable.
Pas evident du faire du DRM avec ca, le risque que des petits malins sortent les clefs et les duplique sur d'autres TPM (voir meme les revellent en clair) est trop grand.
le contenu du blob de migration n'est pas crypté ?
Si bien sur le contenu du blob est crypte, mais avec une clef publique fournie par l'exterieur. Si il etait crypte avec une clef du TPM ca serait pas evident de migrer la clef...
en tout cas faire un backup des clés protégées par PCR suppose des droits complets sur la puce
Droit owner sur le TPM et droit sur une entite parente de la clef, cela ne correspond pas du tout a des droits complets, mais effectivement il faut pas mal de droits.
seul le BIOS possede les tokens d'authentification et ne les donne pas à l'utilisateur
La ca suppose quand meme que le bios possede un systeme d'identification de l'OS qu'il est en train de booter, donc techniquement il implemente deja sans TCPA un systeme equivalent a la certification d'OS. En d'autres termes le probleme existe deja sans TCPA. Un bios capable de refuser de relacher certaines ressources a la vue d'un OS est evidemment un des cauchemars du libre. Mais une fois d eplus dans cet environement la on ne peut pas accuser TCPA, c'est le bios qu'il faut flinguer.
[^] # Re: Polices Vera de Bitstream, version 1.10
Posté par Jerome Herman . En réponse à la dépêche Polices Vera de Bitstream, version 1.10. Évalué à 10.
Bof les projets Gnome et KDE ont jamais vraiment ete en guerre. Il y a meme u paquet de trucs qui ont ete fait de consors et ce depuis le debut. C'est surtout les utilisateurs qui se trollent les un les autres par forums interposes.
Kha
[^] # Re: Mozilla Firebird versus FirebirdSQL
Posté par Jerome Herman . En réponse à la dépêche Mozilla Firebird versus FirebirdSQL. Évalué à 3.
# Re: Mozilla Firebird versus FirebirdSQL
Posté par Jerome Herman . En réponse à la dépêche Mozilla Firebird versus FirebirdSQL. Évalué à 10.
[^] # Re: Étude sur le SPAM
Posté par Jerome Herman . En réponse à la dépêche Étude sur le SPAM. Évalué à 2.
[^] # Re: Un test négatif (mais constructif) de la Mandrake 9.1
Posté par Jerome Herman . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à 8.
Je crois que le terme exact est "vole". Il y a encore un mec qui pleure avec chaque nouvelle edition, et qui se tape la tete contre les murs d'avoir envoye les regles de son jeux a CROC.
Ceci dit INS/MV reste un bon jeu, mais l'idee et le premeir set de regle ne sont pas de CROC.
Kha
N'ecrasez pas les opposums
(sans interet majeur vis a vis de linux, merite des -1, considere comme un troll sur pas mal d'autres listes de diffusions etc.)
[^] # Re: Un test négatif (mais constructif) de la Mandrake 9.1
Posté par Jerome Herman . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à 9.
STDTROLL > /dev/null
Kha
# Re: Étude sur le SPAM
Posté par Jerome Herman . En réponse à la dépêche Étude sur le SPAM. Évalué à 5.
Derriere si je me prend du spam sur cette adresse je sais que lesite est a eviter. Je met en place une regle "unknown mailbox" et generalement le spam se calme tout seul.
Un truc que je fais aussi pas mal dans les desinscription c'est de faire tourner un robot en perl qui desisncrit une persone toute les 5 minutes . Si c'est une vraie desinscription ca ne change rien, par contre si c'est une collecte d'email deguisee, la base devient completement inutilisable en moins de 48h. C'est un systeme assez efficace et assez facile a mettre en place. Mais il faut bien verrifier que les noms de domaines utilisees n'existent pas. Generalement passe 16 lettres on est assez tranquille.
Kha
Spam, spam, spam. Merveilleux spam, spam, spam.
# Re: acheter un portable sous linux
Posté par Jerome Herman . En réponse au journal acheter un portable sous linux. Évalué à 2.
J'ai reussi a tout faire fonctionner sauf le port USB central et le lecteur memory stick integre(qui plante au boot en entrainant avec lui le port USB...). Par contre je grave des DVD, je capture en raw et en video depuis ma camera DV et l'ACPI tourne au poil.
Je suis sur un kernel 2.5.67 pour avoir toutes les fonctions ACPI, et j'utilise Window Maker et Fluxbox comme wm principaux. Le DRI est un peu bancal (modules beta oblige) mais les extensions GLX tournent bien. KDE deconne un peu quand le DRI est actif, il a donc sa propre configuration X.
Je suis sous Gentoo (pas taper) avec comme flags pentium4 pour le march et -O2 (je vois pas l'interet d'un O3 sur PIV, surtout vu qu'il est encore un peu bugge).
Par contre les logiciels fournis de base sont une vrai plaie, impossible de se les faire rembourser, et il sont speficiques Sony donc impossible de les revendre ou de les donneri (GRRRR...).
Sinon je suis vraiment tres content de la bete. Je situe mon niveau vis a vis de linux a intermediaire, et avec la Gentoo j'ai eu quelques ennuis a tout monter (aussi je voulais que TOUT fonctionne en meme temps). J'ai entendu dire que sur des modeles similaires la Mandrake 9.1 s'installait comme un charme.
Kha
[^] # Re: BIOS?????
Posté par Jerome Herman . En réponse à la dépêche Nouveau BIOS Rockbox (archos Jukebox). Évalué à 10.
Ben oui mais la c'est un bios, on a bien un systeme d'entree-sortie basique (ie fourni de base) non ? La notion de bios n'est en aucun cas limitee aux ordinateurs.
La difference majeure entre firmware/FLASH, EEProm ou EProm et bios et la suivante :
EProm : effacable programable rom : C'est un support memoire ROM qui est programmable et effacable, EEprom : electriquement effacable, Flash : effacable par segment (on est pas oblige d'effacer toute la prom a chaque fois). Il s'agit ici d'une composante materielle. Apres je met ce que je veux dessus, un programme, des donnees, un melange de tout ca... Ca me regarde.
Firmware : Interface logicielle ayant pour but de simplifier ou d'authoriser l'acces a certaines parties materielles. Les firmwares sont mis en place des qu'un simple controlleur d'entrees/sorties hardware ne fait plus le poid. Le firmware a la particuliarite d'etre integree a l'element de hardware dont il permet le pilotage.
Bios : Extension du Firmware, les Bios sont des logiciels capables de transformer une interaction sur l'interface en une commande ou en une suite de commandes adaptees. La difference majeure entre un bios et un firmware c'est qu'un bios est capable de s'initialiser tout seul et de mettre a dispotion ses fonctionalites dans l'environement dans lequel il se trouve de lui meme. Une carte graphique, une carte SCSI, un watchdog possedent des bios. Par contre un lecteur CDrom ou un disque dur (meme SCSI) possedent des firmwares. Si un systeme s'initialise tout seul grace a un programme, alors on peut considerer se programme comme un bios.
L'archeos s'allume et fonctionne quand on met des piles dedans et que l'on appuie sur le boutton, il contient donc bien un bios.
Kha
[^] # Re: Vous etes sur que c'est le bon moment ?
Posté par Jerome Herman . En réponse à la dépêche Fork d'XFree86. Évalué à 4.
Tout a fait vrai pour les applis (en theorie hein, on va pas parler des exceptions type wine), par contre completement faux pour le hardware, surtout dans si le noyau preemptif devient le standard. La gestion de thread dans une application OpenGL acceleree qui est par exemple multifenetres (donc plusieurs fenetres accelerees), risque de changer pas mal. En fait le probleme n'est pas XFree en lui meme mais plutot les differents drivers. Cote XFree c'est les drivers GLX et DRI qui m'inquietent un peu. Mais d'un autre cote c'est aussi les drivers qui font la force d'XFree. L'initialisation et la relache du mode DRI sont aussi loin d'etre evident, et une fois de plus comme on jongle avec du hardware d'un cote, c'est pas evident de changer.
Pour faire simple si une ancienne application demande a creer des threads ancien format le wrapper fait son office et tout va bien. Par contre si une nouvelle application demande a creer des threads nouveaux formats avec des fonctions qui font appel a un driver ancien format, la je ne sais pas trop ce qui se passe et comme c'est XFree qui fait tampon ...
2. Pour le noyau, les besoins en APIs de Xfree/DRI/AGP* sont assez minimaux: du genre allocations de DMA, communications PCI, ... donc la aussi la question de l'evolution ne se pose meme pas.
Oui si on part du principe que des fonctions de type transparences hard, T&L, shaders, couleur en flottant et j'en passe ne sont pas interressantes ou doivent etre integralement releguees a X. Perso j'aime bien l'idee de pouvoir me servir de la puissance de calcul de ma CG sans pour autant avoir une session XFree ouverte(il y a un paquet de clusters Maya qui partagent mon opinion).
3. Pour l'openGL, tout le probleme vient du fait que l'API a tres mal vieillit pas rapport, par exemple, aux evolutions de D3D. Pour gerer ce qu'entrevoit les premiers drafts de l'openGL2.0 il faudra pas mal de modifs mais ca ne sera pas en gardant l'ancien principe de developpement de Xfree86 que ca sera possible.
Ah non, OpenGL ca veillit super bien. Le seul truc est de savoir pourquoi ca a ete fait au depart. OpenGL a ete pense comme un generateur d'etats, et n'a pas du tout ete oriente temps reel a la base. Dire que OpenGL a du retard sur D3D c'est comme de dire qu'Acrobat writter est encore loin derriere Word. C'est vrai qu'Acrobat writter comme traitement de texte c'est assez leger. Mais c'est pas fait pour ca.
De plus l'architecture extremement souple d'OpenGL lui permet souvent d'etre au contraire plutot en avance sur D3D d'un point d evue global meme si l'ARB a plutot du retard, je suis bien d'accord.
Le seul probleme avec OpenGL 2.0 c'est surtout qu'on ne sait pas ce qui va etre utilise et/ou implemente. Avant la gueulante de Carmac il ne serait venu a l'idee d'aucun fabriquant de CG de faire des couleurs en flottant. De meme la fonction Render to Render (permet de refaire passer une image completement a travers le pipeline) n'a jamais ete utilisee, ou implementee, ca rend justement la mise en place de Mesa comme nerf de la guerre un peu delicate a l'heure actuelle.
C'est vrai que la meilleure facon d'avoir un systeme propre, rapide, modulaire et avec autant de "bonbon pour les yeux" que l'on veut est de passer par OpenGL. Mais en ce moment ca me parait un peu casse-gueule.
Kha
# Vous etes sur que c'est le bon moment ?
Posté par Jerome Herman . En réponse à la dépêche Fork d'XFree86. Évalué à 2.
Je n'ai rien contre un fork de XFree, en fait ca fait meme un moment que j'attendais ca (d'accord je suis carrement aigri par la liste de "gentilles" reponses que j'ai recu de la part de ce projet) mais pas maintenant. Sincerement, le moindre changement dans XFree entrainne des prises de tete pendant des heures (essayez de compiler les drivers Radeon du CVS au nouveau format de module pour voir). Et la on est en train de parler d'une reecriture complete. Donc soit il y a un grand pas en arriere, avec support minimaliste des fonctions 3D, et la c'est jouable mais qui va etre interresse par un nouveau projet qui ne propose que des fonctionnalites en moins (meme si l'architecture est belle). Soit il y a un grand pas en avant, a savoir on impose des normes nouvelles en profitant du fait que l'on ait pas de support a apporter aux anciennes versions, mais a ce moment la combien de projet vont devoir etre reecrit ou du moins etre adapte.
Bien que XFree soit stable d'un point de vue programme, il est plus qu'instable d'un point de vue projet. et je pense sincerement que c'est pas du tout le moment de faire un fork. Pas avant un an, histoire d'attendre que les choses se tassent, et que l'on sache un peu mieux ou l'on va en matiere de carte graphique, d'OpenGL, de noyeau et de threads.
kha
(mes deux cents)
[^] # Re: Taper sur le clou ;)
Posté par Jerome Herman . En réponse à la dépêche La BSA aide GNU/Linux. Évalué à 10.
Les gens du BSA ne viennent pas juste dire "vous etes en infraction, voici l'amende", ca n'a aucun interet pour eux. Leur technique c'est de dire c'est soit 100 000$ d'ammendes, soit vous regularisez toute vos licenses et vous vous engagez a n'utiliser que des produits et logiciels de nos clients a chaque fois que c'est possible, et ce pendant 3 ans.
Quand on sait que le support WinNT par MS s'arrette en aout, on comprend pourquoi ils deviennent vachement actif en ce moment. Parceque le nombre d'entreprise capable de dire "OK on paie l'ammende et au revoir Windows" est quand meme vachement reduit, surtout en ce moment.
Kha
[^] # Re: Un grand pas pour l'interface de KDE ?
Posté par Jerome Herman . En réponse à la dépêche Un grand pas pour l'interface de KDE ?. Évalué à -10.
Allons, allons tout le monde sait bien que la seule facon correcte de se servir de linux c'est en Gnome2 avec Galeon beta et le dernier kernel patche par Alan Cox. Mort a tous ceux qui utilisent KDE 3.0.2.25 en theme noia 2.32 sur un kernel 2.5.64 !
La bonne nouvelle c'est qu'en plus des trolls Gnome/KDE on aura bientot les trolls Karamba/Slicker.
Que du bonheur en perspective.
Kha
(tty1 RUL3Z !)
[^] # Re: Linux sur LCI
Posté par Jerome Herman . En réponse à la dépêche Linux sur LCI. Évalué à 2.
Kha
Kernel 2.5.65 is good for you
# Re: 8 états des USA veulent interdire le NAT
Posté par Jerome Herman . En réponse à la dépêche 8 états des USA veulent interdire le NAT. Évalué à 10.
extrapolons un peu :
Le broadcast devient interdit (je ne connais meme pas ma cible, pour ce qui est de la dissimuler c'est top) et par extension tout le systeme DHCP tombe a l'eau. Le reseau tele cable (MPEG2=communication electronique, meme si c'est juste de la diffusion) doit s'assurer que chaque chaine sache qui la regardait et a quel moment.
Toutes les formes de relaying, tunneling, masquarading etc. sont interdites, les systemes de routages doivent etre en 1--1 dites au revoir au clustering.
Non seulement les firewalls mais tout systeme de DMZ passe a la trappe. Les systemes de redirection de paquets sont interdits.
Transporter une disquette ou n CD grave d'un point A a un point B (ca peut etre considere comme un "moyen de communication electronique") devient illegal, par extension la possession d'une disquette ou d'un cd gravable aussi.
Et le plus beau : les satellites doivent avoir un moyen de savoir qui recoit les informations qu'ils emettent, sans quoi toute personne qui
possede une technologie dependante des satellites est hors la loi (pas grave c'est juste la tele, le telephone, la radio etc.)
Kha
[^] # Re: HOW-TO : backup d'un système Linux
Posté par Jerome Herman . En réponse au journal HOW-TO : backup d'un système Linux. Évalué à 2.
C'est vraiment une config que tu utilise ou c'est la juste pour tester les back-up/restore ?
Kha
[^] # Re: Attention : Heure d'été
Posté par Jerome Herman . En réponse au journal Attention : Heure d'été. Évalué à 2.
Oui j'ai connu un damin qui s'etait trouve vachement malin de mettre le changement d'heure dans la Cron pour plus y penser, tres drole... la date sur l'ordi a pas bouger pendant pres de 36 heures, week end oblige.
Kha
La cron c'est bien, en abuser ca craint...
[^] # Re: Heu, les becanes non
Posté par Jerome Herman . En réponse au journal Attention : Heure d'été. Évalué à 0.
Kha
Amusant comme certaines personnes ont vraiment du mal a sortir de certaines logiques...
[^] # Re: Demontage en regle
Posté par Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 1.
Ca ca m'interresse comme info, tu as les sources STP ? Je vois assez mal comment le bios pourrait faire un digest de l'OS loader (ni meme savoir quand il a a faire a un OS Loader) et la norme EFI des nouveau bios INTEL risque de ne carrement pas aider.
Kha
[^] # Re: Demontage en regle
Posté par Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 0.
Par contre le fait qu'il y ait du TCPA ou non sur un ordi ne change rien a ce qu'il faut ajouter au bios pour le transformer en outil DRM.
Kha
[^] # Re: Demontage en regle
Posté par Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 1.
Par rendre publique je voulais dire deplacer dans une entite independante du PCR.
tout le monde n'aura pas 2 TPM pour faire des manipes
Ben en fait si a peu de chose pres. Pour que ce genre d'operation serve a quelque chose il faut que tout les ordis soient equipes. Donc on risque de voir fleurir des PC avec TCPA partout.
les connexions permanentes à Internet couplées avec le mécansime d'identification d'OS à distance suffisent à ce que les clés de crypto ne soient pas stockées du tout dans ton ordinateur:
Et vu que TCPA est un coffre a clef et qu'il ne permet pas d'identifier un OS, en quoi est il mele a tout ca ?
un BIOS vicieux pourrait faire ceci: détection d' un OS loader encrypté de MS. Décryptage à la volé de cet OS loader qui contient de clés de cryptage seules connues de MS. Utilistion de ces clés en conjonction avec les informations de boot TCPA garantissant que le premier OS booté est bien un OS MS, pour crypter des fichiers en ayant la certitude qu'ils ne seront pas lisibles par un autre OS. Il est deja capable d'identifier un OS Loader, de le decrypter tout seul. Je suppose que ton OS Loader n'est pas sur le MBR mais sur la partition ammorcee (Donc techniquement on est deja apres loin du POST), le decrypter a ce moment la assure au bios que l'OS qui va etre boote est bien Windows. Dans le cas ou ton OS loader est sur le MBR alors on ne peut booter que Windows (le fait de faire du multiboot changerait surement la signature de l'OS Loader).
Donc un bios qui sait faire tout ca, il n'a pas besoin de TCPA pour bloquer des infos aux autres OS eventuellement installes sur la machine.
Kha
[^] # Re: Demontage en regle
Posté par Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 1.
Kha
[^] # Re: Demontage en regle
Posté par Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 1.
Oui mais si le bios est deja capable de planquer des clefs ou des tokens a un OS, il n'a plus besoin de TCPA pour fiare du DRM, il peut le faire tout seul. C'est clair que si on un systeme qui est deja pret pour le DRM, on peut en plus mettre du TCPA dedans, mais de la a dire que TCPA aide le DRM il y a un gouffre.
Kha
[^] # Re: Demontage en regle
Posté par Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 1.
C'est justement ca qui m'ennuit, je ne sais pas si c'est possible, mais je ne pense pas que tu connaisses de methodes qui permette d'utiliser TCPA pour faire du DRM. N'oublie pas que
-Toute clef qui est migrable peut etre recupere independament du fait qu'elle appartienne a un TPM ou pas
-Toute clef qui interagit avec l'exterieur est miggrable.
Pas evident du faire du DRM avec ca, le risque que des petits malins sortent les clefs et les duplique sur d'autres TPM (voir meme les revellent en clair) est trop grand.
Kha
[^] # Re: Demontage en regle
Posté par Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 1.
Si bien sur le contenu du blob est crypte, mais avec une clef publique fournie par l'exterieur. Si il etait crypte avec une clef du TPM ca serait pas evident de migrer la clef...
en tout cas faire un backup des clés protégées par PCR suppose des droits complets sur la puce
Droit owner sur le TPM et droit sur une entite parente de la clef, cela ne correspond pas du tout a des droits complets, mais effectivement il faut pas mal de droits.
seul le BIOS possede les tokens d'authentification et ne les donne pas à l'utilisateur
La ca suppose quand meme que le bios possede un systeme d'identification de l'OS qu'il est en train de booter, donc techniquement il implemente deja sans TCPA un systeme equivalent a la certification d'OS. En d'autres termes le probleme existe deja sans TCPA. Un bios capable de refuser de relacher certaines ressources a la vue d'un OS est evidemment un des cauchemars du libre. Mais une fois d eplus dans cet environement la on ne peut pas accuser TCPA, c'est le bios qu'il faut flinguer.
Kha