Psychofox a écrit 10851 commentaires

Pour illustrer (à part les fameuses RTT j'ai inventé les acronymes parce que je n'en connais pas les équivalents):

Un français te dira qu'il a du prendre un RTT pour aller au bureau GRUPNIC de la SCRUD locale pour aller chercher le SPLONC afin que sa demande de RSLTTLG soit prise en compte par la AADRMUSV.

Un suisse te dira qu'il a pris congé pour aller au contrôle des habitants de sa ville pour récupérer une attestation de domicile nécessaire à sa demande de subside d'assurance maladie.

Quand je discute avec mes proches qui sont restés en France le décalage me parait en tout cas énorme et je dois les reprendre souvent pour comprendre de quoi on parle. Mais je pense qu'un Français qui est plus au courant des ceux-ci n'y fait pas forcément attention. C'est un peu lié au fait que les gouvernements français n'ont eu de cesse de créer de nouvelles institutions/organismes/procédures aux noms à rallonge et toujours plus pompeux.

Pour vivre à l'étranger ce n'est pas une exclusivité française d'utiliser des acronymes, mais d'en abuser à ce point et de les mentionner systématiquement sans avoir au préalable énoncé la définition à son interlocuteur au moins une fois oui.

D'après le contexte je dirais qu'il parle de Pull Request / Merge Request mais c'est vrai que c'est insupportable cette manie française d'utiliser des acronymes à l'excès.

Je ne crois pas que le verbe espionner soit tout à fait à propos.

Il y'a quand même beaucoup de mafias derrière les ransomwares qui jouent le jeu. Pas par éthique évidemment mais parce que c'est économiquement plus avantageux pour eux.

Paraitrait même que leurs hotline sont tout aussi professionnelles (ou pas!) que celles de la plupart des grandes sociétés fournissant des services ou bien "légaux".

Ouais comme si ce journal était représentatif de la population de linuxfr quoi.

D'ailleurs ce qui est marrant c'est que si on regarde les stats de ce sujet on note que Jérôme Martinez est le deuxième posteur et j'imagine que parmis ceux qui ont réagis à sa réaction certain comme moi n'avaient jamais entendu parler de t411 ni sont des téléchargeur/partageurs de contenu multimédia sous le manteau:

    $ w3m -dump https://linuxfr.org/users/deuzene/journaux/hs-bookmark-deplace-bronsonisation-de-t411 | grep -o -P '(?<=Posté par ).*(?= le)' | sed -e 's/(page perso)//' | sort | uniq -c | sort -nr
      9 EauFroide
      6 Zenitram 
      6 Arcaik 
      4 Diagonale de Cantor 
      3 reynum
      3 Ely
      2 xcomcmdr
      2 Wawet76
      2 tiot 
      2 Moonz
      2 maclag
      2 groumly
      2 Anthony Jaguenaud
      1 titideparis
      1 Tanouky
      1 Sufflope 
      1 PsychoFox
      1 Olivier
      1 nimch
      1 neilux
      1 M5oul 
      1 Larry Cow
      1 kna
      1 Guillaume Denry 
      1 gle
      1 flagos
      1 Ecran Plat 
      1 deuzene 
      1 binbin

(le one liner pourrait très probablement être réduit en 1 seule commande perl/python/awk/sed/ruby/whatever mais c'est ce qui m'est venu par la tête sur le moment et je suis loin d'être un dev alors rouillé, toussa)

Tu notes quoi exactement ?

Une machine de classe serveur passe une batterie de test à chaque reboot. C'est plutôt sain au final et ça n'a pas forcément grand chose à voir avec la qualité du bios/firmware.

Mais bon on est en 2017, ce n'est pas vraiment un problème (virtualisation, containers, toussa).

Ce n'est pas parce qu'il faut rebooter chaque mois qu'on doit rebooter à chaque fois qu'on applique les patchs. Pour ma part je lance un apt upgrade chaque jour. Si par exemple c'est sudo, openssh, mon navigateur ou client mail qui est patché pour ne citer que quelques exemples je n'ai aucune raison de redémarrer mon pc.

Si j'ai connu. Ce n'est pas parce que ça s'est un peu amélioré que ça reste toujours pertinent.

Par ailleurs :

checkrestart

  $ sudo checkrestart
  Found 12 processes using old versions of upgraded files
  (5 distinct programs)
  (5 distinct packages)

  Of these, 3 seem to contain init scripts which can be used to restart them:
  The following packages seem to have init scripts that could be used
  to restart them:
  nginx-extras:
      20534   /usr/sbin/nginx
      20533   /usr/sbin/nginx
      20532   /usr/sbin/nginx
      19113   /usr/sbin/nginx
  openssh-server:
      3124    /usr/sbin/sshd
      22964   /usr/sbin/sshd
      25724   /usr/sbin/sshd
      22953   /usr/sbin/sshd
      25719   /usr/sbin/sshd
  exim4-daemon-light:
      3538    /usr/sbin/exim4

  These are the init scripts:
  service nginx restart
  service ssh restart
  service exim4 restart

  These processes do not seem to have an associated init script to restart them:
  python2.7-minimal:
      2548    /usr/bin/python2.7
  openjdk-7-jre-headless:amd64:
      4348    /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java

needrestart :

$ needrestart 
Scanning processes...                                                                                                                                                                                                                              
Your outdated processes:
akonadi_akonote[2643], akonadi_archive[2644], akonadi_birthda[2645], akonadi_contact[2647], akonadi_control[2459], akonadi_followu[2648], akonadi_ical_re[2649], akonadi_imap_re[2650], akonadi_indexin[2651], akonadi_maildir[2653], akonadi_maildis[2654], akonadi_mailfil[2657], akonadi_migrati[2658], akonadi_newmail[2660], akonadi_notes_a[2661], akonadi_sendlat[2662], akonadiserver[2467], baloo_file[2347], evolution[3708], evolution-addre[2924, 2907], evolution-alarm[2867], evolution-calen[2887, 12588, 2879, 2910, 2932], evolution-sourc[9829], file.so[2771], kaccess[2314], kactivitymanage[2411], kdeconnectd[2778], kded5[2306], kdeinit5[2302], KeeWeb[5458], kglobalaccel5[2338], klauncher[2303], knotes[2376], korgac[2461], krdc[7013, 5324], krunner[2348], kscreen_backend[2343], ksmserver[2327], kuiserver[2775], kwalletd5[2215], kwin_x11[2344], org_kde_powerde[2364], plasmashell[2350], pulseaudio[2368], sky[7273], systemd[2196], xembedsniproxy[2353], yakuake[2456]

et

[yum-utils needs-restarting](http://man7.org/linux/man-pages/man1/needs-restarting.1.html) :

`$ sudo needs-restarting
458 : /usr/lib/systemd/systemd-journald 
668 : /usr/bin/vmtoolsd 
748 : /usr/sbin/NetworkManager --no-daemon 
705 : login -- root      
20350 : /usr/sbin/zabbix_agentd: listener #2 [waiting for connection]
129282 : /usr/sbin/crond -n 
20352 : /usr/sbin/zabbix_agentd: active checks #1 [idle 1 sec]    
20351 : /usr/sbin/zabbix_agentd: listener #3 [waiting for connection]
19974 : /usr/sbin/chronyd 
697 : /usr/sbin/atd -f 
112099 : /usr/bin/ruby /usr/bin/puppet agent help 
1 : /usr/lib/systemd/systemd --system --deserialize 20 
704 : /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid 
19707 : /usr/sbin/sshd -D 
129183 : -bash 
129182 : sshd: admtle@pts/0   
1036 : /usr/bin/ruby /usr/bin/puppet agent --no-daemonize 
1035 : /usr/sbin/rsyslogd -n 
674 : /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation 
672 : /usr/lib/polkit-1/polkitd --no-debug 
673 : /usr/lib/systemd/systemd-logind 
10887 : -bash 
20347 : /usr/sbin/zabbix_agentd -c /etc/zabbix/zabbix_agentd.conf 
20348 : /usr/sbin/zabbix_agentd: collector [idle 1 sec]           
20349 : /usr/sbin/zabbix_agentd: listener #1 [waiting for connection]
129179 : sshd: admtle [priv]  
20308 : /sbin/auditd -n 
1039 : /usr/bin/python -Es /usr/sbin/tuned -l -P 
849 : /sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-helper -pf /var/run/dhclient-ens160.pid -lf /var/lib/NetworkManager/dhclient-ea74cf24-c2a2-ecee-3747-a2d76d46f93b-ens160.lease -cf /var/lib/NetworkManager/dhclient-ens160.conf ens160 
476 : /usr/lib/systemd/systemd-udevd 
474 : /usr/sbin/lvmetad -f 

Et enfin needs-restart.pl

In order to complete the installation of glibc-2.18-11.fc20.x86_64,
you should restart the following services:

    - accounts-daemon.service - Accounts Service   
    - console-kit-daemon.service - Console Manager
    - udisks2.service - Disk Manager
    - auditd.service - Security Auditing Service
    - dbus.service - D-Bus System Message Bus
    - rtkit-daemon.service - RealtimeKit Scheduling Policy Service
    - upower.service - Daemon for power management
    - colord.service - Manage, Install and Generate Color Profiles
    - firewalld.service - firewalld - dynamic firewall daemon
    - polkit.service - Authorization Manager
    - rsyslog.service - System Logging Service 
    - NetworkManager.service - Network Manager   
    - libvirtd.service - Virtualization daemon
    - gdm.service - GNOME Display Manager

In order to complete the installation of glibc-2.18-11.fc20.x86_64,
you should tell the following users to log out and log in:

    - session-1.scope - Session 1 of user rjones`

Bref il y'a des choses possibles à faire.

Idem sur des applis de backup qui du coup impose l'usage des snapshots (shadow copy).

En théorie la méthode traditionnelle sous Linux est belle mais en pratique il y a des soucis.

Déjà, pour que la mise à jour se fasse, il faut au minimum arrêter le logiciel concerné pour le relancer. En cas de mise à jour de MS Office dans Windows (qui passe par Windows Update), il faut relancer MS Office. Est-ce que l'utilisateur y pense ? Pas vraiment. Et tu ne peux pas le forcer à le faire.

Les mises à jour de Windows Update sont en général : Office, le cœur de Windows, Explorer / Edge, la BDD antivirus et des pilotes. Je crois que la BDD antivirus est le seul cas où un redémarrage n'est pas nécessaire et d'ailleurs, c'est la politique de MS sur le sujet.

Ensuite, une mise à jour à chaud cela pose des problèmes de cohérence entre les binaires des applications et des bibliothèques. Cela peut conduire à des bogues difficiles à identifier, prévoir ou éviter. Quand cela ne conduit pas à un crash de la machine.

Dans le cas des applis les bibliothèques sont chargées au démarrage de l'appli et donc ne changent en mémoire que si l'appli est redémarrée. Et pour la gestion du redémarrage tous les OS modernes fournissent des mécanismes de notifications. C'est donc faisable.

Sous debian on a l'outil checkrestart qui permet de lister les process qui nécessitent un redémarrage suite à une upgrade. Un utilisateur chevronné sait relativement facilement quelles applis doivent être redémarrées, parfois c'est tout le bureau, pour d'autre autant redémarrer la machine. Mais la décision pourrait être facilitées en jouant sur une catégorisation des composants (paquets dont dépendent des composants systèmes, un bureau dans son ensemble (exemple tout ce qui touche à des composants gnome/kde), ou seulement des applis isolées.

Crash de la machine ? Cas hyper extrême et que je n'ai pas souvenir d'avoir vu, en tout cas dans le monde debian/BSD. Il n'y a que les composants très bas niveau qui peuvent avoir une influence importante.

Par exemple, il y a pas si longtemps, chez Fedora (https://forums.fedora-fr.org/viewtopic.php?id=65807), un crash du serveur X survenait lors d'une maj de systemd (et non, systemd n'est pas le seul coupable, X11 l'était aussi). Résultat, si tu faisais ta mise à jour via un émulateur de terminal graphique, ta session plantait, ta maj avec et tu avais un système dans un état bien pénible à récupérer.

Je ne crois pas que Fedora, une distribution qui a pour vocation d'implémenter les technos les plus récentes, soit un cas d'école. C'est plus un prototype qu'un OS.

Ouais faut pas oublier tous ceux qui se font avoir quand leur concept de sauvegarde est un share sur leur NAS 24/24 sur leur machine et qui se fait cryptolocker avec le reste.

Où qui se font cryptoplocker la seule et unique clé leur permettant de déchiffrer leurs sauvegardes.

Autant je préfère la méthode "linux" (on remplace des paquets par une version plus récente plutôt que passer des patches) et je trouve débile qu'on demande aussi souvent de redémarrer sous windows là où à priori un redémarrage des services concernés devrait suffir, autant sous win 7 et 10 je n'ai plus vu de démarrage vraiment long (à part lors de la première installation). Les seuls trucs parfois longuet c'est justement à l'arrêt pour l'application des patches mais bon pour l'arrêt du pc on s'en branle que ce soit long vu qu'on ne l'utilise plus (et en plus il nous laisse choisir si on veut le faire ou pas).

Ouais enfin quelque soit l'intérêt du contenu c'est limite insultant de se cacher derrière des excuses totalement bidons quand on est conscient de ne pas faire preuve d'un grand respect pour son interlocuteur.

Un peu comme les signes de la mains en faux remerciements d'un conducteur qui te coupe sciemment la priorité.

Deux fois en combien d'années et ça touchaient combien d'applis ?

Comme tu le dis les retour arrières restent possible il vaut mieux gérer 2 - 3 exceptions, savoir les isoler dans un vlan si besoin le temps que le fournisseur produit une version patchée qui fonctionne avec les maj que de ne faire passer aucune mise à jour de sécurité par peur nébuleuse d'un éventuel bug une fois de temps en temps.

Tu peux préciser ce que tu entends par "dépendant" ?

tu regardes la doc et tu t'aperçois qu'il faut juste mettre les sources de mpfr, mpc, gmp et isl dans des répertoires du même nom avant de compiler.

Mais c'est pas comme si c'était pas marqué en toutes lettres dans le prerequisites.html du tarball de gcc.

Vos utilisateurs sont-ils plus tolérants que les miens ? (J'en doute)

Réponse D: Ça fait belle lurette que je n'ai plus vu de vrais serveurs de fichier avec nfs/cifs. Dans les 4 dernières boites pour lesquelles j'ai bossé on utilisait/utilise des solutions de stockage proprio style netapp/datadomain.

Tes exemples ne sont pas du tout convaincants.

L'histoire des codec vidéos, c'est pipotron, je n'ai jamais vu un format vidéo se généraliser aussi vite. C'est en général au contraire un des domaines où l'adoption a souvent pas mal d'inertie notemment à cause des encodeurs/décodeurs hardware qui mettent plus de temps à arriver que les solutions software.

L'histoire des mails est bien gentillette mais il y'a une tétrachiée de clients mails disponibles dans les repos donc là encore, c'est idiot.

Pour les jeux, la debian stable n'est pas la plus pertinente mais ce n'est pas vraiment ce que j'appelle une utilisation desktop. Le gaming sur pc c'est un truc marginal et encore plus sous linux.

La version de dans 2-3 ans pardi.

Mais 2 ans c'est pas énorme au final.

J'ajouterai que ton problème n'a rien de spécifique à debian et s'efforcer à toujours utiliser ce qui est le plus bleeding edge possible, c'est un peu une forme d'asociabilité. Tu fermes la porte à la plupart des gens qui utilisent du BSD, et même la plupart des distros.

Si on check le nombre de distros packageant gcc > 7 dans leur dernière release on se rend compte qu'il n'y a pas beaucoup de candidates et encore moins de distributions "majeures": en gros Fedora, Arch et Gentoo. C'est peu.

Honnêtement, qu'est-ce qui est compliqué à utiliser un package des backports ?

Saut que au final tu es de très mauvaise foi car on parle de 2ans entre chaque release debian et pas 1000ans.

Les gens qui utilisent debian stable sont conscients de ça, donc je serais tenté de dire que ce n'est pas vraiment ton problème.

On ne peut pas dire qu'utiliser les backports soient une grosse emmerde c'est relativement simple d'autant plus si la seule contrainte est la version de gcc.