C'est simplement que la carte réseau wlp2s0 peut être jointe par 2 adresses IP différentes.
L'idée d'IPv6 est que les fournisseurs d'accès offrent à chacun de leur client non pas une adresse fixe (comme c'était le cas avec IPv4), mais un sous-réseau complet (la taille du sous-réseau peut différer, ici tu vois que sur les 128 bits d'adresse, ton opérateur a fixé les 64 premiers bits).
Comme un sous-réseau comporte énormément d'adresses, chaque périphérique peut sans problème utiliser plusieurs adresses en même temps. Cette propriété permet de créer des stratégies qui permettent d'atténuer un peu le pistage des utilisateurs.
Par exemple, avec une version assez récente de Network-Manager, il est maintenant possible d'utiliser ce genre de stratégie, comme nous l'expliquions dans la dépêche Protéger sa vie privée avec l’IPv6.
Maintenant, avec ce log je n'arrive pas à te dire pourquoi exactement ta carte wifi a 2 adresses IP, ça dépend de la configuration de ton client (Network-Manager ?) et de ton routeur (en France, j'imagine que c'est une "box"). Je peux juste te dire que c'est un fonctionnement normal d'IPv6 et qu'il n'y a pas besoin de s'en inquiété :)
Malheureusement, TabCenter s'est arrêté à cause de son incompatibilité avec les futurs version de Firefox, comme expliqué sur le discourse de Mozilla. L'auteur du commentaire explique qu'il y a une année, lors des débuts des développements, les WebExtension API n'étaient pas encore à disposition et ils ont donc fait le développement sur les anciennes technologies qui sont maintenant incompatibles avec Firefox.
Il y explique aussi que les changements apportés par le projet Photon justement sont un grand chantier et que ceux-ci ont commencé à casser TabCenter.
Par contre, depuis, nous avons le projet TabCenter-Redux qui rendra compatilbe le projet TabCenter avec Firefox 57+ (donc après l'apparition de Photon). Le projet est d'ailleurs maintenant à disposition sur addons.mozilla.org.
Je suis tout a fait d'accord avec toi: un complot est caché où les distributions se passent le mot pour passer des patchs sur KDE pour le casser. Elles sont toutes en réalité gnomecenctristes et elles devraient arrêter l'hypocrisie de faire croire que d'autres logiciels en dehors de ceux du projet Gnome existent.
$RANDOM retourne une valeur entre 0 et 32767 (2**15 valeurs).
Donc fonctionne exactement pour des puissances de 2 mais par pour les autres cas.
Euh, je ne vois pas la transition entre la plage de valeur et "fonctionne exactement pour des puissances de 2" ?
Pour moi, $RANDOM envoie un nombre entre 0 et 32767, et ensuite on fait un modulo 7 pour avoir un nombre entre 0 et 6, ça me semble plutôt correcte. Une autre plage de valeur aurait été plus correcte ?
PS: effectivement, pour avoir un nombre entre 31 et 36, on aurait du faire un modulo 6, mais ça ne change rien à mes questions.
Il serait utile que tu nous précise quelle version de Debian tu utilises, car sysv n'est plus présent (par défaut) sur Debian depuis la version 8 nommée "Jessie". Il y a bien une couche de compatibilité pour que les scripts sysv fonctionnent encore, mais sinon c'est systemd qui gère tout le processus de démarrage.
Pour systemd, voici quelques wiki qui pourraient t'intéresser:
Wiki de Debian (mélange pas mal de choses, mais contient l'essentiel sous "Managing services with systemd")
Wiki d'Archlinux (beaucoup plus complet, notamment la section "Writing unit file" qui aidera pour crée son propre service).
la documentation de systemd (man): systemctl, systemd.service, systemd.unit, systemd.timer, systemd.path, …
I talked about PipeWire before, when it was still called Pinos, but the scope and ambition for the project has significantly changed since then. Last time when I spoke about it the goal was just to create something that could be considered a video equivalent of pulseaudio. Wim Taymans, who you might know co-created GStreamer and who has been a major PulseAudio contributor, has since expanded the scope and PipeWire now aims at unifying linux Audio and Video. The long term the goal is for PipeWire to not only provide handling of video streams, but also handle all kinds of audio. Due to this Wim has been spending a lot of time making sure PipeWire can handle audio in a way that not only address the PulseAudio usecases, but also the ones handled by Jack today. A big part of the motivation for this is that we want to make Fedora Workstation the best place to create content and we want the pro-audio crowd to be first class citizens of our desktop.
At the same time we don’t want to make this another painful subsystem transition so PipeWire so we will need to ensure that PulseAudio applications can still be run without modification.
We expect to start shipping PipeWire with Fedora Workstation 27, but at that point only have it handle video as we need this to both enable good video handling for Flatpak applications through a video portal, but also to provide an API for applications that want to do screen capture under Wayland, like web browser applications offering screen sharing. We will the bring the audio features onboard in subsequent releases as we also try to work with the Jack and PulseAudio communities to make this a joint effort. We are also working now on a proper website for PipeWire.
Pour moi, ce qui est le plus intéressant à court terme (sans le support de l'audio):
utiliser plusieurs applications nécessitant une capture vidéo d'un même périphérique en même temps au lieu d'utiliser un verrou exclusif par application
proposer pour les applications Flatpak un portail vers les périphériques de capture vidéo
proposer une solution pour le protocole Wayland pour permettre la capture et le partage d'écran de manière sécurisée
A long terme, le projet PipeWire sera :
un projet supplémentaire qui gère l'audio Linux, mais dont la volonté est de créer une collaboration avec les communautés de PulseAudio (dont Wim Taymans est un contributeur important et fait partie des développeurs de PipeWire) et Jack
compatible avec les applications sachant utiliser PulseAudio quand l'audio sera supporté (et donc compatible avec les cas d'utilisation de PulseAudio)
compatible également avec les cas d'utilisations prévus par jack
Si PipeWire n'arrive pas à amener une unifications de la vidéo et de l'audio sous Linux, je pense que les objectifs à court terme sont déjà une très grande amélioration de la situation de l'utilisation des périphériques vidéos.
Oui, il est activé par défaut pour tout le monde dans la version 54.
Par contre, il peut être activé depuis la version 48 selon certains critères qui déterminent si l'utilisateur peut faire partie de la population de test: https://wiki.mozilla.org/Electrolysis
Firefox Release
If you're using Firefox 48 or later, you might be using e10s already. Check about:support and look for a number higher than 0 in the "Multiprocess Windows" entry. If you would like to opt-in, open about:config and toggle browser.tabs.remote.autostart to true. On your next restart, e10s should be active.
Dans la release note de Firefox 54, on a par contre la mention:
Dans l'article cité, Firefox 54 active la seconde étape du projet e10s: la première était d'avoir 1 process pour le navigateur et 1 process pour le rendu des pages ; la seconde étape permet d'avoir maintenant 1 process par page chargée.
Le dernier brouillon publié publiquement de c++17 date de mars 2017
Donc, la communauté Debian a décidé d'arrêter les intégrations de nouveaux développements / fonctionnalités en janvier. La communauté a dès lors demandé à tous ses membres et utilisateurs de tester les versions packagées dans le freeze des logiciels qu'ils utilisent afin de remonter tous les bugs possible. Après 6 mois de tests, la communauté Debian a enfin décidé que les paquets disponible durant le gel ont suffisamment été testé pour sortir une version officielle en juin 2017.
Durant cette période de gel, il aurait été impossible d'intégrer Python 3.6.0, puisque Python est un langage fournissant énormément de paquets dépendants et car il venait juste de sortir officiellement de la communauté Python.
Pour c++17, comment dire… Le dernier brouillon n'était même pas à disposition….
C’est toujours un plaisir d’être coincé dans le passé à cause de cette distro.
Pour en remettre une couche, non ce n'est pas "cette distro" qui te bloque, mais "cette communauté de membres et d'utilisateurs qui ont pris la peine pendant 2 ans d'empaqueter des centaines de logiciels et de les tester pendant 6 mois avant de décider qu'une nouvelle version de leur distribution pouvait être distribué".
Maintenant, il n'y a pas de honte d'avertir tes utilisateurs que tu ne leur fournis aucun support et que s'ils souhaitent utiliser ton logiciel, il faut avoir une installation identique à la tienne. Ça ne change rien au fait que ton application sera toujours open-source/libre et appréciée, mais ça a le mérite de mettre directement les choses au claire avec tes utilisateurs: il n'y a pas de support et le logiciel utilise des technologies très récente (moins de 3 mois d'existence quand même).
Il n'y a pas de honte non plus à poser des questions du style "Savez-vous pourquoi la communauté Debian n'intègre pas le support de c++ 17 ?" au lieu de rager et de critiquer directement le travail effectué par des centaines de membres et utilisateurs…
De mon point de vue, c'est très intéressant pour pouvoir tester le logiciel sans modifier directement son système.
En effet, FusionForge s'interface avec des outils comme le serveur de mail en modifiant directement la configuration du service.
Du coup, pour tester leur outil sur une machine, on est quasiment obligé de l'installer dans une machine virtuelle afin d'avoir une réelle compréhension de comment ça marche et ce que ça va demander comme changement dans ses services.
Quitte à être dans cette situation, je pense que proposer une image Docker prêt à tester est très intéressant, même si comme dit dans l'annonce tout ne sera pas fonctionnel (comme les mailing lists automatiquement crées pour les projets).
Pour moi c'est un petit événement qui peu apporter beaucoup au projet, puisque les utilisateurs / administrateurs systèmes seront plus en clin à le tester l'outil ☺
Je n'ai pas beaucoup d'expériences de ROMs Android, parce que j'ai presque toujours utilisé CyanogenMod et comme Lineage OS est son successeur communautaire je ne serai pas impartial: pour moi, Lineage fait bien le job et je n'ai pas eu de problèmes avec. Maintenant, j'utilise un device assez ancien qui a été beaucoup hacké le Samsung Galaxy S3 et je pense que ça aide bien qu'il ait été bien connu.
L'idée des 2 téléphones est je pense une bonne idée, mais je pense qu'elle coûte un peu cher, alors qu'il existe une solution totalement logicielle (faut-il encore faire confiance à Android OSP / Lineage OS): utiliser 2 profils utilisateur.
Je teste cette solution depuis quelques mois avec Whatsapp et ça marche plutôt bien: chaque utilisateur a ses applications (par contre s'ils ont un même logiciel, il est dans la même version des 2 côtés), les fichiers sont séparés, les configurations sont séparées, les comptes sont invisibles d'un côté et de l'autre, …
Ce qui est assez chouette, c'est que grâce à Yalp, nous n'avons même pas besoin des services Google Play (au moins pour Whatsapp, je n'ai pas essayé le reste). Par contre, je sais que certaines applications comme Pokémon GO dépendent de services spécifique à Google, comme la géolocalisation (l'année dernière j'avais essayé de feinter l'application avec la localisation Mozilla et une application qui faisait proxy d'API, mais je n'ai pas réussi à le faire correctement).
Pour moi, une bonne stratégie serait d'acheter un téléphone, de tenter l'expérience des 2 utilisateurs avec les applications qui t'intéressent et si ça ne joue pas bien, acheter un second téléphone.
PS: Par contre, avec la solution des 2 profiles, lors du redémarrage du téléphone, il faut penser à se connecter au second profil pour initialiser le démarrage des applications en fond. J'ai remarqué que si non, Whatsapp ne démarrait pas (on le voit bien avec leur application web: dès que je démarre le second profil, la web app est capable de se connecter).
Si je me souviens bien, le projet gitolite laisse l'outil git-daemon gérer les accès anonyme. Il fallait coordonner les droits de lecture des répertoires entre les deux outils.
Si je me souviens bien, l'astuce est que $() ouvre un nouveau shell avec ses propres variables. Du coup, pour lui la valeur de la variable est vide.
Si tu veux pouvoir passer des paramètres à un shell exécuté ainsi, je tenterai de passer par les variables d'environnement grâce à la commande export depuis le script de base, puis d'employer la variable d'environnement dans le shell créé.
C'est amusant, ils suivent le même cheminement que Mozilla mais un an après. Abandon de Firefox OS pour se focaliser sur l'IoT, cela ne rappelle rien ? Qu'ils ont abandonné quelques mois après.
Je trouve que le cheminement est également très proche, j'ai l'impression suivante:
On annonce que l'on stoppe les nouveaux matériels au point X
une dizaine de mois après le point X, on annonce que l'on réduit les effectifs lié au logiciel, car l'offre matérielle n'a pas fonctionné (en même temps, on l'a stoppé quelques mois avant Oo)
Encore 1-2 mois et on annonce la fin du projet pour se recentrer sur d'autres parties
Enfin, on jette l'eau du bain et le bébé : hey ça fait plus d'un an que le marché du matériel n'est plus intéressé par nous (en même temps, on leur a dit que l'on stoppait la production de nouveau matériels)
Je trouve ça très dommage, car j'ai reçu ma tablette BQ Aquaris M10 au début de l'année et ça fonctionne plutôt bien: ce qui m'a le plus intéressé est d'avoir un réel Ubuntu qui me permette d'utiliser des outils de développement sans me prendre la tête avec un simple "apt-get install".
Leur montage logiciel était assez intéressant:
Une Ubuntu 15.04 de base avec très peu de logiciels (il faut tenir dans moins de 10 Go à cause du partitionnement Oo)
Les logiciels disponibles dans le magasin Ubuntu au format "click" (snap n'était pas encore sorti et allait être intégré à la place)
Pour les autres logiciels plus standards, utilisation de leur solution "Libertine" comme environnement: ça ressemblait à un système d'isolation à la chroot/docker (je ne sais pas exactement) maison qui permettait d'accéder aux périphériques (genre clavier virtuelle/matérielle) et avait des droits restreints.
Le Unity que l'on trouvait sur cette tablette était très proche du Unity 8 disponible sur desktop depuis la version 16.10 en beta.
J'ai trouvé que sur la tablette, la première utilisation était un peu chaude, alors que l'on avait les explications (genre, utiliser les bords gauche/droite pour faire apparaître les applications en cours ou la barre des tâches). Sur desktop, sans explications, autant dire que l'on regarde et que l'on se déconnecte, surtout que le magasin d'application n'est pas disponible Oo Mais quand on connaît un peu le fonctionnement, ça avait l'aire de bien marchait aussi sur desktop.
D'abord, des problèmes physiques : il faut d'abord faire un design électronique qui tienne la route en terme d'électronique et qui passe dans le boîtier final. Ensuite il faut qu'il soit réalisable par un fondeur (chaque lot produit coûte très cher, car les appareils des fondeurs sont cher et que ca prend beaucoup de temps pour les paramétrer).
Typiquement, le design de la carte GTA04A5 semble bon, mais la soudure du CPU et de la RAM échoue dans 60% de cas.
Enfin, même s'il est réalisable, on peut découvrir des bugs matériels uniquement à l'usage. L'OpenMoko avait des problèmes de grésillements dans le micro dans ses premieres versions, il me semble qu'il y avait aussi des interférences entre les ondes produites par les différents modules et le lecteur SD.
Ensuite, il y a des soucis logiciels dus au monde ARM: comme il n'existe pas de procédure de démarrage standard et de découverte de matériel, comme dans x86, chaque firmware et noyau est extrêmement lié au matériel auquel il est destiné. Heureusement pour le démarreur il existe des projets libres comme U-Boot et, depuis quelques temps, le noyau Linux est capable de démarrer sur plusieurs matériels différents grâce aux DeviceTree qui simplifient la definition du matériel présent dans une configuration.
Pour le noyau, Golden Delicious a décidé de pousser upstream un max de patch, mais apparemment ils n'arrivent pas à tout faire intégrer. Grâce à ce travail, ils sont ensuite capable de faire un rootfs Debian et de l'exécuter sur la machine.
Onlyoffice se comporte exactement pareil avec les uns et les autres.
Il semble que OnlyOffice ne soit pas capable d'éditer des fichiers OpenDocument (d'après cette dépêche), donc je ne comprend pas bien, comment il peut se comporter exactement pareil avec un format ou l'autre.
Ensuite, LibreOffice aussi sait très bien se comporter avec les deux standards tant que MS Office ne modifie pas les fichiers.
Ce qui serait plus intéressant, ce serait de savoir comment OnlyOffice gère les documents au format OOXML quand ceux-ci ont été modifiés par MS Office ? Et dans la même idée, est-ce que MS Office est capable de bien traiter les documents créés par OnlyOffice ?
L'interopérabilité sans problèmes serait une réelle plus value, mais, personnellement, je pense que c'est une chimère car les développeurs logiciels sont souvent tentés d'ajouter des comportements non standard que ce soit par stratégie marketing ou par le souhait de fournir des solutions aux utilisateurs rapidement.
Merci pour la nouvelle, il y a juste une coquille : OpenDocument n'est pas « de la Document Foundation », mais du consortium OASIS (d'ailleurs la Document Foundation est bien plus récente que le format OpenDocument ;) ).
D'ailleurs, pour ces formats de fichier, il existe une autre solution intégrée à ownCloud et NextCloud: Collabora Online. Cette solution si je me souviens bien utilise le backend de LibreOffice (ce projet est bien celui de la Document Foundation).
Justement, Conversation (un client XMPP pour Android) supporte OMEMO pour le chiffrement de bout en bout depuis quelques versions, mais il fallait l'activer manuellement, puis autoriser les signatures des périphériques un à un.
Comme cette démarche est difficile en pratique, et ils viennent de sortir une version (1.15) qui apporte une amélioration intéressante dans ce sens: ils proposent d'activer un chiffrement par défaut pour tous les périphériques tant qu'aucune authentification n'a été réalisée.
Quand le processus d'authentification est réalisé (par le scan d'un QR Code [obtenu par un autre canal sécurisé] au lieu du contrôle manuel et fastidieux des signatures [obtenu par le même canal XMPP]), ils considèrent que l'utilisateur est capable d'authentifier les périphériques des contacts authentifiés et ne chiffrent plus que pour ces périphériques.
Je trouve la démarche intéressante, car il permet de ne pas tomber dans un modèle où tout est chiffré sans authentification réelle des utilisateurs, mais il permet quand même aux utilisateurs sans capacités à réalisé l'authentificaiton (soit de sa part, soit de la part du contact) d'avoir le minimum du chiffrement.
Désolé si ce n'est pas très claire, j'ai lu leur explication du principe ce matin plus ou moins en vitesse et je ne suis pas sûr d'avoir tout compris. Je vous conseille donc de lire leur post original qui détaille plus la situation actuelle et la solution intermédiaire qu'ils ont mis en place.
Merci je vais aller voir les différents clients ptete que l'un ou l'autre permet de passer par d'autres port.
Ne cherche pas, ça n'existe pas, car le protocole ACME ne pourra pas vérifier que tu es l'administrateur système (voir ma réponse plus bas).
J'ai déjà un reverse proxy mais pour plusieurs raisons je l'ai remplacé, pour certains services, par un accès direct via un des autres ports web.
Le reverse proxy n'est qu'un bonus, il n'est pas nécessaire. Tu peux garder tes sites accessibles sur d'autres ports, ça ne pose aucun problème.
Il faut savoir qu'un certificat Let's Encrypt n'est utilisable que sur les ports 80, 443, 8080, 8443. Si on utilise des autres ports pour raison X ou Y, firefox bloque et je suppose que ses bêtes compères pareil.
Non, ce n'est pas vrai: les certificats ne définissent pas les ports sur lesquels ils peuvent être utilisés. Par exemple, pour mon serveur, j'utilise les certificats Let's Encrypt sur les ports : 25, 587, 5222, 5269, 5280, 443, 486, … Un certificat n'est qu'un document signé par une autorité de certification. Ce document contient principalement la clé publique utilisée par ton domaine et une date de validité, c'est quasiment tout.
C'est leur choix de bloquer la possibilité de choisir les ports, c'est leur choix de foutre une limite de trois mois, c'est un projet de mozzila dont comme par hasard firefox force a utiliser des certificats trusté.
De un, ce n'est pas Mozilla qui gère ce projet d'après le site letsencrypt.org : "Linux Foundation Collaborative Projects".
De deux, Mozilla ne t'empêche pas d'utiliser des certificats auto-signés: il faut juste ne pas activer HSTS, car dans ce cas, il est nécessaire d'avoir une configuration TLS correcte (sinon, ce n'est pas une configuration de type Strict-Transport-Security), ce qui requiert un certificat signé par une autorité de confiance reconnue par les navigateurs.
Le but de la vérification par HTTP est de vérifier automatiquement que tu maîtrises la configuration du serveur web qui pointe sur le domaine demandé (et donc que ce domaine t'appartienne bien).
Si tu es incapable de maîtriser cette configuration sur le service web standard (ports 80 et 443), alors le protocole ACME considère que tu n'es pas le maître de ce serveur et il n'a pas d'autre moyen de le faire automatiquement.
Si ACME autorise la vérification avec un autre port, alors n'importe quel employé qui a un accès non-root sur un serveur peut créer des certificats frauduleux: en effet, tous les ports plus grand que 1000 (comme les ports 8080 et 80443), si je me souviens bien, peuvent être utilisés par n'importe quel utilisateur de la machine. Dans ce cas, ACME ne peut pas certifier que c'est bien l'administrateur système qui demande la certification.
L'automatisation de la certification demande en effet une préparation non-évidente pour l'auto-hébergement, mais ce n'est pas non plus insurmontable (voire les solutions que j'ai donné plus haut).
Ah et bien sûr, il ne faut pas que ton client ACME touche à la configuration de ton service web.
Il parraît qu'il y a des options pour ça avec le client certbot (que je n'utilise pas), il faut lire son manuel.
Il y a plein de clients ACME alternatifs qui permettent de récupérer les certificats sans toucher au serveur web. Je pense qu'acme-tiny devrait faire l'affaire dans ce cas (en plus il n'a besoin que d'accéder à ta clé Let's Encrypt et aux CSR).
PS: Surtout n'utlise pas chmod 777 pour la protection de tes fichiers, ils seront tous accessibles si quelqu'un arrive à s'introduire sur tes serveurs.
PS2: Tu peux faire un dossier partagé par serveur, rien ne t'oblige de mettre tous les certificats dans le même dossier partagé…
Désolé, je n'avais pas vu que c'était bien le NAT ton problème.
Dans ce cas, il faut:
Pointer tous tes domaines et sous-domaines sur l'adresse IP publique
Configurer le NAT pour envoyer toutes les connexions entrantes sur les ports 80 et 443 vers ton serveur 1
Configurer le service web du serveur 1 pour écouter chaque domaine et sous-domaines sur les ports 80 et 443
Utiliser le serveur 1 pour demander des certificats à Let's Encrypt pour chacun des domaines et sous domaines
Quand les certificats sont reçu, tu peux soit:
demander au serveur 1 de pousser les bons certificats sur chacun de tes autres serveurs (l'avantage est que le serveur 1 sait quand il crée les certificats, par contre le désavantage est qu'il doit avoir un accès sur chacun des serveurs)
dire à chacun de tes autres serveurs d'aller chercher les nouveaux certificats sur le serveur1 (le désavantage est que les autres serveurs doivent récupérer assez souvent les certificats pour être sûr d'avoir le dernier, l'avantage est que chaque serveur aura ses propres droits sur le serveur 1 et le serveur 1 ne peut pas toucher aux autres serveurs)
En bonus, si tu maitrises suffisamment ton service web sur le serveur 1, tu peux l'utiliser comme reverse proxy : si une requête est faite sur les URLs utilisées par Let's Encrypt, il répond lui-même à la requête, dans les autres cas, il renvoie les requêtes vers les bons servuers. Comme ça, tu peux utiliser tout tes domaines avec les ports standards web.
[^] # Re: Fait
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Mettre à jour le logo de la section mozilla. Évalué à 2 (+0/-0).
Merci :)
# C'est le fonctionnement d'IPv6
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message 2 adresses IPv6 free.fr ?. Évalué à 6.
Hello,
C'est simplement que la carte réseau wlp2s0 peut être jointe par 2 adresses IP différentes.
L'idée d'IPv6 est que les fournisseurs d'accès offrent à chacun de leur client non pas une adresse fixe (comme c'était le cas avec IPv4), mais un sous-réseau complet (la taille du sous-réseau peut différer, ici tu vois que sur les 128 bits d'adresse, ton opérateur a fixé les 64 premiers bits).
Comme un sous-réseau comporte énormément d'adresses, chaque périphérique peut sans problème utiliser plusieurs adresses en même temps. Cette propriété permet de créer des stratégies qui permettent d'atténuer un peu le pistage des utilisateurs.
Par exemple, avec une version assez récente de Network-Manager, il est maintenant possible d'utiliser ce genre de stratégie, comme nous l'expliquions dans la dépêche Protéger sa vie privée avec l’IPv6.
Maintenant, avec ce log je n'arrive pas à te dire pourquoi exactement ta carte wifi a 2 adresses IP, ça dépend de la configuration de ton client (Network-Manager ?) et de ton routeur (en France, j'imagine que c'est une "box"). Je peux juste te dire que c'est un fonctionnement normal d'IPv6 et qu'il n'y a pas besoin de s'en inquiété :)
[^] # Re: Onglets rectangulaires
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Firefox Photon: comment l'interface va redevenir ce qu'elle était. Évalué à 5.
Malheureusement, TabCenter s'est arrêté à cause de son incompatibilité avec les futurs version de Firefox, comme expliqué sur le discourse de Mozilla. L'auteur du commentaire explique qu'il y a une année, lors des débuts des développements, les WebExtension API n'étaient pas encore à disposition et ils ont donc fait le développement sur les anciennes technologies qui sont maintenant incompatibles avec Firefox.
Il y explique aussi que les changements apportés par le projet Photon justement sont un grand chantier et que ceux-ci ont commencé à casser TabCenter.
Par contre, depuis, nous avons le projet TabCenter-Redux qui rendra compatilbe le projet TabCenter avec Firefox 57+ (donc après l'apparition de Photon). Le projet est d'ailleurs maintenant à disposition sur addons.mozilla.org.
[^] # Re: ben ca change pas fedora
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Fedora 26 est sortie !. Évalué à 8.
Je suis tout a fait d'accord avec toi: un complot est caché où les distributions se passent le mot pour passer des patchs sur KDE pour le casser. Elles sont toutes en réalité gnomecenctristes et elles devraient arrêter l'hypocrisie de faire croire que d'autres logiciels en dehors de ceux du projet Gnome existent.
[^] # Re: ben ca change pas fedora
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Fedora 26 est sortie !. Évalué à 3.
Et si on essayait de réfléchir autrement : pourquoi KDE / Plasma sont si difficile à intégrer correctement ?
Gnome, LXDE, LXQT, XFCE ne posent que peu de problèmes à la plupart des distributions, alors que KDE n'est bien intégré nulle part…
[^] # Re: Et en Java ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Parce que ca vaut largement un journal .... Évalué à 5.
Merci, c'est très bien expliqué :)
[^] # Re: Et en Java ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Parce que ca vaut largement un journal .... Évalué à 1. Dernière modification le 04 juillet 2017 à 10:40.
Euh, je ne vois pas la transition entre la plage de valeur et "fonctionne exactement pour des puissances de 2" ?
Pour moi, $RANDOM envoie un nombre entre 0 et 32767, et ensuite on fait un modulo 7 pour avoir un nombre entre 0 et 6, ça me semble plutôt correcte. Une autre plage de valeur aurait été plus correcte ?
PS: effectivement, pour avoir un nombre entre 31 et 36, on aurait du faire un modulo 6, mais ça ne change rien à mes questions.
[^] # Re: Cours init debian & init serveur turtl
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Éclaircissement du processus de démarrage debian. Évalué à 4. Dernière modification le 26 juin 2017 à 13:33.
Hello,
Il serait utile que tu nous précise quelle version de Debian tu utilises, car sysv n'est plus présent (par défaut) sur Debian depuis la version 8 nommée "Jessie". Il y a bien une couche de compatibilité pour que les scripts sysv fonctionnent encore, mais sinon c'est systemd qui gère tout le processus de démarrage.
Pour systemd, voici quelques wiki qui pourraient t'intéresser:
man): systemctl, systemd.service, systemd.unit, systemd.timer, systemd.path, …# L'intérêt principal est peut être ailleurs...
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal PipeWire veut unifier la gestion des flux audio et video. Évalué à 5.
Je reprends le paragraphe évoquant PipeWire de l'article annonçant les développements futurs pour Fedora 26 / 27.
Pour moi, ce qui est le plus intéressant à court terme (sans le support de l'audio):
A long terme, le projet PipeWire sera :
Si PipeWire n'arrive pas à amener une unifications de la vidéo et de l'audio sous Linux, je pense que les objectifs à court terme sont déjà une très grande amélioration de la situation de l'utilisation des périphériques vidéos.
[^] # Re: Très mauvaise version ESR
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Printemps 2017 de Mozilla : Firefox 52 à 54 et Thunderbird 52. Évalué à 3.
Oui, il est activé par défaut pour tout le monde dans la version 54.
Par contre, il peut être activé depuis la version 48 selon certains critères qui déterminent si l'utilisateur peut faire partie de la population de test: https://wiki.mozilla.org/Electrolysis
Dans la release note de Firefox 54, on a par contre la mention:
Dans l'article cité, Firefox 54 active la seconde étape du projet e10s: la première était d'avoir 1 process pour le navigateur et 1 process pour le rendu des pages ; la seconde étape permet d'avoir maintenant 1 process par page chargée.
[^] # Re: Vivement la suivante
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Debian 9 : Stretch déploie ses tentacules. Évalué à 10. Dernière modification le 20 juin 2017 à 07:12.
Pour la version longue de "ben, ne l'utilise pas", je voudrais faire remarquer quelques dates:
Donc, la communauté Debian a décidé d'arrêter les intégrations de nouveaux développements / fonctionnalités en janvier. La communauté a dès lors demandé à tous ses membres et utilisateurs de tester les versions packagées dans le freeze des logiciels qu'ils utilisent afin de remonter tous les bugs possible. Après 6 mois de tests, la communauté Debian a enfin décidé que les paquets disponible durant le gel ont suffisamment été testé pour sortir une version officielle en juin 2017.
Durant cette période de gel, il aurait été impossible d'intégrer Python 3.6.0, puisque Python est un langage fournissant énormément de paquets dépendants et car il venait juste de sortir officiellement de la communauté Python.
Pour c++17, comment dire… Le dernier brouillon n'était même pas à disposition….
Pour en remettre une couche, non ce n'est pas "cette distro" qui te bloque, mais "cette communauté de membres et d'utilisateurs qui ont pris la peine pendant 2 ans d'empaqueter des centaines de logiciels et de les tester pendant 6 mois avant de décider qu'une nouvelle version de leur distribution pouvait être distribué".
Maintenant, il n'y a pas de honte d'avertir tes utilisateurs que tu ne leur fournis aucun support et que s'ils souhaitent utiliser ton logiciel, il faut avoir une installation identique à la tienne. Ça ne change rien au fait que ton application sera toujours open-source/libre et appréciée, mais ça a le mérite de mettre directement les choses au claire avec tes utilisateurs: il n'y a pas de support et le logiciel utilise des technologies très récente (moins de 3 mois d'existence quand même).
Il n'y a pas de honte non plus à poser des questions du style "Savez-vous pourquoi la communauté Debian n'intègre pas le support de c++ 17 ?" au lieu de rager et de critiquer directement le travail effectué par des centaines de membres et utilisateurs…
[^] # Re: hein ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal FusionForge & Docker. Évalué à 5.
De mon point de vue, c'est très intéressant pour pouvoir tester le logiciel sans modifier directement son système.
En effet, FusionForge s'interface avec des outils comme le serveur de mail en modifiant directement la configuration du service.
Du coup, pour tester leur outil sur une machine, on est quasiment obligé de l'installer dans une machine virtuelle afin d'avoir une réelle compréhension de comment ça marche et ce que ça va demander comme changement dans ses services.
Quitte à être dans cette situation, je pense que proposer une image Docker prêt à tester est très intéressant, même si comme dit dans l'annonce tout ne sera pas fonctionnel (comme les mailing lists automatiquement crées pour les projets).
Pour moi c'est un petit événement qui peu apporter beaucoup au projet, puisque les utilisateurs / administrateurs systèmes seront plus en clin à le tester l'outil ☺
# Lineage OS
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message LineageOS, retours d'expériences (dégoogleisation). Évalué à 3.
Hello,
Je n'ai pas beaucoup d'expériences de ROMs Android, parce que j'ai presque toujours utilisé CyanogenMod et comme Lineage OS est son successeur communautaire je ne serai pas impartial: pour moi, Lineage fait bien le job et je n'ai pas eu de problèmes avec. Maintenant, j'utilise un device assez ancien qui a été beaucoup hacké le Samsung Galaxy S3 et je pense que ça aide bien qu'il ait été bien connu.
L'idée des 2 téléphones est je pense une bonne idée, mais je pense qu'elle coûte un peu cher, alors qu'il existe une solution totalement logicielle (faut-il encore faire confiance à Android OSP / Lineage OS): utiliser 2 profils utilisateur.
Je teste cette solution depuis quelques mois avec Whatsapp et ça marche plutôt bien: chaque utilisateur a ses applications (par contre s'ils ont un même logiciel, il est dans la même version des 2 côtés), les fichiers sont séparés, les configurations sont séparées, les comptes sont invisibles d'un côté et de l'autre, …
Ce qui est assez chouette, c'est que grâce à Yalp, nous n'avons même pas besoin des services Google Play (au moins pour Whatsapp, je n'ai pas essayé le reste). Par contre, je sais que certaines applications comme Pokémon GO dépendent de services spécifique à Google, comme la géolocalisation (l'année dernière j'avais essayé de feinter l'application avec la localisation Mozilla et une application qui faisait proxy d'API, mais je n'ai pas réussi à le faire correctement).
Pour moi, une bonne stratégie serait d'acheter un téléphone, de tenter l'expérience des 2 utilisateurs avec les applications qui t'intéressent et si ça ne joue pas bien, acheter un second téléphone.
PS: Par contre, avec la solution des 2 profiles, lors du redémarrage du téléphone, il faut penser à se connecter au second profil pour initialiser le démarrage des applications en fond. J'ai remarqué que si non, Whatsapp ne démarrait pas (on le voit bien avec leur application web: dès que je démarre le second profil, la web app est capable de se connecter).
[^] # Re: Patch
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Serveur Git avec Gitolite. Évalué à 2.
Si je me souviens bien, le projet gitolite laisse l'outil git-daemon gérer les accès anonyme. Il fallait coordonner les droits de lecture des répertoires entre les deux outils.
[^] # Re: Salut
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message [RÉSOLU] Bash utiliser variable dans une commande du style result=$(commande | grep $variable). Évalué à 2.
Hello,
Si je me souviens bien, l'astuce est que
$()ouvre un nouveau shell avec ses propres variables. Du coup, pour lui la valeur de la variable est vide.Si tu veux pouvoir passer des paramètres à un shell exécuté ainsi, je tenterai de passer par les variables d'environnement grâce à la commande
exportdepuis le script de base, puis d'employer la variable d'environnement dans le shell créé.[^] # Re: Google postmasters tools
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Merci pour ce moment, gmail. Évalué à 5.
Ça aurait pu être sympa de mieux comprendre sa réputation, mais il faut un compte Google…
[^] # Re: Un an après Mozilla
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Mark Shuttleworth annonce l’abandon d’Unity. Évalué à 8.
Je trouve que le cheminement est également très proche, j'ai l'impression suivante:
Je trouve ça très dommage, car j'ai reçu ma tablette BQ Aquaris M10 au début de l'année et ça fonctionne plutôt bien: ce qui m'a le plus intéressé est d'avoir un réel Ubuntu qui me permette d'utiliser des outils de développement sans me prendre la tête avec un simple "apt-get install".
Leur montage logiciel était assez intéressant:
Le Unity que l'on trouvait sur cette tablette était très proche du Unity 8 disponible sur desktop depuis la version 16.10 en beta.
J'ai trouvé que sur la tablette, la première utilisation était un peu chaude, alors que l'on avait les explications (genre, utiliser les bords gauche/droite pour faire apparaître les applications en cours ou la barre des tâches). Sur desktop, sans explications, autant dire que l'on regarde et que l'on se déconnecte, surtout que le magasin d'application n'est pas disponible Oo Mais quand on connaît un peu le fonctionnement, ça avait l'aire de bien marchait aussi sur desktop.
Enfin, pour ceux intéressés par les "visions" du fondateur d'Ubuntu, Numerama avait fait une très bonne interview au dernier MWC: http://www.numerama.com/tech/238172-mark-shuttleworth-voir-des-gens-brillants-faire-des-choses-brillantes-grace-a-ubuntu-cest-ma-fierte.html L'interview m'avait laissé une impression assez étrange, j'en avais gardé une idée du style: d'une part il a des visions de création de nouvelles technologies qui diffèrent avec les décisions prises par la communauté et ensuite il est chagriné de voir que la communauté ne l'a pas suivi ?
[^] # Re: smartphone et OS
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Les mobiles libres ont du plomb dans l’aile et les systèmes d’exploitation ne vont pas mieux. Évalué à 4.
En fait, il existe pas mal de problèmes.
D'abord, des problèmes physiques : il faut d'abord faire un design électronique qui tienne la route en terme d'électronique et qui passe dans le boîtier final. Ensuite il faut qu'il soit réalisable par un fondeur (chaque lot produit coûte très cher, car les appareils des fondeurs sont cher et que ca prend beaucoup de temps pour les paramétrer).
Typiquement, le design de la carte GTA04A5 semble bon, mais la soudure du CPU et de la RAM échoue dans 60% de cas.
Enfin, même s'il est réalisable, on peut découvrir des bugs matériels uniquement à l'usage. L'OpenMoko avait des problèmes de grésillements dans le micro dans ses premieres versions, il me semble qu'il y avait aussi des interférences entre les ondes produites par les différents modules et le lecteur SD.
Ensuite, il y a des soucis logiciels dus au monde ARM: comme il n'existe pas de procédure de démarrage standard et de découverte de matériel, comme dans x86, chaque firmware et noyau est extrêmement lié au matériel auquel il est destiné. Heureusement pour le démarreur il existe des projets libres comme U-Boot et, depuis quelques temps, le noyau Linux est capable de démarrer sur plusieurs matériels différents grâce aux DeviceTree qui simplifient la definition du matériel présent dans une configuration.
Pour le noyau, Golden Delicious a décidé de pousser upstream un max de patch, mais apparemment ils n'arrivent pas à tout faire intégrer. Grâce à ce travail, ils sont ensuite capable de faire un rootfs Debian et de l'exécuter sur la machine.
Je dois vous laisser, je reviendrai plus tard.
[^] # Re: positionnement
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Intégration de ownCloud avec OnlyOffice. Évalué à 2.
Il semble que OnlyOffice ne soit pas capable d'éditer des fichiers OpenDocument (d'après cette dépêche), donc je ne comprend pas bien, comment il peut se comporter exactement pareil avec un format ou l'autre.
Ensuite, LibreOffice aussi sait très bien se comporter avec les deux standards tant que MS Office ne modifie pas les fichiers.
Ce qui serait plus intéressant, ce serait de savoir comment OnlyOffice gère les documents au format OOXML quand ceux-ci ont été modifiés par MS Office ? Et dans la même idée, est-ce que MS Office est capable de bien traiter les documents créés par OnlyOffice ?
L'interopérabilité sans problèmes serait une réelle plus value, mais, personnellement, je pense que c'est une chimère car les développeurs logiciels sont souvent tentés d'ajouter des comportements non standard que ce soit par stratégie marketing ou par le souhait de fournir des solutions aux utilisateurs rapidement.
# OpenDocument
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Intégration de ownCloud avec OnlyOffice. Évalué à 9.
Merci pour la nouvelle, il y a juste une coquille : OpenDocument n'est pas « de la Document Foundation », mais du consortium OASIS (d'ailleurs la Document Foundation est bien plus récente que le format OpenDocument ;) ).
D'ailleurs, pour ces formats de fichier, il existe une autre solution intégrée à ownCloud et NextCloud: Collabora Online. Cette solution si je me souviens bien utilise le backend de LibreOffice (ce projet est bien celui de la Document Foundation).
[^] # Re: Wire
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Silence : XMPP, chiffrement et méta‐données. Évalué à 2.
Justement, Conversation (un client XMPP pour Android) supporte OMEMO pour le chiffrement de bout en bout depuis quelques versions, mais il fallait l'activer manuellement, puis autoriser les signatures des périphériques un à un.
Comme cette démarche est difficile en pratique, et ils viennent de sortir une version (1.15) qui apporte une amélioration intéressante dans ce sens: ils proposent d'activer un chiffrement par défaut pour tous les périphériques tant qu'aucune authentification n'a été réalisée.
Quand le processus d'authentification est réalisé (par le scan d'un QR Code [obtenu par un autre canal sécurisé] au lieu du contrôle manuel et fastidieux des signatures [obtenu par le même canal XMPP]), ils considèrent que l'utilisateur est capable d'authentifier les périphériques des contacts authentifiés et ne chiffrent plus que pour ces périphériques.
Je trouve la démarche intéressante, car il permet de ne pas tomber dans un modèle où tout est chiffré sans authentification réelle des utilisateurs, mais il permet quand même aux utilisateurs sans capacités à réalisé l'authentificaiton (soit de sa part, soit de la part du contact) d'avoir le minimum du chiffrement.
Désolé si ce n'est pas très claire, j'ai lu leur explication du principe ce matin plus ou moins en vitesse et je ne suis pas sûr d'avoir tout compris. Je vous conseille donc de lire leur post original qui détaille plus la situation actuelle et la solution intermédiaire qu'ils ont mis en place.
[^] # Re: certbot / debian
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Let's encrypt et plusieurs serveurs sur la même IP. Évalué à 5.
Ne cherche pas, ça n'existe pas, car le protocole ACME ne pourra pas vérifier que tu es l'administrateur système (voir ma réponse plus bas).
Le reverse proxy n'est qu'un bonus, il n'est pas nécessaire. Tu peux garder tes sites accessibles sur d'autres ports, ça ne pose aucun problème.
Non, ce n'est pas vrai: les certificats ne définissent pas les ports sur lesquels ils peuvent être utilisés. Par exemple, pour mon serveur, j'utilise les certificats Let's Encrypt sur les ports : 25, 587, 5222, 5269, 5280, 443, 486, … Un certificat n'est qu'un document signé par une autorité de certification. Ce document contient principalement la clé publique utilisée par ton domaine et une date de validité, c'est quasiment tout.
[^] # Re: certbot / debian
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Let's encrypt et plusieurs serveurs sur la même IP. Évalué à 6.
De un, ce n'est pas Mozilla qui gère ce projet d'après le site letsencrypt.org : "Linux Foundation Collaborative Projects".
De deux, Mozilla ne t'empêche pas d'utiliser des certificats auto-signés: il faut juste ne pas activer
HSTS, car dans ce cas, il est nécessaire d'avoir une configuration TLS correcte (sinon, ce n'est pas une configuration de typeStrict-Transport-Security), ce qui requiert un certificat signé par une autorité de confiance reconnue par les navigateurs.Le but de la vérification par HTTP est de vérifier automatiquement que tu maîtrises la configuration du serveur web qui pointe sur le domaine demandé (et donc que ce domaine t'appartienne bien).
Si tu es incapable de maîtriser cette configuration sur le service web standard (ports 80 et 443), alors le protocole ACME considère que tu n'es pas le maître de ce serveur et il n'a pas d'autre moyen de le faire automatiquement.
Si ACME autorise la vérification avec un autre port, alors n'importe quel employé qui a un accès non-root sur un serveur peut créer des certificats frauduleux: en effet, tous les ports plus grand que 1000 (comme les ports 8080 et 80443), si je me souviens bien, peuvent être utilisés par n'importe quel utilisateur de la machine. Dans ce cas, ACME ne peut pas certifier que c'est bien l'administrateur système qui demande la certification.
L'automatisation de la certification demande en effet une préparation non-évidente pour l'auto-hébergement, mais ce n'est pas non plus insurmontable (voire les solutions que j'ai donné plus haut).
[^] # Re: certbot / debian
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Let's encrypt et plusieurs serveurs sur la même IP. Évalué à 4. Dernière modification le 06 novembre 2016 à 20:46.
Ah et bien sûr, il ne faut pas que ton client ACME touche à la configuration de ton service web.
Il parraît qu'il y a des options pour ça avec le client certbot (que je n'utilise pas), il faut lire son manuel.
Il y a plein de clients ACME alternatifs qui permettent de récupérer les certificats sans toucher au serveur web. Je pense qu'acme-tiny devrait faire l'affaire dans ce cas (en plus il n'a besoin que d'accéder à ta clé Let's Encrypt et aux CSR).
PS: Surtout n'utlise pas chmod 777 pour la protection de tes fichiers, ils seront tous accessibles si quelqu'un arrive à s'introduire sur tes serveurs.
PS2: Tu peux faire un dossier partagé par serveur, rien ne t'oblige de mettre tous les certificats dans le même dossier partagé…
[^] # Re: certbot / debian
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Let's encrypt et plusieurs serveurs sur la même IP. Évalué à 4. Dernière modification le 06 novembre 2016 à 20:35.
Désolé, je n'avais pas vu que c'était bien le NAT ton problème.
Dans ce cas, il faut:
En bonus, si tu maitrises suffisamment ton service web sur le serveur 1, tu peux l'utiliser comme reverse proxy : si une requête est faite sur les URLs utilisées par Let's Encrypt, il répond lui-même à la requête, dans les autres cas, il renvoie les requêtes vers les bons servuers. Comme ça, tu peux utiliser tout tes domaines avec les ports standards web.
Pour t'aider pour le reverse proxy, tu peux regarder ce lien : https://blog.bandinelli.net/index.php?post/2016/10/19/Pound-Let-s-Encrypt-%3A-un-service-pour-tout-r%C3%A9gler