Ça devient lassant de répéter la même chose sans que tu lises ce qu'on écrit. C'est mon dernier essai (surtout que pas mal d'autres ont déjà dit la même chose).
> Moi je suis allez le downloadé car j'y ai accès. C'est tout.
> J'ai une licence GPL pour utiliser Linux ?
> Oui ou non ?
Oui
> Il me faut obligatoirement la label "employeur" pour bénéfier de la GPL ?
Non
> > Seule l'entreprise qui a la licence GPL sur ce code peut distribuer ce code si elle le désire.
> Tu expliques ?
Elle l'a reçu (par accord, achat, téléchargement ou tout autre méthode qui te vient à l'esprit) de quelqu'un (entité physique ou morale) qui avait possédait ce logiciel avec cette licence (GPL) et donc avait le droit de donner/vendre ce logiciel sous cette licence.
N'importe quel utilisateur (employé ou pas) recevant ce logiciel sous licence GPL de quelqu'un en possédant déjà une licence GPL peut le redistribuer. MAIS il faut qu'il recoive cette licence.
Ici, ce n'est pas parce que l'entreprise a obtenu une licence (GPL) de son fournisseur que l'employé aussi. De même, ce n'est pas parce que le code ajouté est aussi sous licence GPL que l'employé a reçu une licence (GPL) pour utiliser (et redistribuer) ce code.
Ce que je veux dire, et que tu ne sembles pas comprendre, c'est qu'utiliser un logiciel (GPL ou non) de la part d'un employé ni signifie pas que cet employé possède une licence de ce logiciel, seulement que son entreprise en a une. Et sans licence, l'employé ne peut pas décider de diffuser ce logiciel (de quel droit le ferait-il ?). Ceci reste vrai quelque soit ce qu'il y a dans la licence accordée à l'entreprise.
Sinon, c'est que tu considères que l'employé a acquis une licence GPL sur le logiciel (qui lui donne le droit de le redistribuer). D'où provient alors cette licence ?
Si tu considères qu'elle provient du fait que son employeur lui a fournit ce logiciel, alors je comprends ta position, mais je ne la partage pas (ça me semble évident en considérant d'autres licences qui interdisent justement de sous licencier : un employé peut quand même utiliser les logiciels de sa boîte sans en avoir une licence personnellement).
Si tu considères qu'elle vient de l'utilisation du logiciel lui-même, c'est faux. Juridiquement, une licence est nécessairement cédée/vendue/donnée... par quelqu'un qui a le droit de le faire.
Si tu considères qu'elle vient d'ailleurs, dit moi d'où.
> - "je n'ai pas le droit de downloader (donc copier) Linux car je n'utilise pas Linux et donc la GPL ne s'applique pas."
>
> Reconnais que c'est ridicule.
Oui, ton arguement est ridicule. Linus (et les autres contributeurs) ont mis leur code en GPL ET ils le diffusent sur leur site (www.kernel.org ?). Ils sont les auteurs, ils peuvent diffuser comme bon leur semble.
Les propriétaires des serveurs FTP l'ont mis sur leur site parce qu'ils ont récupéré les sources avec une licence GPL donnée par les auteurs (ou un autre intermédiaire comme eux) leur permettant de les redistribuer (avec la même licence).
Par contre, les modifications, sous licence GPL, du noyau faites par une entreprise X, personne n'aura le droit de les diffuser tant que X ne les aura pas diffusées lui-même. Un pirate qui volerait les sources sur le réseau de l'entreprise ne possèderait pas pour autant la licence GPL les accompagnant. Une licence (GPL ou pas) est un contrat entre deux personnes (au moins). Voler, espionner, ... ne te permet pas de t'approprier ce contrat et de te servir de lui pour justifier d'autres actions (diffuser le code volé/intercepté).
Tu ne peux acquérir une licence d'utilisation d'un logiciel GPL qu'auprès d'une personne possédant une telle licence et acceptant de t'en vendre/donner une (par exemple auprès d'un mainteneur de site ftp en téléchargeant le logiciel proposé). Une fois que tu l'auras, tu pourras la céder comme bon te semble, mais il faut l'avoir avant. Et si une entreprise l'a, un employé ne l'a pas nécessairement même s'il utilise le logiciel.
> Oui. Mais toute personne qui a accès au programme a le droit de le copier/diffuser. Cette personne, peut être un employer.
D'abord, non. Ce n'est pas parce qu'on a accès à quelque chose qu'on peut le copier/diffuser. C'est, dans le cas qui nous occupe, parce qu'on a reçu (et accepté) une licence (GPL) qui nous authorise à le faire. Si on refuse la licence ou si cette licence ne nous est pas proposée, on ne peut pas copier/diffuser.
Dans ce cas présent, comme dis en détail dans d'autres contributions, c'est l'entreprise qui a la licence GPL sur le programme (modifié ou non). Évidemment, si le programme non modifié est distribué librement, alors il est facile à n'importe qui d'acquérir une licence GPL (avec tous les droits et devoirs que cela comporte).
Mais, lorsque le programme (ou ses modifications faites dans l'entreprise) ne sont pas distribuées, alors un employé ne peut pas distribuer ce code. Tout simplement parce qu'il n'a pas la licence qui lui permet de le faire. Seule l'entreprise qui a la licence GPL sur ce code peut distribuer ce code si elle le désire.
Maintenant, un juriste pourrait peut-être argumenter que l'entreprise a effectivement distribué le logiciel à ses employés, les rendant libre (par la GPL) de le rediffuser. Mais ça ne me semble pas vraiment tenable. Comme dit dans d'autres posts, une entreprise n'a pas à (voire même ne peut pas) re/sous licencier les logiciels pour lesquels elle a aquis une licence (fut-elle GPL ou propriétaire).
Mais je suppute que ce qui pose problème, ce sont les modifications que l'employé y apporte. SI il les distribue, alors ça sera nécessairement sous licence GPL. Mais encore faut-il qu'il en ait le droit. Pour cela, ses modifications doivent être sous une licence :
1) compatible avec la GPL (à cause du programme de base sous GPL)
2) compatible avec les règlements de son employeur (c'est du travail, pas du développement personnel)
Remarque en passant : si les deux sont incompatibles, alors le logiciel modifié n'est pas distribuable. Ce n'est pas spécifique aux logiciels propriétaires : c'est aussi le cas de logiciels composées de briques "libres", mais avec des licences incompatibles entre elles (exemple : Qt et GPL pendant un certain temps il me semble (à vérifier)).
Je pense que, lié par un contrat de travail, le code appartient à l'employeur. Ce dernier n'en est pas l'auteur, mais c'est lui qui choisit la licence à utiliser. Et tant qu'il ne le distribue pas, il n'est pas tenu de fournir les sources à qui que ce soit.
Reste pour les jusristes à définir si "utiliser du code appartenant à une entreprise au sein de cette entreprise" constitue une forme de distribution et permet (sous réserve que le code soit sous licence compatible GPL) aux employés de réclamer les sources pour les rediffuser eux-mêmes. Et là, ça me paraît beaucoup plus délicat à argumenter (et largement au delà de mes compérences)
A propos des licenses, je fais une thèse dans une équipe INRIA. Voici quelques observations que j'ai pu faire :
Les chercheurs autour de moi ne faisaient pas très attention aux licenses. Ça change pas mal ces dernières années, mais il faut bien comprendre que c'est quelque chose de récent. Je parle bien sûr des 'petits' codes. 'petits' n'est pas au sens de 'peu de ligne de code', mais 'développé pendant peu de temps' (une thèse, une tâche, ...)
Généralement, les chercheurs sont très contents si des personnes désirent utiliser leur code : ça fait tout plein de retour d'expérience, ce qui est souvent très profitable.
Par contre, il faut aussi comprendre que le travail de diffusion (packaging, documentation complète, publicité, ...) n'est pas très valorisable auprès de nos instances (sauf si le projet/code a déjà acquis une certaine notoriété). C'est pourquoi il faut généralement directement s'adresser aux équipes/développeurs pour avoir une doc un peu plus récente/à jour, ... Et tous les chercheurs ne sont pas prêts à s'investir sur leur temps libre pour faire ce travail de diffusion s'ils n'ont pas la certitude que ça intéressera un certain nombre de personnes. Énormément de code développé est abandonné au bout de quelque temps : des concepts sont validés et subsistent (dans d'autres projets/codes), mais le code de base est souvent archivé et laissé tel quel.
Autre remarque : l'INRIA est structurée en équipes (approximativement 5 à 20 personnes en moyenne) relativement indépendantes. Cela explique les nombreuses disparités dans les politiques de diffusion de code. L'INRIA (centrale) demande de faire remonter les logiciels diffusés (ceux de la page citée plus haut), mais toutes les équipes ne le font pas nécessairement : elles estiment parfois que leur code n'est pas prêt pour une diffusion (pas assez de doc, trop compliquer à compiler/installer sans aide, ...). Les choix de licences, supports, ... sont entièrement fixés par les équipes, pas par un 'bureau central'.
Pour le budget, ne pas perdre de vue que l'INRIA crée actuellement trois pôles supplémentaires (Lille,Saclay, Bordeaux) en plus des cinq autres déjà existants. Cela nécessite des moyens importants (nouveaux locaux et personnel (chercheur et administratif))
Si l'info vient bien d'une ligne de 'top', alors
1) il s'agit de 2h45 (et pas de 2 min 45)
2) il s'agit du temps CPU consommé (et pas de la durée de vie de l'appli)
Ça me semble parfaitement normal qu'une application interactive consomme peu de CPU. C'est le contraire qui serait étonnant/inquiétant.
Pour info, quand j'ouvre une page avec du flash (libé/lemonde), gkrellm passe de 1-4% à 15-20% de consommation CPU. J'essaye donc de penser à fermer les onglets contenant du flash quand j'ai fini de les lire (mais je laisse firefox ouvert).
Il y a peu d'importance : la plupart des sources de jpeg ont une taille en multiple de 16 (et pas 8 : certaines composantes n'ont par défault que 8 valeurs stockées pour 16 pixels), en particulier tous les appareils photos.
Cette limitation provient du format JPEG lui-même. Vu qu'il stocke l'image en la découpant en bloc, on ne peut pas tourner ces blocs sans les recompresser (ie refaire une FFT) si on change leur frontière.
Ça permet de calculer 0.1+0.1+0.1+...+0.1 (dix fois) et d'obtenir 1.0
En effet, 0.1 n'est pas représentable en binaire. Le BCD permet d'éviter des erreurs d'arrondi pour les calculs en base 10.
A mon avis, ce qu'on peut reprocher à Debian, c'est de ne pas publier de DSA avant que les packets ne soient disponibles pour toutes les architectures. Mais que faire alors : un DSA pour la découverte du problème, puis un DSA pour chacun des nouveaux packets par architecture qui essayent de corriger le problème, puis un DSA pour le packet bien testé par architecture qui corrige le problème, puis un DSA quand tout est prêt (le seul actuel) ?
Pour ma part, bof, il suffit vérifier chaque jour qu'aucune mise à jour de sécurité n'est disponible. Et ça, ça se fait très bien avec une crontab pour la distrib stable.
Associé à apt-listchanges, ça permet de choisir si on veut la mise à jour où si on attend la version certifiée/testée.
ça ne risque pas. C'est plus malin que ça. Les chercheurs menacent de démissionner de leurs responsibilités administratives, pas de leur poste.
Or, une fois qu'un labo n'a plus de directeur, il ne peut (légalement) continuer à recevoir du monde : il n'y a plus personne pour couvrir la responsabilité des personnes présentes. La démission (administrative) des chercheurs, en particulier des grands chercheurs, aurait pour conséquence une complète désorganisation de la recherche publique française.
C'est ça qui peut faire peur au gouvernement : la menace ne dérange pas réellement les chercheurs sur le plan personnel, par contre ça gênerait énormément les structures administratives/le ministère. Le fait que tant de chercheurs avec des postes haut placés signent cette pétition montre l'ampleur des problèmes dans cette branche.
Quand je programme directement sur la ligne de commande, j'utilise cette technique.
Quand je fais un script que je veux pouvoir débogguer facilement (ou lancer de temps à autre en étant sur de ne rien cassé), j'ai quelques techniques simples:
# SHOW est choisi (par édition ou avec une option quelconque)
# Ici on débug
SHOW=echo
# ici on fait l'opération
SHOW=
# et après, pour les étapes dangeureuses :
$SHOW rm ...
$SHOW mv ...
Dans le même ordre d'idée, j'ai aussi :
run() {
if [ "$verbose" = 1 ]; then
echo -n "Running:"
for arg; do
echo -n " '$arg'"
done
echo
fi
"$@"
}
C'est marrant comme on applaudit ici quand un établissement passe sous environnement libre (souvent grâce à l'engagement d'une partie du personnel qui s'investit sur son temps libre), mais quand un autre établissement refuse ce changement, alors c'est l'ensemble des "fonctionnaires" qui ont une mauvaise attitude.
C'est ce genre de commentaires qui me hérisse (bien que je ne sois pas fonctionnaire, mais j'en connais beaucoup). Ça crée des tensions inutiles entre deux catégories de la population complètement idiotes (les tensions, pas les catégories :-)). Et surtout, ça énerve BEAUCOUP toute une partie des fonctionnaires qui ne méritent absolument pas ces critiques. Et après, on s'étonne qu'ils soient aigris quand on leur fait des reproches immérités/infondés.
Le problème, c'est que le stylo que je tiens dans mon rêve, il n'a jamais laissé de trace sur la feuille à mon réveil. Tu fais comment ?
(il est où le -1 ?)
> Si je me souviens bien on avait démontré qu'un algo de tri était au mieux en O(n ln(n)).
Avec des hypothèses, tout de même.
Parce que si on ne trie que des entiers de 32bits (ou toute autre taille bornée), on peut alors avoir un tri linéraire (tri radix par exemple). Une recherche très rapide sur google m'a donné : http://fr.wikipedia.org/wiki/Tri(...)
En archi, on forme aussi des réseaux de tri qui font leur boulot en temps linéraire.
La borne donnée n'est valable que pour les tris basés sur des comparaisons successives.
> Sauf que la syntaxe proposée, comme dit plus bas, permet de ne pas créer un autre fichier. Comme ce sont deux commandes disctinctes, tu peux, sans risque, écrire sur le fichier que tu lis !
Faux. le comportement de "cat toto | sed ... > toto' dépend du shell. Tu n'as aucune certitude que toto sera tout lu avant d'être réécrit.
Tu supposes que le 'read()' de cat lit tout le lichier avant le 'open(O_CREATE, ...)' du shell. Je n'ai pas testé, mais je parie que c'est faux au moins pour les gros fichiers (qui ne tiennent pas en mémoire et sont lus bout par bout par cat).
L'option '-i' ou '--in-place' de sed permet par contre de modifier un fichier sans le renommer/faire une copie/...
> Le projet gnome a bien percuté sur ce point. Même s'il y a quelques plaintes, j'espère qu'ils vont tenir bon car c'est la bonne voie.
Bof, les disparitions de plus en plus de réglages me font envisager de changer de logiciel. Si j'utilise gnome, c'est pour avoir une certaine facilité de configuration. S'il faut que j'édite un fichier pour changer de WM ou que j'utilise gconf-editor pour changer ce que font mes boutons de souris avec galeon, ben c'est pas glop.
Que ces réglages soient regroupés dans un bouton 'Advenced' ou autre, ok.
S'ils disparaissent, j'irai voir ailleurs. Et l'évolution actuelle des applis gnomes ne me plait absolument pas de ce point de vue là.
[^] # Re: Fichtre, je ne sais que mettre comme titre
Posté par Vincent Danjean . En réponse à la dépêche Les images ISO de la Mandrakelinux 10.1 sont dispo en téléchargement pour tous !. Évalué à 1.
> Moi je suis allez le downloadé car j'y ai accès. C'est tout.
> J'ai une licence GPL pour utiliser Linux ?
> Oui ou non ?
Oui
> Il me faut obligatoirement la label "employeur" pour bénéfier de la GPL ?
Non
> > Seule l'entreprise qui a la licence GPL sur ce code peut distribuer ce code si elle le désire.
> Tu expliques ?
Elle l'a reçu (par accord, achat, téléchargement ou tout autre méthode qui te vient à l'esprit) de quelqu'un (entité physique ou morale) qui avait possédait ce logiciel avec cette licence (GPL) et donc avait le droit de donner/vendre ce logiciel sous cette licence.
N'importe quel utilisateur (employé ou pas) recevant ce logiciel sous licence GPL de quelqu'un en possédant déjà une licence GPL peut le redistribuer. MAIS il faut qu'il recoive cette licence.
Ici, ce n'est pas parce que l'entreprise a obtenu une licence (GPL) de son fournisseur que l'employé aussi. De même, ce n'est pas parce que le code ajouté est aussi sous licence GPL que l'employé a reçu une licence (GPL) pour utiliser (et redistribuer) ce code.
Ce que je veux dire, et que tu ne sembles pas comprendre, c'est qu'utiliser un logiciel (GPL ou non) de la part d'un employé ni signifie pas que cet employé possède une licence de ce logiciel, seulement que son entreprise en a une. Et sans licence, l'employé ne peut pas décider de diffuser ce logiciel (de quel droit le ferait-il ?). Ceci reste vrai quelque soit ce qu'il y a dans la licence accordée à l'entreprise.
Sinon, c'est que tu considères que l'employé a acquis une licence GPL sur le logiciel (qui lui donne le droit de le redistribuer). D'où provient alors cette licence ?
Si tu considères qu'elle provient du fait que son employeur lui a fournit ce logiciel, alors je comprends ta position, mais je ne la partage pas (ça me semble évident en considérant d'autres licences qui interdisent justement de sous licencier : un employé peut quand même utiliser les logiciels de sa boîte sans en avoir une licence personnellement).
Si tu considères qu'elle vient de l'utilisation du logiciel lui-même, c'est faux. Juridiquement, une licence est nécessairement cédée/vendue/donnée... par quelqu'un qui a le droit de le faire.
Si tu considères qu'elle vient d'ailleurs, dit moi d'où.
> - "je n'ai pas le droit de downloader (donc copier) Linux car je n'utilise pas Linux et donc la GPL ne s'applique pas."
>
> Reconnais que c'est ridicule.
Oui, ton arguement est ridicule. Linus (et les autres contributeurs) ont mis leur code en GPL ET ils le diffusent sur leur site (www.kernel.org ?). Ils sont les auteurs, ils peuvent diffuser comme bon leur semble.
Les propriétaires des serveurs FTP l'ont mis sur leur site parce qu'ils ont récupéré les sources avec une licence GPL donnée par les auteurs (ou un autre intermédiaire comme eux) leur permettant de les redistribuer (avec la même licence).
Par contre, les modifications, sous licence GPL, du noyau faites par une entreprise X, personne n'aura le droit de les diffuser tant que X ne les aura pas diffusées lui-même. Un pirate qui volerait les sources sur le réseau de l'entreprise ne possèderait pas pour autant la licence GPL les accompagnant. Une licence (GPL ou pas) est un contrat entre deux personnes (au moins). Voler, espionner, ... ne te permet pas de t'approprier ce contrat et de te servir de lui pour justifier d'autres actions (diffuser le code volé/intercepté).
Tu ne peux acquérir une licence d'utilisation d'un logiciel GPL qu'auprès d'une personne possédant une telle licence et acceptant de t'en vendre/donner une (par exemple auprès d'un mainteneur de site ftp en téléchargeant le logiciel proposé). Une fois que tu l'auras, tu pourras la céder comme bon te semble, mais il faut l'avoir avant. Et si une entreprise l'a, un employé ne l'a pas nécessairement même s'il utilise le logiciel.
[^] # Re: Fichtre, je ne sais que mettre comme titre
Posté par Vincent Danjean . En réponse à la dépêche Les images ISO de la Mandrakelinux 10.1 sont dispo en téléchargement pour tous !. Évalué à 1.
D'abord, non. Ce n'est pas parce qu'on a accès à quelque chose qu'on peut le copier/diffuser. C'est, dans le cas qui nous occupe, parce qu'on a reçu (et accepté) une licence (GPL) qui nous authorise à le faire. Si on refuse la licence ou si cette licence ne nous est pas proposée, on ne peut pas copier/diffuser.
Dans ce cas présent, comme dis en détail dans d'autres contributions, c'est l'entreprise qui a la licence GPL sur le programme (modifié ou non). Évidemment, si le programme non modifié est distribué librement, alors il est facile à n'importe qui d'acquérir une licence GPL (avec tous les droits et devoirs que cela comporte).
Mais, lorsque le programme (ou ses modifications faites dans l'entreprise) ne sont pas distribuées, alors un employé ne peut pas distribuer ce code. Tout simplement parce qu'il n'a pas la licence qui lui permet de le faire. Seule l'entreprise qui a la licence GPL sur ce code peut distribuer ce code si elle le désire.
Maintenant, un juriste pourrait peut-être argumenter que l'entreprise a effectivement distribué le logiciel à ses employés, les rendant libre (par la GPL) de le rediffuser. Mais ça ne me semble pas vraiment tenable. Comme dit dans d'autres posts, une entreprise n'a pas à (voire même ne peut pas) re/sous licencier les logiciels pour lesquels elle a aquis une licence (fut-elle GPL ou propriétaire).
[^] # Re: Fichtre, je ne sais que mettre comme titre
Posté par Vincent Danjean . En réponse à la dépêche Les images ISO de la Mandrakelinux 10.1 sont dispo en téléchargement pour tous !. Évalué à 1.
Le programme de base, probablement oui.
Mais je suppute que ce qui pose problème, ce sont les modifications que l'employé y apporte. SI il les distribue, alors ça sera nécessairement sous licence GPL. Mais encore faut-il qu'il en ait le droit. Pour cela, ses modifications doivent être sous une licence :
1) compatible avec la GPL (à cause du programme de base sous GPL)
2) compatible avec les règlements de son employeur (c'est du travail, pas du développement personnel)
Remarque en passant : si les deux sont incompatibles, alors le logiciel modifié n'est pas distribuable. Ce n'est pas spécifique aux logiciels propriétaires : c'est aussi le cas de logiciels composées de briques "libres", mais avec des licences incompatibles entre elles (exemple : Qt et GPL pendant un certain temps il me semble (à vérifier)).
Je pense que, lié par un contrat de travail, le code appartient à l'employeur. Ce dernier n'en est pas l'auteur, mais c'est lui qui choisit la licence à utiliser. Et tant qu'il ne le distribue pas, il n'est pas tenu de fournir les sources à qui que ce soit.
Reste pour les jusristes à définir si "utiliser du code appartenant à une entreprise au sein de cette entreprise" constitue une forme de distribution et permet (sous réserve que le code soit sous licence compatible GPL) aux employés de réclamer les sources pour les rediffuser eux-mêmes. Et là, ça me paraît beaucoup plus délicat à argumenter (et largement au delà de mes compérences)
[^] # Re: Merci
Posté par Vincent Danjean . En réponse à la dépêche Quelques précisions sur la bibliothèque de traitement d'images 'INRIA'. Évalué à 10.
Les chercheurs autour de moi ne faisaient pas très attention aux licenses. Ça change pas mal ces dernières années, mais il faut bien comprendre que c'est quelque chose de récent. Je parle bien sûr des 'petits' codes. 'petits' n'est pas au sens de 'peu de ligne de code', mais 'développé pendant peu de temps' (une thèse, une tâche, ...)
Généralement, les chercheurs sont très contents si des personnes désirent utiliser leur code : ça fait tout plein de retour d'expérience, ce qui est souvent très profitable.
Par contre, il faut aussi comprendre que le travail de diffusion (packaging, documentation complète, publicité, ...) n'est pas très valorisable auprès de nos instances (sauf si le projet/code a déjà acquis une certaine notoriété). C'est pourquoi il faut généralement directement s'adresser aux équipes/développeurs pour avoir une doc un peu plus récente/à jour, ... Et tous les chercheurs ne sont pas prêts à s'investir sur leur temps libre pour faire ce travail de diffusion s'ils n'ont pas la certitude que ça intéressera un certain nombre de personnes. Énormément de code développé est abandonné au bout de quelque temps : des concepts sont validés et subsistent (dans d'autres projets/codes), mais le code de base est souvent archivé et laissé tel quel.
Autre remarque : l'INRIA est structurée en équipes (approximativement 5 à 20 personnes en moyenne) relativement indépendantes. Cela explique les nombreuses disparités dans les politiques de diffusion de code. L'INRIA (centrale) demande de faire remonter les logiciels diffusés (ceux de la page citée plus haut), mais toutes les équipes ne le font pas nécessairement : elles estiment parfois que leur code n'est pas prêt pour une diffusion (pas assez de doc, trop compliquer à compiler/installer sans aide, ...). Les choix de licences, supports, ... sont entièrement fixés par les équipes, pas par un 'bureau central'.
Pour le budget, ne pas perdre de vue que l'INRIA crée actuellement trois pôles supplémentaires (Lille,Saclay, Bordeaux) en plus des cinq autres déjà existants. Cela nécessite des moyens importants (nouveaux locaux et personnel (chercheur et administratif))
[^] # Re: fuite de mémoire
Posté par Vincent Danjean . En réponse à la dépêche Firefox 0.9. Évalué à 2.
1) il s'agit de 2h45 (et pas de 2 min 45)
2) il s'agit du temps CPU consommé (et pas de la durée de vie de l'appli)
Ça me semble parfaitement normal qu'une application interactive consomme peu de CPU. C'est le contraire qui serait étonnant/inquiétant.
Pour info, quand j'ouvre une page avec du flash (libé/lemonde), gkrellm passe de 1-4% à 15-20% de consommation CPU. J'essaye donc de penser à fermer les onglets contenant du flash quand j'ai fini de les lire (mais je laisse firefox ouvert).
[^] # Re: La sortie de la prochaine Debian menacée ?
Posté par Vincent Danjean . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à -1.
http://packages.debian.org/stable/base/kernel-image-2.4.18-386(...)
[^] # Re: Sortie de ImageMagick 6.0.0
Posté par Vincent Danjean . En réponse à la dépêche Sortie de ImageMagick 6.0.0. Évalué à 1.
Cette limitation provient du format JPEG lui-même. Vu qu'il stocke l'image en la découpant en bloc, on ne peut pas tourner ces blocs sans les recompresser (ie refaire une FFT) si on change leur frontière.
[^] # Re: Taille du code....
Posté par Vincent Danjean . En réponse à la dépêche Le code source de Win NT4 et Win 2000 sur l'Internet. Évalué à 2.
En effet, 0.1 n'est pas représentable en binaire. Le BCD permet d'éviter des erreurs d'arrondi pour les calculs en base 10.
[^] # Re: Debian en progression pour les serveurs web
Posté par Vincent Danjean . En réponse à la dépêche Debian en progression pour les serveurs web. Évalué à 2.
A mon avis, ce qu'on peut reprocher à Debian, c'est de ne pas publier de DSA avant que les packets ne soient disponibles pour toutes les architectures. Mais que faire alors : un DSA pour la découverte du problème, puis un DSA pour chacun des nouveaux packets par architecture qui essayent de corriger le problème, puis un DSA pour le packet bien testé par architecture qui corrige le problème, puis un DSA quand tout est prêt (le seul actuel) ?
Pour ma part, bof, il suffit vérifier chaque jour qu'aucune mise à jour de sécurité n'est disponible. Et ça, ça se fait très bien avec une crontab pour la distrib stable.
Associé à apt-listchanges, ça permet de choisir si on veut la mise à jour où si on attend la version certifiée/testée.
[^] # Re: Journée d'information sur les brevets (y compris logiciels) pour les chercheurs
Posté par Vincent Danjean . En réponse à la dépêche Journée d'information sur les brevets (y compris logiciels) pour les chercheurs. Évalué à 4.
Or, une fois qu'un labo n'a plus de directeur, il ne peut (légalement) continuer à recevoir du monde : il n'y a plus personne pour couvrir la responsabilité des personnes présentes. La démission (administrative) des chercheurs, en particulier des grands chercheurs, aurait pour conséquence une complète désorganisation de la recherche publique française.
C'est ça qui peut faire peur au gouvernement : la menace ne dérange pas réellement les chercheurs sur le plan personnel, par contre ça gênerait énormément les structures administratives/le ministère. Le fait que tant de chercheurs avec des postes haut placés signent cette pétition montre l'ampleur des problèmes dans cette branche.
[^] # Re: debug de scripts bash
Posté par Vincent Danjean . En réponse au message [Terminal] debug de scripts bash. Évalué à 1.
run() { if [ "$verbose" = 1 ]; then echo -n "Running:" for arg; do echo -n " '$arg'" done echo fi "$@" }[^] # Re: Samba 3 est sortie
Posté par Vincent Danjean . En réponse à la dépêche Samba 3 est sorti. Évalué à 10.
C'est ce genre de commentaires qui me hérisse (bien que je ne sois pas fonctionnaire, mais j'en connais beaucoup). Ça crée des tensions inutiles entre deux catégories de la population complètement idiotes (les tensions, pas les catégories :-)). Et surtout, ça énerve BEAUCOUP toute une partie des fonctionnaires qui ne méritent absolument pas ces critiques. Et après, on s'étonne qu'ils soient aigris quand on leur fait des reproches immérités/infondés.
[^] # Re: La programmation est un art
Posté par Vincent Danjean . En réponse à la dépêche La programmation est un art. Évalué à 5.
(il est où le -1 ?)
[^] # Re: Avancées technologiques du prochain Kernel
Posté par Vincent Danjean . En réponse à la dépêche Avancées technologiques du prochain noyau Linux. Évalué à 1.
Avec des hypothèses, tout de même.
Parce que si on ne trie que des entiers de 32bits (ou toute autre taille bornée), on peut alors avoir un tri linéraire (tri radix par exemple). Une recherche très rapide sur google m'a donné : http://fr.wikipedia.org/wiki/Tri(...)
En archi, on forme aussi des réseaux de tri qui font leur boulot en temps linéraire.
La borne donnée n'est valable que pour les tris basés sur des comparaisons successives.
[^] # Re: le cat ne sert à rien
Posté par Vincent Danjean . En réponse au message [Terminal] Changements rapides avec sed. Évalué à 1.
Faux. le comportement de "cat toto | sed ... > toto' dépend du shell. Tu n'as aucune certitude que toto sera tout lu avant d'être réécrit.
Tu supposes que le 'read()' de cat lit tout le lichier avant le 'open(O_CREATE, ...)' du shell. Je n'ai pas testé, mais je parie que c'est faux au moins pour les gros fichiers (qui ne tiennent pas en mémoire et sont lus bout par bout par cat).
L'option '-i' ou '--in-place' de sed permet par contre de modifier un fichier sans le renommer/faire une copie/...
[^] # Re: Nouveau plan de route pour Mozilla !
Posté par Vincent Danjean . En réponse à la dépêche Nouveau plan de route pour Mozilla !. Évalué à 3.
Bof, les disparitions de plus en plus de réglages me font envisager de changer de logiciel. Si j'utilise gnome, c'est pour avoir une certaine facilité de configuration. S'il faut que j'édite un fichier pour changer de WM ou que j'utilise gconf-editor pour changer ce que font mes boutons de souris avec galeon, ben c'est pas glop.
Que ces réglages soient regroupés dans un bouton 'Advenced' ou autre, ok.
S'ils disparaissent, j'irai voir ailleurs. Et l'évolution actuelle des applis gnomes ne me plait absolument pas de ce point de vue là.
[^] # Re: Système non standard?
Posté par Vincent Danjean . En réponse au message [Terminal] Accelérer le système de fichier. Évalué à 2.
[^] # Re: Utilisez GNU Stow
Posté par Vincent Danjean . En réponse à la dépêche Cheval de troie dans OpenSSH. Évalué à 2.
configure --prefix=/usr/local
make
make install prefix=/usr/local/stow/mon-soft/
Comme ça, si le soft utilise 'prefix' (dans des fichiers d'exemple de config pour l'utilisateur par exemple), on ne voit pas stow/mon-soft/.