Maderios a écrit 1975 commentaires

Tu te casses les dents parce que tu procèdes à l'envers. Ton expérience n'a pu te faire prendre connaissance de ce qu'est réellement un système GNU/Linux. Commence par installer sur ton PC une distribution genre Mint ou même Debian (bien meilleure et pas si difficile que cela) , utilise là réellement puis passe à un truc plus compliqué en te servant de ce que tu as appris. En général, on progresse aisément du plus facile au plus difficile, rarement l'inverse. Fais le, cela en vaut la peine.

C'est peut-être l'usb qui change intempestivement de périphérique. Par exemple la clé montée en /dev/sdb1 passe en /dev/sdc1, etc… J'ai déjà rencontré ce problème avec un disque externe, clé usb, etc, qui ne cessaient de changer de /dev/*, en pleine sauvegarde par exemple. J'étais persuadé que mon matériel était en cause, jusqu'au jour où j'ai désinstallé les paquets usbmount, udisks, etc, bref, tous les trucs censés monter automatiquement l'usb. Le problème a été résolu.

J'ai écrit ci-dessus "jamais cessé de tourner" et j'avoue avoir forcé le trait. En fait, je démarre un PC le matin et je l'arrête le soir. Idem pour le/les DD externes, quoique ces derniers ne sont pas démarrés tous les jours. Je voulais simplement dire que redémarrer un DD plusieurs fois par jour use certainement plus le disque que de le laisser tourner sans arrêt pendant la journée. C'est le démarrage qui sollicite le plus la mécanique du DD et non sa rotation régulière. J'écris actuellement sur un portable acheté il y a 9 ans, disque dur ide d'origine qui se porte comme un charme et qui tourne en continu 12h/j. J'ai connu des gens dont les DD réglés en mode "économie d'énergie" (leurs PC ne cessaient de s'arrêter) ont rendu l'âme en moins de 3 ans. Fabriquer, transporter, remplacer un DD demande énormément d'énergie donc cette méthode d'économie n'a guère de sens, sinon tromper l'utilisateur. Concernant la consommation d'électricité, c'est l'alimentation du DD qui tire sur le réseau EDF et non le DD lui-même, soit entre 12w/h et 20w/h, ce qui est peu comparé à l'alim ou à l'onduleur d'un PC tour (5OO, 600w et plus). La palme de l'économie d'énergie revient à la formule PC portable + DD externe, soit + ou - 30w+20w=50w, consommation environ 10 fois inférieure à celle d'un PC tour. Évidemment, on ne fait pas le même boulot avec…

Ouf!

On trouve pas mal de doc sur les listes enlightenment mais il faut avoir le temps de lire et de filtrer…
http://sourceforge.net/p/enlightenment/mailman/enlightenment-users/
Par ailleurs, on peut obtenir des info pointues sur la liste enlightenment-users. Le dev principal, Carsten Haitzler y répond assez souvent.

E17, 18 et 19 font également du pavage. On peut donc avoir un Terminology splité à l'intérieur d'un bureau pavé…

j'aurais aimé trouver mention des options dans le man, ainsi que dans quels fichiers les placer

C'est le pb avec les E17 et suivants, le manque de documentations. Ce sont des environnements jeunes basés sur des EFL jeunes, cela peut donc s'améliorer.

En sachant qu'en compilant un noyau maison on y gagne quand le matériel est poussif.
https://www.debian.org/releases/wheezy/

ils ont retiré la photo,
le dossier est clos

Pas tout à fait. Ils ont recadré la photo mais comme cette photo est une vue banale, difficile de prouver que cette photo recadrée ne vient pas d'ailleurs. La moindre des choses serait qu'ils mentionnent le nom de l'auteur de la photo recadrée, mais dans ce cas, ils avoueraient le non-respect du droit d'auteur…

J'utilise Terminology (avec E17 sur un vieux portable poussif) en tant que terminal de base, sans chercher à afficher des video ou des images. J'active le split (de terminology) , ce qui m'évite des terminaux ouverts dans tous les coins.
Rectification: concernant l'opengl et E17, on peut l'activer ou le désactiver à n'importe quel moment sur la boite de dialogue (rendering) d'Elementary.

après il a sauté

Pourquoi? Tu as utilisé un Terminology packagé par quelle distribution? Les paquets fournis ne sont pas toujours au top. Sur des Debian Sid et Jessie, je n'utilise pas les paquets officiels, j'ai compilé les sources de Terminology, cela marche bien mieux.

Pas besoin d'accélération 3D pour utiliser E17 et Terminology. C'est à configurer lors du premier lancement de E17.

J'utilise E17 depuis pas mal de temps. C'est très réactif et très peu gourmand en ressources. Idem pour son terminal, Terminology, qui vient d'ailleurs de sortir en version 0.8
https://www.enlightenment.org/p.php?p=download&l=en

Le problème est résolu. Les changements sont mentionnés à la fin du post. Merci à tous ceux qui, ici et ailleurs, m'ont aidé à corriger les erreurs.

J'ai désactivé le bridge sur le lan

config interface 'lan'
option force_link '1'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '192.168.2.4'
option orig_ifname 'eth0.1 radio0.network1 radio1.network1'
option _origbridge 'true'
option mtu '1492'
option ifname 'eth0.1'

La connection internet depuis le lan ne marche pas sauf en tant que root@OpenWrt. Dans ce cas je peux pinguer les hosts, installer les softwares OpenWrt depuis Luci ou la console.

Ma box est une Livebox 3 Sagem de base louée chez Orange, n'offrant aucun mode bridge (contrairement à la freebox parait-il) et aucune possibilité de paramétrer un routage.

Effectivement, l'ip de la gateway coté machine client est bien celle du lan, erreur grossière réparée ce matin…
J'ai fait des modifications sur la route, ajouté un SNAT, les DNS du serveur Orange, ajusté à la MTU à 1492 (1500 n'a jamais fonctionné chez moi). Fait étrange, à partir de l'interface graphique Luci de Openwrt, ping, traceroute et nslookup fonctionnent normalement alors qu'aucune connection à la livebox ou au web n'est possible depuis une console ou le navigateur.
Bizarre encore: je peux me connecter à l'interface de Openwrt coté wan http://192.168.1.19/cgi-bin/luci/

Les nouveaux paramètres:

#Openwrt /etc/config/network
config interface 'loopback'
    option ifname 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config globals 'globals'

config interface 'lan'
    option force_link '1'
    option type 'bridge'
    option proto 'static'
    option netmask '255.255.255.0'
    option ip6assign '60'
    option ipaddr '192.168.2.4'
    option _orig_ifname 'eth0.1 radio0.network1 radio1.network1'
    option _orig_bridge 'true'
    option ifname 'eth0.1 eth0.2'
    option mtu '1492'

config interface 'wan'
    option _orig_ifname 'eth0.2'
    option _orig_bridge 'false'
    option proto 'static'
    option netmask '255.255.255.0'
    option ifname 'eth0.2'
    option gateway '192.168.1.1'
    option ipaddr '192.168.1.19'
    option mtu '1492'
    option dns '81.253.149.9 80.10.246.1'

config switch
    option name 'switch0'
    option reset '1'
    option enable_vlan '1'

config switch_vlan
    option device 'switch0'
    option vlan '1'
    option ports '0t 1t 2 3 4 5'
    option vid '1'

config switch_vlan
    option device 'switch0'
    option vlan '2'
    option ports '0t 1'
    option vid '2'

config route
    option interface 'wan'
    option gateway '192.168.1.1'
    option target '0.0.0.0'
    option netmask '0.0.0.0'

#Openwrt /etc/config/firewall

config rule
    option target 'ACCEPT'
    option src 'wan'
    option proto 'tcp'
    option dest_port '80'
    option name 'http'
    option dest 'lan'
    option src_port '80'
    option dest_ip '192.168.2.4'

config rule
    option target 'ACCEPT'
    option src 'wan'
    option proto 'tcp'
    option dest_port '443'
    option name 'https'
    option dest 'lan'
    option src_port '443'
    option dest_ip '192.168.2.4'

config rule
    option name 'Allow-Ping'
    option src 'wan'
    option proto 'icmp'
    option icmp_type 'echo-request'
    option family 'ipv4'
    option target 'ACCEPT'
    option enabled '0'

config defaults
    option syn_flood '1'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'

config zone
    option name 'lan'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option mtu_fix '1'
    option network 'lan'
    option masq '1'
    option forward 'ACCEPT'

config zone
    option name 'wan'
    option output 'ACCEPT'
    option mtu_fix '1'
    option input 'ACCEPT'
    option forward 'ACCEPT'
    option network 'wan'

config include
    option path '/etc/firewall.user'

config redirect
    option target 'DNAT'
    option src 'wan'
    option proto 'tcp'
    option dest_port '80'
    option name 'http'
    option src_port '80'
    option dest 'lan'
    option dest_ip '192.168.2.4'

config redirect
    option target 'DNAT'
    option src 'wan'
    option proto 'tcp'
    option dest_port '443'
    option name 'https'
    option src_port '443'
    option dest 'lan'
    option dest_ip '192.168.2.4'

config redirect
    option target 'DNAT'
    option dest 'lan'
    option proto 'tcp'
    option dest_port '2049'
    option name 'NFS'
    option src 'lan'
    option src_port '2049'
    option dest_ip '192.168.2.4'

config forwarding
    option dest 'lan'
    option src 'wan'

config forwarding
    option dest 'wan'
    option src 'lan'

config redirect
    option target 'SNAT'
    option src 'lan'
    option dest 'wan'
    option proto 'all'
    option name 'subnetpriv'
    option src_ip '192.168.2.4'
    option dest_ip '192.168.1.19'
    option src_dip '192.168.1.19'
    option src_port '1-65000'
    option dest_port '1-65000'

Contrairement au modèle précédent, la nouvelle livebox 3 (la "play" qui est fournie en standard) ne permet pas de configurer le routage. Il faut passer à la livebox dite "pro". No comment… C'est pour cette raison que j'ai fait du masquerading pour tenter de contourner le problème.

La notion de 'Libre" n'est pas figée, elle peut évoluer, avoir plusieurs facettes. Même si ces facettes sont contestées, elles posent question.
"Du logiciel libre aux théories de l’intelligence collective"
http://ticetsociete.revues.org/451

Va p'têt falloir que tu t'habitues à ne pas trop politiser ton approche du logiciel

C'est cette démarche qui m'a fait adopter Linux en 1999 et non la gratuité. Tout a une dimension politique. On pourrait en discuter pendant des heures mais ce n'est pas l'endroit.

C’est pas la politique de colonisation d’Israël le problème

Je pensais à l'éthique du Libre. Rien que le mot "Libre" est incompatible avec la colonisation, les murs, les barbelés, les expropriations, l'asservissement et la destruction de tout un peuple depuis 70 ans.

Merci à la boite israelienne StartSSL

Humour noir? C'est comme si l'on écrivait "Merci à la boite russe StartSSL" ou bien "Merci à la boite chinoise StartSSL"

http://www.artistes-contre-le-mur.org/palestine/Carte_1946_2005.jpg

Désolé, Photoshop n'est pas notre référence

Moi non plus
Les dev de Gimp qui sont certainement des amateurs amoureux de l'image n'ont rien à voir avec le monde des professionnels de l'image, c'est une des causes principales du problème évoqué ci-dessus. Chacun son boulot. Coder n'est pas faire des images. Par contre, que des créateurs d'images aident les codeurs serait positif. Mais choc des cultures… Utopie ?

car un utilisateur avancé ne fera pas un travail sans le sauvegarder

Nous sommes d'accord et c'est une discussion éternelle…. Cf les parties de ping-pong sur le net concernant ce sujet. Pour résumer ma position personnelle: quand on passe des jours (eh oui) à construire une image, on ne cesse de sauvegarder chaque étape, c'est un réflexe, l'enjeu est trop important. Pour ce faire, pas besoin d'un enregistrement par défaut en .xcf. On est assez grand pour connaître le risque et choisir le format de fichier en conséquence. L'argument des dev de Gimp pour privilégier le .xcf c'est que bcp d'utilisateurs se trompent et enregistrent en jpeg ou png et de ce fait perdent les étapes. C'est un truc qui ne m'est jamais arrivé. D'ailleurs, le concurrent commercial de Gimp utilisé par la majeure partie des professionnels propose le save et save as classique, comme dans l'ancien Gimp :
https://helpx.adobe.com/photoshop/using/saving-images.html
Des utilisateurs ont proposé que l'on puisse avoir le choix dans la conf entre les deux modes de sauvegarde, rien à faire, c'est le nouveau mode d'enregistrement de Gimp, point barre… Circulez…

un projet en manque de contributeurs

Les dev de Gimp semblent un peu repliés sur leurs idées parfois décalées du réel. Les propositions d'utilisateurs n'ont aucune chance d'aboutir, contrairement à ce qui se passe pour d'autres projets tels que Enlightenment ou Digikam.

Le nouveau mode d'enregistrement des fichiers (par défaut en .xcf) a déclenché un débat (saignant) à tendance trollesque sur le net. Pour contourner en partie ce mode (aberrant pour les utilisateurs avancés) de sauvegarde, Akkana Peck (enfin une femme!) a créé le 'plugin save-export-clean.py' https://github.com/akkana/gimp-plugins/ qui fonctionne bien.
http://www.gimpusers.com/forums/gimp-user/14746-a-plug-in-for-those-who-still-don-t-like-the-new-save-export
Il y eut même une tentative de fork pour revenir au 'save as/save' des anciennes versions de Gimp
http://ansuz.sooke.bc.ca/entry/242
https://github.com/mskala/noxcf-gimp