1Go de stockages en USB mass-storage (donc montage sans problème par linux), lit les mp3 et les ogg (et d'autres trucs dont je me moque ;) ), marche avec une pile AAA (et aussi avec l'équivalent en accus rechargeables, à la vitesse où ça consomme un chargeur d'accus c'est un investissement).
Il y a aussi des versions à 512M (et 256M) si on veut moins cher.
La lecture OGG/Vorbis marche tres bien. Mais j'ai eu quelques soucis sur des .ogg corrompus (que j'ai du créer il y a longtemps avec une libvorbis pas au point ?), qui freezent le bidule (obligé d'enlever la pile pour l'éteindre...). Donc penser à vérifier que les fichiers sont "propres" avec un "ogginfo".
Pareil, le ² ne marche pas pour moi. Mais c'est parceque j'ai décommenté la ligne NOUSLAYOUT="true" dans le script nexuiz (pour avoir un clavier azerty). Du coup y a pleins de trucs qui ne marchent plus (la gestion du clavier par SDL ne semble pas trop connaitre le monde en dehors des US...), le ² donc, et la selection des armes par numéros. Et comme il ne connait pas les caractères accentués, faut que je trouve un remplaçant pour les armes 2,7,9 et 0...
Donc au choix, soit tu laisse la ligne commentée, mais pour chatter ce sera du qwerty, soit tu décommentes et tu galère pour les touches un peu spéciales.
Personnelement j'ai remappé la console sur F9. Crée un fichier ~/.nexuiz/data/autoexec.cfg dans le lequel tu mets:
bind "F9" "toggleconsole"
L'autoexec, contrairement au config.cfg, n'est pas réécrit par le jeu, donc tu peux y mettre des configurations sans crainte qu'elles soient écrasées ou perdue.
C'est pas bien compliqué de vérifier que la fluidité commence largement au dessus de 24 fps.
Avec une config qui ne rame pas histoire d'avoir un framerate constant, si je fais "/com_maxfps 24" pour fixer à 24 images par secondes, c'est HORRIBLE. Ça saccade, ça fait mal aux yeux. Avec /com_maxfps 48, ça devient presque bien, mais peut mieux faire. Et à 85/86 (le taux de rafraichissement de l'écran) c'est impec. (Il parait que c'est aussi pratique pour exploiter les bugs du code physique, effectivement).
Ça marche aussi avec des diviseurs de la fréquence de l'écran, pour qu'on ne vienne pas m'accuser de problème de frame droppée ou quoi.
Il faut bien aussi se rendre compte que, même dans l'hypothèse où l'oeil n'est sensible qu'à environ 25hz (voire 10 d'apres qqun qui semble s'y connaitre), il ne voit pas un "instantané" absolu, mais les capteurs de lumière font une intégration de tous les signaux reçu pendant ce 1/25e de seconde. Si le jeu tourne à 25fps, il verra une suite d'image figées, alors que s'il tourne à 50fps, chaque image "vue" par l'oeil sera une combinaison de 2 images générées à l'écran, et le cerveau pourra en extraire le double d'information (enfin je crois)
Ah, je l'ai eu entre les mains quelques minutes (la version classique blanche en bas de la page). Effectivement, alors qu'une souris classique a 2 degres de liberté (translation X et Y), celle la en a au moins 6 (translation Z, et rotations selon les 3 axes). C'est pratique pour tout ce qui est modélisation/exploration 3D.
Et pour ceux qui veulent se tenir au courant de ce genre de baratinage ("relations publiques"): http://www.sourcewatch.org(...) (anciennement appelé "disinfopedia.org", je trouvais ça plus parlant)
Deja, je ne m'y suis pas pris au dernier moment...
Et comme j'ai eu ce problème aussi, je suis allé voir sur les forums; il y avait des liens dans les journaux linuxfr à l'époque d'ailleur.
Pour mon cas, je crois que ça se résumait à lancer le navigateur avec "LANG=fr_FR" (au lieu du LANG=C que j'ai actif habituellement) pour que l'applet java ne s'emmele pas les pinceaux.
j'ai cru constater que "hdparm -T /dev/hda" retournait en pratique le débit de la RAM
C'est bien le rôle de l'option -T: « Perform timings of cache reads [...] This displays the speed of reading directly from the Linux buffer cache without disk access » donc effectivement, on peut s'en servir pour avoir une idée du débit de sa RAM.
(c'est l'option -t pour avoir le débit physique du disque)
l'attribut CSS3 opacity, mais seul mozilla le supporte
Si tu veux utiliser des PNG transparents pour que ça passe aussi sous Internet Explorer, je crois que ça reviendra à peu près au même :)..
Apparemment, ce sont des scripts que tu avais écrits, et qui marchaient, sous Mandrake, mais plus sous debian ? Ou bien aussi de nouveaux scripts que tu as fait depuis ta migration ? (quel éditeur de texte utilises-tu ?)
Vérifie que la ligne "#!/bin/sh" contient bien ce que tu crois, et qu'il n'y a pas de caractères invisibles supplémentaires, comme des sauts de lignes "MS-DOS": le kernel tenterait dans ce cas de trouver un /bin/sh^M au lieu de /bin/sh, par exemple.
Tu peux vérifier avec un "head -1 script.sh | od -c" qui doit te donner exactement:
0000000 # ! / b i n / s h \n
0000013
Si tu as par contre (remarque le \r en trop)
0000000 # ! / b i n / s h \r \n
0000013
ça peut venir de là. (par contre chez moi le message d'erreur ne serait pas le même que le tiens, j'ai juste ": bad interpreter: No such file or directory" puisque le \r écrase le début de la ligne)
/etc/shells n'est utilisé que pour autoriser le shell de connexion (celui qui a son entrée dans /etc/passwd), ça n'a aucun impact sur des interpréteurs ou shells qu'on lancerait à la main par la suite.
grip utilise un programme externe pour ripper, tu as normalement le choix entre cdparanoia et cdda2wav (s'ils sont installés) (dans l'onglet d'options).
Si l'un ne marche pas bien, essaye l'autre. J'ai eu des CDs qui ne passaient qu'avec l'un.
Une question que je me pose toujours en lisant ce genre de truc: comment font les gens pour écrire des programmes C ou shell qui marchent, s'ils ne sont même pas capable d'écrire en français sans provoquer des Parse Error chez leur lecteur ?
Est-ce qu'ils relancent gcc 20 fois de suites pour corriger les fautes dans leurs 3 lignes de codes ?
"ah merde j'ai oublié de fermer la parenthèse"
"ah oui, j'ai pas mis le point-virgule final"
"la non plus"
"ah j'en ai mis 10 de trop à cette ligne"
'tiens, il faut mettre une virgule entre chaque paramètre de fonction"
"undefined function... ah oui il faut écrire son nom correctement, sans oublier la moitié des lettres"
"oh merde..."
[ évidemment, je fais des fautes moi aussi.. ce qu'on reproche c'est pas une faute ou deux, c'est l'excés flagrant ]
[verbeux]
Il faut bien distinguer le fonctionnement de TCP, de celui d'UDP. TCP est en mode connecté, ça tout le monde le sait je pense, et c'est le kernel qui s'occupe de la connexion avec l'hôte distant quand on fait un connect().
En cas de port fermé, il recevera un paquet ICMP d'erreur, ou un timeout, et le signalera au processus appelant en code de retour de connect()
TCP est aussi en mode "stream", donc a priori les données qu'on envoit avec sendto() peuvent être bufferisées en local, et envoyé en 1 ou plusieurs paquets, restransmises s'il n'y a pas d'acquittement... tout ça est géré par le kernel.
UDP par contre c'est du bête et méchant: pas de connexion, par de stream, pas de buffer, pas de retransmission. Quand le programme fait un sendto(), ça envoie le paquet tel quel, point barre. Le noyau s'occupe juste de rajouter les entêtes IP et d'envoyer ça sur l'interface réseau qui va bien. Apres c'est plus son problème; si on veut savoir si le paquet est bien arrivé, ou attendre une réponse, c'est au programme de le faire lui-même (avec un select() à timeout suivi d'un recvfrom())
Le problème c'est que si l'API socket est capable de gérer ces deux protocoles avec les mêmes fonctions, c'est au prix de grande variations sémantiques. Ça peut t'induire en erreur si tu as l'habitude de TCP et que tu continues à raisonner "en TCP"
connect() par example (pour contredir le post précédent), établit une vraie connexion, gérée par le noyau, si c'est une socket TCP, et renvoie une erreur en cas d'eche. En UDP par contre, c'est juste un raccourci pour éviter de redonner continuellement à sendto() l'adresse du destinataire, aucun échange de paquet ne se fait à ce moment-là et donc connect() marche TOUJOURS.
sendto() de même va gueuler si la socket TCP n'a pas été connect()ée avant ou a été "reset by peer"; par contre, pour de l'UDP, sendto() marchera TOUJOURS (moyennant peut-etre assez de mémoire kernel pour les buffer et l'existence d'une interface réseau).
[/verbeux]
Regarde la page de man de "nmap" '-sU UDP scans', et les sources correspondantes :)
Résultat: alors que le kernel gere tout en TCP, en UDP il faut tout faire soi-même. En particulier, quand un port destination est fermé, il faut
récupérer le paquet ICMP d'erreur de retour. Et pour ça, il faut être root...
(car il faut ouvrir une socket raw pour acceder à ce type de protocole).
J'avais eu ce probleme un moment (mais je ne suis pas sous mandrake, ni Gnome), "<" et ">" inconnus. J'en étais rendu à ajouter des lignes xmodmap dans mon .xsession pour définir cette touche moi-même. (pour info: xmodmap -e "keycode 94 = less greater" )
Mais en fait apres je me suis rendu compte que j'avais mal défini le clavier pour X, avec un "pc102" au lieu de "pc105" et c'est ça qui changeait tout. Regarde si tu peux modifier ça.
Le fait que ça remarche quand tu reselectionne le clavier dans le centre de contrôle, doit tenir au fait que ça redéfinit toutes les touches (comme moi avec mes xmodmaps) selon le clavier detecté par Gnome, indépendamment de celui configuré pour X initialement.
Je rappelle les 4 Libertés Fondamentales qui seront utilisées pour juger si un programme est libre:
* la liberté d'exécution : tout le monde a le droit de lancer le programme, quel qu'en soit le but ;
* la liberté de modification : tout le monde a le droit d'étudier le programme et de le modifier, ce qui implique un accès au code source ;
* la liberté de redistribution : tout le monde a le droit de rediffuser le programme, gratuitement ou non ;
* la liberté d'amélioration : tout le monde a le droit de redistribuer une version modifiée du programme.
Ta licence est incompatible avec les points 3 et 4, et éventuellement avec le 2 aussi.
Deja, comme d'autres, je ne comprends pas l'intérêt d'écrire une n-ième licence.
Un truc qui est sûrement pas Libre (et pas clair)
6.2. Modifications
----------------------
L'Utilisateur est autorisé à apporter des Modifications à l'OEuvre, sous réserve des
conditions suivantes :
6.2.1. Ses Modifications doivent rester dans l'objectif de l'OEuvre;
Ça veut dire quoi, "rester dans l'objectif de l'oeuvre" ? Où se situe la limite ? Dans les Libertés Fondamentales, on a la liberté de modification; là, tu restreint la porté de ces modifications. Si je prends le code d'un Emulateur de Terminal et que je le fais évoluer progressivement jusqu'à devenir un noyau de système d'exploitation, je viole la license ? (Pour info, c'était l'évolution du code de Linux si je me rapelle bien).
Ensuite tu parles de Fork (pour une licence en français, je pense qu'il faudrait plutot appeler ça OEuvre Dérivée ?..); où se situe la limite entre "Modification" et "Fork" ? D'apres les définitions j'ai l'impression que les Modifications sont celles de l'oeuvre "originale", donc les patches envoyés par des contributeur au mainteneur officiel ? Dans ce cas c'est au mainteneur de savoir ce qu'il accepte ou pas, c'est son code. Pourquoi la Licence le préciserait ?
6.3.4. Si le Fork nuit à l'OEuvre, ne respecte pas les termes du Contrat et/ou que lui ou l'OEuvre est vendu, le Titulaire peut en interdire la création jusqu'à les 30 jours suivant sa première version.
"nuire" à l'oeuvre ? Ça veut dire quoi ? Mauvaise image, concurrence commerciale ? Dans les contrats de certains logiciels Microsoft on a vu passer des clauses du style "interdit d'utiliser ce logiciel pour en publier des benchmarks". J'espère que tu prends pas cette voie...
Quand à l'interdiction de vendre, c'est clairement du Pas Libre du tout.
Cette restriction sur la vente se retrouve dans d'autres articles, que je ne remets pas.
Imagine LinuxMag qui fournit un CD dans son magazine. Ils peuvent y mettre tous les logiciels libres qu'ils veulent. Inclure un logiciel avec cette licence, est-ce considéré comme de la "vente à un prix excédent le prix du média" ? Ils ne prendront pas le risque.
6.4.2. L'Utilisateur ne peut distribuer l'OEuvre si celle-ci lui a été vendue, à moins d'un accord avec le Titulaire.
Incompatible avec les "4 Libertés Fondamentales": Un logiciel libre, on a le droit de le redistribuer, point. Peu importe qu'on l'ait obtenu gratuitement, contre un bière, ou pour 1000$.
Il y a encore d'autre clauses bizarres, mais à ce stade là j'ai arreté de regarder.
Pour moi, cette licence n'est pas libre.
Posté par daggett .
En réponse au journal Pango.
Évalué à 2.
> > Comme celui de transformer gnome-terminal en grosse citrouille bloated ?
> Ça tu l'inventes. C'est un troll sans fondement.
Lancement d'une compile dans un xterm: 1h. La meme dans un gnome-terminal: 2h; à cause de la lenteur d'affichage des sorties de Make et gcc en antialiasé et tout. C'est sans fondement ça ?
(durées à 10 minutes près, d'après mes souvenirs d'il y a 1 an; je ne sais pas si il y avait pango à cette époque, ou si c'etait bloated dès le départ)
Plutot que d'imposer de maintenir des distribs identiques sur chaque machine, ou de développer votre propre FS, est-ce que ça ne serait pas plus simple d'utiliser une système de fichier centralisé externe unique, qui utiliserait un FS distribué style GFS (maintenant redevenu libre) ?
# Samsung YP-ST5*
Posté par daggett . En réponse au journal en attendant bientot le supermarché du libre .... Évalué à 4.
http://www.fnac.com/Shelf/article.asp?PRID=1615711(...)
1Go de stockages en USB mass-storage (donc montage sans problème par linux), lit les mp3 et les ogg (et d'autres trucs dont je me moque ;) ), marche avec une pile AAA (et aussi avec l'équivalent en accus rechargeables, à la vitesse où ça consomme un chargeur d'accus c'est un investissement).
Il y a aussi des versions à 512M (et 256M) si on veut moins cher.
La lecture OGG/Vorbis marche tres bien. Mais j'ai eu quelques soucis sur des .ogg corrompus (que j'ai du créer il y a longtemps avec une libvorbis pas au point ?), qui freezent le bidule (obligé d'enlever la pile pour l'éteindre...). Donc penser à vérifier que les fichiers sont "propres" avec un "ogginfo".
[^] # Re: Console & FPS
Posté par daggett . En réponse au journal nexuiz faut s'entrainer. Évalué à 1.
Note qu'il y a complétion par TAB des commandes, dans la console.
[^] # La console
Posté par daggett . En réponse au journal nexuiz faut s'entrainer. Évalué à 2.
Donc au choix, soit tu laisse la ligne commentée, mais pour chatter ce sera du qwerty, soit tu décommentes et tu galère pour les touches un peu spéciales.
Personnelement j'ai remappé la console sur F9. Crée un fichier ~/.nexuiz/data/autoexec.cfg dans le lequel tu mets:
bind "F9" "toggleconsole"
L'autoexec, contrairement au config.cfg, n'est pas réécrit par le jeu, donc tu peux y mettre des configurations sans crainte qu'elles soient écrasées ou perdue.
[^] # Re: Outch !
Posté par daggett . En réponse à la dépêche Nexuiz 1.0. Évalué à 4.
Avec une config qui ne rame pas histoire d'avoir un framerate constant, si je fais "/com_maxfps 24" pour fixer à 24 images par secondes, c'est HORRIBLE. Ça saccade, ça fait mal aux yeux. Avec /com_maxfps 48, ça devient presque bien, mais peut mieux faire. Et à 85/86 (le taux de rafraichissement de l'écran) c'est impec. (Il parait que c'est aussi pratique pour exploiter les bugs du code physique, effectivement).
Ça marche aussi avec des diviseurs de la fréquence de l'écran, pour qu'on ne vienne pas m'accuser de problème de frame droppée ou quoi.
Il faut bien aussi se rendre compte que, même dans l'hypothèse où l'oeil n'est sensible qu'à environ 25hz (voire 10 d'apres qqun qui semble s'y connaitre), il ne voit pas un "instantané" absolu, mais les capteurs de lumière font une intégration de tous les signaux reçu pendant ce 1/25e de seconde. Si le jeu tourne à 25fps, il verra une suite d'image figées, alors que s'il tourne à 50fps, chaque image "vue" par l'oeil sera une combinaison de 2 images générées à l'écran, et le cerveau pourra en extraire le double d'information (enfin je crois)
[^] # Re: Installeur pour linux
Posté par daggett . En réponse à la dépêche Nexuiz 1.0. Évalué à 3.
[^] # Re: Ca existe pas déjà?
Posté par daggett . En réponse au journal Idée à la con. Évalué à 2.
[^] # Re: L'intégrisme à la française
Posté par daggett . En réponse au journal Un jour, dans un petit pays de l'ouest.... Évalué à 5.
Marrant, moi j'etais persuadé que « arrosage » ça faisait reférence à un DDoS/Flood... Bref, effectivement, on n'est toujours pas plus avancé.
[^] # Re: Phear !
Posté par daggett . En réponse au journal Voleurs de pensée : nouveau FUD de Microsoft. Évalué à 1.
# Pour l'année prochaine alors ?..
Posté par daggett . En réponse au journal impots : declaration en ligne et signature - histoire d'un echec. Évalué à 4.
Et comme j'ai eu ce problème aussi, je suis allé voir sur les forums; il y avait des liens dans les journaux linuxfr à l'époque d'ailleur.
Pour mon cas, je crois que ça se résumait à lancer le navigateur avec "LANG=fr_FR" (au lieu du LANG=C que j'ai actif habituellement) pour que l'applet java ne s'emmele pas les pinceaux.
[^] # Re: Quelques hypothèses
Posté par daggett . En réponse au journal contreperformances étonnantes de calculs sur diverses machines. Évalué à 4.
C'est bien le rôle de l'option -T: « Perform timings of cache reads [...] This displays the speed of reading directly from the Linux buffer cache without disk access » donc effectivement, on peut s'en servir pour avoir une idée du débit de sa RAM.
(c'est l'option -t pour avoir le débit physique du disque)
# autorisé
Posté par daggett . En réponse au journal World of Warcraft Natif. Évalué à 1.
# En même temps...
Posté par daggett . En réponse au message Créer une image png transparente. Évalué à 1.
Si tu veux utiliser des PNG transparents pour que ça passe aussi sous Internet Explorer, je crois que ça reviendra à peu près au même :)..
[^] # Re: Ordinateur
Posté par daggett . En réponse au journal Un article du monde ou l'on apprend qu IBM nous a donné l'"ordinateur".. Évalué à 2.
# Caractères parasites ?
Posté par daggett . En réponse au message Nécessité de préciser "sh script.sh". Évalué à 2.
Vérifie que la ligne "#!/bin/sh" contient bien ce que tu crois, et qu'il n'y a pas de caractères invisibles supplémentaires, comme des sauts de lignes "MS-DOS": le kernel tenterait dans ce cas de trouver un /bin/sh^M au lieu de /bin/sh, par exemple.
Tu peux vérifier avec un "head -1 script.sh | od -c" qui doit te donner exactement:
0000000 # ! / b i n / s h \n
0000013
Si tu as par contre (remarque le \r en trop)
0000000 # ! / b i n / s h \r \n
0000013
ça peut venir de là. (par contre chez moi le message d'erreur ne serait pas le même que le tiens, j'ai juste ": bad interpreter: No such file or directory" puisque le \r écrase le début de la ligne)
[^] # Re: /etc/shells
Posté par daggett . En réponse au message Nécessité de préciser "sh script.sh". Évalué à 1.
[^] # Re: un lien
Posté par daggett . En réponse au journal Luxuriousity ou comment voler ce qui appartient à tout le monde pour ne le donner à personne. Évalué à 6.
[^] # Re: TCE?!
Posté par daggett . En réponse au journal [OT] TCE tenez, vous informé. Évalué à 3.
[^] # Re: rip ?
Posté par daggett . En réponse au message CD protege. Évalué à 2.
Si l'un ne marche pas bien, essaye l'autre. J'ai eu des CDs qui ne passaient qu'avec l'un.
[^] # Re: Distinction entre la grammaire et l'orthographe
Posté par daggett . En réponse au message Help!!!!!!!! mail script. Évalué à 8.
Est-ce qu'ils relancent gcc 20 fois de suites pour corriger les fautes dans leurs 3 lignes de codes ?
"ah merde j'ai oublié de fermer la parenthèse"
"ah oui, j'ai pas mis le point-virgule final"
"la non plus"
"ah j'en ai mis 10 de trop à cette ligne"
'tiens, il faut mettre une virgule entre chaque paramètre de fonction"
"undefined function... ah oui il faut écrire son nom correctement, sans oublier la moitié des lettres"
"oh merde..."
[ évidemment, je fais des fautes moi aussi.. ce qu'on reproche c'est pas une faute ou deux, c'est l'excés flagrant ]
# Un port doit être ouvert, ou bleu
Posté par daggett . En réponse au message Gestion des erreurs de connection UDP. Évalué à 6.
Il faut bien distinguer le fonctionnement de TCP, de celui d'UDP. TCP est en mode connecté, ça tout le monde le sait je pense, et c'est le kernel qui s'occupe de la connexion avec l'hôte distant quand on fait un connect().
En cas de port fermé, il recevera un paquet ICMP d'erreur, ou un timeout, et le signalera au processus appelant en code de retour de connect()
TCP est aussi en mode "stream", donc a priori les données qu'on envoit avec sendto() peuvent être bufferisées en local, et envoyé en 1 ou plusieurs paquets, restransmises s'il n'y a pas d'acquittement... tout ça est géré par le kernel.
UDP par contre c'est du bête et méchant: pas de connexion, par de stream, pas de buffer, pas de retransmission. Quand le programme fait un sendto(), ça envoie le paquet tel quel, point barre. Le noyau s'occupe juste de rajouter les entêtes IP et d'envoyer ça sur l'interface réseau qui va bien. Apres c'est plus son problème; si on veut savoir si le paquet est bien arrivé, ou attendre une réponse, c'est au programme de le faire lui-même (avec un select() à timeout suivi d'un recvfrom())
Le problème c'est que si l'API socket est capable de gérer ces deux protocoles avec les mêmes fonctions, c'est au prix de grande variations sémantiques. Ça peut t'induire en erreur si tu as l'habitude de TCP et que tu continues à raisonner "en TCP"
connect() par example (pour contredir le post précédent), établit une vraie connexion, gérée par le noyau, si c'est une socket TCP, et renvoie une erreur en cas d'eche. En UDP par contre, c'est juste un raccourci pour éviter de redonner continuellement à sendto() l'adresse du destinataire, aucun échange de paquet ne se fait à ce moment-là et donc connect() marche TOUJOURS.
sendto() de même va gueuler si la socket TCP n'a pas été connect()ée avant ou a été "reset by peer"; par contre, pour de l'UDP, sendto() marchera TOUJOURS (moyennant peut-etre assez de mémoire kernel pour les buffer et l'existence d'une interface réseau).
[/verbeux]
Regarde la page de man de "nmap" '-sU UDP scans', et les sources correspondantes :)
Résultat: alors que le kernel gere tout en TCP, en UDP il faut tout faire soi-même. En particulier, quand un port destination est fermé, il faut
récupérer le paquet ICMP d'erreur de retour. Et pour ça, il faut être root...
(car il faut ouvrir une socket raw pour acceder à ce type de protocole).
[^] # Re: re :problème avec la touche "<" et ">"
Posté par daggett . En réponse au message problème avec la touche "<" et ">". Évalué à 3.
Mais en fait apres je me suis rendu compte que j'avais mal défini le clavier pour X, avec un "pc102" au lieu de "pc105" et c'est ça qui changeait tout. Regarde si tu peux modifier ça.
Le fait que ça remarche quand tu reselectionne le clavier dans le centre de contrôle, doit tenir au fait que ça redéfinit toutes les touches (comme moi avec mes xmodmaps) selon le clavier detecté par Gnome, indépendamment de celui configuré pour X initialement.
[^] # 4 libertés
Posté par daggett . En réponse au journal Ma licence. Évalué à 3.
* la liberté d'exécution : tout le monde a le droit de lancer le programme, quel qu'en soit le but ;
* la liberté de modification : tout le monde a le droit d'étudier le programme et de le modifier, ce qui implique un accès au code source ;
* la liberté de redistribution : tout le monde a le droit de rediffuser le programme, gratuitement ou non ;
* la liberté d'amélioration : tout le monde a le droit de redistribuer une version modifiée du programme.
Ta licence est incompatible avec les points 3 et 4, et éventuellement avec le 2 aussi.
# gnééé
Posté par daggett . En réponse au journal Ma licence. Évalué à 3.
Un truc qui est sûrement pas Libre (et pas clair)
Ça veut dire quoi, "rester dans l'objectif de l'oeuvre" ? Où se situe la limite ? Dans les Libertés Fondamentales, on a la liberté de modification; là, tu restreint la porté de ces modifications. Si je prends le code d'un Emulateur de Terminal et que je le fais évoluer progressivement jusqu'à devenir un noyau de système d'exploitation, je viole la license ? (Pour info, c'était l'évolution du code de Linux si je me rapelle bien).
Ensuite tu parles de Fork (pour une licence en français, je pense qu'il faudrait plutot appeler ça OEuvre Dérivée ?..); où se situe la limite entre "Modification" et "Fork" ? D'apres les définitions j'ai l'impression que les Modifications sont celles de l'oeuvre "originale", donc les patches envoyés par des contributeur au mainteneur officiel ? Dans ce cas c'est au mainteneur de savoir ce qu'il accepte ou pas, c'est son code. Pourquoi la Licence le préciserait ?
"nuire" à l'oeuvre ? Ça veut dire quoi ? Mauvaise image, concurrence commerciale ? Dans les contrats de certains logiciels Microsoft on a vu passer des clauses du style "interdit d'utiliser ce logiciel pour en publier des benchmarks". J'espère que tu prends pas cette voie...
Quand à l'interdiction de vendre, c'est clairement du Pas Libre du tout.
Cette restriction sur la vente se retrouve dans d'autres articles, que je ne remets pas.
Imagine LinuxMag qui fournit un CD dans son magazine. Ils peuvent y mettre tous les logiciels libres qu'ils veulent. Inclure un logiciel avec cette licence, est-ce considéré comme de la "vente à un prix excédent le prix du média" ? Ils ne prendront pas le risque.
Incompatible avec les "4 Libertés Fondamentales": Un logiciel libre, on a le droit de le redistribuer, point. Peu importe qu'on l'ait obtenu gratuitement, contre un bière, ou pour 1000$.
Il y a encore d'autre clauses bizarres, mais à ce stade là j'ai arreté de regarder.
Pour moi, cette licence n'est pas libre.
[^] # Re: pango
Posté par daggett . En réponse au journal Pango. Évalué à 2.
> Ça tu l'inventes. C'est un troll sans fondement.
Lancement d'une compile dans un xterm: 1h. La meme dans un gnome-terminal: 2h; à cause de la lenteur d'affichage des sorties de Make et gcc en antialiasé et tout. C'est sans fondement ça ?
(durées à 10 minutes près, d'après mes souvenirs d'il y a 1 an; je ne sais pas si il y avait pango à cette époque, ou si c'etait bloated dès le départ)
[^] # Re: OS et machines hétérogènes
Posté par daggett . En réponse à la dépêche Sortie de la version 1.0.0 de Kerrighed. Évalué à 2.