> Même en multicast, on a toujours une IP qui identifie chaque ordinateur, et le multicast doit bien garder une trace des adresses IP individuelle à un moment donné pour que les routeurs prennent leur décision, non ?
Non, et c'est l'interet du multicast. Ca marche comme ca (en gros) :
- un client s'abonne a un flux multicast, et envoie une requete IGMP au serveur de flux
- les routeurs sur le chemin memorisent cette requete
- le serveur emet son flux vers cette adresse multicast
- les routeurs envoient le packaget multicast vers tous les clients qui en ont fait la demande (grace a la memorisation de la requete IGMP)
- le client renouvelle periodiquement son abonnement (par d'autres requetes IGMP)
- a la fin, le client se desabonne du flux (par une autre requete IGMP)
- chaque routeur sur le chemin memorise, et si plus aucun client sur cette interface n'a d'abonnement en cours pour ce flux, le routeur cesse d'envoyer le flux sur cette interface
Comme ca, du cote serveur, un seul et unique packet est envoye, et ce sont les routeurs qui decident de dupliquer sur chacuen des interfaces ou ils ont vu une requete IGMP pour ce flux.
> Pas de définition de licence libre par contre. Faudrait pas non plus être trop précis, hein.
Non, mais par contre un petit laius sur les licences libres pour les " oeuvres de l'esprit " :
--8<--
Creative Commons
Elles désignent des licences non exclusives en vertu desquelles un titulaire de droits autorise à l'avance le public à effectuer certaines utilisations de son œuvre à titre gratuit, sous réserve du respect de certaines conditions (ex : pas d'exploitation commerciale de l'oeuvre). Ces conditions sont variables selon la licence Creative commons choisie par le titulaire de droits. (Source : http://fr.creativecommons.org).
--8<--
Une solution ultra simple pour ajouter au début :
LD_LIBRARY_PATH="${newpath_1}:${LD_LIBRARY_PATH}"
LD_LIBRARY_PATH="${newpath_2}:${LD_LIBRARY_PATH}"
# etc...
LD_LIBRARY_PATH="${LB_LIBRARY_PATH%:}"
Comme ça tu ne te casses pas avec des lignes ignobles, et tu vires le ':' seulement à la fin, au cas où le LD_LIBRARY_PATH initial était vide.
Et si tu veux ajouter à la fin :
LD_LIBRARY_PATH+=":${newpath_1}"
LD_LIBRARY_PATH+=":${newpath_2}"
# ...
LD_LIBRARY_PATH="${LB_LIBRARY_PATH#:}"
Et en Anglais, ça donne: Commercial Agreement for Counterfeiting Annihilation. CACA.
Comme quoi, ça marche d'inverser les acronymes Français <-> Anglais! :-)
> PS: si vous avez une idée pour faciliter l'utilisation de logiciel non packagés, je suis preneur.
J'installe chaque package (ou groupe de packages) dans /opt/mon_package.
Et mon /etc/bashrc scan /opt/*/bin pour les ajouter dans le PATH automatiquement.
> j'utilise tmpname ou un truc dans le genre qui me produit warning de sécurité
En C, c'est 'mkstemp'.
En feuilletant le code de Mercurial l'autre jour, je suis aussi tombé dessus: 'tempfile.mkstemp'.
Je ne sais pas s'il te faut importer quelque chose, mais bon, c'est déjàa un point de départ...
...tourne ma vieille Sun. Une SPARC-Station 5, format pizza-box.
Allumée environ deux jours par mois, c'est pas beaucoup. mais c'est marrant.
Et sinon, j'ai aussi des lunch-box, mais elles servent à faire une table basse, donc utilisées au quotidien, celles-ci! :-) ( qui a dit que le matos devait être allumé, il a dit 'utiliser couramment'! )
> Par exemple, l'état français reconnait l'intérêt de soutenir des projets
> culturels, et permet à quiconque (en gros, hein, les règlements sont
> multiples selon les disciplines, je ne détaille pas) qui présente un dossier
> argumenté de pouvoir au moins faire une demande de financement : il y
> a des guichets à l'écoute. On pourrait s'inspirer de ce type de dispositifs ?
Le logiciel etant considere comme une oeuvre artistique, on devrait pouvoir
presenter un projet de logiciel libre de la meme maniere, non?
Et surtout: "...La Sacem est une PME qui a la culture Open Source dans la peau..."
Mais oui, une societe qui defend bec et ongles un modele economique a base de DRM et de "propriete intellectuelle", avoir la culture Open Source, ca doit etre un peu schyzophrenique...
Je pense surtout que si NVIDIA preconisait d'utilisait nouveau, ca pourrait avoir l'effet de decredibiliser leur pilote pivateur, en mettant en avant que deux/trois geeks dans leurs garages font mieux qu'une floppee d'ingenieurs payes a faire ca a plein temps.
Au fait, mon explication est valable pour les applications, pas pour le noyau. Le noyau peut effectivement travailler avec de la memoire physique, lui.
Et pour la memoire physique c'est effectivement plus complique...
Exemple :
- de la memoire est allouee et desalloue par le kernel, en plusieurs fois, de maniere 'aleatoire' ; tout va bien, il y a assez, mais la memoire est pleine de petits trous...
- un driver est charge (par exemple, par chargement de module) et a besoin d'une grosse quantite de memoire contigue (ex. pour mapper avec du materiel). Meme s'il y a assez, mais en plein de tout petits bouts, alors l'allocation va echouer. Il est en effet impossible de remapper les petits bouts, car d'autres parties du kernel ont des pointeurs dessus, et il faut surtout pas les contrarier, ces petites betes la!
Lorsque tu alloues de la memoire, tu obtiens un pointeur sur de la memoire _virtuelle_. Si le system re-ordonne les blocks _vituels_ pout obtenir des block contigus, alors tes pointeurs deviennent faux! Et tu n'as aucun moyen de le savoir!
Par contre, le re-ordonnancement des blocks physiques est possible (sauf certains cas) puisque la MMU est la pour ca : translation adresse virtuelle -> adresse physique. Et ca, ca peut changer sans probleme. D'ailleurs, ca arrive tout le temps!
Exemple :
- ton appli alloue un bloc de memoire : elle obtient de la memoire virtuelle, et une correspondance avec de la memoire physique est etablie a travers la MMU (grosso modo, hein!)
- ton appli est preemptee par une autre appli, qui a besoin de memoire
- le block precedent est mis en 'swap'
- ton appli est a nouveau schedullee et a besoin de son block
- le systeme reprend le block ; son adresse virtuelle n'a pas change, mais rien ne garantit qu'il soit au meme endroit en memoire physique
Une autre explication : si tu as 128KiB de memoire (virtuelle!), et que tu alloues 4 blocks de 32KiB, tu as la place, et la memoire est repartie ainsi :
Block 0 : 32KiB : indisponible
Block 1 : 32KiB : indisponible
Block 2 : 32KiB : indisponible
Block 3 : 32KiB : indisponible
Maintenant, tu liberes les blocks 1 et 3, donc tu as 64KiB de memoire libre, repartis ainsi :
Block 0 : 32KiB : indisponible
Block 1 : 32KiB : libre
Block 2 : 32KiB : indisponible
Block 3 : 32KiB : libre
Enfin, tu veux allouer un block de 64KiB. He bien ce n'est pas possible, car le plus gros block dispo n'est que de 32KiB. Donc meme si tu as 64KiB de memoire disponible, tu n'as pas 64KiB _contigus_ de disponible, et donc ta memoire est fragmentee!
[^] # Re: Chapi-Chapo
Posté par ymorin . En réponse au journal Définition d'une adresse IP par l'hadopi. Évalué à 4.
Non, et c'est l'interet du multicast. Ca marche comme ca (en gros) :
- un client s'abonne a un flux multicast, et envoie une requete IGMP au serveur de flux
- les routeurs sur le chemin memorisent cette requete
- le serveur emet son flux vers cette adresse multicast
- les routeurs envoient le packaget multicast vers tous les clients qui en ont fait la demande (grace a la memorisation de la requete IGMP)
- le client renouvelle periodiquement son abonnement (par d'autres requetes IGMP)
- a la fin, le client se desabonne du flux (par une autre requete IGMP)
- chaque routeur sur le chemin memorise, et si plus aucun client sur cette interface n'a d'abonnement en cours pour ce flux, le routeur cesse d'envoyer le flux sur cette interface
Comme ca, du cote serveur, un seul et unique packet est envoye, et ce sont les routeurs qui decident de dupliquer sur chacuen des interfaces ou ils ont vu une requete IGMP pour ce flux.
[^] # Re: Y'en a d'autres...
Posté par ymorin . En réponse au journal Définition d'une adresse IP par l'hadopi. Évalué à 2.
Non, mais par contre un petit laius sur les licences libres pour les " oeuvres de l'esprit " :
--8<--
Creative Commons
Elles désignent des licences non exclusives en vertu desquelles un titulaire de droits autorise à l'avance le public à effectuer certaines utilisations de son œuvre à titre gratuit, sous réserve du respect de certaines conditions (ex : pas d'exploitation commerciale de l'oeuvre). Ces conditions sont variables selon la licence Creative commons choisie par le titulaire de droits. (Source : http://fr.creativecommons.org).
--8<--
# Restons simples...
Posté par ymorin . En réponse au message Comment concaténer des chemins de façon plus simple sous Bash ?. Évalué à 3.
LD_LIBRARY_PATH="${newpath_1}:${LD_LIBRARY_PATH}"
LD_LIBRARY_PATH="${newpath_2}:${LD_LIBRARY_PATH}"
# etc...
LD_LIBRARY_PATH="${LB_LIBRARY_PATH%:}"
Comme ça tu ne te casses pas avec des lignes ignobles, et tu vires le ':' seulement à la fin, au cas où le LD_LIBRARY_PATH initial était vide.
Et si tu veux ajouter à la fin :
LD_LIBRARY_PATH+=":${newpath_1}"
LD_LIBRARY_PATH+=":${newpath_2}"
# ...
LD_LIBRARY_PATH="${LB_LIBRARY_PATH#:}"
Voila...
[^] # Re: iTrt eudc moemtniaer
Posté par ymorin . En réponse au journal SOLR-2128: full param substitution for function queries. Évalué à 5.
Ah bah oui, mais non. On n'inverse pas des bits. On inverse des octets...
Et encore, le petit-boutisme et le grand-boutisme ne sont pas les seules religions à exister. Il y a aussi eu le boutisme du milieu (e.g. PDP-11)...
Par exemple en grand-boutisme, on écrit: 1234; en petit-boutisme, on écrit 4321, et en boutisme du milieu, c'était 2143.
Bhe oui, il y avait des sado-maso aux premiers temps de l'informatique...
[^] # Re: Softs qui déchiraizent \o/
Posté par ymorin . En réponse au journal Softs qui déchiraizent \o/. Évalué à 2.
Et en plus il semble mieux maintenu !
Merci pour le tuyau ! :-)
[^] # Re: Softs qui déchiraizent \o/
Posté par ymorin . En réponse au journal Softs qui déchiraizent \o/. Évalué à 1.
Misère... J'y avais bien pensé qu'un soft aurait ce nom, mais j'ai eu la flemme de vérifier...
# Re: Softs qui déchiraizent \o/
Posté par ymorin . En réponse au journal Softs qui déchiraizent \o/. Évalué à 4.
Dans la catégorie "je développe", les lauréats sont :
- gcc
- qemu
- awk
Dans la catégorie "console", les lauréats sont :
- screen
- twin
- bash
Dans la catégorie "Hawaï", les lauréats sont :
- firefox
- kmail
- aria2
Les lauréats hors-catégorie sont :
- le noyau Linnux
- k3b
- gimp
Vala. Ca fait plus que trois, mais bon, il fallait des catégories.
[^] # Re: et ?
Posté par ymorin . En réponse au journal [HS] Des chips jusque dans les oreilles !. Évalué à 1.
Attention! Ce flim n'est pas un flim sur cyclimse...
http://fr.wikipedia.org/wiki/La_Classe_am%C3%A9ricaine
[^] # Re: prononciation ?
Posté par ymorin . En réponse à la dépêche Mandriva Linux et après ? Mageia !. Évalué à 2.
Trop gros, passera pas. Et on n'est pas vendredi... :-)
[^] # Re: Provenance ?
Posté par ymorin . En réponse au journal HDCP : c'est fini ?. Évalué à 5.
http://cryptome.org/hdcp-weakness.htm
[^] # Re: Accord commercial anti-contrefaçon
Posté par ymorin . En réponse au journal HDCP : c'est fini ?. Évalué à 10.
Comme quoi, ça marche d'inverser les acronymes Français <-> Anglais! :-)
OK, je --> []
# Simple install
Posté par ymorin . En réponse au journal Réinventer la roue est parfois plus simple que de réutiliser l'existant .... Évalué à 10.
J'installe chaque package (ou groupe de packages) dans /opt/mon_package.
Et mon /etc/bashrc scan /opt/*/bin pour les ajouter dans le PATH automatiquement.
Si je n'en ai plus besoin, "rm -rf" est mon ami.
[^] # Re: Florilège
Posté par ymorin . En réponse à la dépêche HADOPI : nouveau recours en référé de FDN devant le Conseil d'État.. Évalué à 5.
Merki! :-)
[^] # Re: Fichier temporaire
Posté par ymorin . En réponse au journal [PUB] sortie d'un logiciel de gestion de document électronique. Évalué à 2.
# Fichier temporaire
Posté par ymorin . En réponse au journal [PUB] sortie d'un logiciel de gestion de document électronique. Évalué à 4.
En C, c'est 'mkstemp'.
En feuilletant le code de Mercurial l'autre jour, je suis aussi tombé dessus: 'tempfile.mkstemp'.
Je ne sais pas s'il te faut importer quelque chose, mais bon, c'est déjàa un point de départ...
[^] # Re: Mon serveur ...
Posté par ymorin . En réponse au journal Le vieux materiel. Évalué à 5.
Bref, Rincevent et la peur...
# Et sinon, hors du monde x86...
Posté par ymorin . En réponse au journal Le vieux materiel. Évalué à 6.
Allumée environ deux jours par mois, c'est pas beaucoup. mais c'est marrant.
Et sinon, j'ai aussi des lunch-box, mais elles servent à faire une table basse, donc utilisées au quotidien, celles-ci! :-) ( qui a dit que le matos devait être allumé, il a dit 'utiliser couramment'! )
[^] # Re: Bravo ... mais
Posté par ymorin . En réponse à la dépêche K3b 2.0 est juillet. Évalué à 2.
> culturels, et permet à quiconque (en gros, hein, les règlements sont
> multiples selon les disciplines, je ne détaille pas) qui présente un dossier
> argumenté de pouvoir au moins faire une demande de financement : il y
> a des guichets à l'écoute. On pourrait s'inspirer de ce type de dispositifs ?
Le logiciel etant considere comme une oeuvre artistique, on devrait pouvoir
presenter un projet de logiciel libre de la meme maniere, non?
Bon, d'accord, je ---> []
[^] # Re: Et si la SACEM se remettait en question ?
Posté par ymorin . En réponse à la dépêche Revue de presse de l'April pour la semaine 21. Évalué à 10.
Mais oui, une societe qui defend bec et ongles un modele economique a base de DRM et de "propriete intellectuelle", avoir la culture Open Source, ca doit etre un peu schyzophrenique...
# Pour info aussi...
Posté par ymorin . En réponse à la dépêche Open vSwitch, le commutateur virtuel bientôt sur votre serveur. Évalué à 2.
Mes 2 euro-cents.
[^] # Re: Victoire \o/
Posté par ymorin . En réponse au journal Nvidia arrête le support de son pilote opensource nv. Évalué à 4.
[^] # Re: Juste une question
Posté par ymorin . En réponse à la dépêche Nouvelle version 2.6.33 du noyau Linux. Évalué à 3.
Et pour la memoire physique c'est effectivement plus complique...
Exemple :
- de la memoire est allouee et desalloue par le kernel, en plusieurs fois, de maniere 'aleatoire' ; tout va bien, il y a assez, mais la memoire est pleine de petits trous...
- un driver est charge (par exemple, par chargement de module) et a besoin d'une grosse quantite de memoire contigue (ex. pour mapper avec du materiel). Meme s'il y a assez, mais en plein de tout petits bouts, alors l'allocation va echouer. Il est en effet impossible de remapper les petits bouts, car d'autres parties du kernel ont des pointeurs dessus, et il faut surtout pas les contrarier, ces petites betes la!
Re-hop, re-voila! ;-)
[^] # Re: Juste une question
Posté par ymorin . En réponse à la dépêche Nouvelle version 2.6.33 du noyau Linux. Évalué à 1.
Par contre, le re-ordonnancement des blocks physiques est possible (sauf certains cas) puisque la MMU est la pour ca : translation adresse virtuelle -> adresse physique. Et ca, ca peut changer sans probleme. D'ailleurs, ca arrive tout le temps!
Exemple :
- ton appli alloue un bloc de memoire : elle obtient de la memoire virtuelle, et une correspondance avec de la memoire physique est etablie a travers la MMU (grosso modo, hein!)
- ton appli est preemptee par une autre appli, qui a besoin de memoire
- le block precedent est mis en 'swap'
- ton appli est a nouveau schedullee et a besoin de son block
- le systeme reprend le block ; son adresse virtuelle n'a pas change, mais rien ne garantit qu'il soit au meme endroit en memoire physique
Hop, voila.
[^] # Re: Juste une question
Posté par ymorin . En réponse à la dépêche Nouvelle version 2.6.33 du noyau Linux. Évalué à 3.
Block 0 : 32KiB : indisponible
Block 1 : 32KiB : indisponible
Block 2 : 32KiB : indisponible
Block 3 : 32KiB : indisponible
Maintenant, tu liberes les blocks 1 et 3, donc tu as 64KiB de memoire libre, repartis ainsi :
Block 0 : 32KiB : indisponible
Block 1 : 32KiB : libre
Block 2 : 32KiB : indisponible
Block 3 : 32KiB : libre
Enfin, tu veux allouer un block de 64KiB. He bien ce n'est pas possible, car le plus gros block dispo n'est que de 32KiB. Donc meme si tu as 64KiB de memoire disponible, tu n'as pas 64KiB _contigus_ de disponible, et donc ta memoire est fragmentee!
Voila...