zerkman a écrit 1107 commentaires

Oui, c'est ce qu'on appelait les serveurs RTC. La plupart n'acceptaient qu'une, voire deux connexion(s) distante(s) à la fois, selon le nombre de lignes consacrées. Apparemment il était possible d'avoir plus de lignes accessibles par un seul même numéro, mais ça dépasse mes connaissances.

La matos nécessaire était un PC/Amiga/Atari avec autant de ports série et modems (4800 bps suffisaient !) que de lignes téléphoniques consacrées.

C'étaient surtout des serveurs tenus par des passionnés, pour des passionnés d'informatique, de jeux interactifs, et autres forums de discussion sur minitel.

Par ex j'ai retrouvé une vieille liste de RTC datant de 1995:
http://3430.online.fr/computing/servers/rtc_list.htm

Oui, je serais curieux de savoir ce que ça donne.

Il y a donc toujours un hyperviseur / micronoyau (pour les consoles non firmware 3) qui empeche un accès direct au processeur graphique ?
oui, il a toujours été là.

Alors, comment le contourner ? en fait le faire péter sera suffisant...
pour l'instant personne n'a la réponse.

je suis en train de te répondre en utilisant Firefox sur ma PS3 sous Debian.

L'utilisation est plus que correcte, on n'a certes pas la réactivité d'un core duo, mais comparativement aux mac G5 d'il y a quelque temps il n'a pas à rougir.

J'utilise aussi Inkscape, Gimp, Blender, les compilateurs GNU (non, pas Emacs) et ça tourne au poil. Faut juste faire gaffe à avoir un environnement pas trop lourd en mémoire, donc mon bureau c'est Icewm couplé au filer Rox.

Pour ce qui est de l'accélération des applications, en général plus de 90% du temps CPU est passé dans moins de 5% du code d'une appli. Donc c'est juste ces 5% de code qu'il faut accélérer avec les SPE, le reste peut rester tel quel. L'optimisation sur Cell ne nécessite pas de réécrire toute une appli, heureusement !

Enfin, pour une utilisation desktop, même si je suis d'accord qu'on n'aura pas d'accélération 3D correcte sans le RSX, le Cell peut faire de très belles choses pour ce qui est de l'accélération 2D (scaling, blitting, conversions type RGB/YUV en tout genre).
Par contre ce qui est clair c'est que ça reste à faire, et trop peu de personnes du monde du libre se sont mises à ce genre de travail.

toutafé, c'est ça le plus drôle. J'ai même l'impression que tout le monde chez Sony n'était pas au courant de la suppression de l'otheros.

En gros les principaux contributeurs de Sony dans le noyau Linux étaient aux USA et en Europe, et n'ont pas vu venir la baffe venue du Japon... J'attends leurs réactions sur les mailing lists.

Le mode otheros sur PS3 permet de lancer un noyau Linux, qui pour tout ce qui est accès au GPU est obligé de passer par des appels à l'hyperviseur.

Les appels hyperviseur pour l'affichage sont très limités, mais permettent quand même un certain nombre de choses, comme les transferts de données entre la RAM vidéo et la RAM principale et vice versa (c'est comme ça que fonctionne le module PS3VRAM dont je parle au dessus), les changements de mode graphiques, ou la synchro VBL. Il n'y a pas d'accélération 3D ni même 2D.

Je ne vois absolument pas de quoi tu veux parler ... tu ne confondrais pas micro-noyau et hyperviseur par hasard ?

et l'accès à la VRAM est autorisé depuis le départ par l'hyperviseur justement. Yellow Dog n'a rien à voir avec cela, c'est juste qu'un module pour mapper la VRAM dans le système de fichiers a été inclus dans les dernières versions du noyau, permettant par exemple d'utiliser la VRAM comme espace de swap.

et sinon pour l'accès total au matériel, il n'y a absolument rien là dessus. Tu confonds pas avec la xbox 360 ?

et une fois pour toutes : ce n'est PAS la mise à jour du firmware qui bloque l'otheros, mais une limitation hardware sur les PS3 slim. les autres modèles continueront à avoir accès à l'otheros.

We felt we wanted to move forward with the OS we have now [...] We wanted to standardize our OS

Oh, la belle langue de bois.

Surtout que l'otheros n'a rien à voir avec l'OS de la PS3, les deux peuvent parfaitement cohabiter. C'est de l'enfumage de la plus belle espèce.

Les hackers n'avaient pas de raison d'essayer de casser le système comme cela a été fait sur toutes les autres consoles, vu qu'ils avaient déjà de quoi s'amuser.

Et puis je trouve que Sony se faisait de la bonne publicité pas cher en laissant l'accès à la machine, même si ce n'était qu'en partie.

Oui, ou sinon l'installation du bootloader sur le disque dur interne de la machine ne me parait pas non plus technologiquement insurmontable.

A part des économies de bouts de chandelle (une flash en moins), je ne vois pas l'intérêt. Par contre je ne suis pas sûr que l'otheros intéressait grand monde à la base, par contre la baisse de 100 euros est un argument bien plus déterminant pour gonfler les ventes :/

Ce n'est pas forcément évident. La distinction n'est pas très claire dans ce qu'ils appellent le "PS3 system" entre la partie matérielle est la partie logicielle.

Sur les modèles actuels, une petite mémoire flash (de l'ordre de 4 Mo) intégrée à la machine permet de stocker un bootloader composé d'un noyau Linux et de quelques outils, généralement BusyBox et kboot, parmi d'autres. On peut supposer que cette flash a été supprimée de la nouvelle PS3 Slim, rendant toute installation de bootloader impossible. Le firmware 3.0 pourrait alors laisser la possibilité d'installer des systèmes autres sur les PS3 pourvues de flash.

De plus le choix du démarrage entre l'OtherOS et le GameOS sur les anciennes machines se fait par le code de boot du processeur, que le système ne maîtrise vraisemblablement pas.

Nous aurons de toutes façons très rapidement la réponse à nos interrogations.

si ça permettait d'éviter les horreurs telles que "language", ce serait salutaire, en effet.

j'ai toujours été nourri avec du vrai lait, pas cette merde infame sans gout

en fait le lait du commerce est transformé, et est normalisé selon un gros paquet de normes:
[http://www2.afnor.org/espace_normalisation/structure.aspx?co(...)]

Cela permet de trouver le même produit, avec les mêmes qualités nutritives, teneur en lipides, garanties d'hygiène etc, quelque soit l'endroit du pays où on l'achète.

Cela permet d'éviter les problèmes liés aux allergies, aux éventuelles contaminations (salmonelles ..), et peut garantir des durées de consommation. Au vu des quantités produites et au peu de problèmes (visiblement) rencontrés, cela est plutôt efficace.

l'odeur, ça aide aussi.

ça en ferait, des licences windoz à payer ...

Une bonne raison de migrer vers YAML ?

Très bon groupe, d'ailleurs.

c'est pas debian-installer ?

sachant que c'est utilisé depuis un paquet d'années dans Debian ...

moi aussi, je suis dubitatif

Justement, je trouve que l'interface Motif de nedit a un côté old school geek qui n'est pas pour me déplaire.

Et je crois que justement la légèreté vient de l'absence de fioritures type polices lissées et interface à la GTK2.

Du coup on peut bosser efficacement sur des machines avec moins de RAM que la norme (qui a dit peu ?) sans les mettre à genoux (ex. une PS3 avec ses 256 Mo bien tassés)

non, on ne lancera pas de troll svn/git/bazaar/mercurial ...

J'ai donc un double ! (cf. un vieil épisode de twilight zone)

J'aurais vraiment du mal à me passer de nedit, il est tout simple et ultra efficace, il fait tout ce que je veux ! avec un peu de config on peut lui faire faire de la complétion automatique avec la touche tab, et après on a l'éditeur ultime !

Possibilité de sélection rectangulaire, excellent pour le formatage de commentaires de code.

son seul défaut est qu'il ne gère pas l'utf-8, mais bon, pour du code c'est pas hyper grave.

Et sinon pour tout ce qui est fichier de conf, édition à distance par ssh, y'a pas mieux que vim.

il manque le / (slash) sur ton clavier, pour vim ça va pas le faire.

je t'avouerai être bien incapable de faire ce genre de choses.

De plus mon exemple était mauvais, car la structure des SVG générés par Inkscape reste relativement compréhensible. Cela dit les chemins de plusieurs centaines de points qui tiennent sur une seule ligne (sous forme de chaîne de caractères), c'est un peu dur à lire.
La structuration XML a ses limites, apparemment. Cela dit je ne crois pas YAML permette de faire mieux.

En fait le gros défaut dans la conception de XML a été de reprendre ce qui servait à écrire des documents (html) pour stocker tout et n'importe quoi. Autant le formatage de documents avec balises avait du sens, et permettait à des humains de modifier facilement des documents complexes à la main, autant le stockage de données, principalement destiné à des machines, n'avait pas besoin de ce genre de fioritures, notamment en raison de la complexité du parsing.

Je ne dis pas que YAML résoud tout niveau légèreté, lisibilité, toussa. Juste que ça me paraît plus adapté au stockage et à l'échange de données informatiques, et l'accessibilité par un humain est garantie par le format.

Par rapport à la lisibilité et l'efficacité: La lisibilité a forcément un coût: fichiers plus gros, temps CPU pour la conversion, etc. Pour une efficacité maximale, ni XML ni YAML ne peuvent rivaliser avec les formats binaires (cités plus bas dans la discussion). Donc autant utiliser un format prévu pour être humainement compréhensible si la performance n'est pas la priorité.