Vous n'êtes pas identifié(e).
Pages : 1
Le démarrage est plus rapide qu'avec l'init Système V.
Pourquoi ?
Et J'en conclus que tu as testé les deux systemes d'init sur une même distribution ? Comment as tu fait ?
Sinon installe samba sous Buster, et ne connecte aucun réseau, et tu nous dira combien de temps ça met au démarrage ?
Sinon, je plussoie ce que raconte Beta-Pictoris sur les units systemd. C'est facile d'usage. J'aime.
Alors le problème viens des développeurs debian ?
Par exemple, quand on installe samba, ça met un target systemd du genre "network-online".
Et si ya pas de connexion réseau, alors ça attend indéfiniment une connexion réseau au boot.
Résultat obligé de désactiver network-online.target et networking.service. Et d'ajouter dans /etc/network/if-up.d/ un fichier pour lancer le service (service ou daemon ? avec systemd on ne sait plus à quoi on a affaire) le "service" nmbd quand une connexion réseau est détectée.
Sans vouloir véxer personne, j'ai l'impression que systemd est une windowisation de linux, car ça introduit la notion de "service" en remplacement des bons vieux daemons.
Bref, maintenant, on fait comme avec Windows, on est contraint de désactiver les services indésirables et même plus, aussi les targets indésirables... Mais bon, il semblerait qu'on ai plus de controle que sous windows, mais pour combien de temps encore ?
Sector Sizes: 512 bytes logical, 4096 bytes physical
Le disque ne serait'il pas en plus mal formaté ?
Je suis pas un expert mais les secteurs logiques ne devraient'ils pas être au minimum de la taille des secteurs physiques, et si ils sont plus grands, être un multiple de la taille des secteurs physiques ?
je l'ai rendu exécutable:
Et ça semble fonctionner, mais je suis pas sûr que ce soit la meilleure méthode.
suivit d'un reboot.
Mais je ne sais pas quelles sont les implications de ces changements au niveau de la sécurité des communication samba sur le réseau...
Quelle est ta version de gcc ?
La 8.3, celle de Buster.
Aussi par curiosité comment lances-tu la compil du kernel avec les options, tu modifie les makefiles ou tu ajoute les args
J'ai modifé le makefile à la racine du dossier du noyau. C'est un kernel 5.8.4, J'ai remplacé l'option "-O2" par "-O3 -march=native -mtune=native".
Makefile d'origine, la deuxième ligne:
Makefile modifié, seulement la deuxième ligne, à la place de -O2:
Pour conclure appliquer des optimisation c'est pas "yes je vais gagner beaucoup de perf et c'est sans conséquences...". Il y a des impacts en fonction du types d'optimisation à prendre en compte
OK, merci pour toutes ces infos. Du coup je me dit qu'un -O3 est peut-être pas une bonne idée, mais les optimisations basées sur les instructions spécifiques à un processeur ?
En fait, je voit pas trop l'intérêt de faire des processeurs avec des instructions spécifiques qui sont sensées accélérer les logiciels, si ni le noyau, ni les logiciels, ne les utilisent. Pour moi, c'est au moins le noyau qui doit les utiliser, les logiciels eux font en général des appels systèmes au noyau et pour le reste, c'est mieux qu'ils les utilisent, mais pour ça il faut avoir leur code source et qu'il soit compilable sur la machine.
J'ai aussi essayé de compiler gnu icecat avec les mêmes optimisations, résultat: j'ai une librairie .so de 2 Giga, et des erreurs qui s'affichent dans le terminal, mais icecat semble fonctionner quand même. En tout cas, ces erreurs et cet librairie de 2 Giga, ça ne me met pas en confiance pour utiliser le logiciel.
Par contre pour le noyau, compiler avec les optimisations ne m'a jamais posé de problèmes sauf une fois avec un vieux kernel: un warning dans le pilote AMDGPU sur la longueur d'une chaine de carractère, j'ai corrigé le code source, et plus de warning. Le warning n'apparaissait qu'avec -O3, pas en -O2.
et
Et voilà le résultat pour mon processeur apollo lake (nom de code goldmont):
-march: skylake
-mtune: generic
Malgrès ça, le noyau semble fonctionner. Apparemment ma version de gcc ne gère pas encore les goldmont. Mais sur le site web de gcc il y a de grosses différences entre un skylake et un goldmont:
‘skylake’
Intel Skylake CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AVX2, AES, PCLMUL, FSGSBASE, RDRND, FMA, BMI, BMI2, F16C, RDSEED, ADCX, PREFETCHW, CLFLUSHOPT, XSAVEC and XSAVES instruction set support.
et:
‘goldmont’
Intel Goldmont CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PCLMUL, RDRND, XSAVE, XSAVEOPT and FSGSBASE instruction set support.
Donc, je me demande si il y a un moyen de donner à GCC les options goldmont sans utiliser les -march et -mtune ? EDIT: je viens de lire sur la page des option gcc qu'il fallait passer les options de la façon suivante: -m suivit du nom de l'instruction par exemple: "-mmmx -mmovbe -msse".
Mais je me demande aussi si le -march=native et -mtune=native fonctionnent correctement ?
Sinon, comme j'ai un autre pc à optimiser, je me demande où sur internet trouver la liste des instructions supportées par un microprocesseur ?
Libre : le consentement ne doit pas être contraint ni influencé. La personne doit se voir offrir un choix réel, sans avoir à subir de conséquences négatives en cas de refus.
Ok, mais les commerciaux/developpeurs de google ont fait un système web tellement pénible pour désactiver les options, que je suis contraint de cliquer "j'accepte", malgrè que je n'accepte pas.
On ne vois pas ça sur d'autre sites où il suffit de cliquer "personnaliser", puis "refuser tout". C'est réglé en deux clicks.
Pourquoi veux-tu donner un autre nom que root à l'administrateur du système ?
Mon idée était que les pirates ignorent le nom d'utilisateur de l'administrateur, mais si il suffit de taper "su -" pour passer admin, alors ça ne sert à rien.
System Requirements
Before attempting to install the AMD Catalyst™ Proprietary Linux Graphics Driver, the following software must be installed:
Xorg/Xserver 7.4 and above (up to 1.17)
Linux kernel 2.6 or above (up to 3.19)
glibc version 2.2 or 2.3
POSIX Shared Memory (/dev/shm) support is required for 3D applications
Donc la version de Xorg et du noyau de Buster sont peut-être trop récentes pour les pilotes propriétaires.
Si ça fonctionnait avec Jessie, c'est peut-être parceque le noyau de Jessie était un 3.16, donc inférieur à 3.19, si je me souvient bien ?
As tu essayé les pilotes Mesa ?
Pages : 1