Mildred a écrit 2245 commentaires

En même temps, chrome même si propriétaire dispose d'une version libre, chromium.

Les utilisateurs de gentoo seraient-il sauvés. Théoriquement, ils sont le seul utilisateur du logiciel qu'ils ont compilé eux même.

La ligature dynamique ne résout rien du tout, le code pour le décodage du flux est embarqué dans le processus du navigateur ce qui en fait un lecteur. On croirait entendre les mecs qui croient qu'avec la ligature dynamique, ils sont libérés des contraintes de la GPL.

Je pense que je peux très bien faire un dlopen sur une bibliothèque et un dlsym sur une fonction, et distribuer le tout dans une autre licence que la GPL sans être en infraction. C'est similaire à faire un fork()+exec() sur un processus GPL..

Là où la GPL peut se propager c'est lors de la liaison des bibliothèques à la compilation. Les codecs (plugins) gstreamer ne sont pas dans ce cas de figure. ils suivent un protocole commun à tous les plugins gstreamer qui permet à gstreamer de faire un dlopen()+dlsym() dessus de manière standard.
C'est le principe des plugins, un chargement à l'exécution uniquement.


De même, je ne vois aucune raison pour qu'un navigateur web qui passe simplement le flux vidéo (sans regarder son format probablement) à gstreamer peut être en infraction. De même, je vois mal un lecteur multimedia en infraction pour utiliser les codecs Fluendo, même si le player n'est pas licencié mais juste les codecs.

Essayons de raisonner par l'absurde. Imaginons un coder XYZ soumis à licence. Imaginons un codec C1 pour gstreamer non licencié et un codec C2 licencié. Le lecteur multimédia n'a jamais entendu parler de XYZ, cependant via gstreamer et un des codecs C1 ou C2 il peux lire ce format. Si le lecteur multimédia était en infraction vis à vis de XYZ cela veut dire que toute application utilisant gstreamer (ou gestionnaire de codecs similaire) doit obligatoirement s'acquitter de toutes les licences sur tous les formats possibles et imaginables, passés ou futurs. Impossible en réalité.

En effet, mon lecteur multimédia gstreamer datant d'il y a 5 ans n'a pas pu s'acquitter de la licence XYZ, car ce format n'était pas encore inventé. Pourtant il peut décoder du XYZ si le codec C1 ou C2 est présent sur le système.

Il est beaucoup plus probable que ce soit le codec C1 qui soit en infraction (dans la mesure où les brevets logiciels existent dans la zone de marché visée par C1).

je ne sais pas si vous avez remarqué, mais il y a déjà beaucoup de serveurs qui utilisent zeroconf, essayez de démarrer avahi-discover. Chez moi j'ai:

- Serveur VNC (de GNOME)
- Serveur WebDAV (Apache sans doute)
- Serveur Web (Apache)
- SSH Daemon
- MPD (Music Player Daemon)
- iChat (Telepathy)
- libvirt (un truc Fedora)

J'imagine mal une machine linux qui n'utilise pas du tout avahi, et je ne pense pas que avahi ait plein de dépendances. En tout cas, je ne pense pas que l'installation d'Apache me fasse installer mono ou Abiword.

A mon avis c'est un serveur maison.
Il me semble même qu'au début le s2s (server to server) n'était pas implémenté.

Ceci dit je n'en sais rien. Mais ça me semble bien dans leur façon de faire.

Je ne suis pas sur que Python puisse permettre de faire tout ce que fait Ruby.

Je crois qu'il y a quelque chose que Ruby peut faire de base, mais que python ne peux pas (sauf avec PyPy ou d'autres, mais qui ne sont pas encore matures) c'est l'exécution d'un script d'origine non authentifiée dans un environnement restreint.

Et je trouve que c'est important quand même. Ça permet entre autre de pouvoir utiliser des scripts python sur le web (comme JavaScript) ou pour d'autres usages similaires.

Tu peux configurer chromium pour qu'il utilise le window manager:
Options -> Personnal Stuff -> Apparence -> Use system title bar and borders

(c'est pareil, j'ai le bouton pour fermer la fenêtre à gauche, pas à droite)

¥ chez moi c'est sur alt-shift-$
La touche $ possédant aussi * et €

Bon, c'est sur Linux, mais avec le layout mac alors ça doit être ça.

Donner des détails sur les drivers et la version de certains logiciels peut être intéressant aussi. En particulier pour les drivers vidéo et la version de Xorg.

On peut aussi parler de l'intégration des technologies freedesktop, PackageKit, DeviceKit, PolicyKit et les autres Kit qui se sont multipliés ces derniers temps.

J'utilise Fedora et je dois dire que j'apprécie vraiment. Je pense que pour un poste de bureau chez un particulier c'est la meilleure solution. Fedora cherche à intégrer les dernières nouveautés, et par conséquent les derniers drivers. Il me semble que c'est plus adapté qu'une RedHat (ou CentOS, je ne sais pas trop) qui ne sont pas si souvent à jour.

Et malgré tout ça, je trouve qu'il y a très peu de bugs par rapport à d'autres distributions que j'ai utilisé. J'apprécie beaucoup le travail de finition apporté à cette distribution.

Et si tu as peur de ne pas pouvoir écouter du MP3 (parce que c'est breveté dans certains pays), RPMFusion permet d'avoir tout ce qui manque.

Sauf qu'installer apache et rediriger le port 80 pour héberger son site perso, ça a l'air super compliqué, coûteux en électricité et tout et tout. Dès qu'il s'agit d'installer eMule, de rediriger un port TCP et un autre UDP, et de laisser tourner la babasse toute la nuit, ce ne sont plus des obstacles.

Sauf qu'installer un serveur web est beaucoup plus contraignant. Si ton client P2P est en rade, tu perd ta connexion internet, le portable sur lequel il tourne se met en veille ... le contenu pourra toujours se trouver chez d'autres nœuds P2P.

Si ton serveur http tombe en rade (panne de connexion, électrique, ...) les personnes qui s'y connecte ne vont pas pouvoir accéder au contenu. Au final, un serveur http chez soi est beaucoup plus contraignant.

Sinon, l'auteur de ce post propose un repository chromium:
http://rajaseelan.com/2009/07/04/how-to-install-google-chrom(...)

Rajoutez juste dans /etc/yum.repos.d/chromium.repo

[chromium]
name=Chromium Test Packages
baseurl=http://spot.fedorapeople.org/chromium/F$releasever/
enabled=1
gpgcheck=0

Et puis installez le avec yum install chromium

http://spot.livejournal.com/312320.html

Cet article explique en détail pourquoi Chromium n'est pas dans les dépôts de base Fedra, et c'est intéressant. Il explique en particulier que Chromium ne cherche pas a améliorer les bibliothèques qu'il utilise et à faire remonter les changements upstream, et qu'ils préfèrent embarquer des versions modifiées de ces bibliothèques. Un peu comme debian quoi.

Google is forking existing FOSS code bits for Chromium like a rabbit makes babies: frequently, and usually, without much thought. Rather than leverage the existing APIs from upstream projects like icu, libjingle, and sqlite (just to name a few), they simply fork a point in time of that code and hack their API to shreds for chromium to use. This is akin to much of the Java methodology, which I can sum up as "I'd like to use this third-party code, but my application is too special to use it as is, so I covered it with Bedazzler Jewels and Neon Underlighting, then bury my blinged out copy in my application.". A fair amount of the upstream Chromium devs seem to have Java backgrounds, which may explain this behavior, but it does not excuse it. This behavior should be a last resort, not a first instinct.

Parmi les arguments que tu avances, la plupart sont incorrects :
- le webmail que j'utilise me permet de sauvegarder mes emails sur un disque local, et je ne m'en prive pas
- le webmail que j'utilise ne charge pas les images dans les mails en HTML et, au passage, le filtre antispam du webmail que j'utilise fait partie des plus efficace que j'ai rencontré
Mais l'argument préféré est "etc". Imparable !

Tu peux m'expliquer comment avec un webmail tu peux archiver tes e-mails en local. Je ne parle pas de sauvegarder les e-mails un par un, mais de tous les avoir en local, sans avoir peur de les perdre.

La recherche sur 2GB de mails est immédiate, mais le fichier d'index doit peser au moins 1GB, non ?

J'ai 2.4GB de mails avec une base de donnée de 1.9GB. Et je dois dire que ma partition /home a tout de suite vu passer Thunderbird 3. J'ai du faire de la place.

J'adore les clients lourds par contre. On a un accès offline et on sait exactement où sont nos e-mails. On m'a dit dernièrement que GMail pouvait aussi fonctionner offline. Peut être, mais mes mails sont stockés dans un cache. Un cache, c'est transitoire par définition.

Et en plus, l'application GMail n'est pas libre.
Pourtant, j'aime bien l'ergonomie. Si il existait un client lourd ayant la même présentation que GMail, je l'utiliserait tout de suite.

Ça donnerait un code comme ça je pense (reste à tester) :


static void make_skip_input (GtkWidget *widget)
{
GtkAllocation allocation;
GdkBitmap *mask;

gtk_widget_get_allocation (widget, &allocation);
mask = gdk_pixmap_new (gtk_widget_get_window (widget),
allocation.width,
allocation.height,
1);

/* make the whole window ignore events */
gdk_window_input_shape_combine_mask (gtk_widget_get_window (widget), mask, 0, 0);
g_object_unref (mask);
}

http://git.gnome.org/cgit/gnome-settings-daemon/tree/plugins(...) (fonction gsd_media_keys_window_real_realize)

A mon avis, tu ajoute la ligne manquante dans ce fichier, toute seule, et ça devrait marcher.

Des raisons simples en premier:
- les applications natives fonctionnent déconnectées d'Internet
- les applications natives peuvent être compilées en code machine et ne sont pas obligées d'être interprétées comme Javascript
- les applications natives peuvent être libres. on peut modifier le code source et exécuter l'application modifiée. Pour une application web, on a pas accès au serveur.

maintenant, les applications web ont aussi des avantages, come par exemple le fait qu'elles soient confinées au navigateur. Elle ne peux pas faire n'importe quoi sur mon ordinateur, et c'est rassurant.

La meilleure évolution que je puisse voir c'est d'avoir des applications qu'on puisse télécharger et qui soient portables. C'est la voie qui est prise par Google Gears il me semble, mais il faudrait faire un pas de plus et réformer le HTML (et peut être le Javascript aussi, ou en tout cas proposer d'autres langages). Le HTML n'est pas prévu pour des applications (je pense de plus en plus que l'introduction des formulaires dans HTML était une mauvaise idée).

Et si en prime, les applications téléchargées par Google Gear sont libres, et qu'on peut remplacer la version du cache par sa propre version, je crois que ça commencera a me plaire.

Et je connais des gens qui ne comprennent pas le concept du copier/coller ...

Sauf que ce n'est pas une fenêtre existante (navigateur) qui change de taille, mais une nouvelle fenêtre qui s'ouvre et qui conserve accessoirement la taille et position qu'elle avait avant.

Du coup ça fait sens.

Et pourquoi pas ? Rien ne leur empêche d'essayer de vendre la musique des majors sans DRM. Amazon et iTunes le font bien (enfin je pense, Amazon c'est du MP3 — je préfèrerais un meilleur format — et iTunes a enlevé ses DRM il y a un certain temps je crois)

Il me semblait que les DRM sur la musique c'était obsolète ...

En tout cas, ce 'bug' m'a sauvé mon upgrade Fedora 11 -> rawhide (Fedora 12 beta).

J'avais un conflit sur une dépendance de sudo (je ne le savais pas) et je l'ai temporairement désinstallée pour la réinstaller plus tard. le seul problème, je n'avais aucune console root ouverte et travaillait avec des commandes "sudo yum ..."

Bien sûr, le sudo suivant a échoué.
su ne marchait pas non plus
login, et les consoles texte, ne pas en parler

J'ai finalement pu créer un paquet RPM avec les fichiers qui manquaient (téléchargés de rpmfind.net) et l'ai installé en utilisant PackageKit.

Et sudo fonctionnait a nouveau :)

Ce que j'aime bien c'est le fait qu'une fenêtre représente un dossier. Sa taille et son emplacement à l'écran est sauvegardée en fonction du dossier. Cela permet pour certains dossier qui n'ont que deux éléments d'avoir une fenêtre petite, et pour les gros dossiers d'avoir une grosse fenêtre.

Maintenant, je n'aime pas travailler avec les fenêtres en plein écran. souvent, je vais chercher les fenêtres sous les autres au lieu d'utiliser la barre des tâches. Et j'utilise beaucoup le glisser-déposer. Pouvoir placer plusieurs fenêtres est primordial.

Et maintenant, pour aller plus vite dans la navigation des dossiers, j'ai trois choix:
- les bookmarks
- Le Ctrl-L qui permet de saisir un chemin (avec auto complétion)
- lancer nautilus depuis un terminal (avec F12 je vois le dossier courant, zsh peut faire ça)

Pour limiter le nombre de fenêtres à l'écran, j'utilise le clic-milieu pour ouvrir les dossiers. Et comme ça je peux choisir ce que je garde et ce que je ferme très facilement.


A vrai dire, je suppose que c'est plus une question d'habitude. J'ai commencé avec MacOS 7 qui avait ce comportement. Je n'ai presque jamais utilisé le copier/coller sur les fichiers par exemple alors que je vois que pour beaucoup c'est presque l'unique manière de copier ou déplacer des fichiers.

Et enfin, je n'aime pas naviguer dans l'arborescence. Lorsque j'ai trouvé le dossier que je veux, soit je laisse une fenêtre, soit un terminal ouvert dans ce dossier. Je navigue dans les dossiers au début de ma session de travail, et ensuite c'est fini.

Je n'aime tellement pas naviguer dans les fichiers que souvent, pour la boîte de dialogue ouvrir/enregistrer-sous de GNOME, je fais un glisser déplacer du dossier que je veux au milieu de la boîte de dialogue, et ça m'amène directement au dossier que je veux. Et lorsque j'ai une application KDE qui ne fonctionne pas comme ça, (je suis obligée de naviguer dans les dossiers), je n'aime pas du tout.

Mais je me débrouille pour que ça n'arrive pas, j'ouvre à partir du dossier (et non pas fichier->ouvrir), je crée le document avec nautilus en copiant un template (~/Templates) et j'enregistre dans le même fichier (ou un autre fichier dans le même répertoire).


J'espère que ça t'éclaire sur d'autres habitudes de fonctionner

Le catalogue Jamendo et iTunes Store n'est pas le même non plus. Je ne dis pas qu'un est meilleur que l'autre, mais que le choix est restreint.

En l'occurrence, ce choix par défait est mon choix par défaut aussi alors ... La seule chose que je peux dire c'est que les avis divergent, et que de toute façon, l'un a-ou l'autre fera des mécontents. Et des contents (dont je fais partie :)