enclair a écrit 32 commentaires

Tu conseilles quelle IHM parce que je suis complètement perdu sous git.

On peut installer plusieurs versions d'un logiciel en parallèle, ou revenir en arrière, cool.
Comment ça se passe pour les fichiers de configuration qui sont dans $HOME, comme ~/.mozilla ?
Sont-ils aussi versionnés ? Comment les conflits sont-ils gérés ? (par exemple pour kmail la configuration est compatible lorsqu'on met à jour, mais pas forcément lorqu'on revient en arrière).

Oui j'ai réussi ! J'ai utilisé Thunderbird avec imap, et j'ai juste configuré mes emails en mode texte.

Comment sais-tu qu'il s'agit de Greg Kroah-Hartman ?
Le seul email en rapport que je vois dans les archives de la liste kernel newbie vient de "Little Penguin"
http://lists.kernelnewbies.org/pipermail/kernelnewbies/2014-February/009837.html

Apparemment c'est aptitude:

aptitude is the recommended package manager for Debian GNU/Linux systems.
http://www.debian.org/doc/manuals/debian-faq/ch-uptodate.en.html

Par contre pour les mises à jour entre releases, ça dépend.

Un inconnu du nom de Eric S. Raymond, sans doute un trolleur, a écrit un message sur la liste de diffusion de GCC en se demandant s'il ne faudrait pouvoir autoriser les plugins propriétaires dans GCC (D'après : http://gcc.gnu.org/onlinedocs/gccint/Plugin-API.html#Plugin-API seuls les plugins sous licences compatible GPL sont autorisés).
Selon lui, les logiciels de la FSF sont ses meilleurs outils pour promouvoir les logiciels libres, et GCC en fait évidemment partie. Or, clang serait une menace pour la domination de GCC dans 3 ou 5 ans.

La discussion ici http://gcc.gnu.org/ml/gcc/2014-01/msg00176.html

Dans ce cadre, quel sens cela aurait de donner du pouvoir à des gens qui voudraient garder pour eux une partie de ce contrôle ?

Avoir plus de contributions.
A cause des clones sous BSD, je pense qu'il y aura moins de contributions vers les projets GPL.
Si le combat de RMS est tel que tu le décris, je pense qu'une licence plus permissive que la GPL serait plus efficace.

Uniquement au premier utilisateur en cas de travaux dérivés, pas nécessairement les suivants.

C'est précisément, pour moi, le but de la GPL : assurer la liberté des utilisateurs même dans le cas de travaux dérivés.
Or, si quelqu'un écrit un clone d'un programme GPL sous licence BSD, l'effort est caduc. Quelqu'un qui veut dériver en proprio grep ou readline va maintenant pouvoir utiliser leurs équivalents BSD.
Alors que si ces programmes avaient été sous une licence plus raisonnable comme la MPL ou la LGPL, je pense que :
- personne n'aurait pris la peine d'écrire un clone sous BSD
- quelqu'un souhaitant faire un logiciel proprio, ne se sentant pas obliger de tout libérer, est plus à même de l'utiliser et d'éventuellement contribuer sur les parties libres

Écrire un programme sous GPL, c'est avant tout assurer les 4 libertés de celle-ci à ses utilisateurs.

La licence BSD, en tant que licence libre, assure aussi les 4 libertés.

Ok je comprends, ça permet de savoir que c'est la première utilisation.

Je comprends pas l'intérêt de :
let mut x = 1.0; // sans indication, le type déduit est f64
x = 1f32; // le compilateur devine que x est en fait un f32

Pourquoi ne pas faire let mut x = 1f32 dès le début ?

Ca serait plus simple surtout de virer le let. A quoi sert-il ?
x = 1;
mut x = 1;

C'est cool c'est un bon système.
C'est dommage que FreeBSD n'utilise pas pkgsrc, le système de port de NetBSD.
Ca ferait moins de boulot et permettrait de se concentrer sur l'essentiel : le système de base.
En plus il y a pkgin. Il y a pkgng côté FreeBSD mais c'est plus récent.
pkgsrc est utilisé par Minix et DragonflyBSD alors ça devrait pas être difficile d'en faire le défaut sur FreeBSD aussi.

Malheureusement, la personnalité abrasive d'Ulrich et ses décisions abruptes ont provoqué une certaine exaspération parmi les contributeurs.

S'il y avait un comité, il n'était pas le seul à prendre des décisions donc qu'est-ce que ça va changer ?

the direct responsibilities of GNU Project maintainership for the C Library will be taken on by a smaller team

Quelle est la différence entre le comité de direction qu'il y avait avant et cette petite équipe ?

Une tumeur ?

Il voulait dire que c'était un poisson d'avril, une fausse découverte.

J'ai pris un mauvais exemple.
Ca permet d'avoir un ensemble cohérent de logiciels.
Par exemple, si une distribution a Gimp 2.6 et gtk 2.21, et qu'elle veut proposer Gimp 2.8 qui ne compile qu'avec gtk >= 2.24 (j'en sais rien si c'est le cas, c'est un exemple), il y aura quelque chose comme ça :

/opt/rh/gimp28/root/usr/bin/gimp (binaire de Gimp 2.8)
/opt/rh/gimp28/root/usr/lib/libgtk-2.0.so (bibliothèque de Gtk 2.24)

C'est une sorte de "bundle" j'ai l'impression.

Ah oui j'ai oublié de préciser le plus "marrant" (polémique avec le FHS etc..., lire la mailing list ça commence là : http://lists.fedoraproject.org/pipermail/devel/2012-February/162240.html ) :

Ces collections sont installés dans /opt (/opt/rh/nom_de_la_collection), exemple /opt/rh/perl514.

Ben oui le FHS prévoit un /opt/provider, je pensais qu'il prévoyait seulement des /opt/package. C'est plutôt bien pensé.

Je me demande si Debian ne mettrait pas plutôt tout ça dans un /usr/lib/dsc ?

J'ai lu ce guide qui explique comment faire sur Fedora 15, mais d'après l'auteur ce n'est pas conseillé.

Plusieurs partitions pour le home, et par exemple une autre partition commune pour les données ?
C'est ce que j'avais fait, mais j'ai des problèmes avec GNOME. Si je veux supprimer un fichier de la partition commune via Nautilus, il ne passe pas par la corbeille (mais c'est peut-être parce que mes homes sont aussi dans la partition commune, montés avec l'option --bind).

Je voudrais garder les données entre chaque distribution et pouvoir faire ça :

J'installe et j'utilise Fedora 16.
Quand Fedora 18 sort, je l'installe dans une partition à part, et je remplace mon nouveau répertoire utilisateur par l'ancien.
De cette façon, je peux revenir à ma Fedora 16 en cas de soucis.
Mais je ne sais pas si le fait d'avoir des noms d'utilisateurs différents est problématique.

Je reformule ma question :

Si quelqu'un récupère un fichier sous licence BSD, le modifie, ajoute une licence propriétaire (a t-il le droit ?), et le donne à une autre personne, le fichier résultant est-il libre ou propriétaire ?
(je rappelle que ce n'est pas parce qu'on a le code source d'un programme que celui-ci est libre)

Est-ce que les packages binaires sont mis à jours pour la branche -stable ?

Savez-vous où en est le projet "Desktop" ( cf http://mail-index.netbsd.org/current-users/2009/02/07/msg007(...) ) ?
Il y avait une page sur l'ancien wiki, mais celui-ci est mort.

Merci, j'ai utilisé la première solution + find (puisque mon répertoire où je place mes fichiers objets suit la structure des sources).

Je regarderai le papier ci-dessous plus tard.

Bon j'ai modifié la page : « Chaque fichier modifié doit clairement mentionner le fait qu'il a été modifié. »
N'hésitez pas à la rectifier si c'est faux.