jihele a écrit 1228 commentaires

Les codes source du logiciel et les spécifications du matériel sont sous GPL.

Je ne me souviens plus si j'ai écrit ceci ou bien si ça fait partie de l'édition à la modération. En tout cas si ce n'est pas moi, je suis fautif car j'aurais du spécifier la licence.

Les licences sont précisées sur cette page. Le logiciel est sous GPL v3 et le matériel sous Creative Commons Attribution-ShareAlike 3.0.

Je ne crois pas que le choix des licences ait fait l'objet d'une réflexion poussée. La volonté était de faire du libre, point. Par exemple, la GPL v3 a du être choisie (plutôt que la v2) parce que c'est la dernière version.

En effet. Je ne sais pas où ça en est maintenant, mais il y a un an, je développais (pour bricoler) une petit application python /GTK (cf. journal) et je suis passé de pygtk à PyGObject.

Ça ne s'est pas fait sans mal parce que pygtk a été considéré comme déprécié alors que la doc de PyGObject n'était pas du tout au point. Et lorsque j'ai évoqué le sujet sur la trollinmailing-list, on m'a répondu qu'il fallait que je l'écrive si elle était incomplète…

Ceci dit, c'est clair que l'introspection est une excellente idée et un effort utile pour l'avenir.

Un autre bon point pour Qt, c'est le portage Windows. Côté Gtk, la dernière fois que j'ai regardé, il y a un an, c'était abandonné.

Je suis utilisateur de Xfce dont plutôt Gtk, mais entre les difficultés que j'ai éprouvées, mes lectures ici et autres conversations, si je devais partir de zéro demain, je pourrais m'orienter vers Qt. Tout ça m'inquiète d'ailleurs un peu pour l'avenir de Xfce.

Bah rien, DRM ou pas DRM si tu affiches un media sur l'écran de ton ordinateur il est fatalement enregistrable d'une manière ou d'une autre.

Dans le cas d'un téléphone, je n'ai pas trop de mal à imaginer un flux décodage DRM matériel -> carte graphique -> écran qui ne passe pas par du logiciel, ce qui me paraissait assez inconcevable avec les PC de bureau (puisqu'il faut bien passer par VGA/DVI/HDMI et il faudrait des écrans "complices").

Je ne vois pas comment introduire un DRM sans que ça nécessite du code obfusqué à un endroit. Il y a peut-être une réponse sur la dépêche de la pétition, je n'ai pas lu tous les commentaires.

Admettons que l'idée est de "protéger" une vidéo. S'il est possible de la lire avec un logiciel libre grâce à une clé telle que tu la décris, alors qu'est-ce qui empêche d'enregistrer la vidéo ?

L'engouement pour le flash (mis à part l'aspect pratique quand il n'y avais pas d'alternative) c'était ça : le lecteur n'est pas sous contrôle de l'utilisateur. Certes ont peut toujours agir en aval (screencast), d'où l'idée d'obfusquer le canal jusqu'à l'écran (informatique de confiance) avec des cartes graphiques et écrans complices. On pourra toujours filmer l'écran…

En général, faute de pouvoir rendre la copie impossible, les lobbies poussent pour la rendre compliquée, et ça suffit puisque pour l'immense majorité des gens, compliqué, c'est impossible. Même installer l'extension firefox qui fait le boulot peut être une barrière. Surtout si le prix à payer pour accéder au contenu n'est pas jugé élevé : un peu de pub, quelques ralentissements à cause de streaming.

Dans ce contexte, c'est pas simple de discuter technique puisque leur objectif n'est pas de faire quelque chose de propre et logique, mais un truc techniquement bancal qui ralentira une évolution qui ne leur plaît pas. Il leur suffit d'avoir toujours une longueur d'avance sur les outils de rip de vidéo, par exemple, même si c'est impossible de faire un truc propre véritablement sécurisé.

J'ai bon ou j'ai raté un épisode ?

J'ai jamais compris ce qui empêchait de faire des ordis de bureau qui consommerait la même chose que des portables. Il suffit de mettre le même matériel, la contrainte de place en moins. Ça serait trop cher et pour le même prix les clients préfèreraient un portable ?

Ça me fait toujours un peu tiquer de voir des présentations de bâtiments HQE et compagnie où on met en avant l'utilisation d'ordinateurs portables au titre d'économie d'énergie alors que c'est moins évolutif dans le temps, et au final le bilan est peut-être pas meilleur.

Pourquoi pas des PC de bureau économes ?

(Une réponse partielle pourrait être que de toute façon les gens ont besoin d'un portable…, mais c'est le fait de présenter ça comme une mesure de sobriété énergétique qui me gêne.)

Il est évident que c'est lui qui ne mentionne pas la distribution pour éviter le troll, pas l'article original !

Pour quelqu'un qui ne connaissait pas l'auteur, c'était pas évident, d'autant que sa tournure est un peu maladroite.

Maintenant, je le connais…

Heureusement que tu es intervenu pour y mettre un terme.

Pour éviter un troll la distribution n'a pas été mentionnée. Mais bon, Linux reste Linux

Alors soit tu as mal lu, soit c'est moi qui ai lu beaucoup trop en diagonale, mais je vois 13 occurrences de "Suse" dans l'article dont une dans le titre : "Asia’s oldest stock exchange has saved huge costs by deploying SUSE Linux for powering a majority of its applications"

De toute façon, dès lors qu'il y a pas écrit GNU/Linux, il reste matière à débat. On pourra en reparler demain.

Effectivement, ça n'est pas prévu pour tous les modèles.

        def system_info(self):
            '''
            Do a check if the notebook is a m1730 or not.
            Then adjust the labels to the correct model.
            '''

            info = self.xpslc.SystemInfo()
            # m1730 = MXG071
            # m1710 = MXG061
            # Other = ??? (Use same labels as m1710)
            if "MXG071" in info:
                print "Found the XPS m1730, setting correct labels..."
                self.labelFans.set_label("Touchpad")
                self.labelSpeakers.set_label("Speaker (Left)")
                self.labelBack.set_label("Speaker (Right)")
                self.labelTouchpad.set_label("Backpanel")
            else:
                print "Found an other model than the XPS m1730, setting correct labels..."
                self.labelFans.set_label("Fans")
                self.labelSpeakers.set_label("Speakers")
                self.labelBack.set_label("Backpanel")
                self.labelTouchpad.set_label("Touchpad")

Rhaaa, c'est malin. Maintenant, je suis tenté d'essayer d'ajouter le mien…

A noter que le truc dépend de libsmbios et libsmbios-bin. Ils sont appelés directement mais apparemment des bindings sont disponibles dans le dépôt experimental de debian.

Merci ! Je regarderai. Curieux que tout ces logiciels ne me soient pas apparus il y a un an lorsque je cherchais.

Merci pour le pointeur. Quelques infos ici :
http://doc.ubuntu-fr.org/alienfx

Notamment un pointeur vers un programme en python :
https://code.google.com/p/pyalienfx/

Pas sûr que ça fonctionne tel quel pour mon XPS, ni même que ça s'adapte, mais c'est fait pour Alienware, qui est quand même le sujet du journal au départ…

Bonne question.

J'ai une machine DELL (XPS 630i) et pour allumer/éteindre/choisir la couleur des diodes, il faut un utilitaire windows. Je ne crois même pas qu'il y ait de paramétrage BIOS. Donc c'est toujours allumé pour rien. Et c'est un sacré bordel à démonter, donc j'ai laissé tomber l'idée de les débrancher.

Je n'ai pas essayé de faire tourner l'utilitaire windows sous wine. Ni de hacker quoi que ce soit. Je suis un peu surpris en revanche de ne pas avoir trouvé de trace d'un projet visant à faire ça. Peut-être serait-il possible de tracer ce que fait le truc windows pour "l'ingénierie-inverser".

Voilà, je viens de trouver mon vieux message de forum :

https://linuxfr.org/forums/general-general/posts/nvidia-esa-enthusiast-system-architecture-linux

Le protocole qui sert à dialoguer avec les diodes sur mon PC est ESA (Enthusiast System Architecture), de nVidia. Je viens de regarder vite fait et je n'ai pas trouvé si c'était pareil sur le Alienware X51.

Donc à Yakuake fixé, Debian > Arch. Et par extension…

CQFD

bref ce sondage me parait inutile, surtout sous sa forme.

Il manque donc l'option

[] J'ai bien vu les boutons pertinent / inutile mais ça va mieux en le disant.

Mais ne le répétez pas.

Je connaissais pas la journée de la serviette ! A Brive ça doit être une institution, comme la journée de la sardine.

Tu as tort.

Euh, bah sous debian c'est au moins une fois par semaine, et de temps en temps tous les jours, donc bon.

Certes, mais c'est une seule interface pour toutes les mises à jour, pas chaque logiciel qui a son icône dans la zone de notification et qui lance son interface de mise à jour qui déclenche une alerte pare-feu et une alerte anti-virus, et qui te demande (en cochant oui par défaut) si tu veux la version payante et la barre de recherche.

Le problème, c'est pas les mises à jour (en tout cas dans sa phrase, car ça peut l'être pour certains par ailleurs), c'est ceux qui les font.

Pas de ramage sur ici (PC du boulot, Windows 7). Mais ça écrit "des plugins sont nécessaires", alors j'ai cliqué pour voir et il me demande le plugin flash.

Faut-il chercher plus loin ?

Oui, ça, par exemple. C'est du KDE, je suppose.

Possible que j'aie la même chose avec un Xfce récent.

Possible que j'avais pas ça dans les clickodromes GTK parce que le touchpad n'est ou n'était pas reconnu comme il fallait, mais que la fonctionnalité existe pourtant. Si c'est le cas, je serais curieux de savoir pourquoi.

A l'occasion je réessaierai. Merci pour la capture d'écran.

Oui, je comprends bien l'idée des options par défaut. Et je ne voudrais surtout pas être de ceux qui veulent à tout prix que leur config soit celle par défaut.

Néanmoins, on est d'accord que l'idéal serait que le matériel soit prix en charge correctement dès l'installation. Ça veut dire pouvoir installer une distro grand public et poupouf, les touches Fn qui fonctionnent, le touchpad qui fonctionne tout de suite avec une config consensuelle (scrolling qui marche, on peut discuter pour l'activation du clic) et qui se paramètre facilement pour le reste (pas en créant un fichier dans xorg.conf.d).

Ça veut pas dire activer n'importe quelle option au démarrage sur toutes les configs. L'installeur pourrait reconnaître le matériel. Est-ce que certains matériels sont mal reconnus parce que les fabricants font n'importe quoi avec les numéros de série ? Je sais pas. Je n'ai pas de mal à imaginer un paquet ou un script post-install propre à chaque machine, qui automatiserait les choses présentées par exemple sur la page DebianOn du bouzin. En gros. Je veux dire, si le problème est identifié, et si on a la correction, on doit pouvoir automatiser celle-ci.

Finalement, mon exemple était pourri parce que cette option proto=imps" était précisément celle qui mettait la merde, et la bonne config peut se faire avec synclient. En réalité, mon problème se limitait à l'absence d'une interface de config. Et encore, c'est peut-être juste que je l'ai pas trouvée. J'ai pourtant essayé l'interface Xfce et celle de Gnome. (Peut-être que ça marche mieux chez KDE ?…)

Concernant le développement d'une telle interface, ce serait me mentir que de croire que je ferai quelque chose. C'est bien trop loin dans ma liste de priorités. De plus, je partirais sans doute de la config souris de Xfce (à la limite de gpointing-device-settings de Gnome), et pour cela il faudrait que j'utilise une version récente (pas forcément simple sous debian, enfin ça veut probablement dire se recompiler tout Xfce et tout juste pour ça…), que je rentre dans le projet, ce qui est très bien, mais je pense que les devs qui sont déjà dedans sont bien plus efficaces que moi pour ça ("Faire c'que d'autres font mieux que moi, ça me rend malade" - Con et blasé - Les Ogres de Barback).

Je me dis même que si c'était simple au point que je puisse le faire, ça serait déjà fait. Donc je me vois plus (TODO) aller sur le forum demander pourquoi ça existe pas encore, si c'est prévu, etc. A la limite faire des propositions constructives, voire filer un coup de main de test.

Bon, je sais que c'est pas l'endroit, mais si quelqu'un tombe sur ma question, autant qu'il y trouve une réponse.

Il se trouve que c'est précisément "options psmouse proto=imps" qui m'empêchait (je ne sais pas pourquoi) d'utiliser synclient.

Je l'ai virée, et je peux tout configurer (y compris le clic) via synclient.

Les bonnes nouvelles c'est que le coloc va garder son linux encore au moins quelques temps, et que j'ai découvert les joies du Touchpad, que je n'avais jamais pris la peine de configurer sur mon propre PC.

La mauvaise, c'est que pour que tout ça soit prêt pour le bureau, il faudrait au minimum une belle GUI pour configurer tout ça, et ce que j'ai vu n'était pas top fonctionnel.

Notes pour plus tard :
- Remonter le problème quelque part
- Se pencher sur la question d'une GUI (compléter l'existant). Je pense que si c'était trivial, ça existerait déjà. D'ailleurs il est probable que Xfce 4.10 améliore ça, mais Debian est coincée à 4.8, c'est ballot.

Au passage, merci pour les conseils.

Ça n'est clairement pas fait pour un RPi…

D'accord. C'était un peu l'objet de mon commentaire.

Tu peux réduire de beaucoup le temps d'exécution en jouant avec les variables LP_ENABLE_* ou en virant des fonctionnalités dans ton propre LP_PS1 (cf. la doc).

OK, merci. Si j'ai le temps et si j'en ressens le besoin, j'y regarderai.

A vue de nez, en désactivant la prise en charge des gestionnaires de version, ça fait comme quand je suis dans un répertoire non versionné, à savoir que c'est plus rapide, mais quand même pas instantané comme quand je n'utilise pas liquidprompt.

Le RPi c'est pas une foudre de guerre, il faut bien le reconnaître.

Je viens d'essayer (pour la première fois, donc je ne peux pas comparer) sur un Raspberry Pi, avec la config par défaut et c'est un poil lourdeau. Je dois bien mettre une demi-seconde à récupérer le curseur lorsque j'envoie une commande vide (juste "entrée") dans un dépôt git. C'est moins lent lorsque je suis hors du dépôt git, mais pas instantané.

C'est sympa d'avoir certaines infos (branche) mais en effet ça fait une ligne super longue. Trop, je trouve.

J'ai conscience que ceci est juste un retour sur la config par défaut. Je n'ai pas essayé de la modifier.