Debian, Ubuntu.
steven Membre non connecté
-
- Voir le profil du membre steven
- Inscrit le : 18/05/2018
Reprise du message précédent
Savez vous pkoi Snowden n'utilise pas non plus ubuntu/debian ?No Comment ... 
Merci de ne pas 'rebondir' sur mes post's Censor => 2025
Merci de ne pas 'rebondir' sur mes post's Censor => 2025 
arte-naki Membre non connecté
-
- Voir le profil du membre arte-naki
- Inscrit le : 03/11/2020
Pourquoi Trisquel a choisi Ubuntu comme base, je ne sais pas. Il y avait sûrement des raisons. Par exemple, il y avait des outils prêts à l'emploi, moins de travail.
seb95 Membre non connecté
-
- Voir le profil du membre seb95
- Inscrit le : 26/08/2007
- Site internet
- Groupes :
Citation :
Au fait, je faisais des recherches et openSUSE est un système très douteux. J'ai remarqué des fonctions d'espionnage et les médias sont muets à ce sujet. Au moins trois caractéristiques étranges:
1. Utilisation active du portail captif (conncheck.opensuse.org)
2. Identifiant unique lors de la connexion de zypper aux serveurs de référentiel
3. Étrange bogue de cache DNS qui reflète les requêtes DNS.
1. Utilisation active du portail captif (conncheck.opensuse.org)
2. Identifiant unique lors de la connexion de zypper aux serveurs de référentiel
3. Étrange bogue de cache DNS qui reflète les requêtes DNS.
Je reviens dessus, voila une réponse:
Concernant 2: L'identifiant est stocké dans / var / lib / zypp / AnonymousUniqueId. Comme son nom l'indique, il est complètement anonyme et utilisé pour obtenir un nombre approximatif d'utilisateurs. Si vous ne voulez pas être compté, vous pouvez simplement supprimer ce fichier.
seb95 Membre non connecté
-
- Voir le profil du membre seb95
- Inscrit le : 26/08/2007
- Site internet
- Groupes :
Citation :
As for conncheck, wasn't that only used via Networkmanager for connectivity?
I don't use NM myself but as I recall conncheck was used by NM's [connectivity] to see if the network is up. Maybe check NetworkManager.conf in /etc/NetworkManager/ - I'm pretty sure you can just remove/disable it or use a service of your own.
And I'm pretty sure Mageia uses it too, just a different address.
so nefarious it's documented in the man page for NetworkManager.conf
(connection check)
but no one reads man pages, so actually it's rather brilliant, hiding in plain sight
I don't use NM myself but as I recall conncheck was used by NM's [connectivity] to see if the network is up. Maybe check NetworkManager.conf in /etc/NetworkManager/ - I'm pretty sure you can just remove/disable it or use a service of your own.
And I'm pretty sure Mageia uses it too, just a different address.
so nefarious it's documented in the man page for NetworkManager.conf
(connection check)
but no one reads man pages, so actually it's rather brilliant, hiding in plain sight
Papoteur Membre non connecté
-
- Voir le profil du membre Papoteur
- Inscrit le : 03/10/2011
- Groupes :
-
Modérateur
-
Équipe Mageia
-
Administrateur
-
Forgeron
seb95 :
Pour cette partie, 1. Utilisation active du portail captif (conncheck.opensuse.org), a priori c'est Networkmanager le fautif, je cite des gars de chez SUSE:
Citation :
As for conncheck, wasn't that only used via Networkmanager for connectivity?
I don't use NM myself but as I recall conncheck was used by NM's [connectivity] to see if the network is up. Maybe check NetworkManager.conf in /etc/NetworkManager/ - I'm pretty sure you can just remove/disable it or use a service of your own.
And I'm pretty sure Mageia uses it too, just a different address.
so nefarious it's documented in the man page for NetworkManager.conf
(connection check)
but no one reads man pages, so actually it's rather brilliant, hiding in plain sight
I don't use NM myself but as I recall conncheck was used by NM's [connectivity] to see if the network is up. Maybe check NetworkManager.conf in /etc/NetworkManager/ - I'm pretty sure you can just remove/disable it or use a service of your own.
And I'm pretty sure Mageia uses it too, just a different address.
so nefarious it's documented in the man page for NetworkManager.conf
(connection check)
but no one reads man pages, so actually it's rather brilliant, hiding in plain sight
Bonjour,
Le gars de chez Suse profère des affirmations gratuites. Il devrait étayer celles-ci.
Connaissant la paranoïa de certains des packageurs, ceci me semblait surprenant. Comme j'utilise NetworkManager, je suis allé vérifier.
Voici le fichier de config NetworkManager.conf qu'il cite :
Code TEXT :
[main] plugins=ifcfg-rh,keyfile dhcp=internal hostname-mode=none
Il n'y a aucune section de check de connexion, aucune uri, aucun interval.
Pas l'ombre non plus d'un autre fichier de configuration.
Ce fichier de configuration est fourni par le rpm networkmanager. On le retrouve ici : http://svnweb.mageia.org/packages/cauldron/networkmanager/current/SPECS/networkmanager.spec?view=markup#l315
Donc le gars de chez Suse a beau être pratiquement sûr, et lire le man de NetworkManager, il n'est pas allé voir comment ça se passait chez Mageia.
Édité par Papoteur Le 27/01/2021 à 08h50
Papoteur Membre non connecté
-
- Voir le profil du membre Papoteur
- Inscrit le : 03/10/2011
- Groupes :
-
Modérateur
-
Équipe Mageia
-
Administrateur
-
Forgeron
PS: @Seb95: Pourrais-tu fournir un lien vers ta citation, qu'on puisse avoir un droit de réponse ?
Édité par Papoteur Le 27/01/2021 à 09h03
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
Alors d'après la spec, j'ai téléchargé les sources, décompressé, et lancé une recherche :
Code TEXT :
[jybz@localhost NetworkManager-1.29.9]$ grep -A 10 -R '\[connectivity\]' ./ ./src/tests/config/NetworkManager-warn.conf:[connectivity] ./src/tests/config/NetworkManager-warn.conf-uri=http://example.com ./src/tests/config/NetworkManager-warn.conf-interval=100 ./src/tests/config/NetworkManager-warn.conf-response=Hello ./src/tests/config/NetworkManager-warn.conf-audit=true ./src/tests/config/NetworkManager-warn.conf- ./src/tests/config/NetworkManager-warn.conf-[connection] ./src/tests/config/NetworkManager-warn.conf-ipv4.route-metric=50 ./src/tests/config/NetworkManager-warn.conf-ipv4.addresses=1.2.3.4 ./src/tests/config/NetworkManager-warn.conf-ipv4.dad-timeout=100 ./src/tests/config/NetworkManager-warn.conf- -- ./src/tests/config/NetworkManager.conf:[connectivity] ./src/tests/config/NetworkManager.conf-uri=http://example.com ./src/tests/config/NetworkManager.conf-interval=100 ./src/tests/config/NetworkManager.conf-response=Hello ./src/tests/config/NetworkManager.conf- ./src/tests/config/NetworkManager.conf-[extra-section] ./src/tests/config/NetworkManager.conf-extra-key=some value ./src/tests/config/NetworkManager.conf- ./src/tests/config/NetworkManager.conf- ./src/tests/config/NetworkManager.conf- ./src/tests/config/NetworkManager.conf-[connection] -- ./src/tests/config/conf.d/10-more.conf:[connectivity] ./src/tests/config/conf.d/10-more.conf-uri=http://example.net ./src/tests/config/conf.d/10-more.conf- ./src/tests/config/conf.d/10-more.conf-[order] ./src/tests/config/conf.d/10-more.conf-a=10 ./src/tests/config/conf.d/10-more.conf-b=10 ./src/tests/config/conf.d/10-more.conf- ./src/tests/config/conf.d/10-more.conf-# the following sections are tested for their order across ./src/tests/config/conf.d/10-more.conf-# multiple files. ./src/tests/config/conf.d/10-more.conf-[connection.ord.2.1] ./src/tests/config/conf.d/10-more.conf-ord.key09=C-2.1.09
Seulement trois fichier avec les sections connectivity contenant en uri juste "example.net|.com", rien qui ne puisse fonctionner, par défaut.
On peut les retrouver sur le git https://gitlab.freedesktop.org/NetworkManager/NetworkManager pour ceux qui ne souhaitent pas télécharger et rechercher en CLI.
seb95 Membre non connecté
-
- Voir le profil du membre seb95
- Inscrit le : 26/08/2007
- Site internet
- Groupes :
J'ai aussi un peu de temps pour chercher et comprendre,
Citation :
Le gars de chez Suse profère des affirmations gratuites. Il devrait étayer celles-ci.
Connaissant la paranoïa de certains des packageurs, ceci me semblait surprenant. Comme j'utilise NetworkManager, je suis allé vérifier.
Connaissant la paranoïa de certains des packageurs, ceci me semblait surprenant. Comme j'utilise NetworkManager, je suis allé vérifier.
Il dit "je suis presque sûr" , il n'affirme pas il suppose. Ensuite, paranoia ou non, en quoi est ce mal de pointer sur un serveur / adresse du projet? On a beau être parano, si on travail pour le projet, on a confiance en ce projet et donc ça me choque pas qu'il y ait un test de connectivité vers le serveur du projet, maintenant je sais pas si c'est vraiment utile à part de voir un faille dans les logs ou au démarage de la bécane si elle n'a pas de connexion ou si le serveur est HS.
J'ai donc cherché:
~/rpmbuild/SRPMS/opensuse/NetworkManager-1.28.0-2.1.src$ grep -A 10 -R '\[connectivity\]' ./
sebastien@debiacerlinux:~/rpmbuild/SRPMS/opensuse/NetworkManager-1.28.0-2.1.src$
sebastien@debiacerlinux:~/rpmbuild/SRPMS/opensuse/NetworkManager-1.28.0-2.1.src$
Rien avec grep! Mais c'est qu'il est découpé en plusieurs (voir plus bas).
Citation :
Voici le fichier de config NetworkManager.conf qu'il cite :
Sous openSUSE:
[main]
plugins=keyfile
[connectivity]
uri=http://conncheck.opensuse.org
plugins=keyfile
[connectivity]
uri=http://conncheck.opensuse.org
Dont la partie incriminé
[connectivity]
uri=http://conncheck.opensuse.org
Sous Debian, il n'y a rien non plus:
[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=false
plugins=ifupdown,keyfile
[ifupdown]
managed=false
Les sources pour openSUSE sont là :
https://ftp.lysator.liu.se/pub/opensuse/source/tumbleweed/repo/oss/src/
Ce qui veulent pas de la vérification peuvent utiliser le paquet networkmanager-branding-upstream comme c'est indiqué dans le spec et dans les descriptions du paquets, donc c'est pas caché comme c'est soufflé par ici.
%description branding-upstream
This package provides the default upstream configuration for
%{_sysconfdir}/NetworkManager/NetworkManager.conf. Specifically,
it is not configured for connection checking against
http://conncheck.opensuse.org. For, the version with connection
checking, install %{name}-branding-openSUSE.
This package provides the default upstream configuration for
%{_sysconfdir}/NetworkManager/NetworkManager.conf. Specifically,
it is not configured for connection checking against
http://conncheck.opensuse.org. For, the version with connection
checking, install %{name}-branding-openSUSE.
Mais ça ressemble fort à ce que Fedora semble faire sans que personne ne crie au loup:
https://download-ib01.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/source/tree/Packages/n/NetworkManager-1.30.0-0.3.fc34.src.rpm
%if %{with connectivity_fedora}
%package config-connectivity-fedora
Summary: NetworkManager config file for connectivity checking via Fedora servers
Group: System Environment/Base
BuildArch: noarch
Provides: NetworkManager-config-connectivity = %{epoch}:%{version}-%{release}
%description config-connectivity-fedora
This adds a NetworkManager configuration file to enable connectivity checking
via Fedora infrastructure.
%endif
%if %{with connectivity_redhat}
%package config-connectivity-redhat
Summary: NetworkManager config file for connectivity checking via Red Hat servers
Group: System Environment/Base
BuildArch: noarch
Provides: NetworkManager-config-connectivity = %{epoch}:%{version}-%{release}
%description config-connectivity-redhat
This adds a NetworkManager configuration file to enable connectivity checking
via Red Hat infrastructure.
%endif
%package config-connectivity-fedora
Summary: NetworkManager config file for connectivity checking via Fedora servers
Group: System Environment/Base
BuildArch: noarch
Provides: NetworkManager-config-connectivity = %{epoch}:%{version}-%{release}
%description config-connectivity-fedora
This adds a NetworkManager configuration file to enable connectivity checking
via Fedora infrastructure.
%endif
%if %{with connectivity_redhat}
%package config-connectivity-redhat
Summary: NetworkManager config file for connectivity checking via Red Hat servers
Group: System Environment/Base
BuildArch: noarch
Provides: NetworkManager-config-connectivity = %{epoch}:%{version}-%{release}
%description config-connectivity-redhat
This adds a NetworkManager configuration file to enable connectivity checking
via Red Hat infrastructure.
%endif
Je regarde ce soir les conf sous fedora, j'en ai une qui traîne sur une machine mais déjà à l'aide de grep:
~/rpmbuild/SRPMS/fedora/NetworkManager-1.30.0-0.3.fc34.src$ grep -A 10 -R '\[connectivity\]' ./
./20-connectivity-fedora.conf:[connectivity]
./20-connectivity-fedora.conf-uri=http://fedoraproject.org/static/hotspot.txt
./20-connectivity-fedora.conf-response=OK
./20-connectivity-fedora.conf-interval=300
--
./20-connectivity-redhat.conf:[connectivity]
./20-connectivity-redhat.conf-uri=http://static.redhat.com/test/rhel-networkmanager.txt
./20-connectivity-redhat.conf-response=OK
./20-connectivity-redhat.conf-interval=300
./20-connectivity-fedora.conf:[connectivity]
./20-connectivity-fedora.conf-uri=http://fedoraproject.org/static/hotspot.txt
./20-connectivity-fedora.conf-response=OK
./20-connectivity-fedora.conf-interval=300
--
./20-connectivity-redhat.conf:[connectivity]
./20-connectivity-redhat.conf-uri=http://static.redhat.com/test/rhel-networkmanager.txt
./20-connectivity-redhat.conf-response=OK
./20-connectivity-redhat.conf-interval=300
Sous opensuse il faut regarder le paquet de NetworkManager-branding-openSUSE comme dit plus haut:
~/rpmbuild/SRPMS/opensuse/NetworkManager-branding-openSUSE-42.1-9.7.src$ grep -A 10 -R '\[connectivity\]' ./
./NetworkManager.conf.in:[connectivity]
./NetworkManager.conf.in-uri=http://conncheck.opensuse.org
./NetworkManager.conf.in-
./NetworkManager.conf.in:[connectivity]
./NetworkManager.conf.in-uri=http://conncheck.opensuse.org
./NetworkManager.conf.in-
Citation :
Personnellement, je n'en fais pas une maladie. La question est aussi de savoir si ceci est conforme au RGPD. Il faut donc que l'utilisateur soit averti de cette "collecte" et puisse opter pour l'éviter.
Quelle collecte? Je n'ai aucune collecte sur ma machine... Si on parle du petit identifiant qui ne sert qu'à compter, c'est comme sous Debian, indiqué mais honnetement je ne sais plus où j'ai vu ça, je suppose lors de l'installation. En tout cas sous fedora aussi et je n'ai rien vu d'indiqué lors de l'installation:
Citation :
Collecte des données à des fins statistiques
Le projet améliore la façon d’avoir des statistiques sur l’utilisation de Fedora. L’objectif est de connaître plus finement le nombre de machines employant Fedora, mais aussi avoir des informations sur la version utilisée, sa variante (comme le spin), etc. Ce qui permet à l’équipe qualité, mais aussi au projet dans son ensemble, de baser ses décisions sur des données factuelles.
Actuellement le tout reposait sur la collecte de données des différents miroirs pour connaître le nombre d’installation en vigueur, ce qui n’était pas fiable à cause du fait que derrière une adresse IP peut se cacher plusieurs installations. Et cette méthode était plutôt lente pour remonter les informations.
Il fallait également trouver un moyen qui garantisse un respect de la vie privée maximale, ce qui n’autorise pas l’utilisation d’un identifiant unique par installation qui pourrait servir à suivre un utilisateur pour d’autres fins. Et, bien évidemment, il faut que le mécanisme fonctionne si l’utilisateur utilise dnf, GNOME Logiciels ou Cockpit, par exemple, pour gérer ses paquets.
Pour éviter cela, tous les sept jours lors d’une requête vers un dépôt, libdnf va envoyer la chaîne libdnf/VERSION (NAME VERSION_ID; []OS[.BASEARCH](VARIANT_ID
) comme user agent et incrémenter un compteur interne. Cela permet d’obtenir les informations suffisantes, à savoir la version de Fedora, la variante utilisée et l’architecture. Le user agent peut être changé via l’option user_agent dans le fichier de configuration de dnf. Cette fonctionnalité est également désactivable avec l’aide de l’option countme configurée à False dans ce même fichier, cette option étant activée par défaut.
Collecte des données à des fins statistiques
Le projet améliore la façon d’avoir des statistiques sur l’utilisation de Fedora. L’objectif est de connaître plus finement le nombre de machines employant Fedora, mais aussi avoir des informations sur la version utilisée, sa variante (comme le spin), etc. Ce qui permet à l’équipe qualité, mais aussi au projet dans son ensemble, de baser ses décisions sur des données factuelles.
Actuellement le tout reposait sur la collecte de données des différents miroirs pour connaître le nombre d’installation en vigueur, ce qui n’était pas fiable à cause du fait que derrière une adresse IP peut se cacher plusieurs installations. Et cette méthode était plutôt lente pour remonter les informations.
Il fallait également trouver un moyen qui garantisse un respect de la vie privée maximale, ce qui n’autorise pas l’utilisation d’un identifiant unique par installation qui pourrait servir à suivre un utilisateur pour d’autres fins. Et, bien évidemment, il faut que le mécanisme fonctionne si l’utilisateur utilise dnf, GNOME Logiciels ou Cockpit, par exemple, pour gérer ses paquets.
Pour éviter cela, tous les sept jours lors d’une requête vers un dépôt, libdnf va envoyer la chaîne libdnf/VERSION (NAME VERSION_ID; []OS[.BASEARCH](VARIANT_ID
) comme user agent et incrémenter un compteur interne. Cela permet d’obtenir les informations suffisantes, à savoir la version de Fedora, la variante utilisée et l’architecture. Le user agent peut être changé via l’option user_agent dans le fichier de configuration de dnf. Cette fonctionnalité est également désactivable avec l’aide de l’option countme configurée à False dans ce même fichier, cette option étant activée par défaut.Mais chez openSUSE c'etait connu:
https://translate.googleusercontent.com/translate_c?depth=1&hl=fr&prev=search&pto=aue&rurl=translate.google.com&sl=en&sp=nmt4&u=https://lwn.net/ml/fedora-devel/CA%2BvoJeWUG3EY7UrS85xJB4pBmPK1mP9NyhfO0YjvTATArMkZwg%40mail.gmail.com/&usg=ALkJrhh08HeDpx-wJLd9bNZn5A97CzHCTQ
https://translate.googleusercontent.com/translate_c?depth=1&hl=fr&prev=search&pto=aue&rurl=translate.google.com&sl=en&sp=nmt4&u=https://en.opensuse.org/openSUSE:Statistics&usg=ALkJrhhkAa1dHa3-luqayY_7lKCgOdIbcw
https://en.opensuse.org/openSUSE:Statistics
Le comptage des adresses IP présente l'inconvénient que de nombreuses machines sont cachées derrière des serveurs proxy ou des routeurs masqués. Afin d'obtenir une vue plus précise sur le nombre d'installations, le projet openSUSE compte à la place des signatures UUID Zypper uniques frappant download.opensuse.org. Cette chaîne UUID est une étiquette aléatoire créée lors d'une installation. Le projet openSUSE n'utilise pas cet identifiant pour suivre autre chose que pour compter. Il n'y a aucun moyen de relier cette chaîne aléatoire à un utilisateur ou à une machine.
L'UUID est stocké dans le fichier / var / lib / zypp / AnonymousUniqueId. Afin de ne pas avoir une installation comptée pour les statistiques, le fichier peut être supprimé ou vidé. Les référentiels en ligne peuvent également être commutés pour utiliser un serveur miroir spécifique au lieu du redirecteur automatique sur download.opensuse.org.
du reste certains s'en plaignent:
https://forums.opensuse.org/showthread.php/535339-Zypper-amp-UUID
Les stats sont là:
https://metrics.opensuse.org/d/osrt_access/osrt-access?orgId=1
seb95 Membre non connecté
-
- Voir le profil du membre seb95
- Inscrit le : 26/08/2007
- Site internet
- Groupes :
Citation :
Au fait, je faisais des recherches et openSUSE est un système très douteux. J'ai remarqué des fonctions d'espionnage et les médias sont muets à ce sujet. Au moins trois caractéristiques étranges:
1. Utilisation active du portail captif (conncheck.opensuse.org)
2. Identifiant unique lors de la connexion de zypper aux serveurs de référentiel
3. Étrange bogue de cache DNS qui reflète les requêtes DNS.
1. Utilisation active du portail captif (conncheck.opensuse.org)
2. Identifiant unique lors de la connexion de zypper aux serveurs de référentiel
3. Étrange bogue de cache DNS qui reflète les requêtes DNS.
C'est de un, un simple mensonge, une fumisterie et de deux un manque de recherche...
Et tellement que c'est dissimulé car chez opensuse on est des espions et des personnes malveillantes:
Édité par seb95 Le 31/01/2021 à 17h59
Visiteur
Preuve des requêtes DNS sur le forum LOR (mais peut-être que la situation a déjà changé).
Comptage des utilisateurs ... Linux se vante qu'il est difficile de compter les utilisateurs car il n'y a pas de télémétrie ...
Sachez admettre vos erreurs et corriger. Je n'ai aucune haine pour SUSE, bien que la recherche soit très suspecte. J'espère que ce ne sont que des bugs et non des intentions malveillantes (USA).
seb95 Membre non connecté
-
- Voir le profil du membre seb95
- Inscrit le : 26/08/2007
- Site internet
- Groupes :
Citation :
À propos, la connexion à conncheck.opensuse.org se produit très souvent. Je dirais même que les serveurs SUSE sont exposés quotidiennement aux attaques DDoS.
Preuve des requêtes DNS sur le forum LOR (mais peut-être que la situation a déjà changé).
Comptage des utilisateurs ... Linux se vante qu'il est difficile de compter les utilisateurs car il n'y a pas de télémétrie ...
Sachez admettre vos erreurs et corriger. Je n'ai aucune haine pour SUSE, bien que la recherche soit très suspecte. J'espère que ce ne sont que des bugs et non des intentions malveillantes (USA).
Preuve des requêtes DNS sur le forum LOR (mais peut-être que la situation a déjà changé).
Comptage des utilisateurs ... Linux se vante qu'il est difficile de compter les utilisateurs car il n'y a pas de télémétrie ...
Sachez admettre vos erreurs et corriger. Je n'ai aucune haine pour SUSE, bien que la recherche soit très suspecte. J'espère que ce ne sont que des bugs et non des intentions malveillantes (USA).
Je mets en doute vos paroles et je vois déjà la guerre Russie / USA dans vos propos.
Ensuite toutes les distributions de gros calibre mettent en place des stats, que ce soit Ubuntu, Fedora, openSUSE, Debian, je sais pas pour Mageia mais Archlinux aussi et j'en passe...
Méfiez vous de votre connection, ce sont les ricains qui ont la main mise dessus et ils font ce qu'ils veulent de ces données...
Visiteur
seb95 :
Méfiez vous de votre connection, ce sont les ricains qui ont la main mise dessus et ils font ce qu'ils veulent de ces données...
Méfiez vous de votre connection, ce sont les ricains qui ont la main mise dessus et ils font ce qu'ils veulent de ces données...
Ce n'est pas loin de la vérité en fait.
Visiteur
(Bonsoir Séb
)Alors, l'oeuf ou la poule, c'est ça le sujet du post?
Ubuntu basé sur Debian, ou Ubuntu qui est le plus gros contributeur à Debian (suffit d'aller voir les commits, au niveau du kernel c'est flagrant).
Magnux77, parlé de MIR, le projet de serveur d'affichage de Canonical, qui avait pour but d'unifier les écrans...Tous le monde se moque de Canonical à l'époque, mais force est de constater, que maintenant, la convergence des écrans est devenu le but de pas mal de société informatique.
Le projet Mate souhaité utilisé MIR, pour éviter de gaché le travail de dev déjà fournis, et justement limité celui à fournir...Unity? Pas si désagréable que ça, et vers la fin, moins consommateur de ressources que Gnome. Unity est encore dans les dépôts Canonical il me semble.
Les récents échanges sur l'incorporation des futures version de Gnome sous Ubuntu, montrent certaines divergences...Il n'est pas dit qu'Unity ne pourrait pas réapparaitre (A titre personnel je préfère d'ailleurs Unity). Pour finir, la majorité des paquets mis a disposition par les entreprises, pour le monde Linux, comporte une version Ubuntu.
Debian, pilier du libre, configurable à souhait, stable, principalement utilisé pour sa version serveur....
Les plus grosses entreprises privées participe à Debian à leurs manières.
https://www.debian.org/partners/
Google, Hewlett Packard.......Moralité, pour survivre, même quand l'on s'appelle Debian, il faut de l'investissement, et l'image de distribution exempte des entreprise privée est fausse...Si Canonical et Google suspendent un jour leurs subventions, il risque d'être difficile au projet Debian de continuer avec ces moyens actuels.
Ubuntu est faite pour ceux qui n'ont pas envie/pas le temps de passer plusieurs heures à tout configurer....Debian à ceux qui souhaitent une base qui évolue peu.
Édité par Visiteur Le 31/01/2021 à 21h46
Visiteur
Encore une fois, j'ai lu attentivement votre message. Et je vois la logique dans les actions de SUSE et Fedora (mais je ne comprends toujours pas le bug DNS).
Je veux juste dire qu'Ubuntu et Debian n'utilisent pas d'UUID lors de la connexion aux référentiels et n'utilisent pas "Captive Portal" à en juger par les journaux Wireshark. Mais je n'ai pas testé Ubuntu 20.04.
Cependant, Ubuntu a activé par défaut les "unattended-upgrades", ainsi que "whoopsie" et "apport". Debian synchronise l'heure sans demander (sudo systemctl disable systemd-timesyncd)
En général, comme l'a dit un forumite russe toxique, Linux est devenu aussi cheval de Troie que Windows (ainsi que Mac et Android).
On peut en dire autant de Firefox et de Chromium.
C'est triste.
L'utilisateur doit comprendre tout cela.
seb95
Installez Wireshark, ajoutez-vous au groupe wireshark, redémarrez votre ordinateur, exécuter le Wireshark et regardez tout par vous-même.
Vous pouvez également installer Fiddler, il peut décrypter https. Mais jusqu'à présent, cela n'est pas nécessaire. Toutes les connexions utilisent http ou DNS UDP simple.
Édité par Visiteur Le 31/01/2021 à 22h41
Papoteur Membre non connecté
-
- Voir le profil du membre Papoteur
- Inscrit le : 03/10/2011
- Groupes :
-
Modérateur
-
Équipe Mageia
-
Administrateur
-
Forgeron
artenox :
3. Étrange bogue de cache DNS qui reflète les requêtes DNS.
Je ne comprends pas de quoi il s'agit. Peux-tu être plus clair (je sais, il y a la question de la traduction qui n'arrange pas) ?
Visiteur
Cela a été observé dans openSUSE Tumbleweed Xfce. Confirmé par au moins deux personnes (moi et un autre membre du forum). De plus, nscd ne peut pas être supprimé car il reviendra après la mise à niveau (update). Le service systemd doit être désactivé sudo systemctl disable nscd.
Si vous incluez la paranoïa et réfléchissez aux raisons pour lesquelles la NSA a dû introduire un tel bogue, nous pouvons supposer ce qui suit: une augmentation du nombre de requêtes DNS pour les domaines fréquemment visités. Cela sera suivi par le fournisseur (américain).
Édité par Visiteur Le 01/02/2021 à 00h19
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie