CoinKoin a écrit 698 commentaires

Chez moi (Mdk 9.2.1), j'ai aussi eu un probleme avec le cron. J'ai decouvert qu'il lancait bien les commandes que je lui donnais, mais qu'il tuait les fils ainsi crees presque aussi sec. Resultat : les lignes de script sont bien executees, mais les gros programmes lances ainsi sont tues juste apres leur lancement

Je pense qu'il s'agit d'un (gros) bogue du cron. Pour le contourner, au lieu de :
0 1 * * * ma_commande_qui_dure_longtemps

, il suffit de faire :

0 1 * * * echo "ma_commande_qui_dure_longtemps" | at now

Je ne crois pas, non. Mais tu peux toujours mapper tes fichiers en memoire, si ca peut t'aider.

xhost doit etre lance sur le serveur X auquel tu veux te connecter. Si seul l'utilisateur coinkoin (par exemple) peut actuellement se connecter au serveur X, parce que c'est lui qui l'a cree (ou parce que c'est lui qui est logge, ou pour une autre raison) , il suffit que tu fasses :

root@localhost# su coinkoin -c "xterm -display :0 -e xhost +localhost"

Et coinkoin va (involontairement) donner le droit aux personnes situees sur localhost de te connecter au serveur X.

Et tant que tu y es, s/interessant/interessants/g;s/marrant/marrants/g ;-).

Cela dit, t'as bien raison, c'est assez interessant :-) . Et marrant. Et parfois tres utile.

Alors deja si tu veux le binaire exécuté par l'appli il faut pas regarder top/ps qui n'affichent que le "nom" du processus.

Exact. Pour avoir l'identite du programme qui s'execute, il faut regarder /proc/numero/exe.

Ensuite si tu veux savoir le processus qui l'a lancé, je ne sais pas comment/si on peut le trouver dans /proc

On peut le savoir, en regardant /proc/numero/stat. Cela dit, la lecture de ce fichier n'est pas simple (voir man proc), et "ps faux" (ou pstree, je ne connais pas) est autrement plus simple a interpreter.

Trop tard, il a deja recu un spam parlant de petrole en Irak, et il a marche droit dans le panneau, du coup, maintenant, il commence a se mefier.

Je sais mettre ma machine quand je veux dans cet état-là (qui ne répond pas à la commande "reboot"), et sans passer root !!

Il me suffit de lancer mplayer en framebuffers, de faire ctrl-Z, puis bg, puis kill -9 -1 (à l'aveuglette). Et hop, dans le décor, l'OS... Même après un ctrl-alt-suppr (qui, chez moi, arrête la machine), pas moyen de revenir dans un état normal. Il paraît que c'est dû à une instabilité kernel avec les framebuffers...

$/sbin/runlevel
5 0
$halt &
$/sbin/runlevel
0 0
$whoami
coinkoin


Arf...

D'un autre côté, il s'agit d'une offre de portables, pas de supercalculateurs scientifiques :-) .

De toute façon il n'y avait rien dans l'Observateur d'évènements... ;-)

Oui, enfin, moi, j'ai déjà eu la même chose avec Linux (un processus qui se bloque et rien dans /var/log/messages).

Je vois...

Le problème de cette technique, c'est que ce n'est pas très loin du codage en dur du système d'exploitation sur la machine.

Comment fait-on une mise à jour du système d'exploitation, dans ce cas?

Parce que si on peut en faire une qui soit inoffensive sans perdre la capacité à appeler la puce, alors on peut en faire une "méchante" qui ne perde pas non plus cette capacité, tout en re-permettant d'utiliser son ordinateur normalement. La puce ne peut pas conna^itre à l'avance les mises à jour du système d'exploitation qui seront proposées.

Et je vois mal une technologie pareille s'implanter avec la restriction "attention, avec cette technologie, vous ne pourrez plus faire de mises à jour de sécurité de votre système".

Cela dit, cela m'a tout l'air contournable, mais tout de m^eme plus technique que je ne le pensais.

Qu'est ce que tu racontes?

Le rejet par Debian et Apache de cette solution date effectivement d'il y a quelque temps, mais pas son rejet (enfin, son classement en "expérimental") par l'IETF. L'article cité dans le journal est d'ailleurs daté d'aujourd'hui.

le technicien qui devait veiller à la bonne marche de la procédure, n’a pas accompli son travail du tout puisqu’il a « oublié » de le faire.

On ne peut pas rebooter un Windows de façon automatique? Ca m'étonnerait.

l'OS modifié et le serveur X modifié pour gérer correctement la technologie pourraient s'identifier de manière sure auprès de l'application

Et comment? L'application ne peut communiquer avec l'OS (et l'autre application, et tout le matériel, y compris la puce) qu'au travers d'appels-systèmes (ou de quelques autres services offerts par l'OS, comme /proc).

S'ils sont tous truqués, l'application est bernée.

Et si tu essaie avec un ReactOS bricolé, tu te fais jetter parce que la signature n'est plus valide.

M^eme remarque. C'est ReactOs, et lui seul, qui fournit à l'application tous les éléments dont elle a besoin pour calculer cette signature. Si ReactOs ment de partout, en se comportant à chaque fois comme le ReactOs certifié (ou mieux, comme le Longhorn certifié :-) ), c'est fichu.

Tu veux dire un émulateur de PC avec un émulateur de puce TCPA ou composant hardware de NGSCB, et avec un émulateur de clé secrete dedans ?

Pourquoi, c'est g^enant? La puce n'a m^eme pas à ^etre émulée, je peux intercepter tous les appels que l'application fait à la puce, et les rediriger sur la mienne, qui n'y verra elle aussi que du feu, et me donnera les réponses dont j'ai besoin...

Mais si, voyons, il y a la solution de Farenheit 451...

Je ne sais pas où c'est codé dans le code de gcc, mais ces fichiers et répertoires sont dans /usr/include .

Vous êtes-vous fait avoir ???

Meuh non, c'était pas crédible, les solutions préconisées marchent.

Ok, ok, c'est par où, déjà?

Si tu as déjà utilisé directement quelque chose de la deuxième liste, ça n'a pas dû être très souvent

Bien vu : je ne les ai jamais employés. Bon, ben, je vais peut-être essayer le Perl, puisque c'est ça...

au niveau assembleur, il y a des gens qui ont eu une idee geniale : faire un macro assembleur sur un processeur à registre et pile avec la possibilité d'avoir un support objet au niveau de l'assembleur.

< humour >

Ca y est, ils vont nous faire un helloworld en assembleur orienté objet. Pour l'héritage, on fait :

heritl %eax %ecx

< /humour >

:-)

Quel genre de programme tu fais pour avoir besoin de faire des syscalls tout le temps ?

Ca dépend. Je programme pour plusieurs raisons :

1) pour m'amuser. Là, je me déchaine sur les appels-système, parce que c'est ce qui m'amuse le plus. Cela dit, les programmes de ce genre ne servent à rien d'autre qu'à me distraire (dernièrement, j'ai codé un programme dont le seul intérêt était que l'on pouvait changer ou même arrêter dynamiquement son interface, mais qui ne faisait rien d'utile, juste pour voir si c'était possible), donc, sitôt débogués, sitôt oubliés.


2) pour développer un projet. Là, je fais assez peu d'appels-système, mais en revanche, dès que je dois en faire un (genre lancer plusieurs threads, forker, créer une socket...), je le fais sans hésiter. Sans le C, je nagerais...


En ce qui concerne le Perl, je n'y avais pas pensé, merci pour l'idée :-) .

Cela dit, s'il manque des appels-systèmes, je pense que je vais vite l'oublier.


Bref, comme bien des programmeurs, je fais avant tout ce qui m'amuse...



Mais sur le fond je suis bien sur d'accord que lorsqu'un systeme est ecrit en C il est plus facile de s'y interfacer dans le meme langage... pour les trucs systeme.

Nous sommes donc d'accord :-). Et, pour apporter de l'eau à ton moulin, j'ajoute que je trouve effectivement la gestion de la mémoire pénible en C, ce qui me fait perdre du temps par rapport à un code Java. Mais j'aime tant les appels-système... :-)


Au fait, est-ce que quelqu'un sait où on peut trouver la liste des appels-systèmes Windows en C? J'aimerais comparer avec les appels-systèmes Linux, mais je n'ai pas trouvé, même sur mon Google favori :-( .

Le pire c'est que sous Linux je pense que vous êtes une majorité de programmeurs de ton avis.

Personnellement, je programme en C, et je vais t'expliquer pourquoi : lorsque je veux faire un appel-système, en C, il me suffit d'un coup de RTFM. Dans tous les autres langages, je suis perdu (sauf en shell, mais ce langage a beaucoup trop de limitations).

Si, un jour, un autre langage (comme Java, par exemple) venait avec une aide semblable embarquée dans les systèmes Linux, j'essayerais sans doute, mais d'ici-là, je préfère m'en tenir à mon bon vieux C.

En résumé, m^eme s'il est antédiluvien, je préfère programmer avec, parce que je sais que je trouverai toujours une solution à mes problèmes, et où la trouver.

Résumer un texte (sans le recopier exhaustivement, s'entend) relève du droit de courte citation, qui t'est guaranti par la loi. Donc la license n'a pas d'influence ici.

>Réponse de NGSCB : Si l'application accepte de se lancer sur un serveur X comme le tien, elle n'aura pas la certification.

L' application et l'OS bricolés apparaissent à l'application certifiée comme rigoureusement identiques au vrai OS et au vrai serveur X. Donc la seule solution pour les bloquer est de ne certifier aucune application sur serveur X et sur cet OS... Ce qui revient à renoncer à proposer le produit à la vente (ben oui, il y aura bien un rigolo pour faire le m^eme coup avec ReactOs, donc on ne peut pas certifier sous Windows non plus, et ainsi de suite...)

Ah si, éventuellement, on pourrait imaginer d'embarquer l'OS avec le film, en rendant le support bootable.

Sauf si ce tra^itre de client boote le film dans un émulateur de PC...

Aaaarghhhhh!

Pour quelqu'un qui veut faire un logiciel libre qui accède au contenu, on oublie : L'auteur pourra faire signer certaines versions particulières du logiciel, mais si l'utilisateur s'amuse à modifier le logiciel, ou bien à le recompiler avec d'autres options, paf, la signature n'est plus bonne, le soft n'a plus accès au contenu.

Bob télécharge son cher film avec une application parfaitement certifiée (et pour cause, il ne l'a pas modifiée).

Ensuite, il lance un faux serveur X, qui se comporte comme un vrai vis-à-vis des applications qui croient s'exécuter dessus, mais qui, au lieu de s'afficher à l'écran, redirige ce qu'il devrait afficher dans un fichier. Puis il lance l'application certifiée sur le nouveau serveur X...

Comment fait-on, au juste, pour certifier un serveur X avec des DRMs? En sachant bien s^ur que les appels-système de l'application certifiée ont toutes les chances d'avoir été interceptés et leurs résultats modifiés, pour éviter qu'elle ne puisse faire la différence entre les vrais et les faux serveurs X...

Et toc, Bob a encore fait leur f^ete aux DRMs :-) !

est ce que microsoft brevete tout et ni'mporte quoi comme des trucs du genre for(i=0,i=5,i++)

Exactement. Dernièrement, Microsoft a m^eme déposé un brevet sur la commande UNIX sudo, après que leur service juridique ait découvert que cette commande n'appartenait à personne... Alors qu'elle existe depuis des années (et qu'ils n'en sont évidemment pas les auteurs).


En ce qui concerne tes points d'exclamation, je ne parlais pas spécifiquement de ce commentaire-là, mais de façon plus générale (si tu vérifies, tu verras que ce n'est pas la première fois que je réponds à tes questions :-) ).

Il ne s'agit pas de breveter du code, ce qui ne poserait pas de problème (le code est la propriété de celui qui l'écrit, ça, tout le monde est d'accord), mais de breveter les fonctionnalités des logiciels indépendamment du code qui implémente ces fonctionnalités (et m^eme parfois de breveter des fonctionnalités qui n'ont jamais été implémentées, m^eme par le breveteur).

Remarque : marseillais, tu devrais peut-^etre mettre un peu moins de points d'exclamation dans tes phrases, ça te rend pénible à lire :-) .