Obsidian a écrit 5303 commentaires

Pour faire plus simple on a qu'a comparer cela a une cassette audio, qui fonctionne sur le même principe (magnétique).

Tu as déjà du remarquer que lorsque tu effaçais une cassette musicale pour y mettre autre chose, en enregistrant 60 minutes de silence avec un appareil bon marché, tu pouvais encore entendre très faiblement le signal original même s'il avait été fortement attenué par l'effacement. Maintenant, imagine que tu enregistres au préalable soixante minutes de bruit par dessus ta musique originale avant de l'effacer. Là, il va devenir beaucoup plus difficile de tirer le vrai du faux.

Encore plus criant, imagine que tu veuilles masquer le contenu d'une feuille de papier. Si tu la recouvres avec une couche noire uniforme, tu pourras toujours distinguer ce qu'il y a en dessous par transparence. Si tu écris des caractères aléatoires par dessus, ce sera beaucoup moins lisible.

L'important, au point de vue magnétique, est de générer un grand nombre de transitions. C'est nécessaire pour magnétiser ou démagnétiser correctement un support. Mais surtout, il ne faut pas que la séquence que tu utilises soit prévisible, sinon on peut toujours la soustraire du signal effectivement lu pour en déduire ce qu'il y avait en dessous.

0,37 seconde de recherche avec Google :

http://www.google.fr/search?hl=fr&sa=X&oi=spell&(...)
http://www.google.fr/search?hl=fr&q=APR+routines&btn(...)

Les premiers liens de chacune de ces pages te donnent respectivement la définition et l'interface de cette bibliothèque. Tu aurais pu chercher un peu.

APR, c'est "Apache Portable Runtime" library.

En gros, ils ont suivi le même chemin que la plupart des développeurs de gros projets spécialisés tels que Apache : Ils ont développé leur application, en déposant à chaque fois ce qui a été écrit pour les besoins du projet mais qui peut avoir un intérêt général dans une bibliothèque distincte de l'application elle-même. Ca leur évite de réinventer eux-mêmes la roue à chaque fois, et permet aux développeurs d'en tirer profit même pour des projets complètement étrangers à celui qui lui a donné naissance (ici le serveur WEB).

J'ai fait exactement la même chose au boulot : J'ai des applications, avec éventuellement des petites bibliothèques propres à chaque contexte, mais une seule grosse bibliothèque d'intérêt général, écrite avec beaucoup plus de soins que le reste, je l'avoue, qui grossit au fur et à mesure de ma présence derrière mon clavier.

Dans le cas d'APR, cette bibliothèque est censée être portable. Donc, typiquement, tout ce qui est gestion des locks ou des sommes MD5 est censé être indépendant de l'application (pas propre à un serveur web par exemple) et de la plateforme, mais c'est rarement le cas : Les locks sont intimement liés au système et une couche d'abstraction efficace est requise dans le cadre d'un projet aussi populaire et multiplateforme que Apache.

C'est clair :

http://googlefight.com/index.php?lang=en_GB&word1=lol&am(...)

Je vois pas le rapport...

C'était un peu trop subtil, visiblement :-) C'est par là :

http://musique.ados.fr/Katerine/Louxor-J-adore-t42075.html

Lorsque j'ai un peu de temps libre et que je me plonge dans les journaux de LinuxFR. Il m'arrive régulièrement de prêter attention au lien "pages perso" de chacun. C'est amusant de regarder ce que les autres font sur leur site perso ! J'abuse des onglets de Firefox pour afficher toutes vos homepages !

Et de temps en temps, tu coupes le son ? :-)

PAN !

Salut !
Ta distrib ?

Sans les « $ » initiaux, cela va sans dire ...

Reste sur ton post initial, s'il-te-plaît :

http://linuxfr.org/forums/20/16252.html

La commande est :
$g++ -o monprogramme monprogramme.c++
$./monprogramme

« -o » signifie « Output » et permet de spécifier le nom de l'exécutable une fois compilé. Pour le reste, tu es désormais prié de demander à Google d'abord :

http://www.google.fr/search?hl=fr&q=G%2B%2B&btnG=Rec(...)

Bonjour,

« Question » n'est pas un titre valide.

Qu'entends-tu par « le lien direct pour télécharger le C++ » ? S'il s'agit de récupérer le compilateur sur ta machine, et que tu utilises GNU/Linux, il y a des chances pour qu'il s'y trouve déjà. Essaye g++.

Sinon, on aurait besoin de connaître la distribution de Linux que tu utilises (Ubuntu, Mandriva, etc). En fonction de cela, tu pourras probablement utiliser apt-get ou urpmi pour récupérer directement l'application sur ta machine.

Attention enfin : Je ne sais pas si tu es un afficionado de Visual Studio ou de tout entre IDE (environnement de développement), mais sous Linux, il s'agit de deux choses bien distinctes. La plupart des gens utilisent gcc et sa suite directement depuis la ligne de commande et par l'intermédiaire des Makefiles ...

La plupart des linux, solaris et quelques FreeBSD "rebootent au bout de 497 jours.

Tu peux développer ça ?

Non ?

Non.

Tu confonds encore. Selon ton dernier post, on parlait de la mise en état hors-interruption, pas de l'opération qui la nécessite. Pour faire simple : L'opération assurant l'atomicité d'une transaction n'a pas besoin d'être elle-même atomique (car elle ne fait pas partie implicite de la transaction). Donc :

1) Tu inhibes les interruptions avec le nombre d'instructions que tu veux (et qui peuvent donc être interrompues).
2) À l'issue du point précédent, les interruptions ont été inhibées. Peu importe à quel moment, l'état est garanti à la frontière entre 1) et 2). Tu fais ton opération atomique (ton lock ou n'importe quoi d'autre) en utilisant à nouveau le nombre d'instructions qui te chante.
3) Tu réactives les interruptions.

Il ne s'agissait pas non plus d' « ajouter » un transistor. Tous les microprocesseurs huit bits, à ma connaissance, sont capables d'inhiber les interruptions eux-mêmes et en une seule opération, ce qui les rend en principe éligibles à la mise en ½uvre de systèmes d'exploitation évolués, selon tes critères. L'exemple donné mettait en lumière le fait que même dans le pire des cas (CPU dépourvu de cette simple fonctionalité), il est parfaitement possible de garantir l'atomicité recherchée.

Je maintiens que c'est du jargon. Le jour ou les articles concernant l'informatique seront écrits en bon français sans aucun jargon, fais moi signe.

Ce n'est pas une raison. Ils le seront quand ceux qui les écrivent feront l'effort.

il faut quand même qu'il y ait un moyen de le faire de façon non-interruptible sinon le serpent se mors la queue et tu limites juste les risques.

Tous les microprocesseurs, même les plus anciens, savent faire cela en une opération et l'inhibition des IRQ est faite en interne, mais cela n'est même pas nécessaire. Si, par exemple, tu mets en place un système d'inhibition en tamponnant la ligne d'IRQ avec un transistor dont la base est attaquée par un port, tu n'as pas besoin d'une opération atomique pour activer la bonne ligne. Une interruption peut avoir lieu pendant que tu récupères l'état du port, se dérouler normalement et te rendre la main pour que tu modifies le bit qui t'intéresse et mette le port à jour. L'atomicité de l'exécution débute au moment où la ligne est mise à l'état adéquat. C'est d'ailleurs le principe de toute transaction.

Supporter est du jargon informatique. C'est marrant, supporter te gêne et pas CPU ...

CPU est un sigle pour « Central Processing Unit ». La seule chose incorrecte à la limite, c'est l'emploi du masculin à la place du féminin, par rapprochement avec « microprocesseur », masculin lui aussi.

« Supporter », ce n'est pas du jargon, c'est une faute de français, et c'est également très laid. C'est une traduction ridicule et mot-à-mot de « to support », qui ne signifie pas la même chose du tout. Et surtout, si cela passe à la limite en français parce qu'on est inondé de termes techniques anglo-saxons, ce n'est absolument pas réversible. Le sens français ne passera absolument pas en anglais en utilisant « to support ».

Ce serait à la limite du jargon si les gens se souvenaient encore d'où cela vient, et surtout que ce n'est pas du tout français. Notre langue est suffisamment riche pour que l'on se permette d'utiliser les termes consacrés, surtout quand ils ont toujours existé. Invoquer le jargon, c'est essayer de justifier une mauvaise habitude plutôt que la pallier.

Même si la quasi-totalité du système est écrite en C, au final c'est bien en assembleur que les instructions sont traduites et il faut donc que le CPU supporte des fonctions essentielles comme, par exemple, un équivalent de l'instruction TAS ( Test And Set ) pour pouvoir implementer des mecanismes de lock

Visiblement cela ne passe pas, donc je développe : Cela ne change absolument rien. D'une part, les locks ne sont en aucun cas gérés par le langage C lui-même, et d'autre part, la seule chose dont le C fasse fortement usage est le système de pile (qui peut même être implémenté à partir de rien à partir du moment où tu peux faire un adressage indexé). Les logiciels écrits en C, notamment Linux, ne sont donc pas du tout censés être articulés autour d'une spécificité d'un microprocesseur donné.

Pour TAS, cette fonction n'existe pas en une seule instruction sur i386. D'une manière générale, si tu as besoin d'effectuer une opération atomique, tu vires les interruptions, tu fais ton travail et tu les réactives. Évidement, avoir une instruction indivisible par essence est cent fois plus efficace, surtout qu'un programme en mode utilisateur qui aurait besoin de faire ce genre de chose devrait demander la permission au noyau, mais c'est nullement une condition vitale pour en écrire un, et heureusement : avec ce genre ce raisonnement, on n'aurait jamais connu Unix en 1970, ni même l'essor du RISC.

integre un MMU et aît pas mal d'autres fonctionalités comme la possibilité d'adresser une taille mémoire suffisante pour au moins pouvoir booter le kernel.

Déjà, j'ai l'impression que pas mal de monde confond les MMUs en général et le mode protégé (comme on l'appelle chez Intel) en particulier.

http://en.wikipedia.org/wiki/Memory_management_unit

La principale tâche d'une MMU est la résolution d'adresses virtuelles en adresses physiques. Un tel circuit n'a absolument pas besoin de se trouver embarqué dans le CPU lui-même pour fonctionner. Le système de banques mémoire, par exemple, était extrêmement répandu sur les 8 bits.

Pour la protection des pages, là encore, même s'il est beaucoup plus pratique de l'embarquer, le système peut très bien être externalisé. Un contrôleur de bus peut très bien bloquer la transmission d'un accès et envoyer un signal d'interruption au processeur, qui lui peut même se permettre de l'ignorer superbement sans que l'intégrité du système soit compromise un instant.

Dans tous les cas, non seulement sa gestion ne relève pas de l'assembleur en particulier, mais cela ne relève même pas intrinsèquement du langage C. C'est une fonction qui consiste à aller déposer une table quelque part en mémoire et qui peut être réalisée par n'importe quel moyen.

Pour la taille mémoire, si tu relis mon commentaire, tu t'apercevras que c'est mon argument principal. Pour la manière dont elle est agencée, c'est au compilateur C de s'en accomoder.

A mon avis il doit manquer pas mal de fonctionalités au CPU pour pouvoir supporter linux.

« Supporter », dans ce sens-ci, n'est pas français ! Dites « prendre en charge », « reconnaître » ou « soutenir », selon les cas. http://linuxfr.org/comments/620840.html#620840 .

Ensuite, ce n'est certainement pas au CPU qu'il manque des fonctionnalités. Étant donné que la quasi-totalité du système est écrite en C, je suis tenté de dire que la seule chose que l'on demande au microprocesseur est de donner la possibilité d'implémenter une pile. Le reste se fait tout seul, et les pilotes pour les différents types de matériels ne réclameront pas des centaines de kilo-octets.

En revanche, c'est l'absence d'une mémoire conséquente qui fera le plus défaut au système. Si en plus, celui-ci ne peut pas se rabattre non plus sur un disque dur, je crains qu'il faille abandonner l'idée d'un système d'exploitation générique sur les vieilles machines.

Voir plutôt ce qui se fait avec OS-9 par exemple, un peu plus haut.

Par contre on fait OS-9 sur MO5.
Les premiers tests ont été très prometteurs.


http://os9.forler.ch/

Sinon, tu lis les lignes de la main ? ;-)

La seule fois où je l'ai fait, ce fut un mauvais présage, donc je me restreins maintenant aux lignes de codes ... :-) Sinon, c'est par ici :

http://www.google.fr/search?hl=fr&q=Chiromancie&btnG(...)

Neuvième commandement du club des fatigués :

« Oublie les vieux travaux et laisse les nouveaux devenir vieux. »

Sous linux :

int main (void)
{
int fd;

fd = open ("/dev/ttys0",O_RDWR)
if (fd>=0)
{
write (fd,"Bonjour\n",8);
close (fd);
}

return 0;
}

Tout ce que tu écriras et lira vers les fichiers /dev/ttyS0 et /dev/ttyS1 iront et proviendront en fait du port série. C'est cool UNIX, non ?

Bon après, il te faudra ouvrir le tout en bloquant ou non-bloquant, faire les réglages du ports, etc. Il faudra jouer avec termios, fcntl, ioctl, et toutes ces bizzarrerie mais chaque chose en son temps.

En attendant : man stty is good for you.

Les bibliothèques partagées en C sont les fichiers "*.so" (Shared Object)
Elles vont la plupart du temps dans /usr/lib.

Regarde le contenu du fichier /etc/ld.so.conf . Il contient la liste des répertoires dont le contenu sera maintenu en cache par le loader dynamique. Tous ces répertoires sont réputés contenir des bibliothèques, mais d'une manière générale, sous UNIX, la variable d'ennvironnement LD_LIBRARY_PATH te donne la liste des répertoires qui seront explorées lors du chargement (de la même façon que PATH te donne la liste des réps qui doivent contenir des exécutables).

Pour ajouter une lib et la rendre disponible, il suffit de la déposer dans un de ces répertoires (et accessoirement de relancer ldconfig pour mettre à jour le cache).

Ca c'est pour les bibliothèques dynamiques (les DLL, quoi). Si c'est pour les utiliser pendant une compilation, tu auras également besoin des *.h qui disent à ton programme comment on les utilise. Habituellement c'est /usr/include


En supposant que ta question n'était pas "comment on crée une DLL sous Linux" ni ne concernait les bibliothèques statiques ...

Pour mémoire i2bp fut une société à vapoware qui promettait (au temps de la bulle internet) de transporter de la vidéo (640x480 25fps) dans un débit de 2Ko/s

Putain ! 5 ans !

Au total, on se retrouve à compresser un fichier de taille énorme en 2 integers !

Par contre il faut 27Go d'espace libre pour installer le codec :-)

Soit à peu près la technologie utilisée dans " South Park " ! :-)

A voir le score du précédent commentaire, je pense qu'il est utile de rappeler qu'il se réfère à ce petit monument :

http://www.bide-et-musique.com/song/4076.html

Si ta question, c'est "je cherche un crack pour pirater le réseau de ma FAC", alors à priori non , il n'y en a pas. C'est même tout l'intérêt du système. Il faudra à la place exploiter les failles de sécurité.

Maintenant, si tu veux faire de la vraie maintenance, la plupart du temps cela relève des droits d'accès plus que de la structure de l'application.

Par exemple, la gestion des partitions d'un disque, donc tu parlais plus haut, se fait en gérant la table des partitions qui se trouve sur le premier secteur (le MBR) du disque lorsque c'est un IDE. Il suffit de donner les droits d'accès avec un "chmod" sur " /dev/hd* " pour que l'utilisateur lambda ait le droit de le faire. Bon, dans ce cas précis, ce n'est pas tout-à-fait vrai car il faut en plus demander au système de relire la table et ça, cela peut demander les privilèges du super-user.

Mais dans tous les cas, l'objectif à atteindre est de se passer au maximum des droits root.