TortuXm a écrit 119 commentaires

Ca ressemble pas mal, mais les problématiques restent plus simples en général parce que les données sont souvent déréférencées "naturellement".

Les cas tordus où on doit, même avec un GC, gérer la mémoire soi-même en déréférençant auraient donné un code similaire en C/C++. Par contre, tous les autres cas plus standard sont gérés par le GC, ce qui enlève une grosse source d'erreurs potentielles.


La gestion de certaines tâches est également facilitée. Je pense par exemple à la gestion d'un cache qu'on peut faire à l'aide de WeakRef. Il faut penser à ne pas mettre des références "normales" mais à part ça, on n'a pas de tâche spécifique à réaliser et on voit bien l'intérêt du GC dans ce cas précis : le cache est vidé si on a besoin de mémoire, ce qui est difficile à faire à la main.

J'ai fait mon petit script pour automatiser le tout, le voilà si ça intéresse quelqu'un.

C'est fait à la main vite fait, si quelqu'un a des suggestions pour améliorer ça, n'hésitez pas !



Sur le poste distant, il faut avoir un fichier batch, je l'ai appelé setup_nx

#! /bin/sh
COOKIE=$(echo "$1" | sed s/HOSTNAME/$(hostname)/)

nxproxy -C link=adsl localhost:8 &
xauth add $COOKIE $2 $3 $4 $5
export DISPLAY=":8"
xterm



Sur le poste client, j'ai un fichier batch ssh_nx :

#! /bin/sh

COOKIE=$(xauth list | grep $(hostname) | sed s/$(hostname)/HOSTNAME/ | sed s/unix:0/unix:8/)

echo $COOKIE

nxproxy -S &

sleep 2

echo $COOKIE

ssh -f -R localhost:4008:localhost:4008 $1 "/chemin/setup_nx $COOKIE"



Les deux gros problèmes qui me restent sont :

× je dois tuer le processus ssh du client "à la main" à la fin de ma session
× je dois appeler xterm (ou un autre terminal graphique), parce que je n'ai pas trouvé de moyen simple de lancer des commandes et en même temps d'avoir un pseudo terminal.

Une option que je vois (qui résoudrait les deux problèmes) est de changer le shell de mon utilisateur, mais je n'aime pas cette option...

Si vous avez des suggestions, je suis preneur.

Je viens d'essayer, ça marche niquel, en plus c'est fait qu'avec des composants libres donc ça me va très bien. Merci pour ce tutorial !


Par contre j'ai suivi bêtement les instructions que tu avais rédigées, et j'avais l'erreur
Warning: X connection failed with error 'No protocol specified'.
à chaque fois que j'essayais de lancer une commande graphique.

J'ai donc remplacé
poste_distant$ xauth add poste_distant/unix:0 MIT-MAGIC-COOKIE-1 bba945268dab0548c74c32fcf483e703
par
poste_distant$ xauth add poste_distant/unix:8 MIT-MAGIC-COOKIE-1 bba945268dab0548c74c32fcf483e703

C'est-à-dire le port 8 au lieu de 0. Je pense qu'il doit s'agir d'une erreur dans ton tutorial, ou nos versions de nxproxy ne fonctionnent pas pareil.


Je vais essayer de faire un petit programme qui automatise tout ça pour avoir une version facile à mettre en oeuvre.

D'ailleurs tant qu'on parle de ce log, j'ai deux petites observations :

* en paramètre de son script, il utilise un fichier users.txt. C'est donc a priori nécessaire d'attaquer avec une liste de noms, je ne vois pas de raison qui proscrive l'utilisation d'une brute force pour rentrer dans OpenSSH.

* Il fait juste après l'entrée sur le serveur un "jail break". Le noyau est patché grsec (cf le uname -a), et il se trouve qu'il a une faille connue donnée en lien plus haut : http://www.digitalarmaments.com/2007200184936274.html. Il n'est pas impossible que ce soit cette faille qui soit utilisée.

On peut trouver des sites qui commencent à parler de hoax à ce sujet : http://isc.sans.org/diary.html?storyid=6760

A ma connaissance, ça n'est pas possible avec juste ssh (par contre, sous windows avec putty, enfin plink plus précisément, tu as bien une option -pw)



Tu peux utiliser http://sourceforge.net/projects/sshpass/ pour faire ça sous Linux.

(dispo dans les paquets debian)

Ben le langage expose une sémantique qui n'existe par réellement : il propose une vue virtuelle au programmeur pour lui offrir un service.

Je peux dire la même chose d'une architecture en classes, ou même des structures du C ou de certains assembleurs. Les structures/classes sont des abstractions de la mémoire de l'ordinateur, elles permettent d'écrire du code plus portable (compare *(p+4) et p->variable par exemple). Ça n'en fait pas des VM.

GCC passe par une représentation intermédiaire, un truc de même niveau que le bytecode.

Et il le jette à la poubelle une fois le code machine généré,et c'est exactement ça la différence, à mon sens, entre une VM et un code natif. On pourrait faire une VM qui exécute le pseudo-langage généré par gcc.

si c'est vrai cela veut dire que le compilo qui génère du bytecode n'optimise rien, ce qui serait surprenant.

Pour avoir décompilé des .class java, je confirme que le code retrouvé ressemble énormément au code de base, à part quelques goto dans des boucles.

Il me semble que l'optimisation se fait en runtime, quand la VM exécute un certain nombre de fois une méthode, elle décide de compiler ladite méthode en code natif pour aller plus vite. Et là, le code généré est optimisé, pas avant.

Je ne vois pas pourquoi le fait de rajouter des métadonnées fait d'un code compilé une VM.

C'est toujours pas du bytecode derrière, c'est vraiment du code compilé binaire et tout... Il y a quelques infos qui pourraient s'apparenter à des informations de débogage, mais je vois pas en quoi on peut qualifier ça de VM. Il n'y a aucun intermédiaire entre le code et la machine, contrairement à une VM.


Après on a peut-être une définition des machines virtuelles un peu différente, vu ton affirmation.

Le cas général c'est quand même que la mémoire est libérée. Je veux bien qu'en pratique, ça ne marche pas toujours... Mais honnêtement, ça doit arriver bien moins souvent qu'un free oublié en C, ou qu'un delete qui manque en C++ ? Surtout qu'il arrive parfois qu'on ne sache pas quand exactement libérer la ressource, sauf à compter les références manuellement.

Si on part du principe que les développeurs sont des tanches, la VM rajoute une sécurité au prix d'une occupation mémoire et CPU plus importante.

Si on n'arrive pas à avoir des garanties quant à la qualité des dévs, c'est un moindre mal.



Ça n'empêche pas qu'en dehors du boulot, j'utilise des langages un peu plus bas niveau, parce que je préfère gérer la mémoire moi-même, et que je ne vais pas travailler avec des développeurs qui ne savent pas gérer ces problématiques.

Les VM garantissent effectivement comme en C qu'à la fin de ton programme, il n'y aura pas eu de perte de mémoire. Mais elles garantissent surtout, et contrairement au C, que la mémoire utilisée puis devenue inutile puisse être libérée ou réutilisée avant la fin du programme. En C si on a un memleak, on le garde jusqu'à la fin du programme. Pas terrible pour une appli serveur... Elles empêchent aussi que les erreurs de débordement classiques sont évitées : on a des exceptions au lieu d'un core dump.


Avant de bosser en entreprise je ne comprenais pas l'intérêt de laisser la gestion de la mémoire à une VM. Les perfs étaient en général moins bonnes que si on gère la mémoire soi même, et ça me paraissait plus relever de la flemme de gérer la mémoire que d'un besoin réel.


Depuis que je bosse, je m'aperçois que certains concepts de base échappent totalement aux développeurs qui bossent avec moi.

Je fais actuellement du J2EE et je ne connais personne qui soit capable ici de gérer la mémoire. Par exemple j'ai aidé à déboguer une lib JNI qui a été codée par des devs Java ne connaissaient pas le C++. Un exemple bien classique de ce que j'ai trouvé :

char *code = new char[2];

fonction_de_remplissage_qui_vient_de_la_dll(code); // cette fonction définissait, entre autres, les valeurs de char[0] et char[1]

conversion_char*_en_StringUTF8_pour_java(code);


Ici personne ne comprenait pourquoi ça plantait. Pour eux, on réservait un espace de 2 caractères, point. Ils passaient totalement outre le fait que la doc mentionnait que code devait être une "null terminated string". Sous MSVC en mode debug, évidemment ça fonctionnait, avec des caractères genre ÿ aléatoires avant la fin de la chaîne.

Ce genre de problème ne peut pas arriver dans une VM type Java parce que la mémoire n'est pas gérée par les développeurs.


Je vois plutôt ça comme un aveu d'impuissance : on pense que les développeurs basiques feront des erreurs. On n'a pas assez d'énergie pour rendre les développeurs meilleurs, donc on leur masque la complexité et on trouve un langage dans lequel ils ne peuvent pas faire ces erreurs.

Sauf que l'OSP ne s'applique que si Mono implémente complètement et exclusivement la partie ECMA de .NET, c'est bien ça ?

Ca voudrait donc dire que si Mono embarque Gtk# ou d'autres technos Gnome portées sur .NET, Mono en entier n'est pas couvert par l'OSP.

Comme il est dit dans la dépêche, ils vont donc séparer Mono en deux, l'autre partie sera donc non couverte par l'OSP et aussi vulnérable qu'elle pouvait l'être avant (que cette vulnérabilité soit avérée ou non). Donc pas de WinForms, pas de Gtk#, pas de.... .NET est-il toujours intéressant sous Linux dans ce cas ?


Le fait que Microsoft pose de telles conditions peut indiquer qu'ils comptent attaquer ceux qui sont en dehors de son OSP, sinon, pourquoi poser de telles conditions ?

On peut faire des jeux en Java à l'aide des applets. Il est possible de faire des jeux en 3D (normalement, ça doit utiliser OpenGL derrière, mais j'en ai jamais fait)


Après les applets c'était la mode à un moment, c'est passé. Comme le JavaScript, mais ce dernier est revenu.... Pourquoi pas les applets Java ? Java a beaucoup progressé depuis le début de Flash. Il est possible de faire de la 3D, de faire une appli qui foncionne en mode desktop et en mode applet (c'est juste du swing, en fait), on peut faire du son, du midi, ...



La dernière fois que je m'étais documenté pour savoir pourquoi les applets Java n'étaient pas utilisées, j'avais retenu ce point de vue :

× Pour faire un jeu en Flash, on n'a besoin que d'un graphiste. La programmation est basique et peut s'apprendre même par un non programm eur(apparemment, j'en ai jamais fait)

× Pour faire un jeu en Java, il faut un programmeur Java. Pas le choix ici, une applet ne part de rien, il faut ajouter des contrôles, éventuellement faire des Threads, etc. Et, en plus, il faut un graphiste.


Je pense qu'il y a de bonnes opportunités au niveau Java. J'ai pas encore regardé ce que donnait JavaFX en détail... Mais je pense qu'avec un framework qui simplifie les développements de jeux ou de petites applications graphiques, le monde libre n'aurait pas à rougir face à Flash.

Ma carte externe en USB fonctionne bien, elle m'a coûté entre 20€ avec les frais de port. Elle est de marque Konig. Par contre aucune idée de ce que ça donnerait sur un ampli, mais je pense qu'il n'y aurait pas de bruit (pas de grésillement quand je mets le son au maximum avec mes enceintes de bureau)


Le seul problème avec cette carte son est le bruit qu'il y a pendant le démarrage de Windows (oui PC de boulot, pas le choix...), je pense que c'est juste parce que le driver s'initialise, donc je ne brancherais pas un ampli au démarrage mais une fois l'OS lancé.



PS : j'ai également un eeePC et la qualité de la sortie casque est similaire à celle de ma carte son USB.

PS²: Mon frère a acheté un PC portable à 500€ et il ne peut pas brancher son ampli sur son portable comme il voulait (grésillements...). J'essayerai avec mon eeePC ou ma carte USB la semaine prochaine, si tu veux.

Certains portables avec une carte son intégrée à la carte mère ont des problèmes avec la prise casque : on entend des interférences pendant les lectures disque/cd, plus ou moins importantes en fonction de la charge du processeur.

En tous cas avec le DELL du boulot, je ne peux pas brancher un casque pour écouter de la musique, c'est trop bruyant. J'ai du acheter une carte son USB pour ça...


J'imagine que ce genre de bruit avec un ampli dessus, ça doit pas être beau à entendre. J'avais entendu dire également que pour certains portables, il fallait brancher le pc sur la même multiprise que l'ampli sous peine d'avoir énormément de bruit (et pas de problème quand on tourne en batterie).

Ce n'était pas dans mon contrat, je connaissais pas du tout.

Merci pour l'info ;)

Il me semble que si tu n'as pas fait la demande de la (ou les) formation(s) en question, ils ne peuvent pas les compter dans le DIF (si j'ai bien compris ta remarque et que le dédit formation correspond aux nombre de journées de DIF en négatif).

J'ai eu le cas, il me mettaient sur plusieurs formations sans intérêt, c'était mieux pour eux que de faire de l'intercontrat.

Je l'ai déjà vu, pourtant.. J'imagine que le client n'avais jamais eu affaire à une SSII avant.

Le pire à mon avis reste quand même le fait que le code produit soit tellement mauvais qu'il n'est plus maintenable que par la SSII en question. Et encore, jusqu'au moment fatidique où tous les développeurs y avant participé ont déserté ladite boîte. C'est très vrai pour un projet que j'ai suivi de loin, et dont les devs étaient délocalisés au Maroc. Pour passer à une autre SSII, le client peut(doit) refaire une étude fonctionnelle et technique complète de l'application. Bien sûr il y a des docs, mais en général elles sont assez vides de sens.

Le problème majeur des SSII (j'y travaille encore, mais j'ai changé pour une plus petite), c'est qu'elles travaillent généralement en mode forfait, et dans ce cas, l'objectif de prendre les contrats à leur concurrentes. Résultat : les prix sont bradés, tous les projets se terminent dans l'urgence... donc le code est bâclé et souvent livré avec des "bugs connus" qui sont des fonctionnalités partiellement implémentées.

Quand j'ai quitté ma première SSII, je me demandais vraiment pourquoi les clients continuaient à faire appel à ce type de boîte. Avec la crise on comprend bien, mais quand même...

Au final les projets qui se sont le mieux passés ont été ceux où on travaillait en régie directement chez le client, ce qui ressemblait beaucoup à du "manpower", en effet.

Pour info, voilà le script que j'utilise (j'ai un peu changé certains noms de dossier pour simplifier) :

fichier connectKeystation.sh :

#!/bin/sh

aconnect "USB Keystation 49e":0 "Emu10k1 WaveTable":1
asfxload -V 100 /opt/midi/soundfont/Airfont\ 380\ GM.sf2


Fichier /etc/udev/rules.d/85-keystation.rules :

UBSYSTEM=="usb", DRIVER=="snd-usb-audio", ATTRS{product}=="USB Keystation 49e", RUN+="/opt/midi/connectKeyStation.sh"


La règle udev permet de lancer le script dès que je connecte le clavier MIDI au port USB.

PS: mes " s'écrivent ", j'arrive pas à avoir des guillemets normaux, donc si ça ne passe pas, c'est pas faute d'avoir essayé.

Est-ce que la SBlive 5.1 a un synthétiseur matériel (un processeur dans la lignée de l'emu10k1 quoi) ? Si oui, le mieux c'est asfxload à mon avis, plutôt qu'un synthé logiciel.

Pour ma part j'ai un clavier MIDI, une Audigy 2 avec un emu10k1 dedans, et je joue avec juste un asfxload suivi d'un aconnect. Je peux te passer les commandes pour le "aconnect" si besoin, mais le man est assez explicite il me semble, et là je suis au boulot.


Avant d'avoir une carte son qui avait un synthétiseur matériel, j'utilisais qjackctl + timidity (mais j'avais trop de latence avec timidity, je trouvais), et qjackctl + qsynth, qui marchait pas trop mal.