Posté par Gilles G. () le 03/03/2008 à 15:53. (lien). Évalué à 2.

Si tu vas sur:
http://openmosix.sourceforge.net/

tu pourras lire:
The openMosix Project has officially closed as of March 1, 2008.

[ Répondre ]

Posté par Gilles G. () le 22/02/2008 à 17:02. (lien). Évalué à 5.

Par contre, (faut pas rêver) si tu ouvre délibérément ta connexion et que tu ne fais rien pour te protèger, tu est tout aussi responsable. D'autant plus si tu es un professionnel
Ah ouais?
Sous prétexte qu'une voiture est ouverte j'ai le droit de la voler?

[ Répondre ]

Posté par Gilles G. () le 21/02/2008 à 19:13. (lien). Évalué à 10.

Ils sont trop fort chez Microsoft: ils ont eu une (plusieurs) amende monumentale pour abus de position dominante notamment parce qu'ils trainaient des pieds à documenter leur bousin. Et maintenant, ils veulent nous faire croire que l'idée d'être interopérable est une idée à eux!
Et le pire c'est que certains y croiront...

[ Répondre ]

Posté par Gilles G. () le 27/01/2008 à 11:43. (lien). Évalué à 1.

le DSP tu lui envoie uniquement le code assembleur et pas le code compilé

Non, le DSP tu lui envoies le code assemblé qui peut prendre effectivement plus de place que le code lui-même.

[ Répondre ]

Posté par Gilles G. () le 27/01/2008 à 11:39. (lien). Évalué à 1.

Merci pour ta réponse, je comprends mieux à présent. Effectivement, en ouvrant les fichiers binaires avec un éditeur hexadécimal, je me suis rendu compte qu'il y a pas mal de chaînes de caractères qui contiennent des noms "manglés".

Par ailleurs le lien donné par Gniarf m'a fait découvrir l'option -nostdlib de GCC, et ça m'a aussi permis de découvrir que:
* GCC fait *toujours* le lien avec la libc.
* la fonction main est une fonction fournie par la libc, pas par le langage.

Merci pour ces explications!

[ Répondre ]

Posté par Gilles G. () le 27/01/2008 à 11:12. (lien). Évalué à 9.

Je voyais déjà exactement ce même type de discussion il y a 14 ans. Et quand je dis exactement, c'est du mot pour mot, et un étonnement, une naïveté identiques.

Heureux de l'apprendre.
Il y a 14 ans j'avais 12 ans, j'espère que tu ne m'en veux pas de ne pas avoir suivi les discussions de l'époque.

[ Répondre ]

Posté par Gilles G. () le 26/01/2008 à 22:45. (lien). Évalué à 1.

ton code C est fonctionnellement équivalent au code assembleur, mais ce n'est pas pour ça qu'ils sont identiques. main() et _start, c'est pas pareil

C'est justement ça le problème: GCC devrait utiliser la méthode la plus efficace en temps et en taille, non?

Toutes les sections présentes dans ton ELF sont facultatives et ne servent qu'à donner des informations (par exemple pour déboguer, mais pas seulement

Voilà ce que j'ai essayé:
gilles@ordi:~$ strip --strip-all --remove-section=".comment" minimal -o minimal_stripped
gilles@ordi:~$ strip --strip-all --remove-section=".comment" cminimal -o cminimal_stripped
gilles@ordi:~$ ls -l cminimal minimal cminimal_stripped minimal_stripped
-rwxr-xr-x 1 gilles gilles 6332 2008-01-26 22:31 cminimal
-rwxr-xr-x 1 gilles gilles 2556 2008-01-26 22:37 cminimal_stripped
-rwxr-xr-x 1 gilles gilles 596 2008-01-26 22:12 minimal
-rwxr-xr-x 1 gilles gilles 248 2008-01-26 22:37 minimal_stripped
Apparement, la commande strip permet la suppression de code mort dans le cas du programme C mais aussi dans le cas du programme ASM.
Donc au final, en utilisant strip, on a toujours un facteur 10 entre les tailles des exécutables.

PS: Au boulot j'utilise des DSP motorola qui ont 16Ko de mémoire programme, et on arrive quand même à faire pas mal de choses (en assembleur), donc je trouve que prendre 6ko pour un programme en C qui ne fait rien c'est abusé.

[ Répondre ]

Posté par Gilles G. () le 25/01/2008 à 12:55. (lien). Évalué à 2.

Excellent!!
Ce type de carte mère m'intéresse beaucoup, mais je ne trouve pas d'alimentation adaptée à de si petites consommations. As-tu des liens vers des alimentations adaptées?

Merci d'avance.

[ Répondre ]

Posté par Gilles G. () le 10/01/2008 à 20:37. (lien). Évalué à 7.

En fait, des sons hautes-fréquences inaudibles par l'oreille humaine peuvent engendrer un son audible à la fréquence différence par démodulation non-linéaire lors de la propagation de l'onde sonore dans l'air.
Ce phénomène est observable sur un violoncelle par exemple: dans le champ très proche il existe des ultrasons très haut fréquence qui "se transforment" par non-linéarité en fréquence audible au-fur et à mesure de leur propagation dans l'air.
Une conséquence remarquable de ce phénomène est la directivité très marqué de l'instrument pour ces fréquences particulières.

En pratique, cela ne justifie pas le codage des ultra-sons pour la retransmission haute-fidélité puisqu'il suffit de placer correctement les microphones lors de la prise de son pour avoir tout le son "audible" de l'instrument.

[ Répondre ]

Posté par Gilles G. () le 10/01/2008 à 20:23. (lien). Évalué à 2.

Bonjour,
les désagréments que tu mentionnes ressemblent fortement à de l'fr:Hyperacousie (la page wikipedia en français n'est pas très complète, mais la page correspondante en anglais est plus précise en:Hyperacusis).
Donc, sans vouloir remettre en question tes "capacités auditives", le fait que tu entendes des sons aigus inaudibles pour la plupart des gens n'implique pas que tu sois capable d'entendre des fréquences plus élevées que 18-20kHz. En pratique, il y a fort à parier que tu sois surtout beaucoup plus *sensible* aux fréquences aigues "normales" (i.e. 16-20kHz) que la plupart des gens, c'est à dire que tu entends ces sons à faible niveau.

PS: j'avoue que lire: "ayant la malchance d'avoir une oreille qui monte au alentours de 25/27KHz" ça m'a un peu fait bondir...

[ Répondre ]

Posté par Gilles G. () le 13/12/2007 à 16:00. (lien). Évalué à 6.

Juste pour pinailler:
les patches RT du kernel ne permettent pas de faire du temps réel "dur", ils rendent simplement le kernel plus préemptible.

Le temps réel dur c'est pouvoir être *certain* qu'une tâche sera exécutée avant un délai donné.

Au final, pour de l'audio avec les patchs d'Ingo Molnar, on n'a quasiment aucun xrun, mais cela ne permet pas d'affirmer que le kernel est temps réel dur.

[ Répondre ]

Posté par Gilles G. () le 06/12/2007 à 12:47. (lien). Évalué à 2.

Je n'ai pas la prétention de statuer sur les qualités et les défauts de Java. Par contre, je me pose la question: tu proposes quoi à la place (typage statique bien sur)?

[ Répondre ]

Posté par Gilles G. () le 30/11/2007 à 15:07. (lien). Évalué à 2.

Bonjour,
as-tu essayé un autre dézippeur? Pour ma part, j'utilise ark (sous Kde) et je n'ai pas rencontré ce problème.
Sinon, ce commentaire:
http://linuxfr.org/comments/884425.html#884425
devrait te mettre sur la voie.

[ Répondre ]

Posté par Gilles G. () le 26/11/2007 à 19:05. (lien). Évalué à 4.

Bonjour,
j'ai trouvé de la doc en anglais en faisant une petite recherche sur google avec les mots clés suivants:
object oriented c
On trouve en particulier les liens suivants (le premier à l'air pas mal)
http://www.planetpdf.com/codecuts/pdfs/ooc.pdf
http://ldeniau.web.cern.ch/ldeniau/html/oopc/oopc.html

Sinon, avec une recherche en français:
c orienté objet
on trouve:
http://chgi.developpez.com/c/objet/
http://happyleptic.org/~rixed/pooc.html

A+

[ Répondre ]

Posté par Gilles G. () le 22/11/2007 à 07:25. (lien). Évalué à 2.

Ce mouvement de copie spontanée fait plaisir à voir: on a des journaux. Des journaux inutiles, certes, mais ça reste des journaux...

PS: Cette copie est très réussie, bravo!

[ Répondre ]

Posté par Gilles G. () le 20/11/2007 à 16:17. (lien). Évalué à 1.

Tu te trompes complètement. Nous sommes deux dans ma boite: mon patron et moi, et on s'entend vraiment bien.

Aujourd'hui, il faut qu'on développe une nouvelle application que nous devons faire en interne. J'aurai souhaité faire cela en Python parce que je pense que je pourrais gagner du temps. Je connais bien Python parce que j'utilise Scipy/Numpy et que je fais du PyQt à mes heures perdues.
Note aussi que je ne suis pas développeur (i.e. pas de formation, mais on fait avec nos ressources).

Python n'a pas le "rayonnement" de Java, et la plupart des gens autour de nous nous ont incité à utiliser Java sans bons arguments puisqu'ils ne sont pas programmeurs eux-mêmes.

Après lecture des commentaires de ce journal, je commence à changer d'avis et à me dire que Java serait une bonne solution.
En particulier, le fait de pouvoir modifier "en toute sécurité" une application que l'on n'a pas touchée depuis 1 an (ou qu'on n'a pas écrite) m'apparait être un *très* bon argument en faveur de Java.


PS: malgré le ton trollesque de mon journal, j'étais sérieux! Les arguments que j'ai pu entendre contre Python et pour Java étaient infondés et semblaient résulter avant tout d'une peur de l'inconnu.

[ Répondre ]

Posté par Gilles G. () le 12/11/2007 à 17:18. (lien). Évalué à 10.

Quand on pense qu'il suffirait que les gens ne les achètent pas pour que ça ne se vende plus...

[ Répondre ]

Posté par Gilles G. () le 08/11/2007 à 07:31. (lien). Évalué à 8.

vous faites quoi?
Et quel est le rapport avec le libre?

[ Répondre ]

Posté par Gilles G. () le 31/10/2007 à 15:42. (lien). Évalué à 8.

Allons-y...
Le format OOXML *authorise* l'inclusion de parties binaires *non-documentées* par souci de compatibilité avec les anciens formats.
Cela implique que tu n'es pas assuré de pouvoir lire tes documents avec un logiciel qui s'appuierait *uniquement* sur la norme.

Par conséquent, tu n'es pas maitre de tes données puisque tu ne sais pas si tu pourras les récupérer un jour.

Il existe d'autres arguments contre OOXML dont les principaux sont assez bien résumés ici:
http://www.noooxml.fr/arguments

[ Répondre ]

Posté par Gilles G. () le 31/10/2007 à 14:44. (lien). Évalué à 1.

Oui il y a le ventilo qui tourne (toujours aussi bruyant d'ailleurs).
<ironie>
En fait à part le fait que *rien* ne s'affiche à l'écran et que la touche "ver num" ne fonctionne pas, tout va bien.
</ironie>

[ Répondre ]