Une redevance qui s'applique au nombre de CD vierge achetés j'appelle ça une taxe. Une redevance c'est payé une fois pour toute comme la télé.
Sauf qu'une taxe va dans la poche de l'Etat, la redevance va dans celle de certains ayant droits.
Ce qui fait que lorsque du grave tes photos personnelles ou un CD Linux tu donnes de l'argent à Universal.
Apparement certains estiment que le but de cette loi n'est pas d'interdire les logiciels libres mais "seulement" interdire les logiciels non équipés de mesures techniques comme tu l'as indiqué ici :
http://eucd.info/index.php?2005/11/14/175-exclusif-amendement-vivendi-universal-sacem-bsa-interdisant-les-logiciels-non-equipes-de-mesures-techniques
Il parait que la phrase "Pressions sur le gouvernement pour faire interdire le Logiciel Libre" fait gamin de 14 ans rebelle...
Tout le monde a bien compris que cela sera une conséquence de cet amendement débile, autant que l'EUCD interdit la copie privé de fait en interdisant les détournements de mesure de protection.
Alors effet de manche ou le but est-il vraiment d'interdire le LL ?
Pour ma part je pense que quelque soit la réponse le danger est réel et qu'il y a lieu de se mobiliser tous.
Je ne sais pas ce qui s'est passé mais j'ai bien la 2ème vidéo de l'après midi qui démarre à partir de Antoine Gallavardin - Le syndrome du Pingouin jusqu'aux lightning talks.
Le OGM fait 747Mo, je peux faire un bittorrent ou l'uploader sur le serveur de l'Aldil...
Je peux en parler puisque je fais du RG2 (GtkRuby) et c'est plutôt vrai pour les binding sur autre chose que Linux.
Mais quand on a fait du GTK+ en C et qu'on en fait en Ruby on se rend compte de l'énorme simplicité et donc rapidité de développement qu'apporte un langage script.
Si le but est de faire du multiplateforme alors effectivement le binding complique les choses surtout si celui-ci est plus ou moins mal porté. Dans ce cas autant coder directement en GTK+ ou QT.
Cependant, l'on parle de desktop ici où la portabilité n'est pas le but premier, même si des projets (stupides à mes yeux) de porter KDE ou GNOME sur Windows existent.
En programmation desktop, l'intérêt d'utiliser un binding est énorme. Quel développeur linux utilisant pyQT ou RG2 voudrait faire du C ou du C++ pour son IHM ?
Quant à faire des applications multiplateformes, à mon avis c'est vouloir sacrifier pas mal de possibilités du desktop sur l'autel de la portabilité ... et c'est une grosse erreur. Il suffit de voir l'énorme catalogue d'applis GTK+ multiplateforme exploitant mal GNOME au contraire des appli KDE, d'ailleurs on ne dit pratiquement pas appli QT puisqu'il n'en existe que très peu pour le bonheur de KDE...
Il faut juste savoir écrire du C quand cà vaut le coup (décompression ogg/FLAC pour suivre mon exemple du lecteur de musique).
Et encore c'est rarement nécessaire car bien souvent il existe déjà des modules python/ruby/perl la plupart en C pour ce genre de choses standards (pyogg, libvorbisfile-ruby, ...).
Cet engouement pour les langages interprétés est-il :
- Une critique du modèle monolithique de Gnome ou de KDE "tout en C" ou "tout en C++" ?
Non, car il n'y aurait aucun intérêt à ce que GNOME et KDE soient codés en langage script, et la première raison est la réactivité du desktop.
Je pense que c'est une grosse erreur de mettre face à face desktop et applications. Le desktop se doit d'être réactif donc codé avec des langages compilés bas niveaux, mais proposant un certain nombre de binding.
L'intérêt des binding est de permettre aux développeurs de coder une application desktop très rapidement en utilisant un langage de plus haut niveau, comme les langages scripts.
Ensuite tout dépend de l'application, et certaines sont codées en C ou C++. Mais pour la plupart un langage script suffit largement, avec au pire une extension C ou C++ ajoutée au langage script (swig aide bien pour cela) pour un fonctionnalité particulière.
Certe, un desktop est composé d'applications, et l'on peut se dire que si celles-ci finissent par être toutes codées en script, cela reviendra à avoir un desktop lent.
Cependant pour moi la base du desktop c'est tout d'abord les biblitohèques de base, GTK+, Glib, Gstreamer, QT, etc, et les lib GNOME et KDE. Ensuite tous les démons associés au desktop (gconf, session, etc...). Tout cela se doit de rester en C ou C++ pour des raisons de perf.
Ensuite un Evolution codé en python ? Pourquoi pas, même s'ils utiliseront surement plus GTK# et mono.
Donc non il n'y a pas de lutte entre les langages de niveaux différents, le C et le C++ trouveront leur place dans les bibliothèques, binding et les services desktop.
Quant à définir un langage script dédié à un desktop je ne suis pas convaincu. Un développeur attaché à perl, python, ruby ... ne changera pas comme ça. Et je n'en vois pas l'intérêt tant qu'il existe un bon binding supportant toute l'API du desktop.
Enfin, on peut espérer que le temps fera son affaire de la diversité des interpreteurs et fera emerger un standard "de fait". http://freedesktop.org
Pour me répéter je ne vois pas l'intérêt d'avoir un standard au niveau langage, il faut laisser le choix aux développeurs, autant que l'on laisse le choix aux utilisateurs pour leur desktop. Il faut avoir un standard au niveau desktop et c'est le but de freedektop.
Si les desktop finissent par utiliser les mêmes bibliothèques, comme Gstreamer par exemple, peu importe ensuite le langage utilisé.
Au contraire je reste persuadé que si l'on veut attirer les développeurs VB, Windev, Delphi, etc, leur laisser le choix d'un langage haut niveau est important.
Certe le prix à payer est la multicité des interpréteurs, mais ceux-ci se dirigent vers des VM. Et l'évolution du matériel compense pas mal.
Encore un petit effort : Ruby : j'aimerais avoir des avis sur Ruby; On en entend parler avec Ruby on Rail pour les applis web, mais pour faire des "vraies" applis ?
Ah oui c'est vrai que c'est interprété donc HS, mais finalement, je me demande si les languages compilés ne vont pas céder le pas aux languages interprétés...
C'est certain dans le domaine des IHM graphiques sous forme interprété ou en bytecode.
Mais ça m'étonnerait pour ce qui est des bibliothèques bas niveau, comme GTK+ ou QT.
Même si KDE et GNOME ne sont pas interprétés, c'est quoi l'intérêt de développer des applications KDE et GNOME en C ou C++ de nos jours ?
Certe je verrais mal un Gimp en python mais la plupart des applications desktop pourraient être sans problème codé avec un langage script ... Il n'y en a finalement que peu qui ont besoin de la forte réactivité d'un langage compilé bas niveau.
Sinon webdav coté serveur marche très bien avec l'extension calendar, il suffit soit de s'installer un serveur, soit d'utiliser un service gratuit comme : http://www.icalx.com/
A savoir que evolution n'est toujours pas foutu d'accéder à un compte webdav via login/pass ... Plutôt utile si l'on veut pas que n'importe qui accède en écriture à son calendrier ...
Concernant le carnet, tbird peut accéder à un carnet d'adresse via ldap. Le problème c'est de trouver un fournisseur de service, or il semble que c'est plutot complexe à mettre en oeuvre (gestion des droits d'accès ...).
C'est aussi parce qu'ils ont compris Internet et le respecte (innovation, sobriété, utilisation poussé des standards et des logiciels libres, ...) , et celui-ci le leur rend bien ...
Pas comme une certaine entreprise aux comportements douteux, employant des méthodes pitoyables pour imposer et conserver son monopole.
Le "monopole" de Google n'est dû qu'à son succès, chapeau.
Je veux bien que PHP soit en majorité utilisé sur des serveurs Linux, mais de la à généraliser à "virus anti-linux" ya des limites ...
Il exploite pas une faille du kernel !
# Rails + AJAX
Posté par fredix . En réponse au message Conseils pour le choix d'un language ?. Évalué à 3.
[^] # Re: attaquer
Posté par fredix . En réponse au journal "'auteur de NVU tire à boulet rouge sur les auteurs de l'ammendement VU. Évalué à 10.
Sauf qu'une taxe va dans la poche de l'Etat, la redevance va dans celle de certains ayant droits.
Ce qui fait que lorsque du grave tes photos personnelles ou un CD Linux tu donnes de l'argent à Universal.
[^] # Re: peercast
Posté par fredix . En réponse au journal La Lamabox : lecteur/enregistreur de salon sous Linux à partir de réseaux P2P !!. Évalué à 3.
Pour le reste je suis complètement d'accord avec toi.
[^] # Re: Extensions/themes et versions...
Posté par fredix . En réponse au journal Firefox 1.5 out!. Évalué à 1.
[^] # Re: Extensions/themes et versions...
Posté par fredix . En réponse au journal Firefox 1.5 out!. Évalué à 1.
[^] # Re: Borg résistant ?
Posté par fredix . En réponse au journal Grand moment pour Gnome. Évalué à 2.
[^] # Re: Pour que les choses soient claires
Posté par fredix . En réponse au journal La liberté de vous l'enlever. Évalué à 6.
http://eucd.info/index.php?2005/11/14/175-exclusif-amendement-vivendi-universal-sacem-bsa-interdisant-les-logiciels-non-equipes-de-mesures-techniques
Il parait que la phrase "Pressions sur le gouvernement pour faire interdire le Logiciel Libre" fait gamin de 14 ans rebelle...
Tout le monde a bien compris que cela sera une conséquence de cet amendement débile, autant que l'EUCD interdit la copie privé de fait en interdisant les détournements de mesure de protection.
Alors effet de manche ou le but est-il vraiment d'interdire le LL ?
Pour ma part je pense que quelque soit la réponse le danger est réel et qu'il y a lieu de se mobiliser tous.
Bravo pour ton travail.
[^] # Re: petit calcul
Posté par fredix . En réponse au journal 174 Mbits/s en download et 18Mbits/s en émission : le futur de FREE. Évalué à 10.
[^] # Re: Présentations Libres
Posté par fredix . En réponse à la dépêche Vidéos des JDLL 2005 et 2004 à Lyon. Évalué à 2.
Le OGM fait 747Mo, je peux faire un bittorrent ou l'uploader sur le serveur de l'Aldil...
Pas d'inquiètude à avoir en tout cas on a tout.
[^] # Re: Le problème avec les bindings...
Posté par fredix . En réponse au journal Langages pour desktop. Évalué à 2.
Mais quand on a fait du GTK+ en C et qu'on en fait en Ruby on se rend compte de l'énorme simplicité et donc rapidité de développement qu'apporte un langage script.
Si le but est de faire du multiplateforme alors effectivement le binding complique les choses surtout si celui-ci est plus ou moins mal porté. Dans ce cas autant coder directement en GTK+ ou QT.
Cependant, l'on parle de desktop ici où la portabilité n'est pas le but premier, même si des projets (stupides à mes yeux) de porter KDE ou GNOME sur Windows existent.
En programmation desktop, l'intérêt d'utiliser un binding est énorme. Quel développeur linux utilisant pyQT ou RG2 voudrait faire du C ou du C++ pour son IHM ?
Quant à faire des applications multiplateformes, à mon avis c'est vouloir sacrifier pas mal de possibilités du desktop sur l'autel de la portabilité ... et c'est une grosse erreur. Il suffit de voir l'énorme catalogue d'applis GTK+ multiplateforme exploitant mal GNOME au contraire des appli KDE, d'ailleurs on ne dit pratiquement pas appli QT puisqu'il n'en existe que très peu pour le bonheur de KDE...
[^] # Re: L'engouement pour les languages interprétés
Posté par fredix . En réponse au journal Langages pour desktop. Évalué à 2.
Et encore c'est rarement nécessaire car bien souvent il existe déjà des modules python/ruby/perl la plupart en C pour ce genre de choses standards (pyogg, libvorbisfile-ruby, ...).
# avis
Posté par fredix . En réponse au journal Langages pour desktop. Évalué à 8.
- Une critique du modèle monolithique de Gnome ou de KDE "tout en C" ou "tout en C++" ?
Non, car il n'y aurait aucun intérêt à ce que GNOME et KDE soient codés en langage script, et la première raison est la réactivité du desktop.
Je pense que c'est une grosse erreur de mettre face à face desktop et applications. Le desktop se doit d'être réactif donc codé avec des langages compilés bas niveaux, mais proposant un certain nombre de binding.
L'intérêt des binding est de permettre aux développeurs de coder une application desktop très rapidement en utilisant un langage de plus haut niveau, comme les langages scripts.
Ensuite tout dépend de l'application, et certaines sont codées en C ou C++. Mais pour la plupart un langage script suffit largement, avec au pire une extension C ou C++ ajoutée au langage script (swig aide bien pour cela) pour un fonctionnalité particulière.
Certe, un desktop est composé d'applications, et l'on peut se dire que si celles-ci finissent par être toutes codées en script, cela reviendra à avoir un desktop lent.
Cependant pour moi la base du desktop c'est tout d'abord les biblitohèques de base, GTK+, Glib, Gstreamer, QT, etc, et les lib GNOME et KDE. Ensuite tous les démons associés au desktop (gconf, session, etc...). Tout cela se doit de rester en C ou C++ pour des raisons de perf.
Ensuite un Evolution codé en python ? Pourquoi pas, même s'ils utiliseront surement plus GTK# et mono.
Donc non il n'y a pas de lutte entre les langages de niveaux différents, le C et le C++ trouveront leur place dans les bibliothèques, binding et les services desktop.
Quant à définir un langage script dédié à un desktop je ne suis pas convaincu. Un développeur attaché à perl, python, ruby ... ne changera pas comme ça. Et je n'en vois pas l'intérêt tant qu'il existe un bon binding supportant toute l'API du desktop.
Enfin, on peut espérer que le temps fera son affaire de la diversité des interpreteurs et fera emerger un standard "de fait".
http://freedesktop.org
Pour me répéter je ne vois pas l'intérêt d'avoir un standard au niveau langage, il faut laisser le choix aux développeurs, autant que l'on laisse le choix aux utilisateurs pour leur desktop. Il faut avoir un standard au niveau desktop et c'est le but de freedektop.
Si les desktop finissent par utiliser les mêmes bibliothèques, comme Gstreamer par exemple, peu importe ensuite le langage utilisé.
Au contraire je reste persuadé que si l'on veut attirer les développeurs VB, Windev, Delphi, etc, leur laisser le choix d'un langage haut niveau est important.
Certe le prix à payer est la multicité des interpréteurs, mais ceux-ci se dirigent vers des VM. Et l'évolution du matériel compense pas mal.
[^] # Re: Ruby ?
Posté par fredix . En réponse au journal Quel langage, pour cette utilisation ?. Évalué à 3.
http://ruby-gnome2.sourceforge.jp/
Ah oui c'est vrai que c'est interprété donc HS, mais finalement, je me demande si les languages compilés ne vont pas céder le pas aux languages interprétés...
C'est certain dans le domaine des IHM graphiques sous forme interprété ou en bytecode.
Mais ça m'étonnerait pour ce qui est des bibliothèques bas niveau, comme GTK+ ou QT.
[^] # Re: python
Posté par fredix . En réponse au journal Quel langage, pour cette utilisation ?. Évalué à 10.
Tu confonds avec Ruby
[^] # Re: Ruby ?
Posté par fredix . En réponse au journal Quel langage, pour cette utilisation ?. Évalué à 4.
Certe je verrais mal un Gimp en python mais la plupart des applications desktop pourraient être sans problème codé avec un langage script ... Il n'y en a finalement que peu qui ont besoin de la forte réactivité d'un langage compilé bas niveau.
[^] # Re: Pas possible
Posté par fredix . En réponse au journal Téléphones portables et Linux. Évalué à 3.
[^] # Re: blaster
Posté par fredix . En réponse au journal Windows 2000 avec Zone Alarme est un system attaquable.. Évalué à 3.
http://www.tatanka.com.br/ies4linux/
[^] # Re: et les éditeurs d'antivirus qui laggent
Posté par fredix . En réponse à la dépêche Du code de VLC dans le rootkit de Sony. Évalué à 8.
[^] # Re: serveur ?
Posté par fredix . En réponse au message Question openwengo / skype. Évalué à 2.
http://www.skype.com/products/explained.html
[^] # Re: plaxo
Posté par fredix . En réponse au journal Synchronisation Bookmarks, Calendar et Address Book pour Firefox et Thunderbird. Évalué à 3.
Pour le bookmark perso je trouve plus intéressant d'utiliser delicious.
# plaxo
Posté par fredix . En réponse au journal Synchronisation Bookmarks, Calendar et Address Book pour Firefox et Thunderbird. Évalué à 3.
http://www.plaxo.com/downloads/tbird
Sinon webdav coté serveur marche très bien avec l'extension calendar, il suffit soit de s'installer un serveur, soit d'utiliser un service gratuit comme :
http://www.icalx.com/
A savoir que evolution n'est toujours pas foutu d'accéder à un compte webdav via login/pass ... Plutôt utile si l'on veut pas que n'importe qui accède en écriture à son calendrier ...
Concernant le carnet, tbird peut accéder à un carnet d'adresse via ldap. Le problème c'est de trouver un fournisseur de service, or il semble que c'est plutot complexe à mettre en oeuvre (gestion des droits d'accès ...).
[^] # Re: c'est pareil
Posté par fredix . En réponse au journal 30 SMS gratuits ... grace à un soft GPL. Évalué à 2.
D'après sa réponse à la question précédente ca va venir.
wait & see ...
[^] # c'est pareil
Posté par fredix . En réponse au journal 30 SMS gratuits ... grace à un soft GPL. Évalué à 2.
[^] # Re: Ce que j'aime dans Google...
Posté par fredix . En réponse au journal Google, the internet trust must go on.... Évalué à 7.
Pas comme une certaine entreprise aux comportements douteux, employant des méthodes pitoyables pour imposer et conserver son monopole.
Le "monopole" de Google n'est dû qu'à son succès, chapeau.
# PHP
Posté par fredix . En réponse au journal Virus!. Évalué à 9.
http://phpxmlrpc.sourceforge.net/
Je veux bien que PHP soit en majorité utilisé sur des serveurs Linux, mais de la à généraliser à "virus anti-linux" ya des limites ...
Il exploite pas une faille du kernel !