Miair Patreau a écrit 191 commentaires

Ok, merci à Laurent et à toi pour les infos respectives.

Hmm, c'est vrai que XTF a l'air sympa mais je ne sais pas si ça peut convenir pour ça (les balises du module ruby partagent le même espace de nom que le xhtml 1.1).

Je m'en doutais bien que ça ne pouvait pas être simple, mais après tout je n'avais jamais demandé ;-).

Suffit de faire en sorte que ça soit pas indispensable de gérer... Dans le sens contraire, firefox ne gère pas les balises ruby http://www.w3.org/TR/ruby/ et je ne me gêne pas pour autant pour en mettre pour ceux qui utilisent IE... (Quelqu'un saurait me donner un lien "contribuer le support d'une balise à Gecko en 10 leçons" ?)

Remarque, ça fait ça de moins à se procurer pour les jeux vidéos.

Et touts ces superbes nouvelles fonctionalités, dans un pacth de seulement 30 Ko, chers clients ! ^^

Sans compter que ce n'est plus très rare, les faux positifs, et que je me retrouve souvent à défendre un brave webmestre débutant accusé de diffuser des virus sur son site.

C'est d'un facile à expliquer à des néophytes que je suis nettement plus à même qu'un antivirus de dire que non, il n'y a pas de cheval de troie java sur un site où il n'y a pas de java...

Ya pas si longtemps, il ne l'était plus... Je suppose que c'est là l'origine de la plainte.

En même temps c'est un mauvais exemple : quel que soit son catalogue de fonctionnalités, la NGAGE est pourrie une fois qu'on l'a en mains...

Bon, maintenant, j'ai aussi les pieds sur terre : c'est pas demain qu'un truc qui fait aussi console de jeux sera intéressant s'il n'est pas LA console de jeux du moment d'un constructeur spécialiste -_-°.

Faut faire un interpréteur Ruby en php, alors !


C'est bon, c'est bon, je peux sortir tout seul... Hé ! Mais ouvrez la porte avant, au moins !

Mais pourtant, c'est l'idée même du typage dynamique, non ? En conséquence, ça voudrait dire que le typage dynamique est forcément faible (et qu'un typage faible, ça implique qu'il soit dynamique.)

Ou alors, tu veux dire qu'un typage fort et dynamique devrait faire quelque chose du genre :

$a="chaine"
gettype(a) // repond string
settype $a=1
gettype(a) // repond int

Mouais. Je vais regarder ça aussi, mais à mon avis, c'est bien plus moche quand quelque chose n'est pas supporté qu'avec les techniques Ajax.

Ah ouais, tiens. Je connaissais pas Ajax et j'étais jusqu'alors persuadé que c'était pas possible, même avec du javascript. Balèze.

Aaargh. Plein de petites réponses :(.

Bon déjà, loin de moi l'idée d'évoquer une certaine transcendance de la nature humaine

À moi non plus, je me contente de dire qu'une telle transcendance, on n'en a pas, et d'observer certaines choses qui en découlent.

Quand tu te dis incapable d'un tel altruisme, en parlant de ne pas participer au développement d'un soft liberticide, peux-tu développer tes raisons ?

Non, car c'est totalement hors-contexte de ce que j'ai dit. Je voulais dire que moi-même je ne suis pas capable de faire passer le bien-être commun avant tout, quand bien même je préfèrerais. Il n'est pas possible de discuter comme on le fait et d'avoir interprété ça comme ça de bonne foi. Aussi, je te demande de ne pas recommencer.

> une communication massive et sans détour
Ben ... je ne partage guère ton opinion.

Pourtant le fait est que si l'on ne dit pas ce à quoi on aspire, le reste du monde ne risque pas de le deviner. Ce n'est pas pour autant qu'on n'y aspire pas.
Conclusion (rapide) : on ne risque pas de s'entendre sans une communication massive. Si on ne s'entend jamais, les opinions liberticides, ou du moins qui ne sont pas anti-liberticides, sont forcément représentatives, car elles ont tendances à apparaître comme première solution naturelle, que ça nous plaise ou non. Si elles sont représentatives, le système a ses chances de vouloir les appliquer, et on trouvera toujours quelqu'un pour les réaliser. Que ça soit souhaitable ou pas, c'est donc bien nécessaire pour obtenir un monde où refuser de réaliser une technologie liberticide ait un quelconque intérêt pour la société.

Pour le reste, je n'en sais rien. Mais la communication massive me semble être à l'opposé de la pensée unique.

> si quelqu'un ne crée pas cette technologie, quelqu'un d'autre le fera.

Il y a une forme de défaussement sur l'autre que me gêne fort, dans cette proposition.

Mais ça reste factuel. Que ça nous gêne ou pas est hors-sujet.

Pour le reste de la réfléxion, oui, on peut essayer de saboter l'avancement de ce qu'on aime pas... C'est un des points positifs de l'inertie des systèmes. Sans aller jusque là, on peut aussi essayer de faire ce qui est demandé et de profitr de tout ce sur quoi on a carte blanche.

Intéressant.

Même si un de mes produits n'est pas liberticide dans l'absolu, mais que le context bien réel lui (une société unidimensionnelle vouée uniquement au bénéfice financier, par ex ...) laisserait tout à penser qu'il sera très problament utilisé dans un cadre liberticide sans que ne n'y puisse grand chose, je me ferai un devoir devoir de ne pas le créer.

Ce qui est très intègre, mais inutile à la société, voire un gâchi de capacité à limiter les dégâts.

En théorie, si nous vivions dans un monde où tout le monde était de bonne foi et avait comme objectif prioritaire le plus grand bonheur commun, ainsi que la compréhension qu'une communication massive et sans détour est nécessaire pour se rapprocher de ce but ; dans ce cas-là, sans doute peu de gens approuveraient la technologie liberticide et personne de capable n'accepterait de la créer. Nous ne vivons pas dans un tel monde, moi-même je ne suis pas capable d'un tel altruisme bien que j'aimerais l'être. Même si on peut vouloir agir dans ce sens, ignorer les faits présents n'est qu'une erreur.

En conséquence, si quelqu'un ne crée pas cette technologie, quelqu'un d'autre le fera. À choisir, je préfère que les autres principes de cette technologie soient tels que j'y adhère, plutôt que pas. (Bon, en fait, personnellement je refuserais parce que "c'est pas viewtiful." Rien de rationnel.)

> Quand on produit de la connaissance elle peut être utilisée pour le meilleure et pour le pire.

C'est, par exemple, le discours d'un bon nombre de chercheurs ou scientifiques qui savent pourtant pertinament à quel dessein fubèbre seront destinées leurs découvertes ou inventions.

Oui. Et d'autres gens, aussi, genre ceux qui se contentent d'énoncer les choses telles que l'histoire et l'expérience prouvent qu'elles sont. Ou qui ont vu leur formidable invention utilisée dans un contexte militaire/pédophile/violemment discriminant. Aussi.

Bof, ya bien des systèmes qui initialisent toute la mémoire à 0xdeadbeef :).

Bah oui, ce que j'ai dit en est un résumé. Non ?

Sauf erreur, c'est la première solution. Un brevet est validé dès lors qu'il est dûment déposé, sans vérification. D'ailleurs, comment vérifier tout ça ? Ces histoires de validité ou invalidité, c'est juste pour permettre à un tiers de se défendre contre un brevet abusif (dès lors qu'il en a les moyens).

Ah, j'ai oublié. Tu voulais aussi qu'on t'aide. À faire quoi, choisir une distribution, la mettre sur un disque partitionné, construire une disquette de boot qui marche partout... ?

Pour résumer et synthétiser ton idée et les deux autres commentaires, tu veux :

- Partitionner ton disque dur externe USB avec une partition windows (FAT32 ou NTFS ?), et deux partitions linux (c'est-à-dire, mettre une partition swap dessus, aussi ?)
- Emmener ton disque dur externe ainsi construit partout avec toi et ainsi avoir la possibilité de démarrer linux ou de consulter tes données partout où que tu sois.
- Savoir ce qu'on en pense.

Réponse :

C'est faisable et pas bête, mais le fait de démarrer linux avec, ça dépend entièrement de la possibilité de la machine à booter sur un périphérique USB. (Ou alors, il faut aussi prévoir une disquette ou un CD bootable qui serve à démarrer le linux sur le disque dur externe, et ça devient assez compliqué à construire.)

La personne qui va installer linux sur le disque dur externe va devoir tenir compte du fait que ce linux doit pouvoir tourner sur n'importe quel PC, pas seulement celui sur lequel il a été installé, et qu'il est sur un disque USB. Donc, soit mettre une distribution prévue pour (qui sont généralement très légères et doivent être complétées à la main), soit mettre pas mal les mains dans le cambouis.

Ça reste discutable. Qu'une bibliothèque soit implémentée hyperproprement peut également être préférable à son hyperefficacité, pour une hyperbonne maintenance.

Du code non hyper optimisé c'est pas du bon code.

Et ça c'est hyper discutable ;-).

Les emplacements morts de disque dur, c'est comme les pixels morts d'écran LCD. Si on tombe sur la mauvaise pioche, on peut très bien en avoir qui étaient là dès la sortie d'usine.
Et ce n'est pas si évident de voir qu'on a des pertes de données, si elles sont sur des fichiers rarement utilisés, ou où une corruption minime ne se remarque pas. Moi je dis méfiance.

Effectivement, s'il n'y a pas le même résultat suivant les différentes méthodes de visualisation, surtout à ce point-là, alors le diagnostic est discutable. Très bonne idée d'avoir sauvegardé la table des partitions. Bon courage pour la suite.

Vu les symptômes qui sont tout de même très précis (dd sur /dev/hdb), et vu la fiabilité actuelle des disques durs, moi là je penserais que le disque dur /dev/hdb a des emplacements défectueux, qu'il faut le considérer comme mort et ne plus compter dessus (c'est-à-dire, récupérer les données qui peuvent l'être puis ne plus s'en servir). Même s'il est neuf, ça ne change pas grand-chose. C'est un cas que j'ai déjà rencontré (par sur cet octet précis du disque, mais bon...)

Une autre possibilité serait un contrôleur ide défectueux, provoquant des erreurs dont la logique serait difficile à comprendre. Une autre serait un malfonctionnement du DMA, provoquant à nouveau des erreurs difficiles à interpréter (pour vérifier, redémarrer la machine sans DMA, même au niveau du chargeur de boot). Dans les deux cas, c'est quand même assez surprenant.

Une autre, enfin, serait un pilote de disque dur buggé. Assez étrange pour un disque IDE, quand même.

Au fait. les spécifications necessaires à l'écriture d'un pilote sont elles publiées?

Bien sûr que non, vu l'importance qu'a prise l'affaire, si c'était le cas il n'y aurait aucun problème.

Pour ma part, j'apprécierais plus de pilotes libres fournis par les constructeurs, mais je pense que ça les regarde. Par contre, disposer des spécs des produits que j'achète ou m'engage à acheter si les specs vont avec, ça me semble légitime et je le demande souvent (sans succès).

Mais comment dit-on, en C, que notre (nos) fichier(s) se trouve(nt) dans soi-même, a l'adresse _debut_prog et se termine à _fin_prog ?

L'idée, c'est que _debug_prog et _fin_prog soient des symboles exportés. Autrement dit, en lexique C, des variables externes.

Il suffirait de déclarer dans le fichier C :
extern void * _debut_prog, * _fin_prog;

Puis de s'en servir tel quel. Je n'ai pas suggéré cette méthode parce que je ne connaissais pas objcopy (et ne sais toujours pas comment m'en servir.)

C'est normal que ça soit long de transformer un code source de 15 Mo en fichier .o, surtout si le source est composé presque uniquement d'une chaîne de caractère : le compilateur n'est pas du tout prévu pour ça et est très peu efficace (reconnaître la chaîne de caractère, la stocker, l'écrire dans un .S, la reconnaître dans le .S, la stocker, l'écrire dans un .o).

Le mieux est de réaliser un petit programme qui, à partir d'un fichier qui contient les données à inclure, fabrique directement un .o contenant ces données et un symbole exporté de pointeur vers ces données. Autrement dit qui fabrique le .o équivalent à ton fichier source géant mais sans avoir à générer ce fichier source et à le faire transformer en .o par un compilateur.

Donc j'aimerai bien le compiler une fois pour toute en .o et ensuite le lier quand j'en ai besoin a un code C qui accéderait aux variables taille et contenu, c'est possible ca ?

Moi je te dis de laisser tomber cette méthode, mais c'est possible, oui. En admettant que ton fichier .c géant se nomme donnees.c, tu les compiles avec :

gcc -c donnees.c

ce qui crée le fichier donnees.o qui exporte les symboles voulus et peut être lié à tout code qui en a besoin (ou pas). En admettant que ton code qui se base sur la taille et le pointeur vers les données s'appelle main.c, il suffira de faire :

gcc donnees.o main.c -o main

pour créer un fichier exécutable "main" complet. Voilà voilà.