Tuto FreeBSD (suite) - Page 1

Bon, vu que Billy Charvet n'aime pas avoir tort et ferme son topic pour empecher les gens de répondre, on continue ici.

Billy Charvet
:

nitro
: Ben voyons, j'imagine que t'es allé voir les sources pour vérifier.

Bien sûr... Va voir, toi.

C'est déjà fait.

As mentioned before, BSD runs not as an external (or user-level) server, but is part of the kernel itself.

Bon. Désolé, ça a changé (depuis Jaguar ou Panther ? )

Non, ça n'a jamais changé.

Some aspects that BSD is responsible for include:
- process model
- user ids, permissions, basic security policies
- POSIX API, BSD style system calls
- TCP/IP stack, BSD sockets, firewall
- VFS and filesystems (see Mac OS X Filesystems for details)
- System V IPC
- crypto framework - various synchronization mechanisms

Ben c'est ce que j'ai dit, non ?

Tu as la mémoire courte, tu disais que :
- les appels systemes sont en user space
- les filesystems sont en user space
- la pile TCP/IP est en user space
Tout ça est completement faux d'apres ce paragraphe, alors venir me dire que "Ben c'est ce que j'ai dit, non ?"...

Because KEXTs run in supervisor mode in the kernel’s address space, they are also harder to write
and debug than user-level modules, and must conform to strict guidelines
Là c'est clair, tu maitrises carrément le sujet.

Effectivement, je me suis planté sur le terme.

Il n'y a pas que sur le terme, si tu veux mon avis. Tu es complètement à coté de la plaque, comme d'habitude.

Strict guidelines est une référence aux délégations Mach. Et c'est valable aussi sous Hurd. -> Point commun. ^^ #kc#

MDR. Je t'invite à aller regarder ce que veut dire "guidelines" dans un dictionnaire. Apparemment il n'y a pas que sur la technique que tu es à coté de la plaque.

Ca suppose par exemple que KDE et C++ sont équivalents. Donc non je crois pas qu'on puisse dire ça.

Ca suppose surtout que KDE soit écrit en C++.

Ensuite, pourquoi pas dire pendant qu'on y est (même ordre d'idée),
que C# est trop suréquipé pour supporter ELF, et par conséquent mettre
ELF à la poubelle ? C'est même chose qu'avec C++ et a.out. ----> C'est débile.

En C# les binaires ne sont pas natifs, ils ne sont pas exécutés par le kernel, on s'en fout d'avoir un format d'executable en plus en userland. Dans le cas de a.out/ELF, l'un des formats permet de tout gerer et l'autre est handicapé, ce n'est qu'une question de bon sens de proposer ELF comme format recommandé.

Je te ferai remarquer que tu parle à quelqu'un qui connaît par coeur les sources des noyaux Linux jusqu'à la 0.99, et qui connaît aussi suffisamment les internals d'autres systèmes (cf ci-haut)

Je pense que tout le monde a pu se rendre compte de ta fabuleuse "connaissance des internals" de Mac OS X.

Comme certain boulet aime avoir raison en fermant leur topic (merci au passage a nitro pour avoir creer un autre) voila ce que j'allait poster :

• Godzil set mode +fleuve on his post

Billy Charvet
:

Godzil :
Un dévellopeur (un vrai, pas un idiot qui se borne a vouloir tout faire pour lui et jamais penser au autres) n'utilisera JAMAIS un OS aussi limitatif, ne serait-ce que pour pouvoir faire des applis pour les autres

Justement, tous les développeurs codent toujours pour les autres.
Ils s'emmerdent à faire des programmes, rien que pour satisfaire
leur ambition d'être reconnu.

Alors que les développeurs humbles qui codent pour eux c'est
bien plus rare. Et dans le cas de la prog d'OS, c'est beaucoup
plus honorable que d'adapter la machine à ses besoins qu'aux
besoins des autres.

Si tu te met dan,s la catégorie "humble" arrete de nous casser les couilles avec ton "savoir" et va nous coder ton os a deux balles

(Et dans mon cas, je ne pense pas qu'à moi mais à tout bon
geek interessé par les qualités des vieux systèmes comme
DOS, TOS, AmigaOS etc)

DOC et TOS sont primitif
AmigaOS est multitache préemptif alors fait attention a ce quer tu dis quoi ?

Avoir un ecran de grande taille est plus qu'apréciable, le 800x600 est au chiotte depuis des années lumieres pour 99% des programmeurs de la planete plsu tu as d'espace plus mieux c'est

Mmmm. Je tiens à rappeler que 800x600 est bien suffisant pour tracer
des fenêtres. La seule autre chose à par les fenêtres (surtout que
y'en aura pas des masses en mono-taches) c'est le texte.

Tu doit bien connaitre le principe d'une interface utilisateur (quelle qu'elle soit, que ça soit windows, X11, la toolbox du Mac (< X) Aqua & co poru dire ça
L'approche meme du mode fenetré en "monotache" implique du multitache meme si il n'est que cooperatif

Et je te fais remarquer que si on a besoin de si hautes résolutions,
c'est principalement parcequ'on utilise des polices prenant trop de
pixels. Y'a qu'à jouer avec ça sous Windows dans les réglages des
DPI de polices et tu verras pourquoi on se sent à l'étroit en 800.

Mouarf, c'est surement pas la taille des polices
Je ne met pas ma police system en 14pts #trigol#

Le multitache/multithread permette une programamtion bcp plus efficace, pas besoin de 1 lancer l'editeur taper le code, quitter l'editeur, lancer la compilation, tester le programme, ça c'est qu'on faisait dans les année 70 avec des machines totalement incapable d'avoir du "vrai" "pseudo" multitache (tel qu'on le retoruve sur des OS modernes)

1) Enlève le multithread de ta phrase, tout d'abord. Seul
le multi-tâches est nécessaire ici. (Plusieurs tâches à un seul
thread, ou plutôt sans notion de threads dans l'OS)
Et bien on a qu'à permettre à un processus d'en lancer un autre,
ce qui met le premier en attente.

bref tu ne sais pas (et ,e comprend pas) l'interet du multithread

DOS le proposait et marchait très bien, et TOUS LES SYSTEMES
UCLINUX fonctionnent comme ça : seul vfork est implémenté.
(En passant, vfork vient de BSD )

vfork N'EXISTE PAS sous DOS #trigol# revois ta documentation
Soit dit en passant si tu prone cette ignominie, c'est que tu n'a rien pigé au multitache

*Rien que le débuggage est impossible si tu n'a pas de multitache,*

Un système tel que celui-ci, une fois conçu en C, peut grâce
à des directives de compilation conditionnelle être adapté de façon
à marcher sur un autre système, multi-tâches, et avec
un mécanisme de débogage.

Il dit qu'il n'a vraiment plus de genou, bref une belle phrase totalement hors sujet

Et pour le mode Trace, si c'est bien pour l'asm c'est cool, puisque
ce système serait bien assez simple à programmer pour pouvoir
s'y prendre en assembleur sans trop de pb.

Le pbm (mais apriori tu ne sais pas lire) c'est que ce mode est "émulé" sur un x86 et n'est pas présent sur ce type de machine

Je sens bien le "regarde j'ai DOS, DJGPP et Rhide" et j'ai pas besoin de quitter Rhide pour compiler/débugguer C'est un HACK bien sale qui est utilisé pour rendre la main au dos et lancer gcc pour pouvoir compiler, et c'est pareil pour pouvoir débugguer et c'est bcp plus sale qu'un vrai OS multitache/multithread

Quand c'est sale et que ça marche, c'est mieux que quand c'est propre
(enfin, soi-disant) et que ça plante.

Alors ça c'est la meilleur, c'est mieux quand c'est codé salement que quand c'est codé proprement ?

Deja avoir 1 seule machine qui permet de coder est d'écouter la musique est plus qu'apréciable, imagine toi dans le train avec ton ordi portable monotache et trimbalant ta chaine stéréo ,

T'as pas tout lu: et le baladeur ? ©

Bof ecouter un MP3 me prend pas plus de 5% du processeur, bref j'ai 95% du temps pour tout le reste (dont la compilation) je vois pas le pbm et un baladeur ça consome des piles alors que le portable lui est en marche et ne peut que faire une compilation et n'utilise meme pas le processeur a 100%
Je vois pas l'interet, surtout en plus si il faut changer le cd (cassette aussi du temps qu'on y est) pour changer de musique

Ensuite je crois que tu n'a jamais du comprendre quelle etait la différence (frondamentale) entre le multitache et le multithread
Le multithread ne peut effectiement etre fait en monotache, mais n'est pas du tout un equivalent de "fonctionnement par interruption"
Le multithread ne peut servir QUE si l'environement est multitache, ET est un des nombreux mécanismes permettant (entre autres) une protection de la mémoire. Le fonctionnement des UNIX classiques en mode "tout est processus" est une abération totale. mais bon je te laisserait a l'occasion découvrir ce que sont vraiment les threads.

Je te ferai remarquer que tu parle à quelqu'un qui connaît par coeur
les sources des noyaux Linux jusqu'à la 0.99, et qui connaît aussi
suffisamment les internals d'autres systèmes (cf ci-haut)

Tu connait les sources par coeur ?

Ok

Interro ecrite :
Je veux la procedure EXACTE (et aps du copier coller sortit tout droit de google hein !!) de la procedure gerant les interuption du kernel linux 0.99

Pardon du conseil, mais:
1) Arrête de poster, franchement... j'ai mieux à faire que du
baby-sitting d'amoureux d'Unix incapables de voir que c'est un
système trop complexe, et qui croient savoir ce qu'est un thread
et bizarrement n'arrivent pas à faire marcher leurs progs parceque
leurs connaissances se limitent au terme thread, et qu'il ne
connaissent visiblement pas "mutex", "sémaphore" ou "spinlock".

amoureux d'unix #triglo# c'est pas moi la dans ce cas qui prone unix, mais toi avec ton FreeBSD
Je sais ce qu'est un Mutex, d'ailleur je vois pas ce qu'il viennent faire la, on a jamais parlé de mutex, d'ailleur les mutex (Mutal Exclusion pour ta culture) ne sont pas un mecanisme propre a la programmation, ni au multithread"age", a ce propos (toujorus pour ta culture qui m'a l'air bien basse) un Mutex est une forme de sémaphore fixé a 1, et je te laisse chercher un peu si tu veux en savoir plus. (d'ailleur un "spinlock" n'a pas gd chose a voir avec un mutex ou un sémaphore, ni d'ailleur avec un event ou un pipe voir meme un mailslot, il ne s'agit pas d'un noyaux, mais d'une erreur de programmation)

2) Pour faire plus classe pour parler de threads, t'as encore mieux
que pthreads, tu peux dire "exétrons".

pthread, soit les posix_thread n'on rien de spécial par rapport au thread "normaux" #trigol# ce n'est que l'api qui est a peu pret standard (meme si linux ne comprend pas le sens du terme posix malgres une lib pthread et soit disant posix compatible)

1) Remets ta sucette dans ta bouche, tu baves sur le clavier. ©

sucette ? ha ? ha ben merde alors ça doit faire 23ans qu'elle est tombé, désolé, toi par contre tu devrait retyourner dans les jupons de ta mere en pleurant qu'il y a un grand méchant qui t'embette

Billy Charvet
:

nitro
: Ben voyons, j'imagine que t'es allé voir les sources pour vérifier.

Bien sûr...
Va voir, toi.

Ah non j'oubliais, dès que ça dépasse 10000 lignes de code t'es perdu...

Mmm... et toi ? --->

tres inteligente réponse

As mentioned before, BSD runs not as an external (or user-level) server, but is part of the kernel itself.

Bon. Désolé, ça a changé (depuis Jaguar ou Panther ? )

Depuis NextStep 1.0 alors va te pendre

Some aspects that BSD is responsible for include:

- process model
- user ids, permissions, basic security policies
- POSIX API, BSD style system calls
- TCP/IP stack, BSD sockets, firewall
- VFS and filesystems (see Mac OS X Filesystems for details)
- System V IPC
- crypto framework - various synchronization mechanisms

Ben c'est ce que j'ai dit, non ?

Non pas vraiment non

Because KEXTs run in supervisor mode in the kernel’s address space, they are also harder to write
and debug than user-level modules, and must conform to strict guidelines
Là c'est clair, tu maitrises carrément le sujet.

Effectivement, je me suis planté sur le terme.
Strict guidelines est une référence aux délégations Mach. Et
c'est valable aussi sous Hurd. -> Point commun. ^^ #kc#

je suis pas sur que c'est oti qui ai cassé nitro mon pauvre

Bah c'est comme tu veux... on peut aussi dire "KDE, Firefox, Fluxbox, Opera, etc (un tiers des projets répertoriés sur freshmeat) sont trop sur-équipé pour supporter a.out".

Mmm. Ca suppose par exemple que KDE et C++ sont équivalents.
Donc non je crois pas qu'on puisse dire ça.

pourtant KDE est ecrit a 100% en C++
BeOS utilisait l'ELF aussi

a.out est dépassé depuis ça conception ELF a été inventé pour eviter ce genre de merde

Ensuite, pourquoi pas dire pendant qu'on y est (même ordre d'idée),
que C# est trop suréquipé pour supporter ELF, et par conséquent mettre
ELF à la poubelle ? C'est même chose qu'avec C++ et a.out.
----> C'est débile.

Je suis pas sur duquel est débile

Hum je viens de dire une bétise, c'est meme pas NextStep 1.0 mais bien avant, des que le choix sur le noyaux Mach a été fait et que en tant que serveur *BSD a été choisis, la solution trouvé (encore aujourd'hui dans 10.3.5) est la MEME

godzil, ce n'est pas en fermant un topic qu'on se justifie/donne raison.

J'ai moins d'eau donc ce n'est pas un fleuve, juste un ruisseau.

Billy Charvet :
Alors que les développeurs humbles qui codent pour eux c'est
bien plus rare. Et dans le cas de la prog d'OS, c'est beaucoup
plus honorable que d'adapter la machine à ses besoins qu'aux besoins des autres.

Je veux bien des statistiques sur ce que tu avances. De tous les programmeurs que je connaisse, que ce soit dans mon école ou ailleurs, TOUS programment pour un besoin qu'ils ont et qui n'est pas encore satisfait.

Alors rompons avec l'habitude. Programmons un peu pour un
cercle fermé d'utilisateurs, comme ça se passait avant.

et si c'était moins bien avant ? Et si on avait progressé, et si on se disait que finalement, ce qu'on fait pour soi dans son coin, ça peut servir aux autres, empêcher de réinventer la roue quand elle existe en plusieurs versions ?

Mmmm. Je tiens à rappeler que 800x600 est bien suffisant pour tracer
des fenêtres. La seule autre chose à par les fenêtres (surtout que
y'en aura pas des masses en mono-taches) c'est le texte.
Et je te fais remarquer que si on a besoin de si hautes résolutions,
c'est principalement parcequ'on utilise des polices prenant trop de pixels.

Je veux bien faire le test, je travaille constamment en 1024x768, et je ne pense jamais aller au delà. Pourquoi ? Je suis myope, et impossible pour moi de lire du texte en dessous de taille 12. Alors si pour toi la solution est de prendre un écran, le mettre en 800x600, mais d'écrire avec des polices plus petites, non. Décidément, on n'est pas du même monde. Je ne vais pas me déchirer les yeux parce que certains préfèrent travailler sur une résolution rétro (je veux dire, pas moderne).

1) Enlève le multithread de ta phrase, tout d'abord. Seul
le multi-tâches est nécessaire ici. (Plusieurs tâches à un seul
thread, ou plutôt sans notion de threads dans l'OS)
Et bien on a qu'à permettre à un processus d'en lancer un autre, ce qui met le premier en attente.

Je travaille sur un site en cgi sous emacs, avec apache en local. J'ai également besoin d'avoir constamment sous les yeux les logs apache qui défilent, et je dois pouvoir visualiser en même temps la charge CPU de mon système. Je peux le faire sur ton système ?

Et pour le mode Trace, si c'est bien pour l'asm c'est cool, puisque
ce système serait bien assez simple à programmer pour pouvoir s'y prendre en assembleur sans trop de pb.

et si on en revenait aux cartes à poinçonner pour programmer ?

Quand c'est sale et que ça marche, c'est mieux que quand c'est propre (enfin, soi-disant) et que ça plante.

Tout à fait. Dis moi ... Linux ça serait (selon toi) sale, mais ... ça marche non ? Tu me proposes quoi qui fasse les mêmes choses (exactement) mais en propre, et qui ne plante éventuellement pas. Darwin n'est pas une réponse.

Deja avoir 1 seule machine qui permet de coder est d'écouter la musique est plus qu'apréciable, imagine toi dans le train avec ton ordi portable monotache et trimbalant ta chaine stéréo ,

T'as pas tout lu: et le baladeur ?

Hmmm ... le baladeur, ça implique d'avoir des écouteurs, plus un appareil séparé que tu mets ... dans ta poche, etc. Ca prend plus de place, tu uses des piles pour rien (bah oui), sur ton ordinateur tu vas avoir plus de cycles inutilisés, donc autant prendre un P100, finalement, ça marche tout aussi bien pour faire du vi en mode console. Oui parce qu'un window manager ça ne sert à rien quand on est programmeur. J'ai un portable, il me permet d'écouter de la musique. Pourquoi ne pas en profiter ?

Je te ferai remarquer que tu parle à quelqu'un qui connaît par coeur
les sources des noyaux Linux jusqu'à la 0.99, et qui connaît aussi suffisamment les internals d'autres systèmes (cf ci-haut)

Quelle est la ligne de code numéro 42 du code du premier driver apparaissant dans le code en faisant un ls -Rl ?
Pardon, boutade.
Je ne quote pas le reste de cet argument non parce qu'il dépasse mes connaissances, mais parce qu'il n'a aucun contenu pédagogique


edit : mal lu un point.

kim
:

Mmmm. Je tiens à rappeler que 800x600 est bien suffisant pour tracer
des fenêtres. La seule autre chose à par les fenêtres (surtout que
y'en aura pas des masses en mono-taches) c'est le texte.
Et je te fais remarquer que si on a besoin de si hautes résolutions,
c'est principalement parcequ'on utilise des polices prenant trop de pixels.

Je veux bien faire le test, je travaille constamment en 1024x768, et je ne pense jamais aller au delà. Pourquoi ? Je suis myope, et impossible pour moi de lire du texte en dessous de taille 12. Alors si pour toi la solution est de prendre un écran, le mettre en 800x600, mais d'écrire avec des polices plus petites, non. Décidément, on n'est pas du même monde. Je ne vais pas me déchirer les yeux parce que certains préfèrent travailler sur une résolution rétro (je veux dire, pas moderne).

J'irais plus loin, plus tu as de point, plus ton image est précise, tu augment la taille de la police, des icones & co et meme si "physiquement" les images sont de la meme taille, la qualité ne peut etre que meilleur, bref

Oh ! des groupies en chaleur, génial !!!
#trifuck#
---->

Avouez simplement que vous êtes venus m'agresser dans mon topic,
comme des gamins de primaire. (Et encore).

La mauvaise foi présente ici est pathétique.
Si on avait l'esprit de contradiction on pourrait trouver
ça risible.

MMM, je ne vais pas flooder davantage ce topic stupide
(mais vu que ceux qui y postent sont ceux qui ont pas
pu répondre, ils ne font que confirmer que je les ai bien emmerdé
en fermant le topic.)

Bon, continuons un peu, je démolirai ce topic et j'aurai plus qu'à
rouvrir l'ancien, en y mettant du sérieux. Vous serez coupés en
plein milieu de votre troll débile et vous vous retrouverez comme
des cons. Ca vous arrive de réfléchir avant (d'essayer tant bien que mal)
d'emmerder quelqu'un ?

R (17:37) Billy Charvet: Vertyos, peux-tu supprimer/locker le topic Tuto BSD
(suite) ? C'est un topic troll qui n'a pas lieu d'être,
et ne peut que dégrader le forum avec des engueulades.

R (17:41) Vertyos » Billy Charvet: Déjà, je ne trouve pas le comportement "je poste mon avis et je ferme le topic pour empecher les réponses" très fair-play... On m'a demandé de réouvrir le topic, je l'ai pas fait même si c'est pas l'envie qui m'en manquait.
Maintenant fermer un topic qui ne t'appartient pas, et surtout vu le 1er post que tu y as mit, hors de question.

R (17:44) Billy Charvet: Mmm. Je te demande cela en tant qu'admin
parceque je pense que tu peux éviter que le forum
se dégrade. Je ne vois pas en quoi des différents passés pourraient te faire te comporter de manière
injuste dans ce cas, c'est irresponsable.

Je suis tout disposé à éditer ce que j'ai posté dans ce second topic et à rouvrir l'ancien, mais ce
topic est un troll direct contre moi, tu comprends bien que je ne peux pas être d'accord avec, non ?

R (17:46) Vertyos » Billy Charvet: Il n'est pas question de "différents passés", ça n'a aucun rapport avec le fait que ce soit toi ou non. Visiblement eux avaient envie de continuer la discussion, tant qu'il n'y a pas d'insultes ou autres, je n'y vois aucun problème.
Maintenant si tu veux réouvrir l'ancien topic (et t'engager à ne plus le fermer), c'est encore mieux, oui.

R (17:47) Billy Charvet: Ok.

R (17:48) Vertyos » Billy Charvet: Ok, je ferme le nouveau