totof2000 a écrit 9656 commentaires

Ici, on parle de GPL, donc il y a une contrainte de plus (Tu dois filer la recette de tes plats à tes invités (ou clients)

oui, à leur demande. S'ils ne demandent rien, tu n'es pas obligé.

et tes invités doivent la filer aussi si il font la même recette)

S'ils font la même recette, la modifient, ou intègrent la recette à une autre (qui elle même devient GPL - cas d'une sauce par exemple que tu intègre dans une recette plus globale), ils doivent la refiler à leurs invités si ceux-ci la demandent. (on peut se poser maintenant cette question : question : est-ce que la recette du plat est GPL ou est-ce que le menu complet devient GPL ?)

Si tu n'es pas invité, tu ne peux pas exiger d'avoir la recette. Même si tu la demandais à un des invités, tu ne pourrais exiger de l'avoir tant que toi-même tu n'as pas été invité.

On va arriver à trouver la bonne analogie pour comprendre le copyleft :).
Oui et on se posera les mêmes questions … :)

sur demande. Très important ça.

Ca amène une queston de ma part : Si A fournit un logiciel a B, et que B fournit le logiciel à C (sans en avoir eu la licence parce qu'il n'en a pas besoin, pas de modification ou étude nécessaire donc pas demandé). C demande le code source à B, qui le demande a A. A refuse de lui donner. Est-ce que B est en faute par rapport à C? Doit-il arrêter de diffuser le logiciel à d'autres tant qu'il n'aura pas les sources de A ?

Je veux dire que le public du site est plutôt connaisseur du sujet, donc on peut se permettre des simplifications.

Hein ? Elle sert à quoi ta simplification alors?

Personnellement je préfère expliquer les points difficile à cmprendre plutot que de les simplifier et déformer la réalité.

Je n'aime pas les simplifications en général : On tombe vite dans la désinformation journalistique.

La GPL s'adresse aux développeurs, pas aux utilisateurs.

Ca OK.

Ben non.

La GPL s'adresse à l'utilisateur qui reçoit un binaire compilé (un développeur n'a rien à en faire d'un binaire compilé). Elle stipule qu'il peu demander le code source à la personne ou l'entité lui ayant fourni ledit binaire. Après cette personne fait ce qu'ele veu des sources. Laseule condition c'est de fournir a quiconque aurait reçu d'elle un binaire compilé tout le code issu du code source qu'elle a obtenu.

Je ne crois pas : le code développé en interne par la boite appartient à la boite, pas à la secrétaire. Le code n'est pas diffusé tant qu'il reste en interne dans la boite Elle ne pourra le diffuser que sous accord des instances dirigeantes de la boite.

Amsant pour quelqu'un qui me faisait la remarque il y a peu de élangerboite/employé/individu/famille, etc …

Sur ton iphone ou sur ton écran de PC ?

Sur un site comme Linuxfr, on s'attend aussi à certaines réactions lors que l'on met :
- un journal bookmark
- un apple bashing
- une citation d'un article "grand public" biaisé
- une pseudo-étude plus ou moins argumentée avec résultats plus que contestables
- un journal avec un titre "sensationnaliste"

Vu le nombre de personnes qui se prennent au sérieux ici, ou qui sont "sensibles" dès qu'on fait une phrase qui pourrait insinuer le moindre début de critique anti-apple (on se demande pourquoi d'ailleurs ces personnes se sentent obligées de se justifier tout le temps), quand on met le tout dans le même journal (avec double redirection, pas récursion comme le dit la personne à qui tu réponds), c'est une bonne rigolade assurée. En tout cas je me suis bien amusé, merci à vous ;).

Note à ceux qui à mon sens surréagissent : il faut savoir de temps en temps prendre un peu de recul et ne pas tout prendre au premier degré.

C'est moche Linux : sous BSD, c'est homogène.

Je ne suis pas sûr qu'entre NetBSD, OpenBSD, FreeBSD ou DragonflyBSD ce soit si homogène que ça mais passons.

Tu te fous du monde ? Je répondais à ça (tu devrais lire un peu avant de répondre):

et parfois même au sein d'une même distribution.

Au sein d'un même BSD c'est homogène.

Sais tu seulement de quoi tu parles ?

Oui : il y a toujours des différences entre les distribs, que tu le veuilles ou non, et systemd n'y changera rien.

Par exemple, les daemons n'ont même plus besoin de forker, c'est implémenté du côté de systemd une fois pour toutes.

Houla ca c'est moche !!!! Et quel est le rapport avec le système de démarrage ? C'est pas son rôle de forker ou pas, c'est le rôle de l'exécutable de faire ça. Systemd se mèle de ce qui nele regarde pas.

systemd est orienté évènement, un truc que SysV et consorts n'ont jamais résolu (-> standardisation).

C'est à dire ? Il est capable de redémarrer les trucs qui plantent ? C'est pas censé être le script de démarrage qui doit monitorer les process applicatifs (celà dit sur ce point je suis un peu mitigé, le respawn de l'inittab étant là pour ça).

Donc oui, ça réduit énormément les différences et les répetitions d'efforts pour implémenter les mêmes choses.

Ca je n'y crois pas. Chaque distribution aura intérêt à maintenir les différences pour pouvoir survivre. Et tant mieux d'ailleurs.

Ca m'intéresserait d'avoir des stats dessus …

Les BSD ne sont PAS sous Sys V : c'est un truc qui en est inspiré mais qui n'est pas complêtement identique.

Les dépendances entre services sont très bien gérées.

l'ensemble des scripts d'init ne sont pas homogènes, ne respectent pas les mêmes conventions d'une distribution à l'autre

On s'en fout tant que c'est homogène sur la même distrib : De toute façon, systemd n'empêchera pas les différences entre les distribs au niveau du démarrage. De ce côté ça n'apportera rien.

et parfois même au sein d'une même distribution.

C'est moche Linux : sous BSD, c'est homogène.

Un IsaExpress ? (avec au passage une correction des problèmes que pouvait rencontrer ce bus …).

… et ce qu'il faut faire pour en bénéficier (changement de box, etc …).

Ensuite je crois qu'il y a des limites (distances par exemple, ou qualité de la ligne) qui font que le VDSL t'apportera ou pas quelque chose.

Un article qui t'apportera peut-être quelques pistes.

Un boulier est encore plus du bonheur, c'est plus simple.

Non, mais démarrer un supercalculateur pour faire une petite addition ça sert à rien.

Ca fait moins de choses? Pas grave, ce n'est pas le sujet?

Ca fait juste ce qu'on lui demande de faire, ni plus ni moins.

C'est compliqué à déchiffrer ce fichier dès que tu veux changer un truc sans tout casser?

Ah, mettre =YES c'est compliqué et difficile à déchiffrer ? Change de métier.

Question : tu as essayé les xBSD ?

Apprendre à utiliser systemd ou journald est le genre de chose que tout administrateur système se doit d'apprendre par lui même s'il veut être à jour et efficace, ne serait-ce parce que cela peut servir et surtout être mieux que la situation actuelle…

Apprendre à utiliser un truc inutile, qui n'ajoute que des surcouches inutiles juste pour faire un start/stop de service ça ne sert à rien.

rc.conf et compagnie n'ont rien de simples, comme pour systemd et journald il faut beaucoup d'apprentissage et de cassage de dents pour y parvenir à quelque chose.
???? Tu l'as déjà utilisé ? Et quels problèmes as-tu rencontrés ?

EMC base certains de ses NAS sur du FreeBSD. Il y a une partie proprio, mais le freebsd est bien visible.

Si tu veux un tel système, il ne faut clairement pas se diriger vers FreeBSD. Mon avis personnel serait que tu essaies Archlinux (ouais, encore la même) ou tu as à priori la toute dernière version des logiciels.

Arrête, Arch Linux c'est bien pire que FreeBSD.

Le seul point que je trouve à peu près valable sur son billet, c'est le fait que FreeBSD supporte moins de matériel que GNU/Linux. Le second : les ports ne sont pas ç la dernière version, mais la plupart du temps ça ne nécessite pas de tout recompiler, juste l'outil dont on a besoin.

Le système de fichiers UFS qui en soit est vraiment mauvais (UFS supporte très mal les crashs système), était malmené, à force d’arrêter "brutalement" la machine pour sortir du freeze.

Alors ça ça me fait rire. ca fait des années qu'il y a un système de fichier journalisé sous FreeBSD.

Je ne trouvais pas à l'époque (de souvenir) Vlc, pas de Inkscape, Openoffice en paquet etc.

En fait tu devrais arrêter l'informatique. Ca fait au moins 10 ans que VLC et/ou OpenOffice existent sous FreeBSD en précompilé.

Tu as mis en place un système RAID et celui-ci a montré son utilité puisque tu disposes encore de tes données malgré une panne d'un disque dur.

BIIIIP !!!! Ce n'est pas le but d'un RAID, ça c'est le but d'une sauvegarde.

Un raid1 sert à assurer la disponibilité (pas de coupure de service), pas la sauvegarde.

Pour le reste, pas de problème.

Il existe une section astuce sur le forum ou ce journal aurait sa place.

Ca peut marcher.

Par contre j'utiliserais method_missing à la place du bloc ci-dessous :

def exists?(msg)
# vérifie si une méthode on<EVENT> existe
# et l'exécute.
meth = "on" + msg.command
send(meth, msg) if respond_to?(meth)
end


dans l'objet Plugin, tu définis la méthode method_missing qui intercepte tous les appels à on_ et qui ne fait rien si l'event est défini.
Par contre s'il s'agit d'un appel à une autre méthode => appel à la méthode method_missing du parent.

Sinon, le fait qu'il n'y ait pas trop de différence entre ce que tu as fait au début et ce que j'ai proposé vient du fait que je n'avais pas compris le besoin initial.

Désolé mais je vais encore te faire perdre ton temps,
je comprends pas :p

Je te rassure, je ne perds pas mon temps, ça m'amuse ce genre de problème. En plus ça permet d'apprendre et de se dérouiller quand on fait plus de ruby depuis un moment (je suis sur Erlan en ce moment). C'était une boutade lorsque je te disais "méchant" :)

Voilà ce que j'ai pu faire ce soir :

#main.rb
module BOT

    class Bot

        @@modules=[]

        def initialize(plugin_path)

            Dir.foreach(plugin_path) do |d| 

                if ((d != ".") and (d != "..")) then
                    #puts "#{d}" 
                    require "#{plugin_path}/#{d}"
                    eval(%Q{@@modules << #{d.capitalize().sub(/.rb$/,"")}})
                end 
            end
        end

        def run
            # parsing
            # msg.command == "JOIN"
            # exécuter les méthodes "onJOIN" des plugins.
            onJoin()
        end

        def onJoin(*args)

            @@modules.each do |m|
                #puts("Module : #{m}")
                s=%Q{#{m}::onJoin(*args)}
                #puts(s)
                eval(s) 
            end
        end
    end

end

b=BOT::Bot.new("./plugins")
b.run()

#plugin3.rb

module Plugin3

    def self.onJoin(*args)
        puts("Module Plugin3, event  onJoin detected,  arguments : #{args}")
    end

end

# plugin4.rb

module Plugin4

    def self.onJoin(*args)
        puts("Module Plugin4, event  onJoin detected,  arguments : #{args}")
    end

end

Explications : tu mets le main dans un repertoire, et tu positionne les plugins dans un sous-répertoire plugins (ou celui que tu veux).

Lorsque tu crées ton objet bot, tu lui passe le repertoire contenant les plugins. Il va aller alimenter le tableau @@modules=[] qui contiendra la liste de tous les plugins présents.

Ensuite lorsque tu appeleras la méthode onJoin, elle ira appeler la méthode onJoin de chaque module référencé dans le tableau.

On pourrait tester la pésence de la fonction onJoin pour chaque module (voir http://ruby-doc.org/core-1.9.3/Module.html#method-i-included_modules pour ruby 1.9.3)

J'ai d'autres idées mais il est un peu tard ce soir, donc on verra plus tard si tu as besoin d'autres choses.