Maderios a écrit 2320 commentaires

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

C'est bizarre cette comparaison Krita/Gimp. Krita n'a pas grand chose à voir avec Gimp. Essayez donc de retoucher un fichier image avec Krita…

J'ai résolu les 2 problèmes (pas testé en statique):
- en supprimant /etc/wpa_supplicant.conf C'est ce fichier inutile avec Debian qui était à l'origine des déconnections intempestives.
- en modifiant sur mon routeur (bewan 900N) le protocole par défaut qui était 11b+11g+11n. Seul le 802.11b semble accepté par le portable (pourtant l'interface est signalée acceptant b et g).
- par ailleurs, j'ai compilé un noyau 3.17.7 (pas depuis le source Debian), cela a peut-être joué vu les bugs signalés concernant le 3.16.
Merci à tous pour votre aide. Bon WE

Sur Debian, /etc/wpa_supplicant.conf n'existe pas et ne sert à rien si on l'ajoute…
Seul compte /etc/network/interfaces

J'ai configuré (à la main) en DHCP, le wifi fonctionne mais la connexion s'interrompt après peu de temps (3 ou 4 mn). Je dois relancer 'interfaces' pour retrouver la connection, connexion qui s'interrompt de nouveau, etc, etc. Je ne vois pas d'où peut provenir ce dysfonctionnement.

Systemd, oui mais aucun Networkmanager.